geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: Geronimo/Spring integration - Moving forward... (Dain, David, Jeremy,... - Please read)
Date Wed, 09 Feb 2005 00:03:37 GMT
I don't know enough about Spring's internals to really evaluate this but 
here are a few questions.

The intent behind GBeans is that they are long running services - for 
example, running for the lifetime of an application. Is that how Spring 
would be using them or are you trying to create/delete instances 
frequently (say on each web request)?

I didn't see anything in the patch about unregistering an instance - how 
would that happen?

Is the target really the user's POJO or is it a Spring proxy? If the 
latter, doesn't it have final methods which would cause a problem for 
Geronimo trying to create proxies to it when it is referenced by other 
GBeans? If the former, is there a problem with having two proxy stacks 
(Spring's and Geronimo's)?

Doesn't the instance get double initialized - once via Spring and then 
again via setter injection from the GBeanData?

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?

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 


Jules Gosnell wrote:
> I enclose a minimal (15 lines changed/added) patch to the kernel which 
> allows a  POJO to be passed via Kernel.loadGBeanProxy(). This POJO is 
> subsequently used as the target of the ensuing GBeanInstance. If the 
> target is already initialise, the GBeanInstance does not bother to 
> construct a fresh instance of its target's class, it just uses the one 
> it has been given.
> Pros:
> It allows existing POJOs to take advantage of management and monitoring 
> services provided by the kernel.
> Cons:
> person providing this POJO needs to be careful about managing its 
> lifecycle - it must be loaded into the kernel after construction and 
> unloaded before destruction. If it implements GBeanLifecycle the 
> relevant methods will be called at the relevant time.
> Thoughts:
> This is really a minimal patch, designed to demonstrate exactly what I 
> am talking about in the simplest manner. It should be immediately 
> obvious that if no target is supplied the codepath will be completely 
> unchanged. The path, if you do supply the target is suboptimal, many 
> lines are still executed finding constructors and arranging parameters 
> for them when they will never be called. Making the current requirement 
> for target classes to provide accessible constructors conditional on 
> whether a preconstructed target is not supplied will take a little more 
> effort, but I don't see any real issue with this.

View raw message