geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <hi...@hiramchirino.com>
Subject Re: [POLL] API and Implementation serialization compatibility and upgrading
Date Wed, 18 May 2005 13:20:18 GMT

Hiram Chirino
Sr. Architect
LogicBlaze, Inc. - a Simula Labs Enterprise
chirino@logicblaze.com
www.logicblaze.com
On May 18, 2005, at 12:28 AM, David Jencks wrote:

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

We just xslt to normal spring xml and pass that to spring.

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

I tried providing GBeanInfo for the existing components.  I ran into a  
few problems.  The first is that they take complex objects for  
configuration.  The second is that the gbean lifecycle did not really  
mesh well with the activemq lifecycle.  The third is that we don't  
really want proxied references.

> 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

I would be quite happy with a single manageable component for our  
configuration since the whole broker is deployed as a unit.  But I  
would also like to a managable components are runtime for stuff like:  
client connections, broker connections and dynamically created  
destinations.

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

yes.  I would not mind the many-little-gbean approach if I did not have  
to wrapper all the activemq components.  I also would not bind the 1  
big gbean solution if it did not have the serialization consequences.

Regards,
Hiram

> 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