tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob S." <>
Subject RE: Extending Server.xml configurability (foradditionalclasspaths)
Date Wed, 29 Aug 2001 23:39:38 GMT
> No worries; in fact, I really don't understand the mechanism.
> However, if it
> helps me, I'd like to understand it. Since then, I've read about the
> ClassLoader, SecurityManager, and System classes.

I'm still getting used to be back in Vancouver, so I dunno if Craig has
mentioned, or possible checked in, his Catalina classloader document, but
kudos to that thing, at least the old one.  It was really good.  I started
working on a class-not-found doc that approached the 'problem' from the
other angle, as in, "I've go

> I could
> experiment, but in
> what I've read, I not sure I can install a new ClassLoader/SecurityManager
> which will get used by all classes in my web app next time a
> class needs to
> be loaded. Is there a way to specify the ClassLoader used by a context?

You're talking about a source-level modification, right?  In the
org.apache.catalina.startup.Catalina (i *think*) there's the initial
creation of the non web-app classloaders.  A good place to start looking at
per-app class loaders is probably in whatever iterates through the <Context>
elements in server.xml.  Not too helpful w/out a class tho', sry =/

> I want to specify a subset of all installed contexts that have access. I
> don't want all installed contexts to have access, just the ones I specify.
> Now, to avoid changing the spec, which I understand to be the Servlet 2.2


> spec, which also understand to specify the structure of the
> web.xml file, I
> propose adding the functionality to the Server.xml file, which I
> believe to
> be defined by the core developers. If this is not the case, well, it makes
> my request more difficult.

Yep, one way could be as children of each <Context> element, because of the
encapsulation of <Contexts> by <Host> elements, it would be messy to have
something global where you specify paths since you can have the same
<Context> path over multiple <Host>S refer to something different.

<Context path="/foo"...>

but I still think you're better off having Ant or Make worry about it ;)

- r

View raw message