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: What do you want to get into M5?
Date Fri, 12 Aug 2005 21:26:58 GMT
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 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">0.0.0.0</property>
  </gbean>
  ...
</config>

	Oh, and since I know David J hates maintaining XML parsing code, I 
volunteer.  :)

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

Aaron

Mime
View raw message