Alex Blewitt wrote:
I really like this idea. Berin seems to think that it's eminantly
doable, Jason sounds like he needs to be convinced.
If this is already provided as part of Avalon, or Avalon-esque systems,
then perhaps this is worth investigating in more detail? Could Berin
provide this?
It might not be doable using the current JMX interceptor stack, but if
it can be done using another mechanism (and demonstrably so) then
perhaps that's a good reason to look at using a different mechanism.
How do you want to prove it, or do it?
I'll be honest about my ignorance of JMX as a whole. I know some rudimentary
support for it has been added to the Avalon Phoenix container code, but I
would like a better idea on how it is desired to be used in the Geronimo/
whatever we want to call this project codebase.
In Phoenix, JMX is relegated to providing an exposed interface to Avalon
components that are meant to be managed externally. It isn't used by the
kernel to create and tear down component instances.
IMO a management interface like JMX/SNMP should only be used for an
administrator's console to customize or manage aspects of the running
system. THat fits in with the Phoenix approach.
That means that the Avalon components can already be loaded on demand--without
any additional coding necessary--once the component is initialized, the JMX
MBean can be created and published.
My GUI app framework at D-Haven.org uses Avalon Fortress, which employs
asynchronous component management--no extra code necessary. I also have
a distributed print server on my harddrive that can take advantage of it,
but it is all about what makes sense for this project.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
