Are you experiencing classloader issues the way you are doing it now, or are you just concerned about non-portability by using JBoss-specific configuration?
i have the classloading issues fixed, but had to do this in a jboss specific way.
i was wondering if there is an elegent and standardized approach.
for other readers info : i have the different ears configured with the same jboss-app.xml loader-repository configuration (which makes jboss 4.2.0 load the ears in the same classloader namespace)
the fundamental question is in fact a question of granularity
my application (as many do prob) exists out of a collection of 'modules' (jars), a group of classes that together offer a more or less independent service.
i could put alle the modules (jars) inside one big ear and avoid inter ear communication but that reduces (hot) redeployment options and has a negative impact on my development cycle.
ideally i would have OSGi like possibilities to load jars dynamically and control very specifically which interfaces they expose to the outside world
i have been wondering about the role of JMX. however, at this time there is not yet a link between JMX services and/or SEAM components and/or SF or SL session beans.
There really isn't a standard way to share classloaders between applications. For remote beans, you need the interfaces from app2 in app1 and the interfaces from app1 in app2. I don't know what other app servers offer to provide the equivalent of a shared-named repository.
If you are sharing classloaders, there's really no reason not to use one big ear instead. If you hot deploy app1 you nearly always need to hot deploy app2 also to avoid classloader issues. Why not bundle in one big ear and force yourself to do the right thing on redeploy? The alternative, in jboss, is to extract common classes to a third app. app1 and app2 can be safely separately redeployed. If the common classes change then both app1 and app2 should be redeployed.
No, we don't really have a link to JMX MBeans. You probably don't want direct app to mbean communication for the most part. Generally you want your MBeans to manage services that are exposed through JNDI or some other communications mechanism. In either case @Factory and @Unwrap are probably your best bets for exposing these services to Seam.
thanx for your very clear answer.
i have worked with OSGi in the past. i still feel that it could be a great enhancement to application servers to provide dynamic loading and a controlled and fine grained 'exposure' mechanism.
but it's def. not something you introduce in an infrastructure like jboss in a short time :)
Well, at office we're are devolping two Enterprise Applicationa, one with plain EJB3 and one with Seam. Communication between both apps is done via WebServices which works very well for us (despite of unicode problems with JBossWS before patching)
Only thing I ran into problems is when both apps are deployed on the same server (there have been issues with class-level isolation and quartz imho). I didn't investigate further because we do not have the requirement to let both apps run on same JBoss.
Did not try multiple Seam apps on one server by now, but possibly in near future. Never say never...