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 20:24:44 GMT

On May 18, 2005, at 9:55 AM, Jeremy Boynes wrote:

> Hiram Chirino wrote:
>>> 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.
> I must be missing something as I still don't see why serialization is 
> an issue. The attribute values would be coming from XML and so would 
> be simple types from the VM.

Right.  The problem with this approach is that I have to wrapper all 
the activemq components.  In other words the IOC geronimo provides is 
not very transparent.

>> 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.
> Hmm - as I read this, you sound like you are trying to avoid any GBean 
> references, which would make the entire broker config a single 
> attribute  and I agree that would impose the serialization 
> requirement.  I don't think that is the right way to go.

Right.  With the other approach you get serialization problems.  I 
don't think thats the way to go either.

>> We also support letting users override the default implementation 
>> class for a component which could be hard to do with a hard coded 
>> gbeaninfo.
> That should not be a problem - the GBeanInfo can be obtained 
> independently from the implementation class and so could be created 
> during the configuration build process by the XSLT or by the builder. 
> I thought you were doing this already for the base components.

I would not mind creating a builder.  Hopefully it will be simpler than 
the xslt that we currently use.  But if I go down that route I want it 
to support everything that spring supports and I don't want to have to 
wrapper all the ActiveMQ classes.

>> 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.
> If they were attributes.  But these sound like managed objects and the 
> easiest way to do that is to create GBean instances for them and wire 
> them together with GBean references.

Well, to me they are not really managed objects in the sense that they 
should not be changed at runtime.  Most of these objects are just 
configuration options and I want them hidden from a users runtime 
management view.

> You will only run into serialization issues if you start making 
> incompatible changes to the attribute set for these objects as the 
> loader is going to check that the attribute values contained in the 
> state are valid for the instance they are being loaded into. This is 
> not an issue with Java Serialization but a result of us checking for 
> incompatible changes and would also be an issue with any form of XML 
> persistence.

Xml persistence would not really have the same issues.  As long as the 
new builder maintains xml compatibility then the object model that the 
builder creates can be radically different.  This not the case when you 
are reconstructing from a serialized object.

> Also remember that this will be handled by the configuration manager 
> ensuring that the right version of the ActiveMQ codebase is loaded for 
> the broker configuration being run. I.e. if you give us a downrev 
> configuration we will run it using a downrev broker.

I agree that this is a non-issue if the user does always deploys of the 
new activemq server instead of just "patching" an old activemq jar with 
and update.

>>> 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 still don't get that unless you are trying to avoid using references.

- I was wrappering each component to define the gbean info for each 
- I also adapting the life-cycle that geronimo provides so that it 
compatible with the life-cycle that activemq uses.
- I have components that need stuff like a DataSource injected into 
them via setter injection.

>>> 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.
> That's not the intention. It could be the result if you don't use any 
> references, but that's not going to give you an good management 
> structure for your objects either (which I assume is one of your 
> intentions). I'd like to see a more concrete example - can we get on 
> IRC later to work through it?

Well that's what I've had to do with the activemq integration so far.  
It's been painful.  If there is an easier way I would love to know 
about it.  If you want to see the current ActiveMQ integration, please 
look at it not big 
a project since I only wrapped a few of the activemq components.  It 
would be ideal if this could be reduced to no wrappers and maybe a 
simple builder that converts the activemq xml to some geronimo friendly 


> --
> Jeremy

View raw message