I believe the "Kernel Infrastructure" used to handle
J2EEManagedObject methods, which I assume include the methods of the
StateManageable interface (start, startRecursive, stop, etc.). That was
removed recently, which is mostly fine -- GBeans now can handle any of
this stuff themselves.
The one problem is with start and startRecursive. Normal
operations can't be called on a GBean that's stopped, but obviously start
and startRecursive are only applicable if the GBean is stopped. (The rest
of the methods [getState, getStateInstance, getStartTime, and stop] have a
less serious issue in that they require a GBean have a Kernel reference to
implement, which spreads knowledge of the Kernel through otherwise
ignorant GBeans, but at least it can be done.) "Framework" operations
work on stopped GBeans, though.
So in the change I'm now checking in, I made startRecursive and
start "Framework Operations" in GBeanInstance -- that is, they are
intercepted and the appropriate calls made on the kernel instead. The
GBean still has to implement those methods in order to implement the
StateManageable interface, so my GBean implementations methods just do
nothing and have a note that the infrastructure will handle those calls.
I would be happy to do the same with the rest of the StateManageable
methods, since every GBean should have essentially the same implementation
of those and it doesn't make sense to copy and paste into every one.
But I'm unhappy either way we handle this. I want the management
interfaces for the GBeans to include StateManageable so a client of the
new management API can reference something as a StateManageable and call
start or stop on it directly, and I definitely agree that all GBeans
should implement their management interfaces. That just means that the
GBeans need a bunch of empty methods saying "the infrastructure will
handle this".
It's possible to make StateManageable the only recommended
exception whereby a GBean would not have to implement it, but then none of
the management interfaces can extend StateManageable, and client code
would *always* have to cast a GBean to StateManageable before calling
those methods on it. Perhaps this is the least onerous path in terms of
not adding cruft to every GBean implementation, but it puts us right back
where we started with the framework magically implementing an interface
for the GBeans.
Thoughts? You can see the effect on the Jetty stuff I'm just
about to check in, where I made the container/connector management
interfaces extend StateManageable and then put the implementation in
JettyConnector and JettyContainerImpl (including the blanks for start and
startRecursive). It's nice for clients (where you can call start and stop
on any WebContainer or WebConnector), but not so nice for the GBeans.
Thanks,
Aaron
