[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2592) Seam 2.0.1 GA patched to support BEA WebLogic Server 10.x with EJB3 support

Seam 2.0.1 GA patched to support BEA WebLogic Server 10.x with EJB3 support --------------------------------------------------------------------------- Key: JBSEAM-2592 URL: http://jira.jboss.com/jira/browse/JBSEAM-2592 Project: JBoss Seam Issue Type: Patch Components: Platform interoperability Affects Versions: 2.0.1.GA Environment: BEA WebLogic Server 10.0 MP1 Reporter: lauerc Assigned To: Pete Muir Priority: Blocker Fix For: 2.1.0.GA Attachments: jboss-seam-2.0.1.GA-patches.zip Hi folks, I'm currently in working on the meanwhile old WebLogic compatibility issue, which is a show stopper for products which are forced to run in an BEA environment and rely on EJB features. The current situation is that the EJB3 compiler of WebLogic Server 10.x doesn't deploy JBoss Seam applications, because it doesn't support EJB3 interfaces containing methods with varars (Object...) definitions. This is obviously a bug, but it's known by the vendor of WebLogic for more than a year and meanwhile I don't believe anymore that is going to be fixed in short. This situation is critical for many projects, since this is a killer arguments against JBoss Seam. Since it is more or less unknown what more supprises this mix brings, I started an affort to patch the current JBoss Seam version (2.0.1.GA) to work wis BEA WebLogic 10.0 MP1. First of all I've replaced the varargs in interfaces to get one step beyond the known EJB3 compiler problem. This was quite easy because only one single EJB interface is affected: org.jboss.seam.async.Dispatcher I've replaced the varargs definitions (Object...) by Object[], which is what the compiler creates anyway from it. For reasons of convenience, I've also created an method which completely reduces the method to the non variable parts. Here's an example: public T scheduleTimedEvent(String type, S schedule, Object... parameters); was turned into: public T scheduleTimedEvent(String type, S schedule); public T scheduleTimedEvent(String type, S schedule, Object[] parameters); Maybe this is not as elegant as the varags solution, but it's a pragmatic way to suit our needs as I don't think BEA will fix the related problem in short. The next problem I stumbled into was a classloading problem related to another problem in BEA WebLogic 10.0 MP1. The server only works properly with it's own jsf implementation which is not deployed by default. It is packed into a war archive located at wlserver_10.0/common/deployable-libraries/jsf-1.2.war I've tried to deploy this archive which failed, so I unpacked it and placed the included jars into the 'lib' folder below my weblogic domain root. After that I found out, that one jboss jar, which is needed to run the application under other application servers was missing in the seam distribution. I placed this file (concurrent.jar) into the folder lib below by test application subproject (examples/jee5/lib). After some more deployment descriptor related changes, which I will not describe in detail, the application seems to work at first. Unfortunately I detected runtime failures when playing around with the booking application. From time to time the application failed with an InvocationTargetException. After hours of code analyzing and debugging, I found out that the problem has to be a side effect of different EJB lifecycle implementation in WebLogic Server compared to JBoss AS (I don't know which behaviour is wrong or right, and I won't judge it here). Actually the method postConstruct(...) of class org.jboss.seam.intercept.SessionBeanInterceptor seems to rule the initialization of this interceptor. This method seems to be called before any call of aroundInvoke at JBoss AS. On WebLogic Server this is different. As a result of this sometimes the injection field or method invoking for a specific object is executed using the reflection fields and methods of different component classes. To fix this problem, I've copied the initialization calls from method post construct into the method aroundInvoke to make sure that it is called prior to the actual invocation. After this change the booking demo seems to work perfectly. I've packed all source changes and the missing jar file into one zip archive and will post it into this thread. To use this, simply extract it below the exploded distro archive and rebuild first seam and then the jee5/booking demo. Best regards, Christian