> With regards to #1 I was planning on looking at the avalon-meta stuff toSounds good. As a first step, supporting the Phoenix style of specifying the
> 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...
management interface and generating the MBean via introspection would be
good, since that's what is currently there.
> 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.
I believe I have a reference to the containment model, I'll see what I can find in there.
Give me a few days to review the code, and see what we can do with it.Sounds great, thanks again :-)
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...
Most of the code was just ripped from the Phoenix codebase anyways. I wouldn't have a problem signing a Contributor License Agreement either.
-Cameron
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
