Classloader parent delegation on Jboss AS7

[jpcunha]

I'm migrating my application from jboss6->7rc1, and I'm having some issues with the new classloading mechanism. My Ear contains an older version of Hibernate on the ear lib folder, and when the application is starting up i get a java.lang.NoSuchMethodError: org.hibernate.SessionFactory.openSession()Lorg/hibernate/classic/Session; because classloader requests are being delegated to the parent classloader, thus trying to use the new hibernate jars bundled on jboss7. On jboss6 everything was working great with java2ParentDelegation set to false.

Do you guys have any idea how can I get my bundled hibernate jars to work?

[jason.greene]

If you are using EJB or JPA spec apis you end up with a module dep on the new version automatically being added.

See: https://docs.jboss.org/author/display/AS7/Implicit+module+dependencies+for+deployments

We plan to add a feature in a future release (7.1 at the latest) that allows you to install custom JPA providers. Optionally, if you are using hibernate directly, and the JPA inclusion isn't really used,  you can exclude the auto hibernate dep (see exlusions):

https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7

Note that the reason that we have to have some kind of provider/implementation is that JPA has all kinds of requirements about how the container should process the deployment. E.g. @PersistenceContext has to properly injected at certain times in the container lifecycle and properly interact with the TM. So a standalone library, wihtout any kind of app server integration is going to not be 100% operational

[jpcunha]

Hi Jason,

Well.. in my case i'm using a EJB+JPA layer, but we do have some legacy modules that are using hibernate directly.

Looking at your 2nd link, will jboss-deployment-structure.xml file solve my problem, by preventing automatic dependencies from being added?

[jason.greene]

What does the structure of your deployment look like? Is this an ear with multiple ejb jars, some which use the legacy hibernate and some which use JPA?

[jpcunha]

Simplified structure:

- myapp.ear

- - lib/hibernate-x.x.x.jar

- - lib/xpto.jar <- this one uses hibernate directly (previous jar), and it's only used on the war classloader context

- - lib/...

- - ejb1.jar (business layer, services)

- - ejb2.jar (data layer, DAOs)

- - web.war (skinny war... no jars on WEB-INF/lib)

[jason.greene]

Sorry for my delay in replying. I had the Final release to get out the door.

So the issue here is that by having hibernate in ear/lib it's always added to all deployments in the ear. What I would recommend you doing is moving it and xpto.jar to the war WEB-INF/lib since you mention that it is only used there. Due to the fact that we auto add hibernate with the presence of JPA annotations to all subdeployments (something I want to limit in a future release), you also need to add an exclusion for your war to not import the server's version of hibernate.

You do that by putting a jboss-deployment-structure.xml file in your ear's META-INF directory. There you list a <sub-deployment name="web.war"> and in that you add an <exclusions> with a module name of "org.hibernate".

Take a look at for more info and an example

https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7

[hostalp]

Just small note to the dependency exclusions stuff. As I already mentioned here http://community.jboss.org/message/615408#615408

dependency exclusions seem to work somewhat strangely.

I've got an ear with lib directory and four wars

MANIFEST.MF Class-Path entries in these wars reference libraries from the ear lib directory

Then I've got jboss-deployment-structure.xml

<jboss-deployment-structure>
  <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
  <deployment>
    <exclusions>
      <module name="org.hibernate" />
      <module name="org.hibernate.validator" />
    </exclusions>
  </deployment>
</jboss-deployment-structure>

Which doesn't seem to behave like I would expect. I can see that with these exclusions the behavior changes a little (when compared with no exclusions at all), but server's hibernate stuff is still being used.

I had to add a sub-deployment entry with the same exclusions for each war to get closer to the expected state.

Is is a normal behavior? It looks a quite strange to me, I'd expect setting these exclusions at deployment level would affect the whole ear but it doesn't seem so.

[jpcunha]

Petr, i have already tried a similar boss-deployment-structure.xml (just for testing purposes) like yours, but in my case i got the jboss hibernate libs completely excluded from my ear classloader, and started to get classnotfound exceptions since i have a JPA layer. Then i tried adding the exclusions to my war deployment and they were still visible...  seems like the oposite result from what you got.

ps: Using jboss7 rc1

[hostalp]

Well, that's funny. I'm using 7 final so there may be some differences, otherwise I've got no good explianation for that.

[jaikiran]

Deployment structure files are top level only. i.e. If you are deploying an .war within a .ear, then the jboss-deployment-structure.xml within the .ear/META-INF/ is what matters.

In an ear the exclusion only applies to ear/lib. To configure it for subdeployments within the .ear, you'll need a sub-deployment element within the .ear/META-INF/jboss-deployment-structure.xml. Here's an example on how the subdeployments can be configured https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7.

The reason you both see different results is because the application that you mention are packaged differently.

[hostalp]

In an ear the exclusion only applies to ear/lib. To configure it for subdeployments within the .ear, you'll need a sub-deployment element within the .ear/META-INF/jboss-deployment-structure.xml.

Alright, then would it be possible to add an option for these filters and other options to affect the whole ear as well? Or at least some sub-deployment level inheritance (from ear) option...

[abhis]

So, are you implying that there is NO similar configuration (like java2ParentDelegation) that would do parent last class-loading in JBoss AS7 as it did in JBoss 5 and the likes?  So, for any jar that we add to our application to overwrite framework's classes, we need to make sure we exclude the implicit dependency for that module (if at all) in our application's jboss-deployment-structure.xml, correct?