On Mon, 27 Aug 2001, Rick Mann wrote:
> Date: Mon, 27 Aug 2001 19:20:08 -0700
> From: Rick Mann <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Extending Server.xml configurability (for additional classpaths)
>
> 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.
>
Historical note - Having been one of the primary answerers of questions
on TOMCAT-USER for the last couple of years, I've accumulated a feel for
the most commonly repeated classes of questions for Tomcat 3.0 - 3.2:
* Configuration of Apache connector
* Classpath problems
* Everything else
With 3.3 and 4.0, the second category of questions has totally disappeared
-- the mechanism in use is clearly understood (all JAR files in the "lib"
directory are automatically made available to all web apps), and it skips
the need for users who have never seen an environment variable before from
having to care about them.
My conclusion, then, is that this change (to ignore the CLASSPATH
environment variable) was very positive, and it would be *extremely*
difficult to convince me to go back to the problem-causing approach.
> 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.
>
Spec changes *cannot* happen here. The appropriate feedback address is
"[EMAIL PROTECTED]".
> 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.
>
Certainly, such a thing is possible. I would still argue that it's *not*
desireable. Disk space costs are so trivial that it's just not an issue
-- the only valid point for discussion is the management of your
application deployment processes. And it is very feasible to set up
processes to take advantage of the existing machinery to create a stable,
predicatable, runtime environment without using classpaths at all (in the
same way that Ant lets you totally free yourself from worrying about
classpaths at compile time).
> 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!
>
>
You would need to change at least the following code:
* org.apache.catalina.core.StandardContext - Add methods to store the
additional classpath variables included in server.xml
* org.apache.catalina.startup.Catalina - Add additional XmlMapper rules
to recognize the <additional-classpath> element and call the
corresponding storage methods on the context
* (Several classes) - Ripple down the collected "extra classpath" things
into the initialization of the web app class loader.
Note, however, that doing this kind of thing makes your application both
more fragile (you've got to get that many more configuration settings just
right in order for your app to work) and that much more Tomcat-dependent
(since this is not a feature that is necessarily portable).
Craig McClanahan
