From jaroslav.bachorik at oracle.com  Mon Jun  3 15:31:49 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 04 Jun 2013 00:31:49 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51A70081.5050203@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com>
Message-ID: <51AD1955.2090109@oracle.com>

On 05/30/2013 09:32 AM, Jaroslav Bachorik wrote:
> On Wed 29 May 2013 07:44:34 PM CEST, Daniel Fuchs wrote:
>> On 5/29/13 7:17 PM, Jaroslav Bachorik wrote:
>>> On Wed 29 May 2013 05:33:21 PM CEST, Eamonn McManus wrote:
>>>> I would recommend against changing the code to do additional calls to
>>>> Class.forName during MBean introspection. As I recall we made the
>>>> opposite change some years ago, both because Class.forName can be slow
>>>> (it may call out to a user ClassLoader) and because it is a potential
>>>> source of security problems.
>>>
>>> Thanks. I was trying to dig some history from mercurial but couldn't.
>>> Walking through all the related interfaces is equally acceptable - I've
>>> tried both of the solutions and they test well with the regtests.
>>>
>>> I am still puzzled by the current implementation which will fail to
>>> locate the correct MBean interface in eg.
>>>
>>> <<CInterface>> extends <<BInterface>> extends <<ServiceMBean>>
>>>
>>> ClassA extends Service implements <<CInterface>>
>>>
>>> as the process would stop on <<BInterface>> (checks the superclass of
>>> the ClassA, checks all the interfaces implemented by the Service class,
>>> checks all the interfaces extended by <<CInterface>>) which plainly
>>> does not conform to the MBean interface naming convention and would
>>> miss the <<ServiceMBean>> interface.
>>
>> Hi Jaroslav,
>>
>> <<Service>> would have to implement <<ServiceMBean>> either
>> directly or indirectly.
>>
>> So the current implementation is correct.
>>
>> If <<ServiceMBean>> is not assignable from <<Service>> then
>> <<ServiceMBean>> is not an MBean interface for ClassA.
> 
> Actually, when you do
> ClassA extends Service implements <<BInterface>>
> 
> the Introspector will return <<ServiceMBean>> as the standard mbean 
> interface for ClassA. I've just tried it on a simple project to make 
> sure I understand the code correctly. The puzzle is which behaviour is 
> correct? Either all the levels of the interface hierarchy should be 
> checked for the [className]MBean interfaces or none, I guess. However, 
> I can not find anything in the spec related to this case.

I've updated the webrev not to use Class.forName() when inferring the
MBean interface to use.

However, I've changed the way the interface hierarchy is treated -
originally, all the interfaces of a certain class and their direct super
interfaces were checked for the MBean interface candidates (with
[class.Name]MBean class name) - but only one level of the hierarchy was
checked. The new implementation will check only the direct interfaces.

I am still not sure whether the interface hierarchy should be searched
for the appropriately named interfaces or not. The spec does not say
anything about this and all the jtreg and jck tests are indifferent to
my changes. But I am sure that if it is supposed to search the interface
hierarchy it should not stop after the first level has been checked, as
is done by the current implementation.

Webrev: http://cr.openjdk.java.net/~jbachorik/8010285/webrev.02

-JB-

> 
> -JB-
> 
>>
>> You can work around that by wrapping an instance of ClassA
>> in an instance of  javax.management.StandardMBean, and by
>> specifying <<ServiceMBean>>.class as the MBean interface
>> in the constructor.
>>
>> Hope this helps,
>>
>> -- daniel
>>
>>>
>>> -JB-
>>>
>>>>
>>>> ?amonn
>>>>
>>>>
>>>> 2013/5/29 Jaroslav Bachorik <jaroslav.bachorik at oracle.com
>>>> <mailto:jaroslav.bachorik at oracle.com>>
>>>>
>>>>      Updated webrev -
>>>>      http://cr.openjdk.java.net/~jbachorik/8010285/webrev.01
>>>>
>>>>      It adds regtests and takes care of the comments from David and
>>>>      Shanliang.
>>>>
>>>>      -JB-
>>>>
>>>>      On 05/28/2013 04:22 PM, Jaroslav Bachorik wrote:
>>>>      > The fix enforces the management interfaces (read MBean and
>>>> MXBean
>>>>      > interfaces) being public. While this is defined in the
>>>>      specification it
>>>>      > was not enforced in any way and it was allowed to create MBeans
>>>>      for eg.
>>>>      > private MBean interfaces.
>>>>      >
>>>>      > The fix adds checks when creating and registering MBeans and
>>>> throws
>>>>      > javax.management.NotCompliantMBeanException when a user tries to
>>>>      create
>>>>      > an MBean with non-public management interface.
>>>>      >
>>>>      > Since this change can cause problems for users having non-public
>>>>      > management interfaces a system property is introduced that will
>>>>      revert
>>>>      > to the old behaviour when set
>>>> (com.sun.jmx.mbeans.allowNonPublic).
>>>>      >
>>>>      > Thanks,
>>>>      >
>>>>      > -JB-
>>>>      >
>>>>
>>>>
>>>
>>>
>>
> 
> 


From jaroslav.bachorik at oracle.com  Tue Jun  4 02:51:15 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 04 Jun 2013 11:51:15 +0200
Subject: jmx-dev RFR: 8002307
 javax.management.modelmbean.ModelMBeanInfoSupport may expose internal
 representation by storing an externally mutable object
In-Reply-To: <51A5631F.6020801@oracle.com>
References: <51A4AD7E.3080701@oracle.com> <51A5631F.6020801@oracle.com>
Message-ID: <51ADB893.80303@oracle.com>

On 05/29/2013 04:08 AM, David Holmes wrote:
> On 28/05/2013 11:13 PM, Jaroslav Bachorik wrote:
>> Please, review the fix for JDK-8002307.
>>
>> The fix assures the immutability by cloning the provided arrays in the
>> constructor and then cloning them again in the getters.
> 
> This fix has the same problems/issues as 8010815:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016930.html
> 
> It is not obvious that the specification of these classes allows for
> cloning, nor that people using this won't expect external changes to the
> arrays to be passed through.
> 
> The use of "immutability" in the spec for MBeanInfo is ambiguous. It
> might just mean that the references to the arrays never change. It need
> not imply/require "deep" immutability.

Hm, I see. While the implicit mutability is an obvious error as it
allows external parties to modify the MBeanInfo contents without proper
checks and without sending the proper notifications there is no word
about the provided info arrays being immutable either in javadoc or the
JMX spec.

> 
> If we want to do this aggressive defensive copying to placate FindBugs
> (which is simply flagging things to pay attention to, not that are
> necessarily incorrect) then I think spec updates may also be required.

We wouldn't be doing this only to placate FindBugs - it is rather easy
to break JMX by eg. nullifying a slot of MBeanAttributeInfo[] array that
was previously used to build a ModelMBeanInfoSupport.

If the spec is to be updated we should also rev the JSR 3. I'm just
wandering whether it is really worth to address this issue :/

-JB-

> 
> David
> -----
> 
>> The constructors are fixed in the javax/management/MBeanInfo.java and
>> the arrays used in getters are cloned using an already existing
>> functionality in the same class.
>>
>> http://cr.openjdk.java.net/~jbachorik/8002307/webrev.01
>>
>> Thanks,
>>
>> -JB-
>>


From david.holmes at oracle.com  Tue Jun  4 05:16:56 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 04 Jun 2013 22:16:56 +1000
Subject: jmx-dev RFR: 8002307
 javax.management.modelmbean.ModelMBeanInfoSupport may expose internal
 representation by storing an externally mutable object
In-Reply-To: <51ADB893.80303@oracle.com>
References: <51A4AD7E.3080701@oracle.com> <51A5631F.6020801@oracle.com>
	<51ADB893.80303@oracle.com>
Message-ID: <51ADDAB8.3000501@oracle.com>

Based on discussions around 8010815 I withdraw my comments on this change.

I'll leave it to others to review this.

David

On 4/06/2013 7:51 PM, Jaroslav Bachorik wrote:
> On 05/29/2013 04:08 AM, David Holmes wrote:
>> On 28/05/2013 11:13 PM, Jaroslav Bachorik wrote:
>>> Please, review the fix for JDK-8002307.
>>>
>>> The fix assures the immutability by cloning the provided arrays in the
>>> constructor and then cloning them again in the getters.
>>
>> This fix has the same problems/issues as 8010815:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016930.html
>>
>> It is not obvious that the specification of these classes allows for
>> cloning, nor that people using this won't expect external changes to the
>> arrays to be passed through.
>>
>> The use of "immutability" in the spec for MBeanInfo is ambiguous. It
>> might just mean that the references to the arrays never change. It need
>> not imply/require "deep" immutability.
>
> Hm, I see. While the implicit mutability is an obvious error as it
> allows external parties to modify the MBeanInfo contents without proper
> checks and without sending the proper notifications there is no word
> about the provided info arrays being immutable either in javadoc or the
> JMX spec.
>
>>
>> If we want to do this aggressive defensive copying to placate FindBugs
>> (which is simply flagging things to pay attention to, not that are
>> necessarily incorrect) then I think spec updates may also be required.
>
> We wouldn't be doing this only to placate FindBugs - it is rather easy
> to break JMX by eg. nullifying a slot of MBeanAttributeInfo[] array that
> was previously used to build a ModelMBeanInfoSupport.
>
> If the spec is to be updated we should also rev the JSR 3. I'm just
> wandering whether it is really worth to address this issue :/
>
> -JB-
>
>>
>> David
>> -----
>>
>>> The constructors are fixed in the javax/management/MBeanInfo.java and
>>> the arrays used in getters are cloned using an already existing
>>> functionality in the same class.
>>>
>>> http://cr.openjdk.java.net/~jbachorik/8002307/webrev.01
>>>
>>> Thanks,
>>>
>>> -JB-
>>>
>

From shanliang.jiang at oracle.com  Wed Jun  5 02:34:05 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Wed, 05 Jun 2013 11:34:05 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51AD1955.2090109@oracle.com>
References: <51A4BD98.1040704@oracle.com>
	<51A6171E.8040606@oracle.com>	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>	<51A6382F.3000204@oracle.com>
	<51A63E82.4050505@oracle.com>	<51A70081.5050203@oracle.com>
	<51AD1955.2090109@oracle.com>
Message-ID: <51AF060D.5070706@oracle.com>

Jaroslav Bachorik wrote:
> On 05/30/2013 09:32 AM, Jaroslav Bachorik wrote:
>   
>> On Wed 29 May 2013 07:44:34 PM CEST, Daniel Fuchs wrote:
>>     
>>> On 5/29/13 7:17 PM, Jaroslav Bachorik wrote:
>>>       
>>>> On Wed 29 May 2013 05:33:21 PM CEST, Eamonn McManus wrote:
>>>>         
>>>>> I would recommend against changing the code to do additional calls to
>>>>> Class.forName during MBean introspection. As I recall we made the
>>>>> opposite change some years ago, both because Class.forName can be slow
>>>>> (it may call out to a user ClassLoader) and because it is a potential
>>>>> source of security problems.
>>>>>           
>>>> Thanks. I was trying to dig some history from mercurial but couldn't.
>>>> Walking through all the related interfaces is equally acceptable - I've
>>>> tried both of the solutions and they test well with the regtests.
>>>>
>>>> I am still puzzled by the current implementation which will fail to
>>>> locate the correct MBean interface in eg.
>>>>
>>>> <<CInterface>> extends <<BInterface>> extends <<ServiceMBean>>
>>>>
>>>> ClassA extends Service implements <<CInterface>>
>>>>
>>>> as the process would stop on <<BInterface>> (checks the superclass of
>>>> the ClassA, checks all the interfaces implemented by the Service class,
>>>> checks all the interfaces extended by <<CInterface>>) which plainly
>>>> does not conform to the MBean interface naming convention and would
>>>> miss the <<ServiceMBean>> interface.
>>>>         
>>> Hi Jaroslav,
>>>
>>> <<Service>> would have to implement <<ServiceMBean>> either
>>> directly or indirectly.
>>>
>>> So the current implementation is correct.
>>>
>>> If <<ServiceMBean>> is not assignable from <<Service>> then
>>> <<ServiceMBean>> is not an MBean interface for ClassA.
>>>       
>> Actually, when you do
>> ClassA extends Service implements <<BInterface>>
>>
>> the Introspector will return <<ServiceMBean>> as the standard mbean 
>> interface for ClassA. I've just tried it on a simple project to make 
>> sure I understand the code correctly. The puzzle is which behaviour is 
>> correct? Either all the levels of the interface hierarchy should be 
>> checked for the [className]MBean interfaces or none, I guess. However, 
>> I can not find anything in the spec related to this case.
>>     
>
> I've updated the webrev not to use Class.forName() when inferring the
> MBean interface to use.
>
> However, I've changed the way the interface hierarchy is treated -
> originally, all the interfaces of a certain class and their direct super
> interfaces were checked for the MBean interface candidates (with
> [class.Name]MBean class name) - but only one level of the hierarchy was
> checked. The new implementation will check only the direct interfaces.
>
> I am still not sure whether the interface hierarchy should be searched
> for the appropriately named interfaces or not. The spec does not say
> anything about this and all the jtreg and jck tests are indifferent to
> my changes. But I am sure that if it is supposed to search the interface
> hierarchy it should not stop after the first level has been checked, as
> is done by the current implementation.
>   
Your modification changes the current JMX behavior, if the spec does not 
say about interface searching, I think it is better to keep the current 
behavior for the implementation compatibility.

Here are examples:
1)    A extends B implements AMBean, BMBean
the current JMX will get AMBean for the class A, but BMBean will be got 
with your modification.
2)    A extends B implements AMBean
the current JMX will get AMBean for the class A, but which mbean 
interface will be found with your modification? I think it will be null.

367             if ((Modifier.isPublic(mbeanInterface.getModifiers()) ||
 368                  MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN) &&
 369                  clMBeanName.equals(mbeanInterface.getName())) {
 370                 return mbeanInterface;
 371             }
As I indicated in my previous mail, better to write as:
    if (clMBeanName.equals(mbeanInterface.getName() &&
         (Modifier.isPublic(mbeanInterface.getModifiers()) || 
MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN)) {

checking name first because it must be cheaper here.

Shanliang
 
> Webrev: http://cr.openjdk.java.net/~jbachorik/8010285/webrev.02
>
> -JB-
>
>   
>> -JB-
>>
>>     
>>> You can work around that by wrapping an instance of ClassA
>>> in an instance of  javax.management.StandardMBean, and by
>>> specifying <<ServiceMBean>>.class as the MBean interface
>>> in the constructor.
>>>
>>> Hope this helps,
>>>
>>> -- daniel
>>>
>>>       
>>>> -JB-
>>>>
>>>>         
>>>>> ?amonn
>>>>>
>>>>>
>>>>> 2013/5/29 Jaroslav Bachorik <jaroslav.bachorik at oracle.com
>>>>> <mailto:jaroslav.bachorik at oracle.com>>
>>>>>
>>>>>      Updated webrev -
>>>>>      http://cr.openjdk.java.net/~jbachorik/8010285/webrev.01
>>>>>
>>>>>      It adds regtests and takes care of the comments from David and
>>>>>      Shanliang.
>>>>>
>>>>>      -JB-
>>>>>
>>>>>      On 05/28/2013 04:22 PM, Jaroslav Bachorik wrote:
>>>>>      > The fix enforces the management interfaces (read MBean and
>>>>> MXBean
>>>>>      > interfaces) being public. While this is defined in the
>>>>>      specification it
>>>>>      > was not enforced in any way and it was allowed to create MBeans
>>>>>      for eg.
>>>>>      > private MBean interfaces.
>>>>>      >
>>>>>      > The fix adds checks when creating and registering MBeans and
>>>>> throws
>>>>>      > javax.management.NotCompliantMBeanException when a user tries to
>>>>>      create
>>>>>      > an MBean with non-public management interface.
>>>>>      >
>>>>>      > Since this change can cause problems for users having non-public
>>>>>      > management interfaces a system property is introduced that will
>>>>>      revert
>>>>>      > to the old behaviour when set
>>>>> (com.sun.jmx.mbeans.allowNonPublic).
>>>>>      >
>>>>>      > Thanks,
>>>>>      >
>>>>>      > -JB-
>>>>>      >
>>>>>
>>>>>
>>>>>           
>>>>         
>>     
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20130605/2beda5c1/attachment.html 

From jaroslav.bachorik at oracle.com  Wed Jun  5 03:31:08 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 05 Jun 2013 12:31:08 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51AF060D.5070706@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com>
	<51AF060D.5070706@oracle.com>
Message-ID: <51AF136C.8070806@oracle.com>

On Wed 05 Jun 2013 11:34:05 AM CEST, shanliang wrote:
> Jaroslav Bachorik wrote:
>> On 05/30/2013 09:32 AM, Jaroslav Bachorik wrote:
>>
>>> On Wed 29 May 2013 07:44:34 PM CEST, Daniel Fuchs wrote:
>>>
>>>> On 5/29/13 7:17 PM, Jaroslav Bachorik wrote:
>>>>
>>>>> On Wed 29 May 2013 05:33:21 PM CEST, Eamonn McManus wrote:
>>>>>
>>>>>> I would recommend against changing the code to do additional calls to
>>>>>> Class.forName during MBean introspection. As I recall we made the
>>>>>> opposite change some years ago, both because Class.forName can be slow
>>>>>> (it may call out to a user ClassLoader) and because it is a potential
>>>>>> source of security problems.
>>>>>>
>>>>> Thanks. I was trying to dig some history from mercurial but couldn't.
>>>>> Walking through all the related interfaces is equally acceptable - I've
>>>>> tried both of the solutions and they test well with the regtests.
>>>>>
>>>>> I am still puzzled by the current implementation which will fail to
>>>>> locate the correct MBean interface in eg.
>>>>>
>>>>> <<CInterface>> extends <<BInterface>> extends <<ServiceMBean>>
>>>>>
>>>>> ClassA extends Service implements <<CInterface>>
>>>>>
>>>>> as the process would stop on <<BInterface>> (checks the superclass of
>>>>> the ClassA, checks all the interfaces implemented by the Service class,
>>>>> checks all the interfaces extended by <<CInterface>>) which plainly
>>>>> does not conform to the MBean interface naming convention and would
>>>>> miss the <<ServiceMBean>> interface.
>>>>>
>>>> Hi Jaroslav,
>>>>
>>>> <<Service>> would have to implement <<ServiceMBean>> either
>>>> directly or indirectly.
>>>>
>>>> So the current implementation is correct.
>>>>
>>>> If <<ServiceMBean>> is not assignable from <<Service>> then
>>>> <<ServiceMBean>> is not an MBean interface for ClassA.
>>>>
>>> Actually, when you do
>>> ClassA extends Service implements <<BInterface>>
>>>
>>> the Introspector will return <<ServiceMBean>> as the standard mbean
>>> interface for ClassA. I've just tried it on a simple project to make
>>> sure I understand the code correctly. The puzzle is which behaviour is
>>> correct? Either all the levels of the interface hierarchy should be
>>> checked for the [className]MBean interfaces or none, I guess. However,
>>> I can not find anything in the spec related to this case.
>>>
>>
>> I've updated the webrev not to use Class.forName() when inferring the
>> MBean interface to use.
>>
>> However, I've changed the way the interface hierarchy is treated -
>> originally, all the interfaces of a certain class and their direct super
>> interfaces were checked for the MBean interface candidates (with
>> [class.Name]MBean class name) - but only one level of the hierarchy was
>> checked. The new implementation will check only the direct interfaces.
>>
>> I am still not sure whether the interface hierarchy should be searched
>> for the appropriately named interfaces or not. The spec does not say
>> anything about this and all the jtreg and jck tests are indifferent to
>> my changes. But I am sure that if it is supposed to search the interface
>> hierarchy it should not stop after the first level has been checked, as
>> is done by the current implementation.
>>
> Your modification changes the current JMX behavior, if the spec does
> not say about interface searching, I think it is better to keep the
> current behavior for the implementation compatibility.
>
> Here are examples:
> 1)    A extends B implements AMBean, BMBean
> the current JMX will get AMBean for the class A, but BMBean will be
> got with your modification.

No, it will return AMBean. Firstly, the A is interrogated and if there 
is an AMBean interface in the list of implemented interfaces it is 
returned.

> 2)    A extends B implements AMBean
> the current JMX will get AMBean for the class A, but which mbean
> interface will be found with your modification? I think it will be null.

No, it will return AMBean.

The only thing I've changed is that if you have BMBean extends AMBean 
and A implements BMBean the AMBean won't be returned. While the current 
implementation would return AMBean if we add CMBean extends BMBean and 
then A implements CMBean it will fail to return the AMBean even though 
it is virtually the same situation. IMO, the implementation should be 
consistent whether it walks up the interface hierarchy to find the 
MBean interface or not - and not to choose an arbitrary number of 
levels that will be checked (currently 2).

>
> 367             if ((Modifier.isPublic(mbeanInterface.getModifiers()) ||
>  368                  MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN) &&
>  369                  clMBeanName.equals(mbeanInterface.getName())) {
>  370                 return mbeanInterface;
>  371             }
> As I indicated in my previous mail, better to write as:
>     if (clMBeanName.equals(mbeanInterface.getName() &&
>          (Modifier.isPublic(mbeanInterface.getModifiers()) ||
> MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN)) {
>
> checking name first because it must be cheaper here.

I am not sure - clMBeanName.equals(mbeanInterface.getName()) involves 
character by character comparison. MBeanAnalyzer.ALLOW_NON_PUBLIC_MBEAN 
is simple static field access and if mbeanInterface.getModifiers() 
isn't horribly slow we should be better off with my version. I can 
profile the code to find out the difference.

-JB-

>
> Shanliang
>
>> Webrev: http://cr.openjdk.java.net/~jbachorik/8010285/webrev.02
>>
>> -JB-
>>
>>
>>> -JB-
>>>
>>>
>>>> You can work around that by wrapping an instance of ClassA
>>>> in an instance of  javax.management.StandardMBean, and by
>>>> specifying <<ServiceMBean>>.class as the MBean interface
>>>> in the constructor.
>>>>
>>>> Hope this helps,
>>>>
>>>> -- daniel
>>>>
>>>>
>>>>> -JB-
>>>>>
>>>>>
>>>>>> ?amonn
>>>>>>
>>>>>>
>>>>>> 2013/5/29 Jaroslav Bachorik <jaroslav.bachorik at oracle.com
>>>>>> <mailto:jaroslav.bachorik at oracle.com>>
>>>>>>
>>>>>>      Updated webrev -
>>>>>>      http://cr.openjdk.java.net/~jbachorik/8010285/webrev.01
>>>>>>
>>>>>>      It adds regtests and takes care of the comments from David and
>>>>>>      Shanliang.
>>>>>>
>>>>>>      -JB-
>>>>>>
>>>>>>      On 05/28/2013 04:22 PM, Jaroslav Bachorik wrote:
>>>>>>      > The fix enforces the management interfaces (read MBean and
>>>>>> MXBean
>>>>>>      > interfaces) being public. While this is defined in the
>>>>>>      specification it
>>>>>>      > was not enforced in any way and it was allowed to create MBeans
>>>>>>      for eg.
>>>>>>      > private MBean interfaces.
>>>>>>      >
>>>>>>      > The fix adds checks when creating and registering MBeans and
>>>>>> throws
>>>>>>      > javax.management.NotCompliantMBeanException when a user tries to
>>>>>>      create
>>>>>>      > an MBean with non-public management interface.
>>>>>>      >
>>>>>>      > Since this change can cause problems for users having non-public
>>>>>>      > management interfaces a system property is introduced that will
>>>>>>      revert
>>>>>>      > to the old behaviour when set
>>>>>> (com.sun.jmx.mbeans.allowNonPublic).
>>>>>>      >
>>>>>>      > Thanks,
>>>>>>      >
>>>>>>      > -JB-
>>>>>>      >
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
>



From shanliang.jiang at oracle.com  Wed Jun  5 05:52:36 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Wed, 5 Jun 2013 05:52:36 -0700 (PDT)
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51AF136C.8070806@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com>
	<51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com>
Message-ID: <51AF3494.3070304@oracle.com>

Jaroslav Bachorik wrote:
> On Wed 05 Jun 2013 11:34:05 AM CEST, shanliang wrote:
>   
>> Jaroslav Bachorik wrote:
>>     
>>> On 05/30/2013 09:32 AM, Jaroslav Bachorik wrote:
>>>
>>>       
>>>> On Wed 29 May 2013 07:44:34 PM CEST, Daniel Fuchs wrote:
>>>>
>>>>         
>>>>> On 5/29/13 7:17 PM, Jaroslav Bachorik wrote:
>>>>>
>>>>>           
>>>>>> On Wed 29 May 2013 05:33:21 PM CEST, Eamonn McManus wrote:
>>>>>>
>>>>>>             
>>>>>>> I would recommend against changing the code to do additional calls to
>>>>>>> Class.forName during MBean introspection. As I recall we made the
>>>>>>> opposite change some years ago, both because Class.forName can be slow
>>>>>>> (it may call out to a user ClassLoader) and because it is a potential
>>>>>>> source of security problems.
>>>>>>>
>>>>>>>               
>>>>>> Thanks. I was trying to dig some history from mercurial but couldn't.
>>>>>> Walking through all the related interfaces is equally acceptable - I've
>>>>>> tried both of the solutions and they test well with the regtests.
>>>>>>
>>>>>> I am still puzzled by the current implementation which will fail to
>>>>>> locate the correct MBean interface in eg.
>>>>>>
>>>>>> <<CInterface>> extends <<BInterface>> extends <<ServiceMBean>>
>>>>>>
>>>>>> ClassA extends Service implements <<CInterface>>
>>>>>>
>>>>>> as the process would stop on <<BInterface>> (checks the superclass of
>>>>>> the ClassA, checks all the interfaces implemented by the Service class,
>>>>>> checks all the interfaces extended by <<CInterface>>) which plainly
>>>>>> does not conform to the MBean interface naming convention and would
>>>>>> miss the <<ServiceMBean>> interface.
>>>>>>
>>>>>>             
>>>>> Hi Jaroslav,
>>>>>
>>>>> <<Service>> would have to implement <<ServiceMBean>> either
>>>>> directly or indirectly.
>>>>>
>>>>> So the current implementation is correct.
>>>>>
>>>>> If <<ServiceMBean>> is not assignable from <<Service>> then
>>>>> <<ServiceMBean>> is not an MBean interface for ClassA.
>>>>>
>>>>>           
>>>> Actually, when you do
>>>> ClassA extends Service implements <<BInterface>>
>>>>
>>>> the Introspector will return <<ServiceMBean>> as the standard mbean
>>>> interface for ClassA. I've just tried it on a simple project to make
>>>> sure I understand the code correctly. The puzzle is which behaviour is
>>>> correct? Either all the levels of the interface hierarchy should be
>>>> checked for the [className]MBean interfaces or none, I guess. However,
>>>> I can not find anything in the spec related to this case.
>>>>
>>>>         
>>> I've updated the webrev not to use Class.forName() when inferring the
>>> MBean interface to use.
>>>
>>> However, I've changed the way the interface hierarchy is treated -
>>> originally, all the interfaces of a certain class and their direct super
>>> interfaces were checked for the MBean interface candidates (with
>>> [class.Name]MBean class name) - but only one level of the hierarchy was
>>> checked. The new implementation will check only the direct interfaces.
>>>
>>> I am still not sure whether the interface hierarchy should be searched
>>> for the appropriately named interfaces or not. The spec does not say
>>> anything about this and all the jtreg and jck tests are indifferent to
>>> my changes. But I am sure that if it is supposed to search the interface
>>> hierarchy it should not stop after the first level has been checked, as
>>> is done by the current implementation.
>>>
>>>       
>> Your modification changes the current JMX behavior, if the spec does
>> not say about interface searching, I think it is better to keep the
>> current behavior for the implementation compatibility.
>>
>> Here are examples:
>> 1)    A extends B implements AMBean, BMBean
>> the current JMX will get AMBean for the class A, but BMBean will be
>> got with your modification.
>>     
>
>   
Sorry I was not clear here, I meant:
class A extends B { ...}
class B implements BMBean, AMBean
> No, it will return AMBean. Firstly, the A is interrogated and if there 
> is an AMBean interface in the list of implemented interfaces it is 
> returned.
>
>   
>> 2)    A extends B implements AMBean
>> the current JMX will get AMBean for the class A, but which mbean
>> interface will be found with your modification? I think it will be null.
>>     
>
> No, it will return AMBean.
>   
class A extends B { ...}
class B implements AMBean {...}
> The only thing I've changed is that if you have BMBean extends AMBean 
> and A implements BMBean the AMBean won't be returned. While the current 
> implementation would return AMBean if we add CMBean extends BMBean and 
> then A implements CMBean it will fail to return the AMBean even though 
> it is virtually the same situation. IMO, the implementation should be 
> consistent whether it walks up the interface hierarchy to find the 
> MBean interface or not - and not to choose an arbitrary number of 
> levels that will be checked (currently 2).
>
>   
>> 367             if ((Modifier.isPublic(mbeanInterface.getModifiers()) ||
>>  368                  MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN) &&
>>  369                  clMBeanName.equals(mbeanInterface.getName())) {
>>  370                 return mbeanInterface;
>>  371             }
>> As I indicated in my previous mail, better to write as:
>>     if (clMBeanName.equals(mbeanInterface.getName() &&
>>          (Modifier.isPublic(mbeanInterface.getModifiers()) ||
>> MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN)) {
>>
>> checking name first because it must be cheaper here.
>>     
>
> I am not sure - clMBeanName.equals(mbeanInterface.getName()) involves 
> character by character comparison. MBeanAnalyzer.ALLOW_NON_PUBLIC_MBEAN 
> is simple static field access and if mbeanInterface.getModifiers() 
> isn't horribly slow we should be better off with my version. I can 
> profile the code to find out the difference.
>   
I meant that Call name.equals would filter off all interfaces except 
those which had same name (at most only one in our case?),  then we 
needed only to call Modifier.isPublic(mbeanInterface.getModifiers() for 
those same named interfaces. 
Modifier.isPublic(mbeanInterface.getModifiers() would returns true for 
all public interfaces so we had to call name.equals for all public 
interfaces until got same named interface.

Shanliang
> -JB-
>
>   
>> Shanliang
>>
>>     
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8010285/webrev.02
>>>
>>> -JB-
>>>
>>>
>>>       
>>>> -JB-
>>>>
>>>>
>>>>         
>>>>> You can work around that by wrapping an instance of ClassA
>>>>> in an instance of  javax.management.StandardMBean, and by
>>>>> specifying <<ServiceMBean>>.class as the MBean interface
>>>>> in the constructor.
>>>>>
>>>>> Hope this helps,
>>>>>
>>>>> -- daniel
>>>>>
>>>>>
>>>>>           
>>>>>> -JB-
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> ?amonn
>>>>>>>
>>>>>>>
>>>>>>> 2013/5/29 Jaroslav Bachorik <jaroslav.bachorik at oracle.com
>>>>>>> <mailto:jaroslav.bachorik at oracle.com>>
>>>>>>>
>>>>>>>      Updated webrev -
>>>>>>>      http://cr.openjdk.java.net/~jbachorik/8010285/webrev.01
>>>>>>>
>>>>>>>      It adds regtests and takes care of the comments from David and
>>>>>>>      Shanliang.
>>>>>>>
>>>>>>>      -JB-
>>>>>>>
>>>>>>>      On 05/28/2013 04:22 PM, Jaroslav Bachorik wrote:
>>>>>>>      > The fix enforces the management interfaces (read MBean and
>>>>>>> MXBean
>>>>>>>      > interfaces) being public. While this is defined in the
>>>>>>>      specification it
>>>>>>>      > was not enforced in any way and it was allowed to create MBeans
>>>>>>>      for eg.
>>>>>>>      > private MBean interfaces.
>>>>>>>      >
>>>>>>>      > The fix adds checks when creating and registering MBeans and
>>>>>>> throws
>>>>>>>      > javax.management.NotCompliantMBeanException when a user tries to
>>>>>>>      create
>>>>>>>      > an MBean with non-public management interface.
>>>>>>>      >
>>>>>>>      > Since this change can cause problems for users having non-public
>>>>>>>      > management interfaces a system property is introduced that will
>>>>>>>      revert
>>>>>>>      > to the old behaviour when set
>>>>>>> (com.sun.jmx.mbeans.allowNonPublic).
>>>>>>>      >
>>>>>>>      > Thanks,
>>>>>>>      >
>>>>>>>      > -JB-
>>>>>>>      >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>       
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20130605/43e7d350/attachment-0001.html 

From jaroslav.bachorik at oracle.com  Wed Jun  5 06:55:52 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 05 Jun 2013 15:55:52 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51AF3494.3070304@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com>
	<51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com>
	<51AF3494.3070304@oracle.com>
Message-ID: <51AF4368.1040403@oracle.com>

On Wed 05 Jun 2013 02:52:36 PM CEST, shanliang wrote:
> Jaroslav Bachorik wrote:
>> On Wed 05 Jun 2013 11:34:05 AM CEST, shanliang wrote:
>>   
>>> Jaroslav Bachorik wrote:
>>>     
>>>> On 05/30/2013 09:32 AM, Jaroslav Bachorik wrote:
>>>>
>>>>       
>>>>> On Wed 29 May 2013 07:44:34 PM CEST, Daniel Fuchs wrote:
>>>>>
>>>>>         
>>>>>> On 5/29/13 7:17 PM, Jaroslav Bachorik wrote:
>>>>>>
>>>>>>           
>>>>>>> On Wed 29 May 2013 05:33:21 PM CEST, Eamonn McManus wrote:
>>>>>>>
>>>>>>>             
>>>>>>>> I would recommend against changing the code to do additional calls to
>>>>>>>> Class.forName during MBean introspection. As I recall we made the
>>>>>>>> opposite change some years ago, both because Class.forName can be slow
>>>>>>>> (it may call out to a user ClassLoader) and because it is a potential
>>>>>>>> source of security problems.
>>>>>>>>
>>>>>>>>               
>>>>>>> Thanks. I was trying to dig some history from mercurial but couldn't.
>>>>>>> Walking through all the related interfaces is equally acceptable - I've
>>>>>>> tried both of the solutions and they test well with the regtests.
>>>>>>>
>>>>>>> I am still puzzled by the current implementation which will fail to
>>>>>>> locate the correct MBean interface in eg.
>>>>>>>
>>>>>>> <<CInterface>> extends <<BInterface>> extends <<ServiceMBean>>
>>>>>>>
>>>>>>> ClassA extends Service implements <<CInterface>>
>>>>>>>
>>>>>>> as the process would stop on <<BInterface>> (checks the superclass of
>>>>>>> the ClassA, checks all the interfaces implemented by the Service class,
>>>>>>> checks all the interfaces extended by <<CInterface>>) which plainly
>>>>>>> does not conform to the MBean interface naming convention and would
>>>>>>> miss the <<ServiceMBean>> interface.
>>>>>>>
>>>>>>>             
>>>>>> Hi Jaroslav,
>>>>>>
>>>>>> <<Service>> would have to implement <<ServiceMBean>> either
>>>>>> directly or indirectly.
>>>>>>
>>>>>> So the current implementation is correct.
>>>>>>
>>>>>> If <<ServiceMBean>> is not assignable from <<Service>> then
>>>>>> <<ServiceMBean>> is not an MBean interface for ClassA.
>>>>>>
>>>>>>           
>>>>> Actually, when you do
>>>>> ClassA extends Service implements <<BInterface>>
>>>>>
>>>>> the Introspector will return <<ServiceMBean>> as the standard mbean
>>>>> interface for ClassA. I've just tried it on a simple project to make
>>>>> sure I understand the code correctly. The puzzle is which behaviour is
>>>>> correct? Either all the levels of the interface hierarchy should be
>>>>> checked for the [className]MBean interfaces or none, I guess. However,
>>>>> I can not find anything in the spec related to this case.
>>>>>
>>>>>         
>>>> I've updated the webrev not to use Class.forName() when inferring the
>>>> MBean interface to use.
>>>>
>>>> However, I've changed the way the interface hierarchy is treated -
>>>> originally, all the interfaces of a certain class and their direct super
>>>> interfaces were checked for the MBean interface candidates (with
>>>> [class.Name]MBean class name) - but only one level of the hierarchy was
>>>> checked. The new implementation will check only the direct interfaces.
>>>>
>>>> I am still not sure whether the interface hierarchy should be searched
>>>> for the appropriately named interfaces or not. The spec does not say
>>>> anything about this and all the jtreg and jck tests are indifferent to
>>>> my changes. But I am sure that if it is supposed to search the interface
>>>> hierarchy it should not stop after the first level has been checked, as
>>>> is done by the current implementation.
>>>>
>>>>       
>>> Your modification changes the current JMX behavior, if the spec does
>>> not say about interface searching, I think it is better to keep the
>>> current behavior for the implementation compatibility.
>>>
>>> Here are examples:
>>> 1)    A extends B implements AMBean, BMBean
>>> the current JMX will get AMBean for the class A, but BMBean will be
>>> got with your modification.
>>>     
>>
>>   
> Sorry I was not clear here, I meant:
> class A extends B { ...}
> class B implements BMBean, AMBean
>> No, it will return AMBean. Firstly, the A is interrogated and if there 
>> is an AMBean interface in the list of implemented interfaces it is 
>> returned.
>>
>>   
>>> 2)    A extends B implements AMBean
>>> the current JMX will get AMBean for the class A, but which mbean
>>> interface will be found with your modification? I think it will be null.
>>>     
>>
>> No, it will return AMBean.
>>   
> 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

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-

>> The only thing I've changed is that if you have BMBean extends AMBean 
>> and A implements BMBean the AMBean won't be returned. While the current 
>> implementation would return AMBean if we add CMBean extends BMBean and 
>> then A implements CMBean it will fail to return the AMBean even though 
>> it is virtually the same situation. IMO, the implementation should be 
>> consistent whether it walks up the interface hierarchy to find the 
>> MBean interface or not - and not to choose an arbitrary number of 
>> levels that will be checked (currently 2).
>>
>>   
>>> 367             if ((Modifier.isPublic(mbeanInterface.getModifiers()) ||
>>>  368                  MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN) &&
>>>  369                  clMBeanName.equals(mbeanInterface.getName())) {
>>>  370                 return mbeanInterface;
>>>  371             }
>>> As I indicated in my previous mail, better to write as:
>>>     if (clMBeanName.equals(mbeanInterface.getName() &&
>>>          (Modifier.isPublic(mbeanInterface.getModifiers()) ||
>>> MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN)) {
>>>
>>> checking name first because it must be cheaper here.
>>>     
>>
>> I am not sure - clMBeanName.equals(mbeanInterface.getName()) involves 
>> character by character comparison. MBeanAnalyzer.ALLOW_NON_PUBLIC_MBEAN 
>> is simple static field access and if mbeanInterface.getModifiers() 
>> isn't horribly slow we should be better off with my version. I can 
>> profile the code to find out the difference.
>>   
> I meant that Call name.equals would filter off all interfaces except
> those which had same name (at most only one in our case?),  then we
> needed only to call Modifier.isPublic(mbeanInterface.getModifiers()
> for those same named interfaces.
> Modifier.isPublic(mbeanInterface.getModifiers() would returns true for
> all public interfaces so we had to call name.equals for all public
> interfaces until got same named interface.
>
> Shanliang
>> -JB-
>>
>>   
>>> Shanliang
>>>
>>>     
>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8010285/webrev.02
>>>>
>>>> -JB-
>>>>
>>>>
>>>>       
>>>>> -JB-
>>>>>
>>>>>
>>>>>         
>>>>>> You can work around that by wrapping an instance of ClassA
>>>>>> in an instance of  javax.management.StandardMBean, and by
>>>>>> specifying <<ServiceMBean>>.class as the MBean interface
>>>>>> in the constructor.
>>>>>>
>>>>>> Hope this helps,
>>>>>>
>>>>>> -- daniel
>>>>>>
>>>>>>
>>>>>>           
>>>>>>> -JB-
>>>>>>>
>>>>>>>
>>>>>>>             
>>>>>>>> ?amonn
>>>>>>>>
>>>>>>>>
>>>>>>>> 2013/5/29 Jaroslav Bachorik <jaroslav.bachorik at oracle.com
>>>>>>>> <mailto:jaroslav.bachorik at oracle.com>>
>>>>>>>>
>>>>>>>>      Updated webrev -
>>>>>>>>      http://cr.openjdk.java.net/~jbachorik/8010285/webrev.01
>>>>>>>>
>>>>>>>>      It adds regtests and takes care of the comments from David and
>>>>>>>>      Shanliang.
>>>>>>>>
>>>>>>>>      -JB-
>>>>>>>>
>>>>>>>>      On 05/28/2013 04:22 PM, Jaroslav Bachorik wrote:
>>>>>>>>      > The fix enforces the management interfaces (read MBean and
>>>>>>>> MXBean
>>>>>>>>      > interfaces) being public. While this is defined in the
>>>>>>>>      specification it
>>>>>>>>      > was not enforced in any way and it was allowed to create MBeans
>>>>>>>>      for eg.
>>>>>>>>      > private MBean interfaces.
>>>>>>>>      >
>>>>>>>>      > The fix adds checks when creating and registering MBeans and
>>>>>>>> throws
>>>>>>>>      > javax.management.NotCompliantMBeanException when a user tries to
>>>>>>>>      create
>>>>>>>>      > an MBean with non-public management interface.
>>>>>>>>      >
>>>>>>>>      > Since this change can cause problems for users having non-public
>>>>>>>>      > management interfaces a system property is introduced that will
>>>>>>>>      revert
>>>>>>>>      > to the old behaviour when set
>>>>>>>> (com.sun.jmx.mbeans.allowNonPublic).
>>>>>>>>      >
>>>>>>>>      > Thanks,
>>>>>>>>      >
>>>>>>>>      > -JB-
>>>>>>>>      >
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>               
>>>>       
>>
>>
>>   
>


From daniel.fuchs at oracle.com  Wed Jun  5 07:27:07 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 05 Jun 2013 16:27:07 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51AF4368.1040403@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com>
	<51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com>
	<51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com>
Message-ID: <51AF4ABB.1080005@oracle.com>

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

>
> 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-
>


From shanliang.jiang at oracle.com  Wed Jun  5 10:54:10 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Wed, 05 Jun 2013 19:54:10 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51AF4ABB.1080005@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com>
	<51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com>
	<51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com>
	<51AF4ABB.1080005@oracle.com>
Message-ID: <51AF7B42.7020902@oracle.com>

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.

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-
>>
>


From jaroslav.bachorik at oracle.com  Wed Jun  5 13:06:46 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 05 Jun 2013 22:06:46 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51AF7B42.7020902@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com>
	<51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com>
	<51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com>
	<51AF4ABB.1080005@oracle.com> <51AF7B42.7020902@oracle.com>
Message-ID: <51AF9A56.4090709@oracle.com>

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-
>>>
>>
>



From shanliang.jiang at oracle.com  Thu Jun  6 08:22:31 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Thu, 06 Jun 2013 17:22:31 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51AF9A56.4090709@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com>
	<51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com>
	<51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com>
	<51AF4ABB.1080005@oracle.com> <51AF7B42.7020902@oracle.com>
	<51AF9A56.4090709@oracle.com>
Message-ID: <51B0A937.90607@oracle.com>

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/jmx-dev/attachments/20130606/d94a150e/attachment.html 

From jaroslav.bachorik at oracle.com  Thu Jun  6 08:28:55 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 06 Jun 2013 17:28:55 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51B0A937.90607@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com>
	<51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com>
	<51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com>
	<51AF4ABB.1080005@oracle.com> <51AF7B42.7020902@oracle.com>
	<51AF9A56.4090709@oracle.com> <51B0A937.90607@oracle.com>
Message-ID: <51B0AAB7.7070802@oracle.com>

On Thu 06 Jun 2013 05:22:31 PM CEST, shanliang wrote:
> 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.

Hm, wouldn't it be better to move the actual logic from 
MBeanServerInvocationHandler.newProxyInstance to JMX.newMBeanProxy and 
delegate the MBSIH.newProxyInstance back to JMX.newMBeanProxy ? This 
way it would be consistent with the way JMX.newMXBeanProxy is written.

>
> All others are OK for me.

Thanks.

-JB-

>
> 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-
>>>>>
>>>>>
>>
>>
>>
>



From shanliang.jiang at oracle.com  Thu Jun  6 09:06:52 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Thu, 06 Jun 2013 18:06:52 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51B0AAB7.7070802@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com>
	<51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com>
	<51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com>
	<51AF4ABB.1080005@oracle.com> <51AF7B42.7020902@oracle.com>
	<51AF9A56.4090709@oracle.com> <51B0A937.90607@oracle.com>
	<51B0AAB7.7070802@oracle.com>
Message-ID: <51B0B39C.1050305@oracle.com>

Jaroslav Bachorik wrote:
> On Thu 06 Jun 2013 05:22:31 PM CEST, shanliang wrote:
>   
>> 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.
>>     
>
> Hm, wouldn't it be better to move the actual logic from 
> MBeanServerInvocationHandler.newProxyInstance to JMX.newMBeanProxy and 
> delegate the MBSIH.newProxyInstance back to JMX.newMBeanProxy ? This 
> way it would be consistent with the way JMX.newMXBeanProxy is written.
>   
I have no opinion here, this is an implementation detail, anyway we have 
to keep both JMX.newMBeanProxy and 
MBeanServerInvocationHandler.newProxyInstance

Shanliang
>   
>> All others are OK for me.
>>     
>
> Thanks.
>
> -JB-
>
>   
>> 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/jmx-dev/attachments/20130606/d4cb41b1/attachment-0001.html 

From jaroslav.bachorik at oracle.com  Fri Jun  7 00:13:07 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Fri, 07 Jun 2013 09:13:07 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51B0B39C.1050305@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com>
	<51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com>
	<51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com>
	<51AF4ABB.1080005@oracle.com> <51AF7B42.7020902@oracle.com>
	<51AF9A56.4090709@oracle.com> <51B0A937.90607@oracle.com>
	<51B0AAB7.7070802@oracle.com> <51B0B39C.1050305@oracle.com>
Message-ID: <51B18803.7060406@oracle.com>

On Thu 06 Jun 2013 06:06:52 PM CEST, shanliang wrote:
> Jaroslav Bachorik wrote:
>> On Thu 06 Jun 2013 05:22:31 PM CEST, shanliang wrote:
>>
>>> 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.
>>>
>>
>> Hm, wouldn't it be better to move the actual logic from
>> MBeanServerInvocationHandler.newProxyInstance to JMX.newMBeanProxy and
>> delegate the MBSIH.newProxyInstance back to JMX.newMBeanProxy ? This
>> way it would be consistent with the way JMX.newMXBeanProxy is written.
>>
> I have no opinion here, this is an implementation detail, anyway we
> have to keep both JMX.newMBeanProxy and
> MBeanServerInvocationHandler.newProxyInstance

http://cr.openjdk.java.net/~jbachorik/8010285/webrev.04

I've moved the newMBeanProxy() logic to JMX to keep it consistent  with 
JMX.newMXBeanProxy(); MBSIH.newProxyInstance() is just forwarded to 
JMX.newMBeanProxy()

-JB-

>
> Shanliang
>>
>>> All others are OK for me.
>>>
>>
>> Thanks.
>>
>> -JB-
>>
>>
>>> 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-
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>
>>
>>
>



From daniel.fuchs at oracle.com  Fri Jun  7 02:07:46 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 07 Jun 2013 11:07:46 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51B18803.7060406@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com>
	<51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com>
	<51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com>
	<51AF4ABB.1080005@oracle.com> <51AF7B42.7020902@oracle.com>
	<51AF9A56.4090709@oracle.com> <51B0A937.90607@oracle.com>
	<51B0AAB7.7070802@oracle.com> <51B0B39C.1050305@oracle.com>
	<51B18803.7060406@oracle.com>
Message-ID: <51B1A2E2.5030001@oracle.com>

> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.04

Hi Jaroslav,

This looks good to me.

I assume you've been running both the java.lang & javax.management
unit tests & JCK (java.lang JCK also has some test cases that
indirectly involve JMX introspection).

Also, maybe you could add a test to check that
the system property which allows to revert to the old
behavior is taken into account?

good work!

-- daniel


On 6/7/13 9:13 AM, Jaroslav Bachorik wrote:
> On Thu 06 Jun 2013 06:06:52 PM CEST, shanliang wrote:
>> Jaroslav Bachorik wrote:
>>> On Thu 06 Jun 2013 05:22:31 PM CEST, shanliang wrote:
>>>
>>>> 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.
>>>>
>>>
>>> Hm, wouldn't it be better to move the actual logic from
>>> MBeanServerInvocationHandler.newProxyInstance to JMX.newMBeanProxy and
>>> delegate the MBSIH.newProxyInstance back to JMX.newMBeanProxy ? This
>>> way it would be consistent with the way JMX.newMXBeanProxy is written.
>>>
>> I have no opinion here, this is an implementation detail, anyway we
>> have to keep both JMX.newMBeanProxy and
>> MBeanServerInvocationHandler.newProxyInstance
>
> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.04
>
> I've moved the newMBeanProxy() logic to JMX to keep it consistent  with
> JMX.newMXBeanProxy(); MBSIH.newProxyInstance() is just forwarded to
> JMX.newMBeanProxy()
>
> -JB-
>
>>
>> Shanliang
>>>
>>>> All others are OK for me.
>>>>
>>>
>>> Thanks.
>>>
>>> -JB-
>>>
>>>
>>>> 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-
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>
>


From jaroslav.bachorik at oracle.com  Tue Jun 18 03:01:55 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 18 Jun 2013 12:01:55 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51B1A2E2.5030001@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com>
	<51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com>
	<51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com>
	<51AF4ABB.1080005@oracle.com> <51AF7B42.7020902@oracle.com>
	<51AF9A56.4090709@oracle.com> <51B0A937.90607@oracle.com>
	<51B0AAB7.7070802@oracle.com> <51B0B39C.1050305@oracle.com>
	<51B18803.7060406@oracle.com> <51B1A2E2.5030001@oracle.com>
Message-ID: <51C03013.2020700@oracle.com>

On 06/07/2013 11:07 AM, Daniel Fuchs wrote:
>> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.04
> 
> Hi Jaroslav,
> 
> This looks good to me.
> 
> I assume you've been running both the java.lang & javax.management
> unit tests & JCK (java.lang JCK also has some test cases that
> indirectly involve JMX introspection).

Yes, I've run all the regtests and JCKs for api/javax_management and
api/java_lang. No regressions were detected.

> 
> Also, maybe you could add a test to check that
> the system property which allows to revert to the old
> behavior is taken into account?

I've added the tests for the proper behaviour when the
"com.sun.jmx.mbeans.allowNonPublic" system property is set to true.

http://cr.openjdk.java.net/~jbachorik/8010285/webrev.05/

-JB-

> 
> good work!
> 
> -- daniel
> 
> 
> On 6/7/13 9:13 AM, Jaroslav Bachorik wrote:
>> On Thu 06 Jun 2013 06:06:52 PM CEST, shanliang wrote:
>>> Jaroslav Bachorik wrote:
>>>> On Thu 06 Jun 2013 05:22:31 PM CEST, shanliang wrote:
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Hm, wouldn't it be better to move the actual logic from
>>>> MBeanServerInvocationHandler.newProxyInstance to JMX.newMBeanProxy and
>>>> delegate the MBSIH.newProxyInstance back to JMX.newMBeanProxy ? This
>>>> way it would be consistent with the way JMX.newMXBeanProxy is written.
>>>>
>>> I have no opinion here, this is an implementation detail, anyway we
>>> have to keep both JMX.newMBeanProxy and
>>> MBeanServerInvocationHandler.newProxyInstance
>>
>> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.04
>>
>> I've moved the newMBeanProxy() logic to JMX to keep it consistent  with
>> JMX.newMXBeanProxy(); MBSIH.newProxyInstance() is just forwarded to
>> JMX.newMBeanProxy()
>>
>> -JB-
>>
>>>
>>> Shanliang
>>>>
>>>>> All others are OK for me.
>>>>>
>>>>
>>>> Thanks.
>>>>
>>>> -JB-
>>>>
>>>>
>>>>> 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-
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
> 


From daniel.fuchs at oracle.com  Tue Jun 18 03:25:35 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 18 Jun 2013 12:25:35 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51C03013.2020700@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com>
	<51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com>
	<51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com>
	<51AF4ABB.1080005@oracle.com> <51AF7B42.7020902@oracle.com>
	<51AF9A56.4090709@oracle.com> <51B0A937.90607@oracle.com>
	<51B0AAB7.7070802@oracle.com> <51B0B39C.1050305@oracle.com>
	<51B18803.7060406@oracle.com> <51B1A2E2.5030001@oracle.com>
	<51C03013.2020700@oracle.com>
Message-ID: <51C0359F.8090201@oracle.com>

Hi Jaroslav,

 > I've added the tests for the proper behaviour when the
 > "com.sun.jmx.mbeans.allowNonPublic" system property is set to true.
 >
 > http://cr.openjdk.java.net/~jbachorik/8010285/webrev.05/

Thanks for adding the test. I haven't looked at the source again,
I trust nothing changed there. Some issues in the tests:

MBeanFallbackTest.java:

   57         if (failures > 0) {
   58             System.exit(1);
   59         }

I think
     throw new Exception("TEST FAILURES: " + failures);
would be more appropriate.

Also I see that you have an @run main line - I believe it
should be @run main/othervm since the test sets some
system properties.


MXBeanFallbackTest.java:

  30  * @author Eamonn McManus

Is that a copy paste issue?

  47         System.in.read();

Left over from debugging session - right ;-) ?

I see that you have an @run main line there too - I
believe it  should be @run main/othervm since this
test also sets some  system properties.


JMXProxyFallbackTest.java:

   63         if (failures > 0) {
   64             System.exit(1);
   65         }

should throw new Exception("TEST FAILURES: " + failures);
instead.

I see that you have an @run main line there too - I
believe it  should be @run main/othervm since this
test also sets some  system properties.

JMXProxyTest.java:

  120         if (failures > 0) {
  121             System.exit(1);
  122         }

should throw new Exception("TEST FAILURES: " + failures);
instead.

best regards,

-- daniel


On 6/18/13 12:01 PM, Jaroslav Bachorik wrote:
> On 06/07/2013 11:07 AM, Daniel Fuchs wrote:
>>> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.04
>>
>> Hi Jaroslav,
>>
>> This looks good to me.
>>
>> I assume you've been running both the java.lang & javax.management
>> unit tests & JCK (java.lang JCK also has some test cases that
>> indirectly involve JMX introspection).
>
> Yes, I've run all the regtests and JCKs for api/javax_management and
> api/java_lang. No regressions were detected.
>
>>
>> Also, maybe you could add a test to check that
>> the system property which allows to revert to the old
>> behavior is taken into account?
>
> I've added the tests for the proper behaviour when the
> "com.sun.jmx.mbeans.allowNonPublic" system property is set to true.
>
> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.05/
>
> -JB-
>
>>
>> good work!
>>
>> -- daniel
>>
>>
>> On 6/7/13 9:13 AM, Jaroslav Bachorik wrote:
>>> On Thu 06 Jun 2013 06:06:52 PM CEST, shanliang wrote:
>>>> Jaroslav Bachorik wrote:
>>>>> On Thu 06 Jun 2013 05:22:31 PM CEST, shanliang wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> Hm, wouldn't it be better to move the actual logic from
>>>>> MBeanServerInvocationHandler.newProxyInstance to JMX.newMBeanProxy and
>>>>> delegate the MBSIH.newProxyInstance back to JMX.newMBeanProxy ? This
>>>>> way it would be consistent with the way JMX.newMXBeanProxy is written.
>>>>>
>>>> I have no opinion here, this is an implementation detail, anyway we
>>>> have to keep both JMX.newMBeanProxy and
>>>> MBeanServerInvocationHandler.newProxyInstance
>>>
>>> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.04
>>>
>>> I've moved the newMBeanProxy() logic to JMX to keep it consistent  with
>>> JMX.newMXBeanProxy(); MBSIH.newProxyInstance() is just forwarded to
>>> JMX.newMBeanProxy()
>>>
>>> -JB-
>>>
>>>>
>>>> Shanliang
>>>>>
>>>>>> All others are OK for me.
>>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> -JB-
>>>>>
>>>>>
>>>>>> 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-
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>


From jaroslav.bachorik at oracle.com  Tue Jun 18 03:30:07 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 18 Jun 2013 12:30:07 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51C0359F.8090201@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com>
	<51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com>
	<51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com>
	<51AF4ABB.1080005@oracle.com> <51AF7B42.7020902@oracle.com>
	<51AF9A56.4090709@oracle.com> <51B0A937.90607@oracle.com>
	<51B0AAB7.7070802@oracle.com> <51B0B39C.1050305@oracle.com>
	<51B18803.7060406@oracle.com> <51B1A2E2.5030001@oracle.com>
	<51C03013.2020700@oracle.com> <51C0359F.8090201@oracle.com>
Message-ID: <51C036AF.1030206@oracle.com>

On Tue 18 Jun 2013 12:25:35 PM CEST, Daniel Fuchs wrote:
> Hi Jaroslav,
>
> > I've added the tests for the proper behaviour when the
> > "com.sun.jmx.mbeans.allowNonPublic" system property is set to true.
> >
> > http://cr.openjdk.java.net/~jbachorik/8010285/webrev.05/
>
> Thanks for adding the test. I haven't looked at the source again,
> I trust nothing changed there. Some issues in the tests:
>
> MBeanFallbackTest.java:
>
>   57         if (failures > 0) {
>   58             System.exit(1);
>   59         }
>
> I think
>     throw new Exception("TEST FAILURES: " + failures);
> would be more appropriate.

I saw both of them used across the regtests and was not really sure 
which is the recommended way of signalling the test failure ...

>
> Also I see that you have an @run main line - I believe it
> should be @run main/othervm since the test sets some
> system properties.

Currently all the testst in javax/management are run as main/othervm. 
But it won't hurt to make the intention of running the test in a 
separate JVM visually clear.

The same applies to the rest of the new tests.

>
>
> MXBeanFallbackTest.java:
>
>  30  * @author Eamonn McManus

Yep :/

-JB-

>
> Is that a copy paste issue?
>
>  47         System.in.read();
>
> Left over from debugging session - right ;-) ?
>
> I see that you have an @run main line there too - I
> believe it  should be @run main/othervm since this
> test also sets some  system properties.
>
>
> JMXProxyFallbackTest.java:
>
>   63         if (failures > 0) {
>   64             System.exit(1);
>   65         }
>
> should throw new Exception("TEST FAILURES: " + failures);
> instead.
>
> I see that you have an @run main line there too - I
> believe it  should be @run main/othervm since this
> test also sets some  system properties.
>
> JMXProxyTest.java:
>
>  120         if (failures > 0) {
>  121             System.exit(1);
>  122         }
>
> should throw new Exception("TEST FAILURES: " + failures);
> instead.
>
> best regards,
>
> -- daniel
>
>
> On 6/18/13 12:01 PM, Jaroslav Bachorik wrote:
>> On 06/07/2013 11:07 AM, Daniel Fuchs wrote:
>>>> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.04
>>>
>>> Hi Jaroslav,
>>>
>>> This looks good to me.
>>>
>>> I assume you've been running both the java.lang & javax.management
>>> unit tests & JCK (java.lang JCK also has some test cases that
>>> indirectly involve JMX introspection).
>>
>> Yes, I've run all the regtests and JCKs for api/javax_management and
>> api/java_lang. No regressions were detected.
>>
>>>
>>> Also, maybe you could add a test to check that
>>> the system property which allows to revert to the old
>>> behavior is taken into account?
>>
>> I've added the tests for the proper behaviour when the
>> "com.sun.jmx.mbeans.allowNonPublic" system property is set to true.
>>
>> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.05/
>>
>> -JB-
>>
>>>
>>> good work!
>>>
>>> -- daniel
>>>
>>>
>>> On 6/7/13 9:13 AM, Jaroslav Bachorik wrote:
>>>> On Thu 06 Jun 2013 06:06:52 PM CEST, shanliang wrote:
>>>>> Jaroslav Bachorik wrote:
>>>>>> On Thu 06 Jun 2013 05:22:31 PM CEST, shanliang wrote:
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> Hm, wouldn't it be better to move the actual logic from
>>>>>> MBeanServerInvocationHandler.newProxyInstance to
>>>>>> JMX.newMBeanProxy and
>>>>>> delegate the MBSIH.newProxyInstance back to JMX.newMBeanProxy ? This
>>>>>> way it would be consistent with the way JMX.newMXBeanProxy is
>>>>>> written.
>>>>>>
>>>>> I have no opinion here, this is an implementation detail, anyway we
>>>>> have to keep both JMX.newMBeanProxy and
>>>>> MBeanServerInvocationHandler.newProxyInstance
>>>>
>>>> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.04
>>>>
>>>> I've moved the newMBeanProxy() logic to JMX to keep it consistent
>>>> with
>>>> JMX.newMXBeanProxy(); MBSIH.newProxyInstance() is just forwarded to
>>>> JMX.newMBeanProxy()
>>>>
>>>> -JB-
>>>>
>>>>>
>>>>> Shanliang
>>>>>>
>>>>>>> All others are OK for me.
>>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> -JB-
>>>>>>
>>>>>>
>>>>>>> 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-
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>



From jaroslav.bachorik at oracle.com  Tue Jun 18 04:27:07 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 18 Jun 2013 13:27:07 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51C036AF.1030206@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com>
	<51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com>
	<51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com>
	<51AF4ABB.1080005@oracle.com> <51AF7B42.7020902@oracle.com>
	<51AF9A56.4090709@oracle.com> <51B0A937.90607@oracle.com>
	<51B0AAB7.7070802@oracle.com> <51B0B39C.1050305@oracle.com>
	<51B18803.7060406@oracle.com> <51B1A2E2.5030001@oracle.com>
	<51C03013.2020700@oracle.com> <51C0359F.8090201@oracle.com>
	<51C036AF.1030206@oracle.com>
Message-ID: <51C0440B.9030601@oracle.com>

On Tue 18 Jun 2013 12:30:07 PM CEST, Jaroslav Bachorik wrote:
> On Tue 18 Jun 2013 12:25:35 PM CEST, Daniel Fuchs wrote:
>> Hi Jaroslav,
>>
>>> I've added the tests for the proper behaviour when the
>>> "com.sun.jmx.mbeans.allowNonPublic" system property is set to true.
>>>
>>> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.05/
>>
>> Thanks for adding the test. I haven't looked at the source again,
>> I trust nothing changed there. Some issues in the tests:
>>
>> MBeanFallbackTest.java:
>>
>>   57         if (failures > 0) {
>>   58             System.exit(1);
>>   59         }
>>
>> I think
>>     throw new Exception("TEST FAILURES: " + failures);
>> would be more appropriate.
>
> I saw both of them used across the regtests and was not really sure 
> which is the recommended way of signalling the test failure ...
>
>>
>> Also I see that you have an @run main line - I believe it
>> should be @run main/othervm since the test sets some
>> system properties.
>
> Currently all the testst in javax/management are run as main/othervm. 
> But it won't hurt to make the intention of running the test in a 
> separate JVM visually clear.
>
> The same applies to the rest of the new tests.
>
>>
>>
>> MXBeanFallbackTest.java:
>>
>>  30  * @author Eamonn McManus
>
> Yep :/

http://cr.openjdk.java.net/~jbachorik/8010285/webrev.06

Unified the way the test failure is reported, removed the forgotten
debug code and copy/paste errors.

I haven't changed "@run main" to "@run main/othervm" since the tests in
javax/management are run in othervm anyway. Also, there is more JMX
tests which eg. start they own MBean server and they don't declare "@run
main/othervm". So I'd prefer staying consistent.

-JB-

>
> -JB-
>
>>
>> Is that a copy paste issue?
>>
>>  47         System.in.read();
>>
>> Left over from debugging session - right ;-) ?
>>
>> I see that you have an @run main line there too - I
>> believe it  should be @run main/othervm since this
>> test also sets some  system properties.
>>
>>

From daniel.fuchs at oracle.com  Tue Jun 18 05:37:37 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 18 Jun 2013 14:37:37 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51C0440B.9030601@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
	<51A70081.5050203@oracle.com> <51AD1955.2090109@oracle.com>
	<51AF060D.5070706@oracle.com> <51AF136C.8070806@oracle.com>
	<51AF3494.3070304@oracle.com> <51AF4368.1040403@oracle.com>
	<51AF4ABB.1080005@oracle.com> <51AF7B42.7020902@oracle.com>
	<51AF9A56.4090709@oracle.com> <51B0A937.90607@oracle.com>
	<51B0AAB7.7070802@oracle.com> <51B0B39C.1050305@oracle.com>
	<51B18803.7060406@oracle.com> <51B1A2E2.5030001@oracle.com>
	<51C03013.2020700@oracle.com> <51C0359F.8090201@oracle.com>
	<51C036AF.1030206@oracle.com> <51C0440B.9030601@oracle.com>
Message-ID: <51C05491.6070507@oracle.com>

On 6/18/13 1:27 PM, Jaroslav Bachorik wrote:
> On Tue 18 Jun 2013 12:30:07 PM CEST, Jaroslav Bachorik wrote:
>> On Tue 18 Jun 2013 12:25:35 PM CEST, Daniel Fuchs wrote:
>>> Hi Jaroslav,
>>>
>>>> I've added the tests for the proper behaviour when the
>>>> "com.sun.jmx.mbeans.allowNonPublic" system property is set to true.
>>>>
>>>> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.05/
>>>
>>> Thanks for adding the test. I haven't looked at the source again,
>>> I trust nothing changed there. Some issues in the tests:
>>>
>>> MBeanFallbackTest.java:
>>>
>>>    57         if (failures > 0) {
>>>    58             System.exit(1);
>>>    59         }
>>>
>>> I think
>>>      throw new Exception("TEST FAILURES: " + failures);
>>> would be more appropriate.
>>
>> I saw both of them used across the regtests and was not really sure
>> which is the recommended way of signalling the test failure ...
>>
>>>
>>> Also I see that you have an @run main line - I believe it
>>> should be @run main/othervm since the test sets some
>>> system properties.
>>
>> Currently all the testst in javax/management are run as main/othervm.
>> But it won't hurt to make the intention of running the test in a
>> separate JVM visually clear.
>>
>> The same applies to the rest of the new tests.
>>
>>>
>>>
>>> MXBeanFallbackTest.java:
>>>
>>>   30  * @author Eamonn McManus
>>
>> Yep :/
>
> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.06
>
> Unified the way the test failure is reported, removed the forgotten
> debug code and copy/paste errors.
>
> I haven't changed "@run main" to "@run main/othervm" since the tests in
> javax/management are run in othervm anyway. Also, there is more JMX
> tests which eg. start they own MBean server and they don't declare "@run
> main/othervm". So I'd prefer staying consistent.
>
> -JB-

Looks good! But I'm not a reviewer...

-- daniel

>
>>
>> -JB-
>>
>>>
>>> Is that a copy paste issue?
>>>
>>>   47         System.in.read();
>>>
>>> Left over from debugging session - right ;-) ?
>>>
>>> I see that you have an @run main line there too - I
>>> believe it  should be @run main/othervm since this
>>> test also sets some  system properties.
>>>
>>>