geronimo-dev mailing list archives

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

> 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.
This would work just as well - I could simply wrap the instance that I 
wanted to inject into the kernel in a SingletonFactory that always 
returned it, but this, until my current proxying approach throws up a 
problem, is no longer an issue, just a refactoring now.

>>> 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.
I agree completely. I only got sidetracked into the lifecycle issue 
because David mentioned it as a concern.

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

now these are valid concerns.

> 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?
these are all things that will require someone having a deep 
understanding of both Geronimo and Spring proxying technologies and 
their interaction. I figured the best approach was to suck-it-n-see. 
With friends in both the Geronimo and Spring camp we should be able to 
overcome any issues that arise, or at least mark them as no-mans-land 
and steer people away from using the problem features with warnings etc.

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

all interesting areas to look into.

let me get the code checked in (I need the cglib upgrade) and then i 
will look at some more serious testing - I may need some advice on how 
to tickle the kernel into doing these things...

>>> Thanks
>> Thank you fot taking the time to go through this with me.
> Better sooner than later :-)

too true :-)


> -- 
> Jeremy

"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 * Open Source Training & Support.

View raw message