geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <lhazlew...@transdynatlanta.com>
Subject RE: Dynamic MBeans. Was: Kernel Architecture
Date Wed, 13 Aug 2003 12:49:15 GMT
Does anyone other than me see the irony here?  :)

>> pasi.salminen@profitsoftware.com

Les Hazlewood

> -----Original Message-----
> From: Pasi Salminen [mailto:pasi.salminen@profitsoftware.com] 
> Sent: Wednesday, August 13, 2003 3:36 AM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: Dynamic MBeans. Was: Kernel Architecture
> 
> 
> Hi,
> 
> At least I'm in favour of model MBeans. They can be described 
> in XML (which I think is a good idea) and they can have 
> annotations. What does it say to an administrator if he can 
> see an operation stop? For us (being professional J2EE 
> propeller heads) it may be obvious but for an administrator 
> it would be nice to see some description of the operation or 
> attribute he is trying to invoke or manipulate. That's why 
> model beans are nice. And if the configuration file is 
> implemented so that it can "dig" information out of the bean 
> (if not overridden in the XML configuration) that's cool and 
> keeps configuration simpler.
> 
> Also, I think it would be good idea to use just simple types 
> in the interface of the beans. Otherwise integrating those 
> beans with management consoles gets really nasty (for 
> example, compiling some stuff again or adding classes to 
> classpath of the console).
> 
> Secondly, I don't understand why some of you are so afraid of 
> JMX. Nobodys afraid of HTTP fading away. It's there in the 
> spec and it'll be part of the server anyhow, just like servlets.
> 
> However, whoever has proposed JMX (kernel) to be used as an 
> invocation bus, I not sure if I agree with him/her. The 
> MBeans could just expose, for example the HTTP support, and 
> from then on it just controls when to stop it and how to get 
> performance metrics (etc) from it. Inter-service 
> bindings/lookups could of course be implemented with JMX 
> relation service...
> 
> Br. Paci
> 
> "Bordet, Simone" wrote:
> 
> > Hi,
> >
> > > Using model mbeans instead of standard mbeans has many advantages.
> >
> > Uhm, I admit to have little knowledge of JBoss' XMBean, but 
> what are 
> > the real advantages of using ModelMBeans (and all the stuff they 
> > carry) ?
> >
> > I think it can be useful to have DescriptorAccessible 
> MBean*Info, but 
> > once again, how do you configure it ?
> >
> > > As I recall someone (Simone?) offered to write an xmbean 
> model mbean 
> > > for mx4j.
> >
> > Yes, it was me :)
> > I even started, but stopped after a while failing to see a definite 
> > use case for them. I don't say they don't have a useful use 
> case, but 
> > that I fail to see it. Lack of experience on my part, I imagine. 
> > ModelMBeans are a pain to configure (very verbose xml files) while 
> > most of the times the metadata can be obtained from the 
> resource (at 
> > the end, you want to call its methods: why not generating 
> the metadata 
> > automatically - a la std mbeans - and add only useful stuff ?).
> >
> > I need a clear use case for XMBeans.
> >
> > > We can use the xdoclet JBoss xmbean template as a
> > > starting point
> > > and generate the xml descriptor from the source.
> >
> > Wouldn't that look too similar to JBoss ?
> >
> > > For now we can generate standard mbean interfaces and, 
> when we get 
> > > an xmbean impl.  switch over with minimal  effort.  Including 
> > > appropriate documentation now will make the switch easier.
> >
> > This brings me to another question: how difficult is to move to a 
> > plain java object (a la Avalon) and have an XMBean that can 
> wrap java 
> > objects automagically ? If the microkernel is responsible to create 
> > the various components, then it can also XMBean-wrap them (or not).
> >
> > Another point worth to discuss is invocation performance: remember 
> > that calling via JMX is waaaaaay slower than with reflection: the 
> > MBeanServer must perform a lot of additional checks to 
> ensure the JMX 
> > specification is respected. I think using it in the container 
> > invocation chain (which should be able to support a LOT of 
> > invocations/second) would really slow down the container 
> performance.
> >
> > Simon
> 
> ______________________________________________________________
> ____________
> 
> This message and its attachments have been found clean from 
> known viruses 
> with three different antivirus programs. 
> ______________________________________________________________
> ____________
> 

Mime
View raw message