geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: GBean Granularity
Date Tue, 19 Jul 2005 23:28:48 GMT

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

View raw message