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 01:09:47 GMT
David Jencks wrote:

> I think you are confusing jmx and lifecycle management.
>
> Jetty exposes some mbeans, but the mbean server AFAICT has nothing to 
> do with creating/destroying jetty components.

I never said it did - Jetty does this

>   In fact it looks to me as if the jetty mbeans are viewers that are 
> completely independent of the components that are doing the work.

Yes, as far as I remember, internal components are 'skinned' with MBeans 
to expose them. The MBean lifecycle matches that of the component - for 
the purposes of this conversation I have treated them as the same object.

>
> It's really easy to take an mbean and make it look like a gbean, that 
> is expose the same attributes and operations.  This has nothing to do 
> with the work the geronimo kernel does to manage lifecycle, namely 
> creating and destroying gbeans, and managing references between them.  
> There is no jmx concept that is very similar to a gbean reference.

Fine, so how would you take an existing MBean instance and having 
translated its interface into GBeanInfo/Data register it with the kernel 
so that any tool attached to the kernel will see it ? That's all i want 
and i cannot have, without jumping through hoops, because GBeanInstance 
will not accept an existing object, but insists on creating a fresh 
instance from a provided class. This is the issue that my patch 
addressed and that I have been trying to explain. Everything else is 
digression and red herring.

Jules

>
> However, in order to expose an mbean as a gbean AND get it in 
> geronimo, you have to be able to create the object in a somewhat 
> unconstrained way -- basically as you would want to in an IOC 
> container.  Jetty lifecycle management is extremely intrusive and 
> makes this difficult to achieve.   I haven't looked at tomcat.
>
> It seems to me that if a project has their components exposed as 
> mbeans, and they have a clean separation between the 
> deployment/construction/wiring code and the components themselves, it 
> should be very easy to simply wrap the components as gbeans and deploy 
> them in geronimo.  If there's a substantial deployment step, writing a 
> builder to construct the gbean configurations is also quite doable.  
> Even though these aspects are somewhat mixed together in jetty, it was 
> not all that hard to separate the phases, expose the components as 
> gbeans, and write a builder.
>
> The tricky part here is we are thinking of taking a completely 
> separate container and integrating it with geronimo.  Both are 
> fighting over the lifecycle stuff: if we can figure that out then 
> exposing the running components as gbeans will be easy.
>
> thanks
> david jencks
>
>
>
>
>
> On Feb 8, 2005, at 4:31 PM, Jules Gosnell wrote:
>
>> Jeremy Boynes wrote:
>>
>>> Jeff Genender wrote:
>>>
>>>> I think Jules has a point on this.  What about the use of other 
>>>> open source projects that manage thier own private mbean 
>>>> lifecycles, such as Tomcat?
>>>>
>>>
>>> Well, the obvious question is how does that integrate with a 
>>> Geronimo kernel that is not based on JMX?
>>
>>
>>
>> see my reply to David.
>>
>>>
>>>> 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.
>>>>
>>>
>>> I would say this is an artifact of mixing two different component 
>>> models in the same MBeanServer. They should either be separated or 
>>> more closely integrated.
>>
>>
>> see my reply to David - I think the onus is on Geronimo to meet 
>> integrating parties once, particularly when they implement the J2EE 
>> standard management interface, rather than leave each integration to 
>> do its own thing, with all the likely incomprehensible and duplicate 
>> code that this would involve.
>>
>> 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.
>> **********************************/
>>


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