Re: packaging jars vs. classes
>>> "Joe Emenaker" <joe@emenaker.com> 09-Nov-00 12:55:05 AM >>>
>.war files aren't searched directly.
I know a bit about this - I'm on the Sun Servlet standardizing
committee.
>They're just archives used for deploying a web application.
>If I create a new directory for a new webapp and drop my
>.war file in there, Tomcat is supposed to unpack it right there
>and use the unpacked version. If I place an updated .war file
>there, that isn't supposed to have any effect unless I erase
>the currently-unpacked version of the webapp. If I erase the
>unpacked version, Tomcat is supposed to look for a .war file
>again and, if found, unpack it.
That's not quite right. Tomcat does do that... but that's not how the
servlet engine *has* to work.
Indeed, one of the things Craig McClanahan (the main Tomcat
architect) has been talking about doing is making Tomcat serve files
and classes directly from the WAR.
The reason Tomcat doesn't serve directly from the WAR already is that
unpacking was easier to develop.
GNU-Paperclips (the GNU servlet container) will also serve files
direct from the WAR (it will offer an unpack too if you want it but
the default is to serve from the WAR using caching and a clever
last-modified system to speed things up).
>Also, the servlet engine (aka, Tomcat) is supposed to have a
different
>instance of the classloader for each webapp to prevent inbreeding of
>classes from different webapps. So, there's a common set of
classes/jars
>that are given to all webapps, and then each webapp gets it's own
private
>set of libs, too.
That's true. In Servlet API 2.3 we have changed the rules there a
little bit. But not much.
>Actually, I think a good way of resolving this is by having the
>classloader check the webapp-specific classpaths first. In
otherwords,
> no matter what version of javamail.jar the rest of the system is
using,
>if you brought your own, then you get to use your own. This would
>keep upgrades to the system-wide javamail.jar from breaking this,
>particular webapp.
That's the rule that what we've changed.
The standardizing committee wanted the ability for a container to
say:
"we're going to use this version of javamail - is it already
loaded? because it it is I don't want to load it again"
>.... and, to top it all off, I'm not sure that Tomcat doesn't
*already*
>do this. This problem might be solved already.
Nope. Not the behaviour I'm talking about because that's new. It will
be in Catalina (Tomcat 4.0) which is due Any Day Now.
But what you're getting at I suspect is "does this matter - Tomcat
has it's own repositories for jars it can just keep to them".
The point I was trying to make is that Debian may want to provide a
standard webapp directory or path (the place where WAR files are put
so that the servlet engine can find them).
Nic
Reply to: