geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James deGraft-Johnson" <jdegr...@digaman.com>
Subject RE: [services] getting service developers started - the initial component model
Date Tue, 12 Aug 2003 14:26:51 GMT
I agree in principle, though I don't see how if the kernel framework is
based on MBeans, it will be easier to support MBeans created by J2EE
application developers.

Anyway, an approach to the kernel framework loosely based on MBeans has been
outlined in another thread, so I think we can worry about supporting JSR077
during design of the appropriate service.

James deGraft-Johnson
Software Engineer - IT
Verizon Information Services
Tel:         (240) 456-7018
Fax:        (240) 456-7072
Mobile:   (240) 475-1444 <jdegraft@verizon-uc.com>

-----Original Message-----
From: Jan Bartel [mailto:janb@mortbay.com]
Sent: Tuesday, August 12, 2003 8:33 AM
To: geronimo-dev@incubator.apache.org
Subject: Re: [services] getting service developers started - the initial
component model

I would have thought that we'd want to support JSR077 management for
J2EE from the outset. JSR077 describes lifecycles, events and
performance statistics for all J2EE components (everthing from ejbs,
datasources, jca through to web containers and servlets) that can be
modelled by mbeans.

It would be by far the simplest if geronimo's services were directly
based JSR077 mbeans, because:

1. we need to support JSR077 anyway
2. the simplest way to support it is directly, without extra layers of
    adaption code
3. there's nothing in the service lifecycle that cannot be encompassed
    by JSR077 mbeans

Jan

Alex Blewitt wrote:
>> My understanding of the JMX/MBeans idea from SUN is so that it is
>> possible
>> to create MBeans (Management Beans) as part of a J2EE application to
>> support
>> administration, management and monitoring of the J2EE application.
>> This is a
>> very powerful idea, which ideally will be supported by Geronimo.
>
>
> Absolutely. I have always been for there being a JMX /interface/ to
> Geronimo, but not as an /implementation/ of the kernel.
>
>> The use of a JMX/MBeans model for Kernel framework shouldn't
>> jeopardize the
>> above. In fact I assumed that the discussion of the MBeans as a service
>> component model was actually MBeans-like, i.e. basing the component
>> model on
>> the MBeans design. (We can structure the Geronimo kernel like JMX without
>> actually making the kernel a JMX implementation, so as to incorporate
>> into
>> the kernel the ability for J2EE application developers to create and
>> install
>> actual MBeans.) Because of the above, this is what makes sense for this
>> approach.
>
>
> I think there should be a distinction between the kernel and a JMX/MBean
> container -- they're not necessarily the same. Granted, that it may be
> desirable for MBeans to be incorporated in at a later stage, but by
> starting off with the doctrine 'everything is an MBean' then it's very
> difficult to be innovative and come up with ideas outside of the JMX spec.
>
> For example:
>
> public abstract Service {
>   public abstract String getName();
>   public abstract void start();
>   public abstract void stop();
>   public MBean getMBeanInterface() {
>     return new ServiceMBeanInterfaceAdapter(this);
>   }
> }
>
> public ServiceMBean implements GenericMBean {
>   private Service instance;
>   public ServiceMBean(Service instance) {
>     this.instance = instance;
>   }
>   public void start() { instance.start(); }
>   public void stop() { instance.stop(); }
> }
>
> That way, you can create subcomponents of Service that are entirely
> independent of JMX, whilst still providing a JMX interface to the same.
> Indeed, subclasses can provide their own specific JMXBean
> implementations if the default is not desirable.
>
> Additionally, if there is a move from using MBeans to another component
> architecture, then this will allow the same representation to be used.
>
> Alex.


Mime
View raw message