Classloader issue in JBoss AS 6 with EJBs and WARs deployed side-by-side

Question

I've found a pretty intricate problem while working on a project with multiple EE deployables. The problem seems to be a confluence of the EJB3.1 TimerService's Hibernate dependencies and insufficient classloader isolation.

Starting with a stock AS 6 CR1 build, I deploy a WAR. This WAR contains Hibernate jars.

Then, I deploy an EJB (technically an MDB) in a JAR. When I do so, JBoss then starts up the TimerService, in order to provide full EJB3.1 support. The TimerService depends on Hibernate. JBoss then goes on strike, because the classloader detects an already loaded version of Hibernate.

I've even tried packaging each of these up into a separate EAR and deploying them. No dice. Something about the way the TimerService is being loaded seems to totally ignore classloading isolation.

My question is, is there anything I can do about it, short of disabling the TimerService? I was intending to make use of its nifty features later in the project. I honestly don't even know if this is a bug, as the classloader documentation for JBoss seems to have been written by angry Klingons. Still, I hope for a work-around.

EDIT - In fact, I don't even have a way of disabling the TimerService, as each of my efforts has been thwarted in one way or another. As it stands, I don't see how anyone can deploy Hibernate and EJBs to the same JBoss instance.

EDIT - I eventually managed to deploy by not including the Hibernate jars in my MDB or WAR, but to rely on JBoss' Hibernate implementation. This is unsatisfying; I'm left with the feeling that there's no isolation between the container and my beans. But at least it's a current version of Hibernate (3.6).

Answer 1

Not sure what you have tried so far, but this should work:

EAR containing:

• JAR for the EJBs
• JAR for the JPA
• WAR for the webapp
• All libs you need.
• jboss-app.xml, with a unique "loader-repository"

And also include a jboss-app.xml in your EAR's META-INF:

<jboss-app>
  <loader-repository>...</loader-repository>
</jboss-app>

You may want to check these two pages:

http://community.jboss.org/wiki/ClassLoadingConfiguration

http://community.jboss.org/wiki/JBossClassLoadingUseCases

But I would reconsider the decision of bundling your own version of Hibernate. While it may sound reasonable, the AS is there to provide you an environment of "application hosting", and it already provides some services, like persistence. So, leave this concern to the AS ;-)

Answer 2

I would suggest removing all evidence of the hibernate jars from the installation of jboss. I don't know why they're included - causes these kinds of things to happen. Jboss will look in its own libraries first so you're bound to get conflicts.

Furthermore, I know Jboss4 was not configured by default to isolate each application into its own classloader so all classes were loaded from the same pool. Not sure if this is still the case, but it's worth investigating. On install of jboss you could configure it to isolate each application's class loader if you so wished. Though if there is a version of hibernate in the jboss common/lib dir isolating the class loaders won't help.