geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: What do you want to get into M5?
Date Fri, 12 Aug 2005 21:34:21 GMT
Can you clarify for me this...

I have Jetty...and I want to add a connector.  I want my application to 
listen on port 9000 too.  I need a GBean.  Do I need the source?

I have Tomcat, and I want to add a logging Valve or Single Signon Valve. 
  I need a Gbean.  Do I need the source?

I need to be able to configure these things and have the ability to add 
a GBean w/o the source.  Will we have this capability for M5 or 1.0?


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

View raw message