tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <>
Subject RE: [next] What's next ?
Date Thu, 02 Oct 2003 15:56:58 GMT


>> 2. Eliminate the shared and common classloader repositories.  Unless
>> these are required by the spec?  Force webapps to be self-contained
>> putting all their classes in WEB-INF/lib or WEB-INF/classes of their
>> webapp.  Have the WEB-INF/clases -> WEB-INF/lib -> endorsed -> system
>> classloader hierarchy, much simpler than current.
>I believe many people won't like that one. It's quite radical :) It is
>true that it would be much simpler to run only "straight" webapps,
>without exceptions.
>I think this kind of classloading structure can be configured in TC 5
>using the

If it can be achieved via configuration, I'm happy ;)  How can it be

Vis a vis native libraries and reloading -- I didn't have that scenario
in mind.  I don't know what to do about that one.  So what you're saying
is there's no way to deploy a self-contained webapp (everything under
the webapp root), and be able to restart it without restarting the
server, if you're using a native library in your webapp?

>> 3. Provide a complete working configuration example for a cluster of
>> tomcat servers with a front-end tomcat as well, i.e. a pure
>> solution.  We already have the jvmRoute mechanism, but I think it
>> more examples/documentation so that people start using it.
>So you want to do a HTTP load balancer ? I think this would be a really
>good project for the commons.

I had something even simpler in mind:
- A cluster of backend tomcat servers
- A single tomcat front-end server, with one filter mapped to /* that
has configurable rules on how to direct requests to the backend servers.
(e.g. string match in URL rules, remote address rules, etc.)

But as someone mentioned, I also think an HTTP load-balancer was
discussed as a future version of ajp1[3-4].  I should search the
archives for those threads.

>> 4. Have no default objects created at runtime.  That means no default
>> session manager if one is not configured, no default context if one
>> not configured, etc.  Ship tomcat with an example server.xml
>> all the default settings, and nothing more.
>Is that useful ? I don't really see how. (ex: if you have no loader for
>a webapp, it won't work) I think you should elaborate more.

I suggested that one in order to simply supporting users.  The less
stuff that happens behind the scenes as far as configuration, the
better.  It should all be visible, so that on the user mailing list we
can say "this happens because line XXX of server.xml you have this
string."  Contrast with "as part of tomcat's default context
initialization, the property gets assigned this default value, which you
can override by adding this element to server.xml, see config reference
here."  The more users can see by themselves by inspecting server.xml,
the better IMHO.

Yoav Shapira

This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message