tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Mann <>
Subject Re: Extending Server.xml configurability (for additional classpaths)
Date Tue, 28 Aug 2001 19:16:55 GMT

on 8/28/01 2:13 AM, Reilly, John at wrote:

> I don't understand why you would want this - doesn't the WEB-INF/lib and
> WEB-INF/classes not already provide seperation of classpaths for the various
> webapps.  Am I missing something?

Well, I need to share a class tree and/or .jar files among a handful of
separate contexts. The currently available options are not really sufficient
for my needs:

1. I can copy the classes/.jar files to each context's WEB-INF directory.
2. I can add a separate directory containing my classes and add that
directory to the environment's CLASSPATH (this has, so far, not worked).

I really want to be able to take a stock installation of Tomcat, add our
Server.xml file and context directories, and start the server. Solution (1)
makes version control difficult (as Douglas notes below), and Solution (2),
aside from not working yet for me, means scripts have to be changed, and is
possibly different for different platforms.

on 8/28/01 11:51 AM, Douglas Seifert at wrote:

> Wouldn't it be better to use META-INF/MANIFEST.MF to specify additional
> classpath information via the Class-Path: manifest header in a .war archive.
> I know disk space is cheap and it isn't a problem to copy jars to multiple
> locations, but it does make version control and updates of jars kind of a
> pain.  Using the Class-Path: manifest header allows a system administrator
> to keep jars in a central place for easy control, while at the same time
> maintaining the compartmentalization of classpath space that you get with
> the web application class loader.  It would be easy enough to extend the web
> app class loader to parse out the Class-Path: headers in any
> META-INF/MANIFEST.MF files it finds in its repository directories and/or
> jars/zips.
> If I have time, I will look at the source tonight and see if I can't whip up
> a patch ...
> It seems to me that using existing classpath extension mechanisms is better
> than adding a non-spec extension to server.xml ...

Ideally, I'd be able to specify additional class paths in the web.xml file,
but that requires changing a spec. However, I was under the impression that
the server.xml file was defined by Tomcat, and so could be extended.

Using the manifest might be an acceptable solution; I didn't know about
that. However, I have these questions:

1) can the manifest be placed in an "open" or "expanded" .war archive (I'm
not sure of the terminology; whatever it is where have separate folders,
rather than a single .war file).

2) can this manifest be easily edited to add/change/remove class paths (i.e.
with a regular text editor)?

I'm not 100% sure that extending the web.xml file or using the manifest are
necessarily the best places for this, because it means that a context can
"extend its reach", so to speak, without intervention from anyone else. This
is potentially a security risk, since someone might install a webapp without
considering what it might touch.

If the control of additional classpaths is placed within the context's dir
contents, perhaps a flag in the Server.xml file indicating that a context is
allowed to "extend its reach" should be considered as well.

Thanks, Douglas, for looking into this for me. I really appreciate it.

Roderick Mann               rmann @

View raw message