[#GDS-672] Coexisting issue with BlazeDS - Granite Data Services

GraniteDS

Coexisting issue with BlazeDS

Created: 07/Apr/10 11:53 PM Updated: 11/May/10 05:43 PM

Component/s:

AMF3 (de)serialization

Affects Version/s:

2.1.0_GA

Fix Version/s:

None

Description

« Hide

We're planning to port a big application from Spring-BlazeDS-Cairngorm to Spring-GraniteDS-Tide. The idea was to move the functionalities gradually, so that for a certain period of time the two frameworks should coexist in the same webapp. The problem arises with the flex.messaging package in the granite.jar (core) whose classes conflict with the ones contained in the blazeds implementation. Would it be possible to rename that package to something like flex_granite.messaging instead of flex.messaging?

Sort Order:

[ Permalink | « Hide ]

William Draï added a comment - 08/Apr/10 02:40 PM

What conflict do you get ?
The flex.* classes in the GDS jar should be identical to those in BlazeDS.
You can maybe try to remove the flex.* classes from the GDS jar.

[ Permalink | « Hide ]

Luciano Blasetti added a comment - 08/Apr/10 04:43 PM

Unfortunately there are quite a number of differences (pls refer to the last stable blazeds distribution http://flexorg.wip3.adobe.com/blazeds/3.0.x/stable/1755/blazeds-src-3.0.1.1755.zip). Just as an example (but there are a lot), the class flex.messaging.message.CommandMessage in GDS has the method isSecurityOperation that doesn't exist in the corresponding blazeds implementation while in blazeds there are an additional constructor public CommandMessage(int operation) as well as the method public Message getSmallMessage() that don't exist in GDS.

:(

[ Permalink | « Hide ]

William Draï added a comment - 08/Apr/10 05:37 PM

I guess your best option is to try to compile GDS with the flex.* classes from BlazeDS and just add the missing methods used by GraniteDS.
Then remove the flex.* classes from the GraniteDS jar.

[ Permalink | « Hide ]

gbondy added a comment - 10/May/10 10:06 PM

Luciano, were you able to resolve this issue. I am doing something very similar and I ran into the same problem. This is the stack trace I am seeing:

org.granite.messaging.webapp.AMFMessageFilter.doFilter(AMFMessageFilter.java:146): AMF message error
javax.servlet.ServletException: Servlet execution threw an exception
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:313)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.granite.messaging.webapp.AMFMessageFilter.doFilter(AMFMessageFilter.java:117)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NoSuchMethodError: flex.messaging.messages.CommandMessage.isSecurityOperation()Z
at org.granite.messaging.amf.process.AMF3MessageProcessor.processCommandMessage(AMF3MessageProcessor.java:84)
at org.granite.messaging.amf.process.AMF3MessageProcessor.process(AMF3MessageProcessor.java:61)
at org.granite.messaging.amf.process.AMF0MessageProcessor.process(AMF0MessageProcessor.java:78)
at org.granite.messaging.webapp.AMFMessageServlet.doPost(AMFMessageServlet.java:59)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)

I was thinking about leaving the GraniteDS core jar as is and remove the duplicate classes from the BlazeDS jar. If you tried this and it worked, I would be interested to hear about it.

[ Show » ]

gbondy added a comment - 10/May/10 10:06 PM Luciano, were you able to resolve this issue. I am doing something very similar and I ran into the same problem. This is the stack trace I am seeing: org.granite.messaging.webapp.AMFMessageFilter.doFilter(AMFMessageFilter.java:146): AMF message error javax.servlet.ServletException: Servlet execution threw an exception at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:313) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.granite.messaging.webapp.AMFMessageFilter.doFilter(AMFMessageFilter.java:117) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.NoSuchMethodError: flex.messaging.messages.CommandMessage.isSecurityOperation()Z at org.granite.messaging.amf.process.AMF3MessageProcessor.processCommandMessage(AMF3MessageProcessor.java:84) at org.granite.messaging.amf.process.AMF3MessageProcessor.process(AMF3MessageProcessor.java:61) at org.granite.messaging.amf.process.AMF0MessageProcessor.process(AMF0MessageProcessor.java:78) at org.granite.messaging.webapp.AMFMessageServlet.doPost(AMFMessageServlet.java:59) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) I was thinking about leaving the GraniteDS core jar as is and remove the duplicate classes from the BlazeDS jar. If you tried this and it worked, I would be interested to hear about it.

[ Permalink | « Hide ]

Luciano Blasetti added a comment - 11/May/10 05:43 PM

Hi gbondy,
actually I don't think it's a safe solution to alter the classes in the jars. There are some methods in the BlazeDs implementations that are not implemented in GDS and vice-versa. Furthermore even if a method exists in both implementations, it should be checked if they perform the same logic. I think that such kind of checks and modifications should be done by the creators od GDS, since they are familiar with the underlying technologies and know well the implications and drawbacks that could occur modifying that libraries. I would suggest you to vote this issue, hoping that some expert in the GDS team will help us :)