Howdy, >> 2. Eliminate the shared and common classloader repositories. Unless >> these are required by the spec? Force webapps to be self-contained by >> 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 catalina.properties.
If it can be achieved via configuration, I'm happy ;) How can it be done? 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 tomcat-only >> solution. We already have the jvmRoute mechanism, but I think it needs >> 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 is >> not configured, etc. Ship tomcat with an example server.xml containing >> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
