On Jul 19, 2005, at 4:14 PM, Aaron Mulder wrote:
On Tue, 19 Jul 2005, David Jencks wrote:
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.
To clarify, I had in mind one master GBean that you configure in
your plan, and it would create child GBeans for the stuff we have
GBeans
for now (and potentially more) and hook them up to each other
appropriately. So I'm not proposing reducing the number of GBeans at
runtime, just the number you need to manually wire up in your plans.
The
"master" would read your config information and decide what "child"
GBeans
to create and how to configure them and so on.
If we can find one gbean that is always present and there's only one of
we might be able to write xml-reference builders to configure all the
"detail" gbeans using a custom xml schema. I'm hoping to find a few
minutes to see if the xml-reference-builder idea can be extended to
work outside a <gbean> element: if this works we could have a custom
xml schema for the entire tomcat "server"
In any case, I think we should follow the current architecture and
construct all the gbean configurations at deploy time, and not try to
figure out what to do at runtime.
david jencks
Aaron
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
