On 3/25/03 07:58 PM [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Jens, > > What do the J2EE specs say about the classpath that app servers provide to > deployed applications that use EARS? Are the EAR files guaranteed to be in > the classpath, or is it just the jars contained within the EAR?
See discussion on this list with Steve. The main issue is using Thread.currentThread().getClassloader(). In my experience it is not safe to say this classloader has access to all ear resources. You may have access to WEB-INF/lib or WEB-INF/classes/ or you may not see those resources in the way you expect them. In my case this approach just fails. Since it is quite usual to refer to shared libraries between ejb-jars and war's or even between ear files through Manifest.MF entries you end up in a classloader nightmare. It seems that the use of the ServletContext Classloader is pretty safe, but this introduces a Web Archive dependency. I am pretty sure it works using (exploded) war archives, but as I said some time ago, I haven't seen a plain war and even exploded deployment since a long some time. If you deploy your application to a cluster it is just not practical to do use something else than EARs. J2EE specs does not say anything about classloaders. It only defines the archive layout and requires that Manifest.MF classpath entries are supported. Jens PS: I am still on the orion server problem someone described on axis-user, now I really believe the J2EE application separation gets broken due to the use of Thread.getCurrentThread().getClassoader(). Hopefully it is only a classloader related JNDI problem ...
