Rick, this is really what I was trying to say. Chris puts it so well I may
as well stop replying ;)
- r
> True, server.xml is Tomcat-specific, fluid, and can be changed, for the
> most part, at will. The reason you will have trouble convincing many of
> the core developers to change server.xml is because what are you are
> proposing skirts dangerously close to encouraging non-portability. As
> the official RI for the specification, the general idea is to think very
> carefully about adding any feature which, if taken advantage of in a
> webapp, would fail to run on another spec-compliant container. Allowing
> admins to specify additional classpaths (in a config file) for a webapp,
> above and beyond what is explicitly provided for in the spec, is a risky
> proposition. Classloading is one of those issues that generally gets a
> lot of thought towards portability before any changes are made.
>
> I'm not saying that there might not be a workable solution to the issue.
> I'm just saying that in proposing changes to server.xml for that
> particular issue, you are probably headed down the wrong path for the
> above reason, primarily. If you aim is to see your solution incorporated
> into the product, that is. Otherwise, go nuts :)
