On Wed 05 Jun 2013 07:54:10 PM CEST, shanliang wrote:
> Daniel Fuchs wrote:
>> On 6/5/13 3:55 PM, Jaroslav Bachorik wrote:
>>>> class A extends B { ...}
>>>> >class B implements AMBean {...}
>>> Yes, I see it now. However, when you check the JMX specification, page
>>> 50 onwards, the current implementation does not seem to be correct.
>>>
>>> "3. If MyClass is an instance of the DynamicMBean interface, then
>>> MyClassMBean is
>>> ignored. If MyClassMBean is not a public interface, it is not a JMX
>>> manageable
>>> resource. If the MBean is an instance of neither MyClassMBean nor
>>> DynamicMBean, the inheritance tree of MyClass is examined, looking
>>> for the
>>> nearest superclass that implements its own MBean interface.
>>> a. If there is an ancestor called SuperClass that is an instance of
>>> SuperClassMBean, the design patterns are used to derive the
>>> attributes and
>>> operations from SuperClassMBean. In this case, the MBean MyClass then
>>> has the same management interface as the MBean SuperClass. If
>>> SuperClassMBean is not a public interface, it is not a JMX manageable
>>> resource.
>>> b. When there is no superclass with its own MBean interface, MyClass is
>>> not a
>>> Standard MBean."
>>>
>>> According to the specification the correct MBean interface for
>>>
>>> class A extends B { ...}
>>> class B implements BMBean, AMBean
>>>
>>> would be BMBean
>>
>> Hi Jaroslav,
>>
>> Given that A is an instance of AMBean I think that according to the
>> specification the correct interface should be AMBean.
>> It's true that the JMX Specification does not explicitly speak of this
>> case - but neither does it forbid it.
>>
>> My advice would therefore be to clarify the spec on this point,
>> if that's needed - rather than risking the introduction of
>> incompatibilities.
>>
>> -- daniel
> Look at the spec 1.4:
> ------
> 2. If the MyClass MBean is an instance of a MyClassMBean interface,
> then only the methods listed in, or inherited by, the interface are
> considered among all the methods of, or inherited by, the MBean. The
> design patterns are then used to identify the attributes and
> operations from the method names in the MyClassMBean interface and its
> ancestors. In other words, MyClass is a standard MBean
> ------
>
> Here A is an instance of AMBean, according to 2), A is a standard
> MBean and AMBean must be taken,
>
> 3) specifies the condition as "If the MBean is an instance of neither
> MyClassMBean nor DynamicMBean", our example is out of this condition,
> so should not apply 3) to our example.
Ok. I've reverted to the original implementation.
http://cr.openjdk.java.net/~jbachorik/8010285/webrev.03/
The whole MBean interface inferring algorithm is a bit of black magic,
though. I mean, checking all the interfaces implemented by all the
classes in the inheritance hierarchy is counter-intuitive. I mean, why
would you do something like :
MyServiceIfc extends ObscureIfc extends ServiceMBean
Service implements MyServiceIfc
and silently supposing that somewhere in the interface inheritance
hierarchy just happen to be a properly named interface and my Service
would become a managed resource. Not mentioning the fact, that the
current implementation will fail to resolve the ServiceMBean as the
MBean interface - it stops checking by ObscureIfc.
It would be much easier for the user if he just specified the MBean
interface alongside the implementation class (... implements ...,
ServiceMBean) cleanly indicating that an object is a managed resource.
But, what you gonna do ... changing the spec would probably open a
whole another can of worms and since nobody is complaining about the
current implementation we can just leave it as it is.
-JB-
>
> Shanliang
>
>>
>>>
>>> and for
>>> class A extends B { ...}
>>> class B implements AMBean {...}
>>>
>>> is not defined; neither B or A are manageable resources.
>>>
>>> As I said, the jtreg and jck test does not seem to mind which
>>> implementation is used, they all pass happily. I would prefer bringing
>>> the implementation in sync with the specification.
>>>
>>> -JB-
>>>
>>
>
