It was a lot to dump in an email, so far now I'll focus on a more modest objective of registering management objects with a local context instead of the 'global' system managemer. The advantage to this is that we can pull the JMX naming stuff inside the management code instead of spreading it around, and this is a good thing to do regardless.
At Peter's suggestion I've read through JSR77 article. Nothing about it sounds incompatible although if that's where Avalon is going there are more direct ways to get there. Also, how well it might fit would depend on how the J2EE container were implemented within Avalon. The List/Target/Topic breakdown is more abstract than the JSR77 spec. It attempts to provide enough structure, as well as enough 'metainfo', so that the block author can expose the block for management by following a few basic rules. The JSR77 spec on the other hand dictates the topics that each type of 'block' will expose so that management tools can look 'tight'. One last thought on JSR77, if Avalon had a J2EE container right now, and the management stuff was in place, and then this spec. came along, I would implement it in much the same way as the JMXBridge example. It would listen to management events (object added, removed), and if the event was for a 'known' object type then it would take additional action as appropriate. One other thing, I haven't made any provision for management events.
