geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: What do you want to get into M5?
Date Fri, 12 Aug 2005 21:33:34 GMT

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?

david jencks

> Aaron

View raw message