geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Framework Operations for StateManageable
Date Sat, 06 Aug 2005 20:51:13 GMT
	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

Mime
View raw message