]
Jay Balunas commented on JBSEAM-2592:
-------------------------------------
Could you post this on
forums with more information on steps you
followed, when you get the error, and any other information. I did see an error similar
to this while investigating, but when all changes were completed I did not see it.
Thanks,
Jay
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: Seam
Issue Type: Patch
Components: Platform interoperability
Affects Versions: 2.0.1.GA
Environment: BEA WebLogic Server 10.0 MP1
Reporter: lauerc
Assigned To: Jay Balunas
Priority: Minor
Fix For: 2.1.0.BETA1, 2.0.2.GA
Attachments: examples-patches.zip, jboss-seam-2.0.1.GA-patches.zip,
SessionBeanInterceptor.java.patch
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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: