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: JMX and stuff...
Date Fri, 07 Sep 2001 20:45:33 GMT

----- Original Message -----
From: "Leo Simons" <mail@leosimons.com>
To: "Avalon Development" <avalon-dev@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
> > certain decisions have been taken and also I checked out the to-do list
> > 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,
> > 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).
> > 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
> > 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
> 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)



> 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

View raw message