geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: Spring integration...
Date Wed, 09 Feb 2005 00:06:11 GMT
Jeff Genender wrote:

> I think Jules has a point on this.  What about the use of other open 
> source projects that manage their own private mbean lifecycles, such 
> as Tomcat?


and not forgetting Jetty :-), which also exposes internals to JMX in 
this way - relevant parts of which, I expect, implement the relevant 
J2EE JSRs and would want to be made available to suitable tooling.

If all goes well with a proxy approach, this fn-ality will go into the 
Spring integration anyway, with a switch to disable it for the 
faint-hearted. So, either way, the kernel will be managing POJOs whose 
life-cycle it does not control. It's just a matter of how complex the 
code has to be and how many levels of proxy we want...

Jules

>
> A significant portion of the Tomcat underbelly infrastructure is 
> managed this way.
>
> In the debugconsole, I can see the Tomcat created mbean objects.  But 
> when I try to manage them (view, etc), the debugconsole throws an 
> Exception that the object is not a gbean.  I don't know of this is 
> directly related, but it would be nice for gernimo to allow the 
> plugged in components to manage thier own mbean lifecycles, and to be 
> exposed.
>
> Jeff
>
>
> Dain Sundstrom wrote:
>
>> I am definitely against this change.  A fundamental assumption of the 
>> current GBean code is it controls life-cycle, and I believe changing 
>> this would have a massive impact on the entire GBean architecture.  I 
>> do believe that you could get it to work for your small use case, but 
>> I believe that the impact will be much larger then a small use case.  
>> Further, I believe that you can use a delegation model to achieve 
>> this today without a kernel patch.
>>
>> I'm not saying that this should never change, but that this is not 
>> the time.  After certification, I would like to spend time rethinking 
>> the GBean architecture.  Specifically, I'd like to make it trivial to 
>> integrate Spring, Avalon, Pico, etc. components, and I'd like to make 
>> it easier to program with GBeans.  This means, taking a second look 
>> at the info object, data object, xml configuration, persistence, 
>> dispatching and life-cycle.  Anyway, this is something I believe can 
>> wait.
>>
>> -dain
>>
>>
>> On Feb 8, 2005, at 1:55 AM, Jules Gosnell wrote:
>>
>>> So, Guys,
>>>
>>> I've given you a few days to look over the minimal kernel patch.
>>>
>>> As I understood it we left the thread with two real options :
>>>
>>> 1) extend the kernel to allow acceptance of an existing object for 
>>> proxying via GBeanInstance, rather than always constructing such 
>>> objects itself.
>>>
>>> 2) submit a dynamically crafted class and required instance (as 
>>> constructor arg for said class). when class is instantiated and 
>>> injected result will be a proxy that is [largely] semantically 
>>> identical to (1). We must be able to proxy non-interfaces and final 
>>> methods.
>>>
>>> To summarise the debate over the two options :
>>>
>>> against (1), for (2)
>>> understandable reticence to change the kernel
>>> concern over the kernel losing explicit ownership of the life-cycle 
>>> of the object that it is managing
>>>
>>> for (1), against (2)
>>> we are talking about an extension, not a backwardly incompatible 
>>> change to the kernel
>>> I have demonstrated that such an extension would have minimal 
>>> footprint and implication
>>> (2) does not restore lifecycle ownership to the kernel
>>> (2) is complex, less efficient and will need to be repeated anywhere 
>>> someone needs this fn-ality
>>> (1) is simpler, more efficient and will only need to be done once
>>>
>>> Finding a resolution to this is, IMHO, critical to the Spring 
>>> integration. Otherwise I would let it go.
>>>
>>> I had a very similar problem integrating two other well known pieces 
>>> of open source some time ago. The host had a JMX kernel and the 
>>> thing that I was embedding had internal MBeans with their own 
>>> private lifecycles. I persuaded the powers-that-were to allow MBeans 
>>> that were not managed by the kernel to be exposed via it. A change 
>>> was made. The extension to the kernel was never rescinded. In fact, 
>>> at least one other integration now makes use of it. It enabled 
>>> embedded components to open themselves up to the services supplied 
>>> by the kernel in a way that could not be done before...
>>>
>>> I humbly await your judgement :-)
>>>
>>>
>>> Jules
>>>
>>>
>>>
>>> -- 
>>> "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.
>>> **********************************/
>>
>


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