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 Tue, 23 Aug 2005 07:10:55 GMT

On Aug 22, 2005, at 7:29 PM, Aaron Mulder wrote:

> 	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.
fine with me, if it can be done quickly.

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

These are good ideas, but I don't think we should hold up m5 for them.
> 	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.

I'm in favor of keeping gbean names, making them more restrictive than 
object names so every gbean name can be converted to an object name, 
and having a separate query object.  I don't care that much about how 
many strings we store.  I would prefer to get this into M5, I don't 
think it will get into 1.0 if not in M5.

david jencks

> Aaron
> 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