Yes this is possible. We currently use 3.0.6 but the principles should apply to later versions. We have 1 ear containing a war and some ejbs. A servlet in this ear routes calls to a routing service also deployed in this ear. This routing service then examines the job and routes to a GatewayBean in another ear. All beans implementations that wish to be called in this way must subclass from the GatewayBean which just offers a ProcessCall like interface. Each of the these beans are then deployed in their own ear. Each of the ear's are hot-deployable so when we add a new customer we add a new route (via the DB) and just deploy their implementation in their own ear)
However there are a few pitfalls. The first being that each ear is scoped to have its own classloader, the second that calls between the ears are sprecified to use pass by value (a different container configuration). We also retain pass by reference when in the same ear. It is also important that you package up all classes that form part of the interface into their own jar. We put this in the lib directory.
Sorry its a little garbled as I am rushing.
I'm using an architecture similar to your GatewayBean except the servlet I use for routing is also deployed to each EAR and only routes to the GatewayBean within that EAR. (My GatewayBean is for EJB client access).
I'm relying on your statement that "each EAR is scoped with its own classloader". In fact, I wasn't aware it was possible (or even desirable) to access a JAR deployed in one EAR from another EAR.
I have a utility JAR deployed with each EAR and I'm finding that classes in that JAR are loaded only from the first EAR deployed containing that JAR regardless of the EAR I'm accessing. This seems so arbitrary since it looks as though deployables are processed alphabetically and is especially problematic when I have the need to deploy a specific version of the utility JAR in an EAR.
Could this be a bug or maybe a configurable JBoss option? If it is an option, is it the default behavior to allow sharing JARs across EARs and where/how do I change it?
BTW - I'm using 3.2.3.
Lea, ok, but then, I'd have to put the home and remote interfaces of this bean that resides in the EAR in a "mylib.jar" and put that jar in the server's lib.
What then if I want to add another method to my EJB. I can't do that without restarting the server, since the remote-class is outside the EAR, so it won't matter if I redeploy it!!
Is there a way around this?
mroony: if the ears are completely independent "units" (ie, they don't rely upon any functionality the other provides), then you can scope them so you can deploy different versions of your util.jar.
chap 2 of the jboss admin book talks about this and how the class loader works in general.
mathias: yes and no....
you can deploy the jar into the deploy directory, and then if you need to add a new method, you are free to do so. since you will have to redeploy the ear w/ the jar (containing the interfaces) anyway, you'll have no issues.
where it can get more complicated is if you have another ear (B.ear) deployed that may rely upon functionality of the newly updated ear (A.ear see above). if you added new methods, once you redeployed A.jar and A.ear, you would also have to "touch" B.ear to cause the classloader to cycle so it doesn't have any stale references to A.jar.
I guess jae77 has already answered the questions.
mroony: Yes in 3.0.6 the default classloading behaviour is as per the UCL (Unified Classloader) Its in the docos provided by jae77.
Its desirable for us to scope our ears since each ear represents a customers product. When we change either a common customer class or a framework class we do not want these changes cascading to other products from the same customer and more importantly products from other customers. We do have to track versions very carefully!
mathias: You dont need to put the home and remote in lib, we only did this because we have a gateway ear which calls down into the customer product ears. I guess we could also have put them in an unscoped gateway ear also.
We have found this structure coupled with hot-deploy a real bonus for our business. I would be interested in everyones thoughts and soes anyone know of a better solution?