geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: GBean Granularity
Date Tue, 19 Jul 2005 23:14:02 GMT
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
> >
> 
> 

Mime
View raw message