1 2 3 4 5 Previous Next 68 Replies Latest reply: Apr 17, 2012 8:54 AM by Ales Justin Go to original post RSS
  • 15. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Daniel Skiles Newbie

    Thanks, I think I follow you.  If I wanted to filter more than one package, would I add additional parameters, or is this argument comma delimited?

  • 16. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Ales Justin Master

    would I add additional parameters, or is this argument comma delimited?

    I think both would work. :-)

  • 17. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Barney Franks Newbie

    Did you finally get this to work?  I have the identical problem with CXF.

  • 18. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Barney Franks Newbie

    You can actually ignore this error with ignoreSet in jboss-scanning-deployers-beans.xml.

    But this is probably not the right thing to do.

     

    How would I do this for the identical problem as Daniel's?

  • 19. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Petr H Newbie

    Hello,

     

    so based on what's discussed here I tried some things but don't seem to have succeeded.

    I'll shortly describe what I'm up to and what I've done:

     

    I've got an ear:

    ear/lib - shared jars

    ear/web1.war

    ear/web2.war

    ear/web3.war

    (wars reference some of the shared stuff in lib via META-INF/MANIFEST.MF Class-Path)

     

    Now I'm trying to filter out JBossAS (6.0.0.Final) own Hibernate stuff for the whole ear globally:

    ear/META-INF/jboss-classloading-domain.xml

     

    <?xml version="1.0" encoding="UTF-8"?>

    <classloading-domain xmlns="urn:jboss:classloading-domain:1.0" name="MyDomain">
    <parent-policy>
      <before-filter>
       <javabean xmlns="urn:jboss:javabean:2.0" class="org.jboss.classloader.plugins.filter.NegatingClassFilter">
        <constructor>
         <parameter>
          <javabean xmlns="urn:jboss:javabean:2.0" class="org.jboss.classloader.spi.filter.PackageClassFilter">
           <constructor>
            <parameter>org.hibernate</parameter>
           </constructor>
          </javabean>
         </parameter>
        </constructor>
       </javabean>
      </before-filter>
    </parent-policy>
    </classloading-domain>

     

    however I'm still getting an exceptions related to hibernate validator which appears to be related to the differences between hibernate bundled in the ear - 3.5.6 - and hibernate in JBoss 6.0.0.Final - 3.6.0 + hibernate Validator 4.1.0 - see below.

     

    So that doesn't seem to be working for me. Now - what's wrong? Should I define a jboss-classloading.xml as well (I don't have any at the moment)? What it should look like then?

    And can all this be done on the ear level, or should I go through each war?

    Or anything else?

     

    org.hibernate.AnnotationException: 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)
    at org.hibernate.cfg.AnnotationConfiguration.applyHibernateValidatorLegacyConstraintsOnDDL(AnnotationConfiguration.java:455) [:3.5.6-Final]
    at org.hibernate.cfg.AnnotationConfiguration.applyConstraintsToDDL(AnnotationConfiguration.java:428) [:3.5.6-Final]
    at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:403) [:3.5.6-Final]
    at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1206) [:3.5.6-Final]
    at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1459) [:3.5.6-Final]
    at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:193) [:3.5.6-Final]
    at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:1086) [:3.5.6-Final]
    at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:685) [:3.5.6-Final]

  • 20. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Ales Justin Master
    however I'm still getting an exceptions related to hibernate validator which appears to be related to the differences between hibernate bundled in the ear - 3.5.6 - and hibernate in JBoss 6.0.0.Final - 3.6.0 + hibernate Validator 4.1.0 - see below.

     

    org.hibernate.AnnotationException: 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)
    at org.hibernate.cfg.AnnotationConfiguration.applyHibernateValidatorLegacyConstraintsOnDDL(AnnotationConfiguration.java:455) [:3.5.6-Final]

    It looks like your Hibernate is kicking in, but the problem is now Validator.

    You're saying you're also bundling Hibernate Validator that matches Hibernate 3.5.6-Final' usage?

  • 21. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Petr H Newbie

    I tried both with bundled Validator and without it, but no difference. In verbose:class output I could see only loading of certain Validator classes from common/lib/hibernate-validator.jar and hibernate-validator-legacy.jar.

     

    Also note that even without specifying that filter the Hibernate 3.5.6 was being used so even here there's no difference.

    One interesting thing is that we don't actually use the Validator in our app, but it looks like since it's on the classpath and gets loaded it interfers with the app.

     

    Isn't some sort of jboss-classloading.xml setup required for this case? I wonder if I don't have to setup an ear level one specifying the MyDomain as domain and then another in each of the wars specifying the MyDomain as parent domain (I'm not sure how the domain inheritance works here - if wars inherit the ear domain as their parent or not).

  • 22. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Ales Justin Master
    I tried both with bundled Validator and without it, but no difference. In verbose:class output I could see only loading of certain Validator classes from common/lib/hibernate-validator.jar and hibernate-validator-legacy.jar.

    Validator should be bundled as well.

     

    Also note that even without specifying that filter the Hibernate 3.5.6 was being used so even here there's no difference.

    One interesting thing is that we don't actually use the Validator in our app, but it looks like since it's on the classpath and gets loaded it interfers with the app.

    If the Hibernate was/is part of war' lib/ dir then this makes sense.

    If not, then it's strange. :-)

     

    Isn't some sort of jboss-classloading.xml setup required for this case? I wonder if I don't have to setup an ear level one specifying the MyDomain as domain and then another in each of the wars specifying the MyDomain as parent domain (I'm not sure how the domain inheritance works here - if wars inherit the ear domain as their parent or not).

    The war' parent classloader is (unless explicity set differently) ear' root classloader.

    And of course this classloader -- via jboss-classloading-domain.xml -- is in its own filtered domain

  • 23. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Petr H Newbie
    Validator should be bundled as well.

    The bad thing is that it was behaving the same way no matter if Validator was bundled or not.

    And still, I don't need it in the app. On other app. servers I can run the same app without the Validator anywhere on classpath.

    If the Hibernate was/is part of war' lib/ dir then this makes sense.

    If not, then it's strange. :-)

    It was in ear/lib, referenced from war via MANIFEST.MF Class-Path entry.

    The war' parent classloader is (unless explicity set differently) ear' root classloader.

    And of course this classloader -- via jboss-classloading-domain.xml -- is in its own filtered domain.

    Based on my recent findings this seems to be only partially true.
    If I use the actual name of ear file as ear-level domain name then it seems to be true.
    If I use something else (in ear/META-INF/jboss-classloading.xml) then it looks like war classloaders don't reflect this change and still work with ear file name so I have to setup their own jboss-classloading.xml
    I think the war classloaders should pick up the change done on ear level by default but they seem like they don't.

    Anyway I still can't get the filtering to work even though I use the ear file name as domain name in ear-level jboss-classloading-domain.xml - the Hibernate Validator stuff from the JBoss is still loaded.

    Also I noticed that the particular class org.hibernate.validator.ClassValidator (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)) comes from the common/lib/hibernate-validator-legacy.jar and isn't bundled in our app.
    The particular code in org.hibernate.cfg.AnnotationConfiguration class (3.5.6.Final) is:
       try {
       Class classValidator = ReflectHelper.classForName(
         "org.hibernate.validator.ClassValidator", this.getClass()
       );
       Class messageInterpolator = ReflectHelper.classForName(
         "org.hibernate.validator.MessageInterpolator", this.getClass()
       );
       validatorCtr = classValidator.getDeclaredConstructor(
         Class.class, ResourceBundle.class, messageInterpolator, Map.class, ReflectionManager.class
       );
    where the last expression throws that NoSuchMethodException (looks like there's an incompatibility between later hibernate annotations and hibernate-validator-legacy because there's really no such constructor in ClassValidator). That gives me an idea - does the JBoss Class Filter still give an access to a particular class (in JBoss libs) when there's a filter match but the class isn't in the app?
    Maybe the problem here is because there's no such class in the app so even though the filter is setup properly it doesn't have any effect here - beceuse it's just a "preference" filter and not really a "blocking" one.

    I'll try some more configurations but I really doubt that I'll be able to get it to work - maybe I'll try to remove hibernate-validator-legacy.jar from JBoss libs.

  • 24. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Ales Justin Master
    The bad thing is that it was behaving the same way no matter if Validator was bundled or not.

    This is a Hibernate issue, or who ever tries to get a hold of Validator resources.

    If the Hibernate was/is part of war' lib/ dir then this makes sense.

    If not, then it's strange. :-)

    It was in ear/lib, referenced from war via MANIFEST.MF Class-Path entry.

    That's the same thing as if were part of WEB-INF/lib, since it becomes war' classpath entry.

    That gives me an idea - does the JBoss Class Filter still give an access to a particular class (in JBoss libs) when there's a filter match but the class isn't in the app?

    Maybe the problem here is because there's no such class in the app so even though the filter is setup properly it doesn't have any effect here - beceuse it's just a "preference" filter and not really a "blocking" one.

    Sure, exactly -- it's a "preference" filter.

    It tells the domain not to look for any "org.hibernate" resources in the parent before it looks into own domain.

    (as we know, usual Java lookup mechanism is parent first)

     

    But since they are not found in own domain,

    it goes into *after* phase and looks into parent domain.

     

    You can also setup the after lookup to be filtered the way you want it.

  • 25. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Ales Justin Master
    Based on my recent findings this seems to be only partially true.

    If I use the actual name of ear file as ear-level domain name then it seems to be true.
    If I use something else (in ear/META-INF/jboss-classloading.xml) then it looks like war classloaders don't reflect this change and still work with ear file name so I have to setup their own jboss-classloading.xml
    I think the war classloaders should pick up the change done on ear level by default but they seem like they don't.

    Ah, I think you're right.

    It's the WebClassLoaderDeployer that messes up things;

    it's missing some more logic to address the new jboss-cl-domain.xml notion.

     

    I'll fix this.

    Too bad we didn't find this one before.

  • 26. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Ales Justin Master
    But since they are not found in own domain,

    it goes into *after* phase and looks into parent domain.

     

    You can also setup the after lookup to be filtered the way you want it.

    Perhaps filter out the "org.hibernate.validator"?

  • 27. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Petr H Newbie

    Perhaps filter out the "org.hibernate.validator"?

    I'll try something, but I'm not sure what to try exactly. Looks like adding NegatingClassFilter for org.hibernate as after-filter isn't the way so I'm not sure which way to go to block some packages/classes completely regardless their presence anywhere or not.

    There should really be some "fully blocking" approach possible (and simply).

     

    EDIT: I tried to setup filters on org.hibernate.validator package several ways - before-filter was always NegatingClassFilter on that package, after-filter was once NegatingClassFilter, once just PackageClassFilter, also tried RecursivePackageFilter for both before-filter and after-filter in the end but to no avail.

  • 28. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Ales Justin Master

    Perhaps filter out the "org.hibernate.validator"?

    I'll try something, but I'm not sure what to try exactly. Looks like adding NegatingClassFilter for org.hibernate as after-filter isn't the way so I'm not sure which way to go to block some packages/classes completely regardless their presence anywhere or not.

    There should really be some "fully blocking" approach possible (and simply).

    The same negating filter should also work for after phase.

    The fully blocking filter is NothingClassFilter.

     

    EDIT: I tried to setup filters on org.hibernate.validator package several ways - before-filter was always NegatingClassFilter on that package, after-filter was once NegatingClassFilter, once just PackageClassFilter, also tried RecursivePackageFilter for both before-filter and after-filter in the end but to no avail.

    Hmm, yeah, I think that was a typo on my end, we need RecursivePackageFilter.

    But apart from that I don't see what can go wrong.

     

    Could you debug a bit more?

    Or do you have some test case / example to share?

  • 29. Re: How to stop my WAR loading JBoss's provided 3rd party classes?
    Ales Justin Master

    The fully blocking filter is NothingClassFilter.

    Of course this only blocks things between domains.

    If the resources are locally present, we need diff mechanism to exclude them - jboss-classloading.xml.