Petr H [http://community.jboss.org/people/hostalp] created the discussion
"Re: How to stop my WAR loading JBoss's provided 3rd party classes?" To view the discussion, visit: http://community.jboss.org/message/578484#578484 -------------------------------------------------------------- > 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. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/578484#578484] Start a new discussion in JBoss Microcontainer at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2114]
_______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
