----- Original Message -----
From: "Leo Simons" <[EMAIL PROTECTED]>
To: "Avalon Development" <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
