On Monday 01 March 2004 05:51, Cameron Fieber wrote: > I have an initial version of a facility to create MBeans for > components. (source is > currently at: http://remsats1.hpr.for.gov.bc.ca/jmx-facility.tar.gz) > > It is working so far in my limited testing.
Ok. A good first step. :o) > Currently, it is detecting a component's "management interfaces" by > looking at its > list of implemented interfaces for interfaces that end with "MBean". > This is not ideal for two main reasons: Yeah, we need to fix that. > 1) It would be nice to not be tied to a naming convention > 2) Currently the component being managed has to declare that it provides > its "MBean" interface as a service (@avalon.service tag) so that the Proxy > for the component returned by ComponentModel.resolve() actually > implements those methods. > > With regards to #1 I was planning on looking at the avalon-meta stuff to > figure out how to > add support for a new component level tag to declare a management > interface, then figuring > out how to propagate that information down into the ComponentModel in > Merlin. I was > thinking @avalon.mx type="interface-name" since it's similar to what was > in Phoenix. Yes. Actually, I was thinking of supporting both the standard MBean as well as Dynamic MBean, meaning the component can either expose its own management methods, or delegate to a separate class. Let us help you getting the meta in place. I guess it will take some "debate" among the people here... > As for #2, it seems wrong to have the management interface for a > component exposed as > one of its service interfaces. Is there a way to go from the > ComponentModel of a component > to a non-proxied reference without forcing the particular component to > never be proxied? I'll need to take a look at your code, but the principal answer is yes. However, I think you will need a reference to the appliance or the ContainmentModel, so I'll need to take a bit look at your code first. Give me a few days to review the code, and see what we can do with it. Then there might be some legal stuff. We are not supposed to accept code, unless the contributor have signed a Contributor License Agreement. We'll take that when we get there... Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
