3:03 p.m.
Ales Justin [http://community.jboss.org/people/alesj] 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/578473#578473
--------------------------------------------------------------
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
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/578473#578473]
Start a new discussion in JBoss Microcontainer at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
5:39 p.m.
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&...]
5:52 p.m.
Ales Justin [http://community.jboss.org/people/alesj] 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/578485#578485
--------------------------------------------------------------
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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/578485#578485]
Start a new discussion in JBoss Microcontainer at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
5:58 p.m.
Ales Justin [http://community.jboss.org/people/alesj] 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/578487#578487
--------------------------------------------------------------
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"?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/578487#578487]
Start a new discussion in JBoss Microcontainer at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
6:25 p.m.
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/578490#578490
--------------------------------------------------------------
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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/578490#578490]
Start a new discussion in JBoss Microcontainer at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
5:55 p.m.
Ales Justin [http://community.jboss.org/people/alesj] 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/578486#578486
--------------------------------------------------------------
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.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/578486#578486]
Start a new discussion in JBoss Microcontainer at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&...]
5107
days inactive
5108
days old
5 comments
2 participants
participants (2)
-
Ales Justin -
Petr H