geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <djen...@gluecode.com>
Subject Re: [POLL] API and Implementation serialization compatibility and upgrading
Date Wed, 18 May 2005 04:28:17 GMT

On May 17, 2005, at 3:19 PM, Hiram Chirino wrote:

> Hi David,
>
> Yes you are right.  Our current activemq broker configuration is a bit  
> simplistic.  I wish it was as easy to support complex broker  
> configuration in geronimo as it is in spring.  With spring we can  
> support a really rich broker configuration language see:  
> http://activemq.codehaus.org/checkout/activemq/modules/core/src/conf/ 
> org/activemq/activemq.dtd

Looks interesting.  I don't know much about spring.  Along with this  
dtd, what do you need to supply so spring will deploy and instance of  
this dtd the way it seems to imply?

>
> The question is what's the simplest way to do something similar with  
> geronimo?  I tried using the GBean approach and it took down a route  
> that seemed like I was going to have to create gbean wrapper classes  
> for each activemq component.  I was hoping for something more  
> transparent since the ActiveMQ components are very IOCish I don't  
> really see the need for extra gbean wrappers.

I'm not sure why you'd need wrappers rather than just GBeanInfos for  
each component.  Could you explain?  I would expect that it would be  
straightforward but probably more lengthy than what you do for spring  
to convert the dtd to a schema and write a builder that constructs  
gbean configurations from essentially the same configuration document  
as you are now using.

A question I have is, what is the size of unit that you want to be  
lifecycle-manageable?  Each component in the broker config or the  
entire config as a unit?  Do you want to be able to add more  
connectors, discovery agents, etc while the broker is running? If so I  
would think the many-little-gbean approach would be worth considering.   
If not I see why you were talking about making all the components  
serializable as a gbean solution; it would be pretty easy to write an  
xml-attribute builder to convert a config document into a configured  
broker, but at deploy time: the only obvious way to save it is indeed  
by serialization.

Hopefully the mailing list delay will go well under the current 6 hours  
so we can continue the discussion in more real time :-)

thanks
david jencks

>
> Regards,
> Hiram
>
> On May 17, 2005, at 2:39 PM, David Jencks wrote:
>
>> Slow down a minute.
>>
>> I just looked at the activemq gbeans used in geronimo currently and  
>> they appear to use for attributes only types from java.xxx.  As I  
>> already indicated in a previous post, the possible problems come from  
>> changing classes used as attributes and changing the GBeanInfo  
>> classes themselves.  An incompatible change in GBeanInfo classes is  
>> very likely to require redeployment of everything and redesign of the  
>> descriptors.  Since activemq is only using standard java types as  
>> gbean attributes, activemq is free to change all their classes as  
>> they see fit and make none of them serializable as long as the types  
>> and names of the gbean attributes remain the same.
>>
>> As far as the form of metadata needed for an IOC container, I  
>> currently prefer GBeanInfo to the alternatives I am aware of.  I  
>> think it's important to specify exactly what interface is presented  
>> to the container, which IIUC spring does not require, and after  
>> working a lot with the jboss xmlbean implementation and writing the  
>> xdoclet xmlbeans plugin, I think that xml is perhaps the worst choice  
>> possible, and javadoc tags not much better.
>>
>>
>> thanks
>> david jencks
>>
>> On May 16, 2005, at 4:13 PM, Hiram Chirino wrote:
>>
>>> Hi,
>>>
>>> From the ActiveMQ viewpoint,  we would rather:
>>>
>>>> PROJECT POLL:
>>>>   [ ]  We will do our best to ensure the implementations of our  
>>>> APIs are serialization compatible to future versions of our code.
>>>>   [X]  We do our best to ensure our public APIs, but use of our  
>>>> implementations in such a way is not supported by us.
>>>
>>> ActiveMQ standalone does not currently have these serialization  
>>> issues so it's unfortunate that for us to play nice with Geronimo we  
>>> would have to add on a Serialization requirement on our GBeans.   
>>> It's actually quite unfortunate that ActiveMQ even needs to  
>>> implement GBeans.  It just proves that the geronimo IOC container is  
>>> not transparent.  And adding the Serialization requirements makes  
>>> that even worse.
>>>
>>
>


Mime
View raw message