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 <[EMAIL PROTECTED]> -----Original Message----- From: Jan Bartel [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 8:33 AM To: [EMAIL PROTECTED] 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.
