avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mircea Toma" <mircea.t...@calgary.qcdata.com>
Subject Re: MBeanComponentManager ???
Date Thu, 14 Jun 2001 15:39:59 GMT

----- Original Message -----
From: "Leo Simons" <mail@leosimons.com>
To: "Avalon Development" <avalon-dev@jakarta.apache.org>
Sent: Wednesday, June 13, 2001 11:56 PM
Subject: RE: MBeanComponentManager ???


> > > > 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'.

It may be a 'hack' but it doesn't brake inversion of control by not
implementing Component iterface. Altough MBeans are components, you only
have a different tagging interface (*MBean) ........ and you can make them
"Component"-s any time.

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

Of course you may have role names that MBeanServer won't expect but the
MBeanComponentManager will mange only MBean-s (Cocoon2 has specific CM-s
too).

>
> Conclusion: if you need a distributed system, using JMX definately saves
you
> a lot of time (but it still feels 'hacky' to me).

Still....you didn't put the finger on the problem yet!

> Phoenix is usually
> conceived
> as lower level than that, so it should not use JMX for comp management
>
> Cheers,
>
> Leo Simons
>
>

Cheers

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


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


Mime
View raw message