geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: [POLL] API and Implementation serialization compatibility and upgrading
Date Wed, 18 May 2005 13:55:30 GMT
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.

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


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

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

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.

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.

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

--
Jeremy


Mime
View raw message