geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: Geronimo/Spring integration - Moving forward... (Dain, David, Jeremy,... - Please read)
Date Wed, 02 Feb 2005 21:04:29 GMT
Jules Gosnell wrote:

> Jeremy Boynes wrote:
>
>> Jules Gosnell wrote:
>>
>>>
>>> I would like to change the kernel - I don't think there is much 
>>> value in Spring support if the first thing we do is to start eroding 
>>> its feature set.
>>>
>>
>> Please not at this time - IMHO changes to the kernel now would pose 
>> too much risk to the rest of the project with the progress to J2EE 
>> certification.
>>
>> Let's explore this in detail first (cough, design work, cough) and 
>> fire off a branch specifically for Spring if necessary.
>>
> OK - I will explore it in my local filespace and see how invasive the 
> change that I need is - then I will come back with my findings and you 
> guys can comment.
>
> Jules

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.

So, Guys, what I am proposing is not really that scary is it ? What do 
you think ?


Jules

>
>> -- 
>> 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)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/


Mime
View raw message