On Tue, 2009-06-30 at 11:59 -0400, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Karan,
>
> On 6/30/2009 3:12 AM, k...@dossier.no wrote:
> > Loading of jar files under WEB-INF/lib/a_foolder/*.jar wont work. On JBoss
> > 5.0.1GA this works fine but
> > The tomcat class loader cant load thease files.
>
> Tomcat is following the servlet specification, which does not have any
> provisions for subdirectories within WEB-INF/lib. JBoss is operating
> outside the servlet specification in order to support this.
>
> > Thease jar files (WEB-INF/lib/a_foolder/*.jar) is referenced from the
> > main.jar file (WEB-INF/lib/main.jar) manifest:
> >
> > WEB-INF/lib/main.jar/META-INF/MANIFEST.MF:
> >
> > /WEB-INF/lib/a_folder/cxf-rt-frontend-jaxws-2.2.jar
> > /a_folder/geronimo-ws-metadata_2.0_spec-1.1.2.jar
>
> A JAR file's manifest isn't used for any class loading operations,
> unless the JAR file is being "run" by the JVM such as "java -jar
> [jarfile]" and the MANIFEST.MF file contains a "Class-Path" entry. The
> contents of your MANIFEST.MF file are not relevant.
I remember Weblogic allowed this CLASSPATH manifest nightmare, but i
don't recommend it because:
1. Even when using WL, only some classloaders (EAR classloader ?) seems
to work with this (WAR classloader do not);
2. If you write the wrong path, there will be no warning/error message
and you just discover the problem when you (or your container/app
server) try to load some classes/resources from that jar;
3. I never knew relative to what this entries in manifest file are. I
think that the path was relative to EAR structure, but (if i'm not
wrong :-)) CLASSPATH manifest entries are relative to the path of the
jar that include them.
If you declare (in the manifest file of dir_one/a.jar) 'dir_two/b.jar',
the classloader will try to load dir_two/b.jar FROM dir_one. I think
that it will try to load dir_one/dir_two/b.jar because a.jar is IN
dir_one.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
