Of course you are right (you always are ;-) about the way classloaders work.
However, I think Eric meant (and if he didn't, I do) that his class X is in fact a single one, and he *needed* to copy the .class file into common/... so that he could instantiate a new object of class X from his object of class Y.
My suggestion to Eric: If you hold a reference to your "X" object in "Y", you can for example myX.getClass().newInstance(). Or maybe myX.getClass().getClassLoader().something... Or, you can simply move "X" into common instead of copying. I don't know what you are ultimately trying to do, so I can't advise on a specific way of doing it. Tell us, and someone will probably help you.
Please correct me if I am wrong about the following:
The common directory/classloader is meant for things that can be accessed (as the name implies) from all and any webapp. The webapp classloader is meant for things that can be accessed from that specific webapp. They are independent.
That means a webapp cannot load something which is in another webapp, but it can load something in "common".
It is very reasonable that something in "common" cannot access something in "any" webapp. That would completely break independence in a bad way.
For example, if I had in the same server (bad practice, I know) the "dev" version and the "production" version of an app, in two different webapps (hence exactly the same class names, but with different content), how could "common" know which my.package.Foo I want to load?
Antonio Fiol
Shapira, Yoav wrote:
Hi, Your understanding is wrong: there can be one class X for each classloader. Your practice of using multiple classes with the same fully-qualified name in the same application is questionable, as it can easily lead to human errors.
Yoav Shapira Millennium Research Informatics
jar,-----Original Message----- From: Eric M. Kascic [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 10:49 AM To: [EMAIL PROTECTED] Subject: Esoteric class loading question/loading constraints/loader constraints
I am somewhat stupified by some class loading results I am seeing from
Tomcat. If I put some class X that refers to class Y in my servlet
Xthe WebappClassLoader loads X. I DO NOT put class Y in my servlet.jar. Instead, I put class Y in a jar that is put in common/lib. When Y is finally loaded as a result of X being loaded, the StandardClassLoader loads it (as the WebappClassLoader delegates to the StandardClassLoader).
Now the stupifying part: class Y has a reference to a class X, *BUT* I
have put that class X in Y's jar. Bottom line, there is to be two
different class X's, one loaded by WebappClassLoader (for the specific
webapp) and one by the StandardClassLoader (for common). Based upon my
understanding of how the JVM tries to ensure "type safety" across
ClassLoaders, StandardClassLoader loading the second version of class
should fail with a LinkageError - because the defining loader for X is already WebappClassLoader, and here we are trying to say the defining loader is now StandardClassLoader.
The rub: Tomcat does not throw a LinkageError. Instead it goes ahead and loads the second class X just fine. Doing an output of getClass().getClassLoader() in the constructors of both class X's shows that is being loaded in two different defining loaders. Am I missing something? Given that the so-called loader/loading constraints are enforced by the JVM, not any particular ClassLoader/app, I am dumbfounded by this behavior.
Thanks in advance for any insights.
smime.p7s
Description: S/MIME Cryptographic Signature
