Ralph Goers wrote:
Sylvain Wallez said:
Actually, it writing your own classloader *does* solve the problem. Cocoon provided a so-called "paranoid" block providing a "ParanoidCocoonServlet". This servlet loads the Cocoon servlet (or any other servlet through a config in web.xml) in a ParanoidClassLoader that shields the webapp's classes from the upper-level classloaders.
Shielding means that classes and resources are always looked up _first_
in the webapp before delegating to the parent classloader. Up to now,
this has always saved my life in crazy classloading environments ;-)
I don't believe this will save you in some environments. I've been told
that JBoss appears to have problems with the logging classes. I've been
told that it expects to get them from its class loader and if it gets them
from the webapp it seems to fall apart.
In such a case, simply ensure that the logging classes are not in your webapp classpath so that they are loaded from the container classloader.
Now I don't really see why JBoss should even know about a webapp's logging classes...
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
