jmx-dev RFR: 8010285 Enforce the requirement of Management Interfaces being public

[shanliang]

Jaroslav,

It is now OK for me about the MBean interface searching in the Introspector.

Here is my comment on JMX.java:
206 -- 212 you added a call
    Introspector.testComplianceMBeanInterface(interfaceClass);

It is better to move this call to:
    MBeanServerInvocationHandler.newProxyInstance
because the real job is done in newProxyInstance and it could be 
directly called by anyone.

All others are OK for me.

Shanliang

Jaroslav Bachorik wrote:
> 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-
>>>>
>>>>         
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130606/d94a150e/attachment-0001.html