geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: Geronimo/Spring integration
Date Wed, 09 Feb 2005 06:25:54 GMT
Jules Gosnell wrote:

<snip for the sake of clarity on the following points/>

>> To what extent is it necessary for Spring to register the actual POJOs 
>> at runtime? How much can be built before hand and be packaged into a 
>> Geronimo Configuration?
> Good question.... I guess it comes down to the fact that user code may 
> be supplied to create the beans inside Spring. So, these must be created 
> at runtime, since we have no protocol with which we can 
> dehydrate/rehydrate them in the way that we can a normal J2EE app. 
> Since, I don't actually see the full set of Beans until runtime, i don't 
> have a chance to build GBean proxies for them until this point. maybe we 
> can break up the process somewhere in Spring and get all this 
> information out without actually creating the bean instances themselves 
> - Rob ?

Would an alternative here be to change the GBean wrapper so that instead 
of constructing the target itself it called out to a factory defined in 
the GBeanInfo? Basic Geronimo could continue to use the constructor but 
we would call back to Spring or the user's factory.

>> To me, the challenges here are not in the lifecycle but in how 
>> references between objects are handled. I would have thought some 
>> level of proxy integration would also be needed with integration at 
>> this low a level.
> So, can we drill down on this - what problems do you foresee that 
> putting a proxy, dumb or otherwise, between me and you will solve ? I 
> simply create the beans when i am started and destroy them when i am 
> stopped....

I think there are two things going on here.

Firstly, there is a desire to expose Spring components to management via 
Geronimo's infrastructure (JMX or otherwise). In the same way Spring can 
register them directly with JMX, we would like to support the ability to 
register them with Geronimo - this is what your patch is doing and in 
this simple scenario I see no issues.

Secondly, and this is where I see concerns, is that both Spring and 
Geronimo already intercept inter-component references and replace them 
with proxies. If the reference type is a interface we may be OK, but we 
both support proxied references to classes and I am concerned about 
interference between the two proxy mechanisms - for example, if the only 
thing Geronimo knows about is the cglib proxy and it contains final methods.

In any non-trival example, the POJO you are registering is going to 
contain Spring proxies for the inter-POJO references. Can we leave those 
as they are, or do we need to re-proxy them with Geronimo references? Do 
we need to add a mechanism to the kernel to allow Spring to obtain a 
Geronimo reference to a GBean so that it can inject it up front?

Geronimo transparently re-proxies references (and updates collection 
valued ones) as a referenced GBean gets loaded and unloaded. Will this 
continue to work with Spring proxies present?

>> Thanks
> Thank you fot taking the time to go through this with me.

Better sooner than later :-)

View raw message