On 3/3/03 06:14 PM Steve Loughran <[EMAIL PROTECTED]> wrote: > > ooh, first we have to enum the problems with different platforms. > > Tomcat: endorsed versus non-endorsed dirs on java1.4 > SunOne: recent postings about its contextClassloader being invalid > WebLogic: doesnt explode WARs into directories, so whenever we ask for the > physical path to something in the webapp, we get failure.
Hmm. I think we should to take a look at classloader hierarchies found on these platforms first. (I might be a little bit off the actual implementation - since I am writing this out of my head). Assuming EAR deployment Bea 6.x will create one EAR classloader (a child of the system classloader) to load all ejb-jars in the EAR. For every .war archive in this EAR a child of the EAR classloader will be created. If you deploy war and ejb archives separately, one classloader (also a child of the system classloader) will be created for every J2EE component. Websphere 4.x is a little bit more complex, since it introduces the concept of visibility for classloaders. I can't remember all details, but I know there is one mode similar to the EAR deployment from weblogic, and another one with "module" visibility. In this case all modules (war, ejb-jar and Manifest Classpath entries) are loaded by a different classloader. Manifest entries will make this more complex: The classloader of the jar containing a Manifest reference will act as a child of the classloader which is responsible for the referenced jar. In all cases these classloaders are child's of the system classloader. (Btw. there are two other modes left). JBoss on the other hand separates the system classloader and its own boot classloader(s) strictly from the server instance classloaders - only a few system classes are accessible to it. The core server deployment and classloading infrastructure of Jboss is made of three parts: A UnifiedClassloader, a shared class repository and deployers. JBoss removes the standard parent delegation model in favour of the shared repository. To make things short - apart from the EAR deployer all other deployers will make their resources accessible through this shared repository. The EAR deployer creates its own class repository (for its resources) and delegates load requests only in case it does not find the given resource. JRun behaves pretty similar to JBoss, since it uses the same JMX kernel. So why did I spend that much time explaining class loading mechanisms? ;) Because I would show that there is nothing you can be sure of while calling getClass().getClassLoader() or currentThread().getContextClassLoader(). If somehow someone put axis.jar in the system classpath and uses weblogic or websphere, it will be tough to access a resource inside the war. Same applies to referenced modules inside Websphere. Ear deployment on bea 6.x will force you in certain situations to reference or add all war archive classes to all ejb archives, otherwise you will run into ClassNotFoundExceptions. But - this also means that your this classes will be loaded by the EAR classloader, not through the war archive classloader. I don't know why, but using the exploded axis web archive on JBoss forced me to copy the servlet classes in its WEB-INF/lib, otherwise usage of the admin servlet would fail. But servlet classes are part of lib/ and should be accessible through the shared repository. So what do I recommend? Avoid using getClassloader().getResource() in web archives at all ;). And btw - hot redeployment and JNDI object registration makes things much worse ;). (I haven't examined Orionserver/Oracle IAS and Pramati Server classloader details, but I haven't had classloader issues apart from struts, earlier versions). ... > Attachments can be configured to go somewhere else, I believe Yes, but default will be inside the war. Jens
