Since I'm just talking to myself here, I figure I'll do it here so others can
find this in a Google search later.
To illustrate how most (every other) environments handle classloading and
Manifest Class-Path entries, try this little experiment.
Create three jars, a.jar, b.jar and c.jar. Give a.jar and b.jar manifest files
that reference c.jar.
Now point a URLClassLoader at a, and another one at b.jar.
Although they are, in some sense, "sharing" a single copy of c.jar, they will
each get different versions of the classes contained in c.jar. That's because
the Manifest Class-Path entry will effectively just-in-time expand the
classpath before any loading takes place.
This is part of the jar specification.
By extension, it is also required behavior in J2EE 1.4, which requires that
implementors respect the jar specification.
That means that if you have a war file with a manifest class-path entry,
whatever classpath its loader has must be augmented right off the bat with
whatever is in its manifest.
So if a war file loader is, in any respect, ultimately a URLClassLoader with a
URL of wherever-the-war-file-is and basically nothing else, then its classpath
must be immediately augmented to contain whatever the Manifest says. So the
loader in this stupid example would have a class path of
{wherever-the-war-file-is, some-jar-the-war-file-references-via-its-manifest,
some-other-jar-similarly-referenced}. This would happen and would take place
before any other class loading occurs within that war.
(Note again this is exactly what happens with URLClassLoaders right out of the
box.)
This means that because webapp loaders are bound by the servlet and J2EE
specifications to "look inward first", anything roped in via this manifest
mechanism will have the same visibility as anything contained in
WEB-INF/classes or WEB-INF/lib. That's the intention, anyway.
This does not appear to be what JBoss 4.0.3 is doing. Either the webapp
manifest is ignored (this is not true; in my case I can see classes inside
framework.jar), or the initiating loader of framework.jar is not correctly
being set by the webapp loader to itself. What I mean by that is from the
standpoint of any code inside the webapp, framework.jar in my case should
appear (from a classloading perspective) as though it were dumped in
WEB-INF/lib.
Since this behavior is free out of the box with URLClassLoaders, I have to
assume that the Tomcat classloader that loads webapps is doing something odd,
or the JBoss subclass thereof is doing something odd.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3941371#3941371
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3941371
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
JBoss-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-user
