You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Mircea Toma <mi...@home.com> on 2001/09/07 07:44:17 UTC
JMX and stuff...
Hi,
I was browsing through the mailing-list archive trying to find reasons why
certain decisions have been taken and also I checked out the to-do list to
see which are the overlaps between Avalon needs and my needs. The conclusion
was that remote management (JMX), hot deploy (preferably with remote loading
of blocks) and LogKit new management are the things that I would like to
have (and work on of course).
What strike me about JMX management is that in Avalon the configuration has
a hierarchical structure (and that's really sweet) but with JMX you can
change only properties, which have a flat structure. Another thing is, if
the blocks made available for management will have very little things to act
on (only the methods that have no args or with primitive arguments). Right
now this can be changed only by making the block follow the JavaBean pattern
(Leo Simon already said this) in order to change the configuration values
but this will brake the Avalon framework contracts (I think!). So, the idea
that came to me (might be a childish one) was to somehow ??? make available
for management the values stored in the ConfigurationRepository in a
structured fashion, in this way when some value was changed by the agent the
reconfigure(...) method will be called on the blocks implementing
Reconfigurable. This will work well also if the SystemManager will use JNDI
to manage the blocks.
The existing mechanism in Phoenix for registering blocks allows only actions
(not values/properties) to be made available for management: like "start",
"stop", "deploy", "undeploy" ...
I guess I was trying to revive the remote management subject which seems to
be stalled for a while now.
Mircea
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JMX and stuff...
Posted by Paul Hammant <Pa...@yahoo.com>.
Mircea,
>[...] The conclusion
>was that remote management (JMX), hot deploy (preferably with remote loading
>of blocks) and LogKit new management are the things that I would like to
>have (and work on of course).
>
>[...] I guess I was trying to revive the remote management subject which seems to
>be stalled for a while now.
>
Leo Simons (may he holiday/party in peace) left quite a gap.... sure
take it Mircea, people will sure speak up if you do the wrong thing to
it so code away... :-)
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JMX and stuff...
Posted by Mircea Toma <mi...@home.com>.
Hi,
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Saturday, September 08, 2001 6:57 PM
Subject: Re: JMX and stuff...
> On Sun, 9 Sep 2001 05:10, Mircea Toma wrote:
> > > So Type 1 (kernel et al) management can be done via normal JMX
> > > mechanisms.
> >
> > It
> >
> > > includes the actions you list above (ie
start/stop/deploy/undeploy/etc)
> >
> > This is my opinion too! There are some problems still with the methods
that
> > don't have 'primitive'/'primitive wrapper' arguments, like the "deploy"
for
> > example.
> >
> > > while
> > > Type 2 (Blocks et al) is different altogether. For Type 2 management
> > > there
> >
> > is
> >
> > > essentially two facets - management of Configuration tree and
management
> >
> > of a
> >
> > > custom management interface that a Block can choose to export.
> >
> > .. the problem is how to do it:
> > 1) manage the Configuration trees that are stored in the repository
> > 2) something that Leo recommended, having a DynamicMBean that takes the
> > Block, its manageable interfaces and its Configuration
> >
> > Solution 1, which I prefer is separating the "configuration" management
> > from the "action" management. For the "action" management the
> > implementation is there (Leo's JMX stuff). The "configuration"
management
> > can be done by changing the configuration trees stored in the
Repository,
> > the Block-s that will implement Reconfigurable interface will receive
> > automatically the new configuration (assuming that the "monitor" package
> > will be used).
>
> +1
>
> But I would like Blocks to be able to export their own interface aswell if
> they so choose.
Of course, this is what I called "action" management (maybe not the best
expresion)!
Mircea
> However that can be left till "later" ;)
>
> --
> Cheers,
>
> Pete
>
> ------------------------------
> Kitsch never goes out of style
> ------------------------------
>
>
> ---------------------------------------------------------------------
> 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
Re: JMX and stuff...
Posted by Peter Donald <do...@apache.org>.
On Sun, 9 Sep 2001 05:10, Mircea Toma wrote:
> > So Type 1 (kernel et al) management can be done via normal JMX
> > mechanisms.
>
> It
>
> > includes the actions you list above (ie start/stop/deploy/undeploy/etc)
>
> This is my opinion too! There are some problems still with the methods that
> don't have 'primitive'/'primitive wrapper' arguments, like the "deploy" for
> example.
>
> > while
> > Type 2 (Blocks et al) is different altogether. For Type 2 management
> > there
>
> is
>
> > essentially two facets - management of Configuration tree and management
>
> of a
>
> > custom management interface that a Block can choose to export.
>
> .. the problem is how to do it:
> 1) manage the Configuration trees that are stored in the repository
> 2) something that Leo recommended, having a DynamicMBean that takes the
> Block, its manageable interfaces and its Configuration
>
> Solution 1, which I prefer is separating the "configuration" management
> from the "action" management. For the "action" management the
> implementation is there (Leo's JMX stuff). The "configuration" management
> can be done by changing the configuration trees stored in the Repository,
> the Block-s that will implement Reconfigurable interface will receive
> automatically the new configuration (assuming that the "monitor" package
> will be used).
+1
But I would like Blocks to be able to export their own interface aswell if
they so choose. However that can be left till "later" ;)
--
Cheers,
Pete
------------------------------
Kitsch never goes out of style
------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JMX and stuff...
Posted by Mircea Toma <mi...@home.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Friday, September 07, 2001 11:37 PM
Subject: Re: JMX and stuff...
> Hiya,
>
> On Fri, 7 Sep 2001 15:44, Mircea Toma wrote:
> > I was browsing through the mailing-list archive trying to find reasons
why
> > certain decisions have been taken and also I checked out the to-do list
to
> > see which are the overlaps between Avalon needs and my needs. The
> > conclusion was that remote management (JMX), hot deploy (preferably with
> > remote loading of blocks) and LogKit new management are the things that
I
> > would like to have (and work on of course).
>
> woohoo.
>
> > What strike me about JMX management is that in Avalon the configuration
has
> > a hierarchical structure (and that's really sweet) but with JMX you can
> > change only properties, which have a flat structure. Another thing is,
if
> > the blocks made available for management will have very little things to
> > act on (only the methods that have no args or with primitive arguments).
> > Right now this can be changed only by making the block follow the
JavaBean
> > pattern (Leo Simon already said this) in order to change the
configuration
> > values but this will brake the Avalon framework contracts (I think!).
So,
> > the idea that came to me (might be a childish one) was to somehow ???
make
> > available for management the values stored in the
ConfigurationRepository
> > in a structured fashion, in this way when some value was changed by the
> > agent the reconfigure(...) method will be called on the blocks
implementing
> > Reconfigurable. This will work well also if the SystemManager will use
JNDI
> > to manage the blocks.
> > The existing mechanism in Phoenix for registering blocks allows only
> > actions (not values/properties) to be made available for management:
like
> > "start", "stop", "deploy", "undeploy" ...
>
> Well I guess there are two types of "management" in Phoenix. One is
> management of the embeddor, deployer, kernel, installer etc. Another is
> management of Application components (ie Blocks).
true!
>
> So Type 1 (kernel et al) management can be done via normal JMX mechanisms.
It
> includes the actions you list above (ie start/stop/deploy/undeploy/etc)
This is my opinion too! There are some problems still with the methods that
don't have 'primitive'/'primitive wrapper' arguments, like the "deploy" for
example.
> while
> Type 2 (Blocks et al) is different altogether. For Type 2 management there
is
> essentially two facets - management of Configuration tree and management
of a
> custom management interface that a Block can choose to export.
.. the problem is how to do it:
1) manage the Configuration trees that are stored in the repository
2) something that Leo recommended, having a DynamicMBean that takes the
Block, its manageable interfaces and its Configuration
Solution 1, which I prefer is separating the "configuration" management from
the "action" management. For the "action" management the implementation is
there (Leo's JMX stuff). The "configuration" management can be done by
changing the configuration trees stored in the Repository, the Block-s that
will implement Reconfigurable interface will receive automatically the new
configuration (assuming that the "monitor" package will be used). This will
be consistent with one of to-do points (altough, true for any type of
persistence mechanism):
"- A standard reconfiguration system. This may require the building of
FileMonitors that will read a file when it is changed. Any kind of block or
component that extends the Reconfigurable interface gets sent the new
configuration."
Solution 2, will make the Block manageable as a unit which may be more
compatible with the JMX style of managing MBean-s. This solution will lack
the reuse of functionality that first solution would have. Also if the
"action" management solution is different (like SOAP) the "configuration"
management won't make to much sense.
Mircea
> ie A Block may
> choose to export an interface that allows actions to be triggered by
> management. (ie a Logging daemon may have a "Rotate Now" actions that
rotates
> all logs now and resets the timers).
>
> --
> Cheers,
>
> Pete
>
> -----------------------------------------------
> "Only two things are infinite, the universe and
> human stupidity, and I'm not sure about the
> former." -Albert Einstein
> -----------------------------------------------
>
> ---------------------------------------------------------------------
> 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
Re: JMX and stuff...
Posted by Peter Donald <do...@apache.org>.
Hiya,
On Fri, 7 Sep 2001 15:44, Mircea Toma wrote:
> I was browsing through the mailing-list archive trying to find reasons why
> certain decisions have been taken and also I checked out the to-do list to
> see which are the overlaps between Avalon needs and my needs. The
> conclusion was that remote management (JMX), hot deploy (preferably with
> remote loading of blocks) and LogKit new management are the things that I
> would like to have (and work on of course).
woohoo.
> What strike me about JMX management is that in Avalon the configuration has
> a hierarchical structure (and that's really sweet) but with JMX you can
> change only properties, which have a flat structure. Another thing is, if
> the blocks made available for management will have very little things to
> act on (only the methods that have no args or with primitive arguments).
> Right now this can be changed only by making the block follow the JavaBean
> pattern (Leo Simon already said this) in order to change the configuration
> values but this will brake the Avalon framework contracts (I think!). So,
> the idea that came to me (might be a childish one) was to somehow ??? make
> available for management the values stored in the ConfigurationRepository
> in a structured fashion, in this way when some value was changed by the
> agent the reconfigure(...) method will be called on the blocks implementing
> Reconfigurable. This will work well also if the SystemManager will use JNDI
> to manage the blocks.
> The existing mechanism in Phoenix for registering blocks allows only
> actions (not values/properties) to be made available for management: like
> "start", "stop", "deploy", "undeploy" ...
Well I guess there are two types of "management" in Phoenix. One is
management of the embeddor, deployer, kernel, installer etc. Another is
management of Application components (ie Blocks).
So Type 1 (kernel et al) management can be done via normal JMX mechanisms. It
includes the actions you list above (ie start/stop/deploy/undeploy/etc) while
Type 2 (Blocks et al) is different altogether. For Type 2 management there is
essentially two facets - management of Configuration tree and management of a
custom management interface that a Block can choose to export. ie A Block may
choose to export an interface that allows actions to be triggered by
management. (ie a Logging daemon may have a "Rotate Now" actions that rotates
all logs now and resets the timers).
--
Cheers,
Pete
-----------------------------------------------
"Only two things are infinite, the universe and
human stupidity, and I'm not sure about the
former." -Albert Einstein
-----------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: JMX and stuff...
Posted by Mircea Toma <mi...@calgary.qcdata.com>.
----- Original Message -----
From: "Leo Simons" <ma...@leosimons.com>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Friday, September 07, 2001 3:38 AM
Subject: RE: JMX and stuff...
> > I was browsing through the mailing-list archive trying to find reasons
why
> > certain decisions have been taken and also I checked out the to-do list
to
> > see which are the overlaps between Avalon needs and my needs. The
> > conclusion
> > was that remote management (JMX), hot deploy (preferably with
> > remote loading
> > of blocks) and LogKit new management are the things that I would like to
> > have (and work on of course).
>
> cool.
>
> > What strike me about JMX management is that in Avalon the
> > configuration has
> > a hierarchical structure (and that's really sweet) but with JMX you can
> > change only properties, which have a flat structure. Another thing is,
if
> > the blocks made available for management will have very little
> > things to act
> > on (only the methods that have no args or with primitive arguments).
Right
> > now this can be changed only by making the block follow the
> > JavaBean pattern
> > (Leo Simon already said this) in order to change the configuration
values
> > but this will brake the Avalon framework contracts (I think!).
>
> not entirely true. What you can do is provide what is called a
> DynamicMBean for a Component (or any object) to describe in "JMX
vocabulary"
> how to use the component. The code in org.apache.jmx.introspector is
> almost finished, and will in fact generate a DynamicMBean exposing
> all public methods and properties.
I saw what you did and I think is really cool! ;)
> It would be smart to (for example) subclass the DynamicMBeanFactory
> to create a DynamicMBeanBlockFactory that exposes all available
> methods for the block and also looks at the configuration of the
> block. In the end, everything _not_ defined in code but only in
> the contracts should be accessible using a method on an MBean as well.
Definetelly, this is would be a good option, altough I don't know how this
will fit with publishing/registering with a SOAP provider.
>
> > So, the idea
> > that came to me (might be a childish one) was to somehow ??? make
> > available
> > for management the values stored in the ConfigurationRepository in a
> > structured fashion, in this way when some value was changed by
> > the agent the
> > reconfigure(...) method will be called on the blocks implementing
> > Reconfigurable. This will work well also if the SystemManager
> > will use JNDI
> > to manage the blocks.
>
> Would be an option. I am worried however that when you flatten the
> hierarchy in some way, things will get messier and thus even more
> complicated to follow.
I agree. I still have to look into it more carefully!
> This is probably easier to do than dynamic
> introspection, though.
>
> > I guess I was trying to revive the remote management subject
> > which seems to
> > be stalled for a while now.
>
> Yup. My fault (no time). Good luck with it! (and in case anyone
> wonders: I have no problems with people throwing away all the
> current code and starting from fresh)
cool!
Mircea
>
> Leo, still packing
>
>
> ---------------------------------------------------------------------
> 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
RE: JMX and stuff...
Posted by Leo Simons <ma...@leosimons.com>.
> I was browsing through the mailing-list archive trying to find reasons why
> certain decisions have been taken and also I checked out the to-do list to
> see which are the overlaps between Avalon needs and my needs. The
> conclusion
> was that remote management (JMX), hot deploy (preferably with
> remote loading
> of blocks) and LogKit new management are the things that I would like to
> have (and work on of course).
cool.
> What strike me about JMX management is that in Avalon the
> configuration has
> a hierarchical structure (and that's really sweet) but with JMX you can
> change only properties, which have a flat structure. Another thing is, if
> the blocks made available for management will have very little
> things to act
> on (only the methods that have no args or with primitive arguments). Right
> now this can be changed only by making the block follow the
> JavaBean pattern
> (Leo Simon already said this) in order to change the configuration values
> but this will brake the Avalon framework contracts (I think!).
not entirely true. What you can do is provide what is called a
DynamicMBean for a Component (or any object) to describe in "JMX vocabulary"
how to use the component. The code in org.apache.jmx.introspector is
almost finished, and will in fact generate a DynamicMBean exposing
all public methods and properties.
It would be smart to (for example) subclass the DynamicMBeanFactory
to create a DynamicMBeanBlockFactory that exposes all available
methods for the block and also looks at the configuration of the
block. In the end, everything _not_ defined in code but only in
the contracts should be accessible using a method on an MBean as well.
> So, the idea
> that came to me (might be a childish one) was to somehow ??? make
> available
> for management the values stored in the ConfigurationRepository in a
> structured fashion, in this way when some value was changed by
> the agent the
> reconfigure(...) method will be called on the blocks implementing
> Reconfigurable. This will work well also if the SystemManager
> will use JNDI
> to manage the blocks.
Would be an option. I am worried however that when you flatten the
hierarchy in some way, things will get messier and thus even more
complicated to follow. This is probably easier to do than dynamic
introspection, though.
> I guess I was trying to revive the remote management subject
> which seems to
> be stalled for a while now.
Yup. My fault (no time). Good luck with it! (and in case anyone
wonders: I have no problems with people throwing away all the
current code and starting from fresh)
Leo, still packing
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org