geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: Geronimo/Spring integration - Moving forward... (Dain, David, Jeremy,... - Please read)
Date Wed, 09 Feb 2005 00:21:28 GMT
Jeremy Boynes wrote:

> I don't know enough about Spring's internals to really evaluate this 
> but here are a few questions.

Rob may like to qualify this, but I will give it a shot.

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

long running services - the SpringGBean will do a kernel load and a 
kernel start on each one at the start-time of the module and a kernel 
stop and unload on each one at module stop-time.

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

kernel stop and kernal unload in the SpringGBean that represents the 
module. You didn't see this because it was not part of the patch to the 

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

I believe that in certain cases it is a 1.3 or cglib proxy, if Spring 
needs to e.g. aspect it, otherwise i think it is whatever the user has 
specified i.e. probably a POJO - Rob ? We have to assume that it may 
have final methods because user space classes can do whatever they want.

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

If Geronimo held a persistant configuration for the POJO (my ultimate 
goal), then yes, this might be the case. If the same setter being called 
twice is a problem for the bean then i would say it was a badly written 
bean and this was a problem for the app-writer. We could get a bit more 
clever and merge Geronimo and Spring's injection so that each setter 
gets called once...

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

> 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 

> Thanks

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


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

"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