Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer;
  b=0omo+RrueI3qbxycD0LhEDfE7PV2E3OSWTK0hlLomOoWWWxyfIjmBXUnYxUhCOqI4y9eTSrCCBjcL4QZ5VjfGaZ0y46AFuh81GkYtAAteRFIGv/Z9ZkIIz9aX3ZedAfqngoEJwZ645md3CgBPWKjPGyWpGXt6dvUdK46LRQH204=
  ;
Mime-Version: 1.0 (Apple Message framework v622)
In-Reply-To: <42FD15DD.8000207@savoirtech.com>
References: <21108273-1DEC-4F97-BCCB-94D3FA2B2B29@iq80.com>
 <fef0fb622ae9becedf69ebab58e7ecc5@yahoo.com>
 <7b3355cb050812122134599bf6@mail.gmail.com>
 <fdfbc232d96f773b0a5b2c60bf36fba7@yahoo.com>
 <Pine.LNX.4.58.0508121711200.1850@saturn.opentools.org>
 <42FD15DD.8000207@savoirtech.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <e81267d8c44e7941200892ba684f3c67@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: What do you want to get into M5?
Date: Fri, 12 Aug 2005 14:41:03 -0700
To: dev@geronimo.apache.org


On Aug 12, 2005, at 2:34 PM, Jeff Genender wrote:

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

You don't need the (java) source now to do these things.  You can 
modify an existing plan or write a new one, deploy it online or 
offline, and start geronimo using it rather than one of the standard 
plans.

Can you be more specific about what you need beyond this scenario?

thanks
david jencks

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