jaikiran wrote:

 

Given the refactoring that was done in Hibernate libraries, isolating them correctly, is a bit more involved. Here's what you have to do http://community.jboss.org/thread/64126?tstart=0

Jaikiran,

I read that series of postings, and my basic question is still not answered. I set up the jboss-web.xml as you recommended:

<jboss-web>
    <context-root>/</context-root>
     <class-loading java2ClassLoadingCompliance="false">
         <loader-repository>
             com.vzw.acsr:loader=acsradmin.war<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
         </loader-repository>
     </class-loading>
</jboss-web>

and the result is the same. I get the following error when the Grails app deploys

java.lang.NoSuchMethodException: org.hibernate.validator.ClassValidator.<init>(java.lang.Class, java.util.ResourceBundle, org.hibernate.validator.MessageInterpolator, java.util.Map, org.hibernate.annotations.common.reflection.ReflectionManager)

The war has the new (grails-friendly) hibernate-validations.jar included in its lib directory, but the one in the JBOSS/default/lib is the one that gets loaded each time. I have confirmed that the jars are where they are supposed to be.

Adding "-verbose:class" to the JAVA_OPTS reveals the truth:

[Loaded org.hibernate.validator.ClassValidator from file:/C:/Jboss/jboss-4.2.2.GA.VZWDEV/server/default/lib/hibernate-annotations.jar]

This is not the location that grails needs, and the isolation appears to be ignored, but I wonder if this is loaded before the jboss-web.xml is even looked at.I do see that library being loaded, but it appears that only classes to don't exist in the default one are being loaded, as in the following:

[Loaded org.hibernate.cfg.RecoverableException from file:/C:/Jboss/jboss-4.2.2.GA.VZWDEV/server/default/tmp/deploy/tmp7080372592080756625acsradmin-exp.war/WEB-INF/lib/hibernate-annotations-3.4.0.GA.jar]

This confirms that the jar is getting read, but only certain classes are being loaded from it, not the ClassValidator class that creates the exception above.

If I remove/replace the old version of the jar from the default lib my existing application (which is not really mine in the first place) starts crashing.

Which part of that posting you referenced was supposed to contain the part that I'm missing?

I appreciate your response,

Brian

The existing ear uses the following hibernate jars, which I believe originate from the JBoss installation:

hibernate3.jar
hibernate-annotations.jar
hibernate-ejb3-persistence.jar
hibernate-entitymanager.jar
hibernate-metadata.jar

The new grails war uses the following hibernate jars:

hibernate-annotations-3.4.0.GA.jar
hibernate-commons-annotations-3.3.0.ga.jar
hibernate-core-3.3.1.GA.jar

The particular jar of conflict is the annotations jar, though I'm aware that there could be others that we are not seeing. Even when I try to isolate that jar the jar in the default/lib is picked up first, and not overidden by the war file. What I'm considering as a next move is to put the (older) jars in the ear file distribution and placing the new hibernate files in the war, since the ear's manifest can specify the libraries that are local to the ear more readily.

The output you requested is attached. Thanks for your assistance.

Brian

Jaikiran,

No, the war is not placed in the ear. The war is in the deploy directory separate from the ear file, which is a different application. So it looks like this:

default

    deploy

        _ears

            MyApplication.ear - (using older hibernate versions)

                        MyOtherApplication.ear

        MyGrailsApp.war - (using new hibernate versions)

Hope that makes this clearer.

Brian