Aaron Mulder wrote:
I was just poking around the Tomcat GBeans a little trying to get
the broken test to work, and there seems to be a moderately complex
structure there.
Yes it follows the Tomcat structure of the server.xml and context.xml.
I'm not sure to what extent this is truly dynamic.
It is dynamic, thats why you see the
Container-->GBean--->Host(s)--->Context(s) structure. You can mix and
match...add additional hosts (for virtualization), etc. It also allows
you to make pluggable Realms, Valves, etc.
I mean, will you really want to fully customize the container, engine,
hosts, connectors, valves, and so on?
Yes...this is one of the powerful facets of Tomcat. Altering Realms is
one of the biggest uses of Tomcat.
What's the feeling on making a coarser GBean that takes a lot of
configuration settings and then instantiates all the more detailed GBeans?
I mean, we might be able to get by with a master Tomcat GBean with set of
more manageable configuration information like (ignoring the format):
tomcat.hosts=localhost,my-host-name
tomcat.http.enabled=true
tomcat.http.port=8080
tomcat.https.enabled=true
tomcat.https.port=8443
tomcat.ajp.enabled=false
We not be able to fully eliminate valve chain GBeans and stuff,
but it would be nicer if we had some more "deployer-like" code to set up
the finicky bits based on a simpler set of configuration data.
Yes...in this instance its doable. As you stated though, the Valves,
Realms, etc, would be difficult to do.
No urgency, I'm just wondering if there's a strong feeling in
favor of very fine-grained GBean configuration in our plans. It's
certainly more flexible, but as the test goes to show, more fragile too.
The test break was my fault...I caught a bug...I'll have it fixed shortly.
Aaron
Jeff
--
Jeff Genender
http://geronimo.apache.org
