Deploying Mule to JBoss
The recommended approach for integrating with enterprise application deployed in JBoss is to deploy Mule as a standalone application and use the Mule EJB Transport Reference or components configured using spring EJB proxies (http://static.springframework.org/spring/docs/2.5.x/reference/ejb.html) using to integrate with your EJB’s in JBoss. If you need to deploy Mule in the JBoss application server for other reasons (e.g., to use JBoss clustering), use the instructions on this page. Note that if you are using JBoss clustering, you cannot use stateful routers.
There are two main approaches you can take to deploying Mule to JBoss:
-
Simple WAR deployment: in this approach, you simply embed Mule in your application and build the WAR. Your custom implementation classes are part of the WAR.
-
EAR application: you can embed the WAR inside the EAR file and include additional files such as EJBs.
Classloader Isolation
When JBoss comes to classloading, unless classloader isolation is specified, JBoss will first try to use its own classes for deployment and only when these are not found will it look for them in the libraries of the deployment file. Since the versions of the libraries used to load Mule are not the same as the ones used by JBoss, various errors such as ClassCastExceptions can appear, so classloading isolation is important. Therefore, for best results, you should use classloader isolation in your JBoss configuration. For more information, see ClassLoadingConfiguration.
JBoss MQ Configuration
For information on configuring a JBoss JMS connector, see JBoss Jms Integration.
Scenarios your User Application with Mule in JBoss
For this scenario, the deployment is very simple: you simply add your own JAR and WAR archives to you EAR file. Because everything will be deployed in the same EAR, all the classes required by both the user application and Mule share the same classloader. However sometimes other classes may be required that are not deployed within your EAR..
Resolving Cross-dependencies
The situation becomes more complex when you want to deploy Mule-dependent code in a separate EAR file (for example, you have a custom transformer that extends Mule’s AbstractTransformer class). The user EAR depends on the Mule libraries to be loaded to be able to load the custom transformer library, while Mule expects the user EAR to be loaded to be able to use the transformer class that is found in the user EAR. To solve these cross-dependencies, you can create a shared library (in another EAR file, perhaps) and specify the library in the <loader-repository> element of the jboss-app.xml file in both the Mule EAR and the user EAR. Mule Enterprise Edition users can see an example of this in the Knowledge Base article titled "Embedding in JBoss: How to Share Classes Between Your Mule EE EAR and Another Application".