RE: Extending Server.xml configurability (for additional classpat hs)

[Douglas Seifert <ds...@SeeBeyond.com>]

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 ...

-Doug Seifert

> -----Original Message-----
> From: Reilly, John [mailto:John.Reilly@xelector.com]
> Sent: Tuesday, August 28, 2001 2:14 AM
> To: 'tomcat-dev@jakarta.apache.org'
> Subject: RE: Extending Server.xml configurability (for additional
> classpat hs)
> 
> 
> 
> 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?
> 
> jr
> 
> > 
> > I've seen lots of discussion on the user list desiring the 
> > ability to have
> > additional classpaths available to web applications, but not 
> > necessarily
> > available to all web apps.
> > 
> > Ideally, this could be specified in the web.xml file, but 
> > that would require
> > changing a spec, and I can think of some arguments against 
> > doing so anyway.
> > 
> > But, perhaps it would be possible to add classpath 
> > specifications in the
> > Server.xml file. Inside a context tag, you could specify 
> > something like
> > this:
> > 
> > 
> <additional-classpath>~someuser/somedir/classes<additional-classpath>
> > 
> > Multiple occurrences of this would just add to the locations 
> > where classes
> > can be found.
> > 
> > An alternative for us would be to do something with the class 
> > loaders in our
> > own web apps, if that's possible, but I'd like to see 
> Tomcat have the
> > functionality.
> > 
> > Can someone give me some pointers to get started adding this 
> > particular
> > configuration tag? I'd really appreciate it.
> > 
> > BTW, I'm currently working with the 4.0b7 codebase. Thanks!
> > 
> 

Re: Extending Server.xml configurability (for additional classpaths)

[Rick Mann <rm...@latencyzero.com>]

on 8/28/01 2:13 AM, Reilly, John at John.Reilly@xelector.com 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 dseifert@SeeBeyond.com 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 @ latencyzero.com.sansspam