Does anyone other than me see the irony here? :)
>> [EMAIL PROTECTED]
Les Hazlewood
> -----Original Message-----
> From: Pasi Salminen [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 13, 2003 3:36 AM
> To: [EMAIL PROTECTED]
> 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.
> ______________________________________________________________
> ____________
>
