On 6/22/2011 9:08 AM, Mark Thomas wrote:
Another issue is that WEB-INF/lib is visible to the parent classloader
embedding Tomcat and to Tomcat as part of the web application and thus
I'm probably getting double scanning -- though really Tomcat should be
avoiding this by detecting that the same jar file is involved in both
cases. The reasons for the duplication in this classpath are long and
historic. Overall I'd rather not try to unwind this now. I'd
hope/assume that an annotation on a class, e.g. a filter annotation,
would only result in one filter instance irrespective of how many times
that class is visible to the classloader(s) in question.
That sounds like it might cause trouble. Classes are identified by the
combination of name and class loader so the same class loaded in two
different class loaders is treated as a different class. If both the web
application class loader and its parent class loader can see WEB-INF/lib
I can image all sorts of things may go wrong.
Well the classloaders are clearly hierarchical, so only one Class
instance is loaded. The fact that both ClassLoaders can see the jar
does not result in 2 Class objects -- nor should it result in an
annotation being applied multiple times. The jars are in fact exactly
the same here -- as one of the web app's WEB-INF/lib directories is
visible to the parent classloader. It may be possible to move the jars
somewhere else so that they're only part of the parent classloader, but
that will require more reshuffling of the longstanding configuration.
Given that the JNDI node maps to a file if the web app is expanded -- as
mine always is (being deployed originally as an expanded directory in
.war layout not as a .ware archive), it seems there should be a "back
door" for Tomcat to notice this and simply use the file location to
begin with rather than doing any extra temporary file shenanigans in any
case. The JNDI wrapping is nice and all, but shouldn't cause a
substantially sub-optimal performance approach when it is clear enough
how to attain the appropriate File object.
It should be doing that already. I'll double check
Is there any danger -- other than worse performance in use cases I don't
have -- in me patching my own Tomcat to always use FileUrlJar? Should
this perhaps be a config option? Or possibly a config option based on
file size? [FileUrlJar may only be faster for larger jars from what
little I know...]
That local patch should be safe. In terms of config, I'd like to keep
this as automated as possible. More research required.
For reference, how big are the JAR files we are talking about here?
They range in size from 48K to 46MB. Only 3 jars are over 25MB in size.
--
Jess Holle
