geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: [POLL] API and Implementation serialization compatibility and upgrading
Date Wed, 18 May 2005 22:39:29 GMT
Damn email delays.

Hiram Chirino wrote:
> On May 18, 2005, at 9:55 AM, Jeremy Boynes wrote:
>> 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.

Although there may be reasons wrapping is needed, this is not one of 
them. As this level the IoC is transparent.


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

OK, but that's a different requirement really :-)

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

That's not necessary. You had talked at one point about generating 
GBeanInfo by introspecting the class to avoid needing to do this and 
I'll admit I thought that was what you were doing.

The GBeanInfo can come from anywhere and does not need to come from the 
implementation class. This is by design so that implementation classes 
can be completely Geronimo-free.

> - I also adapting the life-cycle that geronimo provides so that it 
> compatible with the life-cycle that activemq uses.

Ah - now that may require a wrapper. There is a limitation in 
GBeanInstance in that it requires the component to implement 
GBeanLifecycle (which is obviously not transparent (and obviously not 
related to Serialization :-) )). We should remove this limitation and 
support invocation of any implementation's lifecycle methods.

> - I have components that need stuff like a DataSource injected into them 
> via setter injection.

That should work just by using a reference to a GBean the exposes the 
DataSource interface.

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

I had a quick look and, assuming we can address the lifecycle issue, I 
didn't see anything obvious that we could not support.


View raw message