You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Cameron Fieber <ca...@fieber.ca> on 2004/02/23 09:34:29 UTC
[merlin] JMX MBean autogeneration
Greetings,
I am in the process if migrating a Phoenix based app to Merlin, but I
need the MBean autogeneration functionality that exists in Phoenix.
I have a preliminary implementation of a Merlin lifecycle extension that
creates and exports MBeans for components. It is pretty much a port of
the MX4JSystemManager from Phoenix 4.0.4. It seems to work in my brief
bit of playing with it, and I will be exercising it more thoroughly as
part of my migration to Merlin.
Before I delve too much deeper into this area, I wanted to see what
currently exists in terms of design, coding, or even just random
thoughts for a component management facility in Merlin. If anything is
happening in the area I'd like to participate.
The code for the lifecycle extension is available at:
http://remsats1.hpr.for.gov.bc.ca/merlin-jmx.tar.gz
Regards,
-Cameron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] JMX MBean autogeneration
Posted by Cameron Fieber <ca...@gems6.gov.bc.ca>.
On Mon, 2004-02-23 at 02:51, Niclas Hedhman wrote:
> I haven't spend _that_ much thinking about it, maybe Stephen has a
> better
> view....
>
> My perception is that although LifeCycle extensions can be used for
> this, we
> have postponed the JMX implementation to a great degree because the
> "Deployment Model" (how components hangs together) was static until a
> "few
> hours ago".
> Now it is not anymore!
> Therefor, JMX subsystem should be created as a "facility", practically
> a
> service that has access to the DeploymentModel, and is typically more
> trusted
> than your average component.
>
> It then registers itself to the DeploymentModel and listens for
> changes, and
> creates/destroys MBeans as the model changes.
> Likewise the JMX subsystem can create new components by modifying the
> DM
> (which results in events and destruction/creation of MBeans...)
Sounds pretty cool. I'll look into the DeploymentModel and look at the
HTTP facility implementation as an example.
>
> If you want to "do it right", we would be grateful, and I suggest that
> Stephen
> in that case give you a set of pointers on where to look to understand
> how to
> migrate your current effort.
>
I'd definitely like to "do it right" so any pointers would be
appreciated.
> Niclas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] JMX MBean autogeneration
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 23 February 2004 16:34, Cameron Fieber wrote:
> Greetings,
Welcome.
> I am in the process if migrating a Phoenix based app to Merlin, but I
> need the MBean autogeneration functionality that exists in Phoenix.
We have been talking about it for long.
> I have a preliminary implementation of a Merlin lifecycle extension that
> creates and exports MBeans for components. It is pretty much a port of
> the MX4JSystemManager from Phoenix 4.0.4. It seems to work in my brief
> bit of playing with it, and I will be exercising it more thoroughly as
> part of my migration to Merlin.
>
> Before I delve too much deeper into this area, I wanted to see what
> currently exists in terms of design, coding, or even just random
> thoughts for a component management facility in Merlin. If anything is
> happening in the area I'd like to participate.
I haven't spend _that_ much thinking about it, maybe Stephen has a better
view....
My perception is that although LifeCycle extensions can be used for this, we
have postponed the JMX implementation to a great degree because the
"Deployment Model" (how components hangs together) was static until a "few
hours ago".
Now it is not anymore!
Therefor, JMX subsystem should be created as a "facility", practically a
service that has access to the DeploymentModel, and is typically more trusted
than your average component.
It then registers itself to the DeploymentModel and listens for changes, and
creates/destroys MBeans as the model changes.
Likewise the JMX subsystem can create new components by modifying the DM
(which results in events and destruction/creation of MBeans...)
If you want to "do it right", we would be grateful, and I suggest that Stephen
in that case give you a set of pointers on where to look to understand how to
migrate your current effort.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org