Wouldn't option (3) -- modify the startup shell scripts yourself to
include whatever directories you want -- be easier than either (1) or (2)?
Of course, you're going to be on your own for resolving class loading
difficulties, but that's true under all of these scenarios.
Craig
On Wed, 29 Aug 2001, Rick Mann wrote:
> Date: Wed, 29 Aug 2001 13:41:41 -0700
> From: Rick Mann <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED], Christopher Cain <[EMAIL PROTECTED]>
> Subject: Re: Extending Server.xml configurability (for additional
> classpaths)
>
> on 8/29/01 1:15 PM, Christopher Cain at [EMAIL PROTECTED] wrote:
>
> > 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 think I'd complain mostly on the grounds of lack of sex appeal. ;-)
>
> Seriously, though, this amounts to tricking Tomcat, I think, and that
> solution does not seem terribly elegant.
>
> BTW, I missed the email that said Tomcat ignores CLASSPATH, but I've
> inferred now that it does (which explains why I couldn't get that approach
> to work).
>
> So, I'm left with two alternatives that should satisfy my sense of
> aesthetics, but one of which is easier for me (the app developer) to use.
>
> 1) Extend Server.xml to tell Tomcat what additional directories to put in
> the search path.
>
> 2) Add those search paths myself, in my webapp's code. Keep in mind that, as
> Rob S. speculated, I know very little about the ClassLoader mechanism.
>
> Solution (1) is my preferred choice, because it localizes the burden of
> expanding the search path to Tomcat, and provides the most security (the
> owner of the Tomcat installation has control of what the webapps have access
> to).
>
> Solution (2) works, assuming it can be done, and assuming I can get educated
> on how to do it. However, it adds work to each and every webapp developer,
> in that they have to write code, rather than adding a line to a config file.
> It also means there will be countless ways of specifying (hard-coding,
> private properties, etc), which complicates people working together.
>
> I'm going to look up the ClassLoader now, and see if I can learn anything.
>
> ------------------------------------------------------------
> Roderick Mann rmann @ latencyzero.com.sansspam
>
>
>
