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 Thu, 19 May 2005 01:06:43 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.

An at other levels the IoC is not not transparent.  The mere fact that 
references are proxied introduces a level of non transparency.  
Example: if a proxy reference is used as a key in map then the proxy 
will break the equals(Object o) implementation since the class of the 
object and the proxy to the object's class are not the same.

> <snip/>
>>>> 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 :-)

I'm just saying the don't sound like managed objects to me.  Do you 
think everything should be a managed object?  It's such a pain to 
provide an object name for stuff that that is only going to be 
referenced by one object and that you don't even need exposed for 
runtime management.

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

Yep I was going down that route and I actually had a prototype working 
that defined the GBeanInfo via XML configuration.  I was hoping that by 
doing that geronimo would tottaly transparent and I would not have a 
geronimo dependency the activemq components.  But I started running 
into the roadblocks that caused me to notice that I had to wrapper my 
objects and I dropped the idea since I was going to have to depend on 
the geronimo jars anyways to implement the wrappers.

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

That would be nice :)

>> - 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 didn't know we had a gbean in the default geronimo deployment that 
implemented DataSource.  What's it's object name?

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

Well it's been a long time since I did that gbean exercise for activemq 
I hope I'm not forgetting anything.  One thing in the back of my mind 
is that way references were working was breaking our model but that may 
have been fixed since when I was attempting this stuff.  I think 
references are now valid once they have been injected into the 

> --
> Jeremy

View raw message