Complexity: High Date of First Response: 2009-12-04 15:44:39 project_key: SOA What we want to achieve? We need a Seam application (we use dvdstore from Seam examples) to be able to create a new instance of a jBPM process. This process instance should be able to call a deployed ESB service. We want to preserve other Seam functionality, especially the possibility to use jPDL page flow definitions. How do we want to achieve it? There is no strict way defined. We tried org.jboss.soa.esb.services.jbpm.actionhandlers.EsbNotifier in the process definition. What causes the problem? If there is a separate jbpm-jpdl.jar in the Seam application's EAR, the application can work, but it cannot call an ESB service due to class loading issues (SOA-1234). So the jBPM must be removed from Seam app. to run on SOA-P. This is no problem since process definitions can be deployed separately on the server using jBPM console. What causes a trouble is jPDL page flow definition. It cannot be deployed on the server without Seam libraries (there are unsatisfied dependencies). Possible solutions (not tested): 1) Remove jBPM from the server side. 2) Install Seam libraries on the server. We need a fix or a workaround because this feature must be in 5.0.0 GA.
Link: Added: This issue depends SOA-1234
To get a better picture of the situation, see the attached dvdstore-no-jbpm.zip. To reproduce the problem: 1) deploy helloworld 2) deploy par using jbpm console 3) deploy datasource 4) deploy ear 5) go to server:8080/seam-dvdstore 6) login as user1:password 7) Click on Shop -> The Bourne Id -> Add To Cart -> Checkout -> Purchase 8) see the exception
Attachment: Added: dvdstore-no-jbpm.zip
There really is no good reason to not remember to set the components for an issue, especially when the title of the issue makes them fairly intuitive!
Sorry, but it does not look like this is possible without major changes. Every time I make progress I uncover something else that needs to be addressed. I did manage to get the dvdstore running but, in the process, broke the jbpm-console (seam related). Therefore I think the best course of action is to revert to a scoped ear and use ServiceInvoker directly from a jBPM action. So far the steps have been as follows Within deploy/jbossesb.esb - remove jackrabbit and lucene-core jars (Removes JCR message store) Within jboss-seam-dvdstore.ear - remove jboss-seam.jar, lib/hibernate-commons-annotations.jar, lib/jboss-el.jar, lib/lucene-core.jar, lib/hibernate-search.jar Then add deploy/soa-seam-int.sar (as attached) The sar attempts to address two issues with the seam deployment - setting up the correct ProxyFactoryClassLoaderProvider so that it pulls in from the context classloader - setting up jBPM to do the same (<string name="jbpm.class.loader" value="context" />) Unfortunately these then cause the jbpm-console to break with the following java.lang.NullPointerException org.jboss.seam.jsf.SeamViewHandler.calculateLocale(SeamViewHandler.java:55) com.sun.facelets.FaceletViewHandler.calculateLocale(FaceletViewHandler.java:790) javax.faces.application.ViewHandlerWrapper.calculateLocale(ViewHandlerWrapper.java:102) com.sun.faces.application.ViewHandlerImpl.createView(ViewHandlerImpl.java:372) org.jboss.seam.jsf.SeamViewHandler.createView(SeamViewHandler.java:68) com.sun.facelets.FaceletViewHandler.createView(FaceletViewHandler.java:803) So there is some corruption happening as a result of these settings. I am now of the opinion that we need to spend some serious time looking at this, and provide a tighter integration for SOA. I suspect the only way forward for now is, as stated above, to revert to a scoped ear file and directly use ServiceInvoker. No ESB class referring to jBPM should be used, including EsbNotifier, EsbActionHandler and JBpmObjectMapper. For scoping the ear I changes jboss-app.xml to <loader-repository> seam.jboss.org:loader=seam-dvd <loader-repository-config> java2ParentDelegation=false </loader-repository-config> </loader-repository>
Sorry Martin, this is as far as I can go for now.
sar file
Attachment: Added: soa-seam-int.sar.kev
MBean
Attachment: Added: ProxyFactoryClassLoaderProviderInit.java
Attachment: Added: ProxyFactoryClassLoaderProviderInitMBean.java
Blocked Tests: Added: SEAM testing is blocked Affects Testing: Added: [Blocks Testing]
I am providing a deployable ear given Kevin's suggestion. Here's what I did: 1) Started with SOA-P 5 CR2's seam example dvdstore AS IS. (ant archive creates jboss-seam-dvdstore.ear) Leave jbpm-jpdl.jar in there! 2) Created my own ActionHandler that calls ServiceInvoker. Okay, this is not *completely* true. What I did was I started with EsbNotifier that comes with the ESB and I broke it out (along with it's handful of dependent classes to support variable mappings) and put it into it's own package. This does what Kev suggested without depending on ESB/jBPM code, but additionally supports variable mapping. See attached: jboss-seam-dvdstore.ear/SOA-1673.jar for source files. 3) Scoped the ear exactly as Kev suggested. See attached: jboss-seam-dvdstore.ear/META-INF/jboss-app.xml 4) Edited the processdefinition to invoke the custom ActionHandler, which called the FirstServiceESB/SimpleListener ESB Service and also maps a bpm variable to the esb body content. See attached: jboss-seam-dvdstore.ear/ordermanagement1.jpdl.xml Now, once I re-packaged the jboss-seam-dvdstore.ear, here are the test steps: 1) deploy helloworld esb service 2) deploy datasource 3) deploy ear 4) go to server:8080/seam-dvdstore 5) login as user1:password 6) Click on Shop -> The Bourne Id -> Add To Cart -> Checkout -> Purchase -> Confirm 7) see the ESB Service output in the server console: 18:05:05,192 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 18:05:05,254 INFO [STDOUT] Body: 1 18:05:05,255 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 18:05:05,262 INFO [STDOUT] Message structure: 18:05:05,262 INFO [STDOUT] [1]. "ta-da". So, Kev was spot-on. Of course. ;) I will post a link back here for the wiki page I'm authoring documenting this workaround.
jboss-seam-dvdstore.ear that works per my above comment.
Attachment: Added: jboss-seam-dvdstore.ear
Oops, forgot one other thing I had to do: make the custom ActionHandler class available to the classloader. To do this, I edited jboss-seam-dvdstore.ear/META-INF/application.xml and added this: <module> <java>SOA-1673.jar</java> </module>
Here is the requested wiki page: http://community.jboss.org/wiki/WorkaroundforSeamESBjBPMClassloadingIssue
Have you investigated using jbpm as a shared (installed) library?
Pete, that's only an option if the version of jBPM is exactly the same across the ESB, any deployed Seam applications, and any direct usage of jBPM by other applications. Scoping the application would allow for different library versions. Aside, and maybe this is more of a forum discussion, I'd like to offer my opinion in this circumstance. I'm not trying to dance around the issue, which there definitely is one, however if a customer asked me about this, I would question why architecturally (or maybe more infrastructurally), they would want to deploy their Seam app in the same VM as the ESB to begin with. The ESB is for systems integration / service orchestration / etc. Seam is an application framework that could interact with it, although I would consider it best to run that on it's own "system" separate from the ESB. It could be scaled differently, secured differently, managed differently, etc. The only reason Seam is even included in SOA-P is because it "comes along for the ride" with EAP... and I question if it really should...
To clarrify, I meant to say "I question if Seam really should be included in SOA-P... "
Pete, the original intention was to use jBPM as a shared library and my initial comments on 12th Feb go some way to doing this. This exposes other issues, however, and I feel we need to spend more time understanding these before we can move forward. This is why I suggested the safer route of using a scoped deployment in the meantime.
issues documented as far as possible for the 5.0.0 release, will need further work for a final resolution.
Work to mitigate this is complete. Future issues with Seam/jBPM/ESB integration should be registered in separate JIRAs.