Rick Mann wrote:
>
> on 8/28/01 9:08 PM, Rob S. at [EMAIL PROTECTED] wrote:
>
> >>> 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.
> >
> > ...mainly because people don't take the time to understand the class loading
> > mechanism, and ask for things they wouldn't otherwise, if they knew what was
> > going on =) This happens a lot of times when people are learning new
> > technology.
>
> So, it seems that you're saying that I don't understand the class loading
> mechanism. Aside from the discussion about why that doesn't obviate the need
> for a way to extend the class path in the configuration files (be it
> Server.xml, web.xml, or in the war manifest), can you tell me if there is a
> solution here?
>
> I would like to be able to have a webapp find necessary classes in an
> arbitrary directory, specified as a property. If you can tell me what class
> I can invoke to perform this, then perhaps that would be enough. However, I
> still feel that the original request is valid.
I'll throw an idea out here, although it may well get shot down for
either spec non-compliance, possible security concerns, or just general
lack of sex appeal ;-)
I wouldn't mind providing a way for certain webapps to share classloader
a repository, primarily from a deployment point-of-view. It would be
nice to only have to deploy a new jar or class in one place rather than
several. Like most others who have responded, I am pretty -1 on having
Tomcat once again use the system classpath. That was way more trouble
than it was worth. I am also pretty hesitant to respect any paths
specified in a manifest, since that opens up something of a security can
of worms IMHO.
So how about this. What are the thoughts on removing the ".jar" check on
the WEB-INF/lib classloader, and making a few minor tweaks to allow
subdirectories to be loaded in addition to jars? That way, a subdir
could be a soft link to centralized directory if the wants to set it up
that way. From a security standpoint, I don't necessarily see it as
being any more troublesome than loading whatever jars happed to be
there. It is of course no possible to shoot yourself in the foot by
linking to a non-secured external directory, but that's really the
administrator's own fault. There are certainly plenty of ways to shoot
yourself in the foot already with a bad config. :)
Of course, I have no idea if this would be a spec issue or not. With the
finalization process coming up, I'd rather defer that to Craig for a
more expert opinion than my own reading.
- Christopher
/**
* Pleurez, pleurez, mes yeux, et fondez vous en eau!
* La moitié de ma vie a mis l'autre au tombeau.
* ---Cornelle
*/
