geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <>
Subject Re: [POLL] API and Implementation serialization compatibility and upgrading
Date Wed, 18 May 2005 12:55:20 GMT
> Sorry if this has already been answered but with all the mail delays 
> ...
> 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:  
>> org/activemq/activemq.dtd
>> 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 am guessing that activemq-to-spring.xsl is converting an activemq 
> instance document described by the DTD into a Spring configuration 
> file, which Spring is then able to use to instantiate the broker 
> components. Is this right? (If not ignore the rest of this mail).

yes that's correct.

> If this is true, it seems plausible that you could provide an 
> activemq-to-gbean.xsl that converted the instance document into a 
> GBean service configuration file containing multiple GBean definitions 
> linked together with GBean references and configured with attribute 
> values. Given you have a DTD I would assume the values would be simple 
> types and hence would not run into serialization problems.

That would be outstanding but the problem is that we are wiring runtime 
components not really designed to be serialized.  This means that we 
have to create gbean wrappers for all to components being wired.  And 
doing that introduces the need to use proxied references which we 
really don't need.  We also support letting users override the default 
implementation class for a component which could be hard to do with a 
hard coded gbeaninfo.  And there are many components that can take 
complex objects like WireFormat, DeadLetterPolicy, RedeliveryPolicy, 
etc. as configuration attributes which would run into the serialization 
problems if they were changed in future versions.

> You could also implement this as a Geronimo ConfigurationBuilder that 
> took an activemq instance document and converted it directly to a 
> Configuration which could then be directly installed into any server.

Sure that would be the way to do transformation from activemq xml to 
gbean configuration.  But I still have the problem having to wrapper up 
a ton of the components.

> I'm sure you tried that and there must be some problem I can't see on 
> the surface - could you give us a bit more information on where it 
> wasn't working?

I'm just giving grief cause Geronimo is so close to being able to be a 
transparent IOC framework.  When I started doing the activemq 
implementation I noticed that it's not transparent at all.  At least 
for the ActiveMQ case it almost seems like the IOC system is only 
really useful for wiring together a gbean model of the configuration of 
the system.  Then those gbeans have to manually wire the ActiveMQ 
runtime components once they are started.


> --
> Jeremy

View raw message