Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 98666 invoked by uid 500); 13 Aug 2003 12:52:40 -0000 Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: geronimo-dev@incubator.apache.org Delivered-To: mailing list geronimo-dev@incubator.apache.org Received: (qmail 98653 invoked from network); 13 Aug 2003 12:52:39 -0000 Received: from merlin.transdynatlanta.com (206.228.30.17) by daedalus.apache.org with SMTP; 13 Aug 2003 12:52:39 -0000 Received: by merlin.transdynatlanta.com with Internet Mail Service (5.5.2655.55) id ; Wed, 13 Aug 2003 08:49:20 -0400 Message-ID: From: Les Hazlewood To: "'geronimo-dev@incubator.apache.org'" Subject: RE: Dynamic MBeans. Was: Kernel Architecture Date: Wed, 13 Aug 2003 08:49:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36199.4DB08350" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36199.4DB08350 Content-Type: text/plain; charset="iso-8859-1" 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. > ______________________________________________________________ > ____________ > ------_=_NextPart_001_01C36199.4DB08350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Dynamic MBeans. Was: Kernel Architecture

Does anyone other than me see the irony here?  = :)

>> pasi.salminen@profitsoftware.com

Les Hazlewood

> -----Original Message-----
> From: Pasi Salminen [mailto:pasi.salminen@pr= ofitsoftware.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. =
> = ______________________________________________________________
> ____________
>

------_=_NextPart_001_01C36199.4DB08350--