geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pasi Salminen <pasi.salmi...@profitsoftware.com>
Subject Re: Dynamic MBeans. Was: Kernel Architecture
Date Wed, 13 Aug 2003 17:16:06 GMT
At least I don't so could you be a little bit more specific?

Paci

Les Hazlewood wrote:

> 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.
> > ______________________________________________________________
> > ____________
> >
>

__________________________________________________________________________

This message and its attachments have been found clean from known viruses 
with three different antivirus programs.
__________________________________________________________________________
Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message