Re: packaging jars vs. classes
> *And now some stuff about servlet engines
> This gets more complicated when you consider servlet engines. Servlet
> engines should have their code (jars or classes) specified on the
> classpath (ie: 3).
>
> The classes and jar files that define applications (eg: servlets and
> so forth) go in an application archive called a WAR which could be
> dumped anywhere (but tends to go into a specific directory that the
> servlet engine understands) but *shouldn't* go on the user classpath
> (for security reasons).
.war files aren't searched directly. 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.
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.
> Versioning complicates this even more because as a developer you want
> to be able to specify that your application depends on a particular
> version of a package and not load more than one class into memory if
> the version is available.
>
> eg: a servlet engine archive delivers a webmail solution - the WAR
> contains the documents and images needed to deliver the app. It also
> contains (in it's libraries directory) a copy of the javamail.jar. The
> servlet engine wants it's classloader to be able to confirm that any
> javamail.jar on the *extension classpath* is used before it's own
> copy. It's own copy will only be used if there is a difference in
> versions.
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.
Actually, it has a lot of similarities to the concept of overriding methods
of a superclass in OO programming.
.... and, to top it all off, I'm not sure that Tomcat doesn't *already* do
this. This problem might be solved already.
- Joe
Reply to: