geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leigh Williamson <>
Subject Re: JSR77 StateManageable inconsistency?
Date Mon, 09 Jan 2006 22:18:23 GMT
Yes, I will extract a small example from the program I am working on and 
post it. Thanks!

Leigh Williamson

Aaron Mulder <> 
Sent by:
01/09/2006 02:27 PM
Please respond to


Re: JSR77 StateManageable inconsistency?

Hmm, that's curious.  Every GBean is state manageable in the sense
that if you talk to the kernel it can get and change the state of the
GBean.  And if you have the kernel generate you a proxy it includes
the state manageable methods in one of the implemented interfaces,

However, it may well be the case that invoking such a method through
the MEJB doesn't work properly.  If so, we should be able to just
change the MEJB to make the right kernel calls under the covers if you
call one of the state manageable methods.

Can you send over (post to JIRA or the mailing list) a small test
program that demonstrates the problem, which we could then use to test
the fix?


On 1/9/06, Leigh Williamson <> wrote:
> I have been attempting to port a J2EE 1.4 management program to Geronimo 
> noticed what appears to be inconsistency in the way JSR77 
> attribute is handled.
> The spec says that if one of the JSR77 objects does support the 
> interface it should return "true" for the stateManageable attribute of 
> J2EEManagedObject interface. Returning "true" for the stateManageable 
> is supposed to tell the management program that this object supports the
> StateManageable interface which includes the "state" attribute, as well 
> implementing the "stop", "start", and "startRecursive" operations.
> But the J2EEManagedObjects returned by the ManagementEJB in Geronimo 
appear to
> be inconsistent in this area. For instance, the J2EEDeployedObject 
claims to be
> a state manageable object (stateManageable="true") but if you attempt to
> getAttribute the "state" attribute you will receive an exception:
> state
> In a different example of inconsistency, the J2EEServer object also 
claims to
> be StateManageable, yet I cannot invoke the "stop" operation on that 
> Perhaps I am accessing these J2EEManagedObjects incorrectly? I am using 
> ManagementEJB as per the spec. Is this a bug in the implementation?

View raw message