geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: What do you want to get into M5?
Date Tue, 23 Aug 2005 02:29:24 GMT
	Just pinging this thread again.  Are we all agreed that we should
provide a configuration solution for M5 (as discussed in this thread
previously), that generally speaking allows each configuration to declare
certain manageable attributes, and during GBean startup overrides the
saved values for those attributes with values it pulls out of a
user-editable XML file?  I think David J identified the point to intervene
during the loading process, so we just need any other feedback before
something is implemented.

	I'd also like to consider altering our J2CA WorkManager to use an 
external thread pool, so that we can have one group of thread pools that 
can be managed, and then various other things (WorkManagers, EJB 
network connectors, etc.) will have a reference to one of the thread pools 
defined there.  Jeff was also going to look into how hard it would be to 
cause Tomcat to use a Geronimo-provided thread pool for its network 
connectors instead of always using its own internal implementation.

	Also, we need to resolve the GBeanName issue.  I posted a 
description of a conversation we had at OSCon under the thread 
"GBeanNames" and no one replied.  I don't fancy going ahead with the 
current solution of reverting a really old patch right before every 
release.  I think we were close to agreement there -- perhaps we can agree 
to "store both Strings" for now, inefficient as it may be, and then we 
just need to decide whether to tackle this for M5.  I think it will be a 
very substantial change, as we'd be replacing ObjectName with GBeanName in 
most of the places we use an ObjectName.  It's big to commit to for M5, 
but perhaps even bigger to leave until a closer-to-1.0 release.


On Fri, 12 Aug 2005, David Jencks wrote:
> On Aug 12, 2005, at 2:26 PM, Aaron Mulder wrote:
> > On Fri, 12 Aug 2005, David Jencks wrote:
> >> What I'd like to see is:
> >> --gbeans have regular persistent attributes and manageable attributes
> >> --the configuration expose the manageable attributes of the gbeans
> >> inside
> >> --you can only change the manageable attributes of a compiled
> >> configuration: to change anything else you have to rebuild the config
> >
> > 	Just as a reminder, we already agreed on a strategy for
> > configurations where they will be able to be flagged as "immutable", at
> > which time you could only change what we're now calling manageable
> > attributes.  For a "mutable" configuration you could change anything.
> > Jeremy was going to think about what it would take to implement the
> > "mutable" flag on configurations, as well as adding version numbers 
> > and so
> > on.
> >
> >> --a database abstraction/interface for the manageable attribute values
> >> so we can save just these values: everything else is read from the
> >> config
> >> --a properties file or xml implementation of the db interface so 
> >> people
> >> can edit stuff.
> >
> > 	I'm fine with this -- I don't think it would be very hard to
> > implement.  I expect a GBeanInfo would have a separate Set of 
> > manageable
> > properties, and the "manageable property database" would be part of the
> > kernel, so when a Configuration starts a GBean it could look up any
> > manageable properties for the GBean and override them when loading the
> > GBean.  The only problem is that I'm not sure how we'd work around
> > properties that the GBean expects to be set in the constructor -- since
> > the GBean is deserialized the Configuration doesn't have the 
> > opportunity
> > to call the constructor, so (for the short term) we'd probably need to
> > require that manageable properties can be set via a setter before the
> > GBean is started (and then the Configuration could do it after the 
> > GBean
> > is deserialized).
> I don't understand what you mean here.  GBeans aren't serialized, 
> GBeanData's are.  If you look around line 282 of Configuration I think 
> there is an ideal opportunity to set the manageable attributes.
> >
> > 	I do prefer XML over properties, and since we don't (AFAIK) want
> > the kernel to depend on XMLBeans, I think we could use SAX or DOM to 
> > read
> > the database config.  I'm OK with that since I think it would be quite
> > simple -- something like:
> >
> > <config>
> >   <gbean name="...">
> >     <property name="port" type="java.lang.Integer">8080</property>
> >     <property name="host" type="java.lang.String"></property>
> >   </gbean>
> >   ...
> > </config>
> >
> > 	Oh, and since I know David J hates maintaining XML parsing code, I
> > volunteer.  :)
> It would still be nice to keep actual xml code out of the kernel 
> module... I wonder if this could go in a separate module?  So far the 
> runtime does not use any xml (except for axis)
> >
> >> With this, you really would have to be able to start a configuration
> >> before you could edit values, and there are still serious problems if
> >> someone edits the db while the server is running, or if someone 
> >> changes
> >> a configuration but not its version.
> >
> > 	Well, configurations don't have versions yet, and I think that may
> > itself be a big change, so I think we could go ahead with the 
> > manageable
> > properties but not the configuraiton versions for now.
> >
> > 	As far as changing the DB while the server is running, we can
> > either say that it only takes effect on restart or we can arrange for 
> > the
> > appropriate setter to be called at runtime.  We can also probably 
> > arrange
> > for calls to the setter at runtime to update the database.
> >
> >> Any other ideas on how to do this?  Any ideas on how long it would 
> >> take
> >> to implement some or all of this?
> >
> > 	I suspect it will take longer to agree on what we want than to
> > implement it.  :)
> >
> We just need to proclaim agreement now and start coding :-)
> How far along is your configuration editing code?
> thanks
> david jencks
> > Aaron
> >

View raw message