GBean Granularity

[Aaron Mulder <am...@alumni.princeton.edu>]

	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

Re: GBean Granularity

["Alan D. Cabrera" <li...@toolazydogs.com>]

Geir Magnusson Jr. wrote, On 7/20/2005 4:53 PM:

>
> On Jul 20, 2005, at 12:21 AM, Alan D. Cabrera wrote:
>
>> David Jencks wrote, On 7/20/2005 7:04 AM:
>>
>>
>>> 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.
>>>
>>
>> I like the idea of a coarser grained GBean for simpler  
>> configurations.  Are the reasons for your preference for these  
>> "detail" GBeans purely for management?
>>
>
> I like the idea too, for the user (and keep dealing with fine-grained  
> optional...)
>
>>
>>> 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.
>>>
>>
>> I don't like the idea of GBeans being factories for other GBeans.   I 
>> think that the GBean configuration should be frozen at deployment  
>> time.  With that said, I like your preference for a specialized  
>> builder.
>
>
> So the builder would create any fine-grained beans that the user  
> didn't specify by default?

Yes, that was what I was thinking.


Regards,
Alan

Re: GBean Granularity

["Geir Magnusson Jr." <ge...@apache.org>]

On Jul 20, 2005, at 12:21 AM, Alan D. Cabrera wrote:

> David Jencks wrote, On 7/20/2005 7:04 AM:
>
>
>> 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.
>>
>
> I like the idea of a coarser grained GBean for simpler  
> configurations.  Are the reasons for your preference for these  
> "detail" GBeans purely for management?
>

I like the idea too, for the user (and keep dealing with fine-grained  
optional...)

>
>> 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.
>>
>
> I don't like the idea of GBeans being factories for other GBeans.   
> I think that the GBean configuration should be frozen at deployment  
> time.  With that said, I like your preference for a specialized  
> builder.

So the builder would create any fine-grained beans that the user  
didn't specify by default?

geir

>
>
> Regards,
> Alan
>
>
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: GBean Granularity

[David Blevins <da...@visi.com>]

On Jul 19, 2005, at 9:21 PM, Alan D. Cabrera wrote:

> David Jencks wrote, On 7/20/2005 7:04 AM:
>
>
>> 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.
>>
>
> I like the idea of a coarser grained GBean for simpler  
> configurations.  Are the reasons for your preference for these  
> "detail" GBeans purely for management?
>
>
>> 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.
>>
>
> I don't like the idea of GBeans being factories for other GBeans.   
> I think that the GBean configuration should be frozen at deployment  
> time.  With that said, I like your preference for a specialized  
> builder.
>

Side note; our builders are GBeans.  They just take the long way when  
creating other GBeans :)

On topic, you guys realize this is a "problem" we are seeing over and  
over again; the best runtime design is not necessarily the best  
config/management perspective.

-David

Re: GBean Granularity

["Alan D. Cabrera" <li...@toolazydogs.com>]

David Jencks wrote, On 7/20/2005 7:04 AM:

> 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.

I like the idea of a coarser grained GBean for simpler configurations.  
Are the reasons for your preference for these "detail" GBeans purely for 
management?

> 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.

I don't like the idea of GBeans being factories for other GBeans.  I 
think that the GBean configuration should be frozen at deployment time.  
With that said, I like your preference for a specialized builder.


Regards,
Alan

Re: GBean Granularity

[David Jencks <da...@yahoo.com>]

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
>>>
>>
>>
>

Re: GBean Granularity

[Aaron Mulder <am...@alumni.princeton.edu>]

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.

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
> >
> 
> 

Re: GBean Granularity

[David Jencks <dj...@gluecode.com>]

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
>

Re: GBean Granularity

[Jeff Genender <jg...@apache.org>]

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