I'm against making coarser grained gbeans for this. In fact, I would
prefer to see gbeans for servlets, servlet mappings, and filters as
well.
If this is really a problem (i.e. it is something users will actually
want to configure rather than always using our setup) IMO the way to
fix it is with a specialized builder. An example is the login config
builder.
david jencks
On Jul 19, 2005, at 3:53 PM, 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. I'm not sure to what extent this is truly dynamic. I
mean, will you really want to fully customize the container, engine,
hosts, connectors, valves, and so on?
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.
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.
Aaron
