Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Development" <avalon-dev@jakarta.apache.org>
From: "Leo Simons" <mail@leosimons.com>
To: "Avalon Development" <avalon-dev@jakarta.apache.org>
Subject: RE: MBeanComponentManager ???
Date: Thu, 14 Jun 2001 07:56:29 +0200
Message-ID: <LPBBIELKDCIBOMAGCPIOMEKKDFAA.mail@leosimons.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <000901c0f47a$81ed3d90$65634318@home.com>

> > > At 11:11 PM 6/12/01 -0600, Mircea Toma wrote:
> > > >The ComponentManager will use internally a MBeanServer to lookup
> MBean-s
> > > >using role names which in this case will be the MBean's object
> > > name. Also it
> > > >uses the MBeanServer to manage Component/MBean lifecycle by calling
> > > >mBeanServer.isInstaceOf(...) in order to learn what to do with it.
> >
> > I'm all for filling gaps in Java specs, but this sounds like a
> > 'modification'
> > which is probably not something we should do here at Apache. But that's
> not
> > my primary concern.
> >
> > Conceptually, the MBeanServer is there to expose a management interface
> > to humans / console apps / cronjobs / init scripts / whatever. the JMX
> > impl(s) are written to support this. When you use an MBeanSever as the
> > component manager, you loose inversion of control (probably),
>
> ......why??

The MBeanServer manages MBeans, which are not Components. Using it to
manage Components is a 'hack'.

> > The ComponentManager needs to be speedy, JMX isn't (doesn't have to be).
>
> .....yes, but it will be a distributed ComponentManager if the
> MBeanServer is
> distributed.

In distributed envs it will definately be useful. It's still better to
code your DistributedComponentManager from scratch tho =)

> > I think that what should be exposed for management (by phoenix) are
> > ServerApplications. Finer graining is inappropriate here. And of course,
> > life cycle management for those could be handled with a MBeanServer
> > (something we've talked about but have yet to decide on).
> >
> > Finally, making the assumption {MBean object name} == {role name} may
> > cause problems in some apps; it probably violates some
> framework contract.
>
> ......then maybe the framework contracts are to tight!

I don't think so. We don't specify dots as separators yet, the JMX spec
does. I have to look up the details but it seems possible to have role names
that the MBeanServer won't expect.

Conclusion: if you need a distributed system, using JMX definately saves you
a lot of time (but it still feels 'hacky' to me). Phoenix is usually
conceived
as lower level than that, so it should not use JMX for comp management.

Cheers,

Leo Simons


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org