From jaroslav.bachorik at oracle.com  Thu May  2 03:39:29 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 02 May 2013 12:39:29 +0200
Subject: jmx-dev [PING] Re: [PATCH] JDK-7199324: IPv6
 JMXConnectorServer.getConnectionIDs() return IDs contradicting address
 grammar
In-Reply-To: <51794290.7050806@oracle.com>
References: <50D302B1.7080203@oracle.com> <50D86A01.2060703@oracle.com>
	<51793F3B.9020303@oracle.com> <51794290.7050806@oracle.com>
Message-ID: <51824261.9060100@oracle.com>

On ?t?25.?duben?2013,?16:49:52?CEST, Alan Bateman wrote:
> On 25/04/2013 15:35, Jaroslav Bachorik wrote:
>> Reviving the review process.
>>
>> I still need an official openjdk reviewer for this.
>>
>> Thanks,
>>
>> -JB-
> Just so I understand, the issue is that RemoteServer.getClientHost is
> returning a String with an IPv6 literal address so you need to enclose
> it in [] when building the connection id. That seems reasonable to me.

Exactly.

> A minor comment on the wording of the comment it that it would be
> clear if there was a comma after "package description".

Fixed.

>
> The test looks okay to me although I had to read it a few times to
> understand that <proto>:// was being removed from s.

I've improved the client address detection - in addition to being more 
readable it handles properly the <host_id>:<port> form of the IPv4 
address.

Update webrev @ 
http://cr.openjdk.java.net/~jbachorik/JDK-7199324/webrev.02

-JB-

>
> -Alan.
>
>



From Alan.Bateman at oracle.com  Thu May  2 03:48:06 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 02 May 2013 11:48:06 +0100
Subject: jmx-dev [PING] Re: [PATCH] JDK-7199324: IPv6
 JMXConnectorServer.getConnectionIDs() return IDs contradicting address
 grammar
In-Reply-To: <51824261.9060100@oracle.com>
References: <50D302B1.7080203@oracle.com> <50D86A01.2060703@oracle.com>
	<51793F3B.9020303@oracle.com> <51794290.7050806@oracle.com>
	<51824261.9060100@oracle.com>
Message-ID: <51824466.2020905@oracle.com>

On 02/05/2013 11:39, Jaroslav Bachorik wrote:
> On ?t 25. duben 2013, 16:49:52 CEST, Alan Bateman wrote:
>> On 25/04/2013 15:35, Jaroslav Bachorik wrote:
>>> Reviving the review process.
>>>
>>> I still need an official openjdk reviewer for this.
>>>
>>> Thanks,
>>>
>>> -JB-
>> Just so I understand, the issue is that RemoteServer.getClientHost is
>> returning a String with an IPv6 literal address so you need to enclose
>> it in [] when building the connection id. That seems reasonable to me.
> Exactly.
>
>> A minor comment on the wording of the comment it that it would be
>> clear if there was a comma after "package description".
> Fixed.
>
>> The test looks okay to me although I had to read it a few times to
>> understand that<proto>:// was being removed from s.
> I've improved the client address detection - in addition to being more
> readable it handles properly the<host_id>:<port>  form of the IPv4
> address.
>
> Update webrev @
> http://cr.openjdk.java.net/~jbachorik/JDK-7199324/webrev.02
>
This looks okay to me. A minor comment on the test is that we usually 
put the "final" after the "private static". Also constants are usually 
in upper case.

-Alan.

From jaroslav.bachorik at oracle.com  Thu May  2 03:52:33 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 02 May 2013 12:52:33 +0200
Subject: jmx-dev [PING] Re: [PATCH] JDK-7199324: IPv6
 JMXConnectorServer.getConnectionIDs() return IDs contradicting address
 grammar
In-Reply-To: <51824466.2020905@oracle.com>
References: <50D302B1.7080203@oracle.com> <50D86A01.2060703@oracle.com>
	<51793F3B.9020303@oracle.com> <51794290.7050806@oracle.com>
	<51824261.9060100@oracle.com> <51824466.2020905@oracle.com>
Message-ID: <51824571.6010702@oracle.com>

On ?t?2.?kv?ten?2013,?12:48:06?CEST, Alan Bateman wrote:
> On 02/05/2013 11:39, Jaroslav Bachorik wrote:
>> On ?t 25. duben 2013, 16:49:52 CEST, Alan Bateman wrote:
>>> On 25/04/2013 15:35, Jaroslav Bachorik wrote:
>>>> Reviving the review process.
>>>>
>>>> I still need an official openjdk reviewer for this.
>>>>
>>>> Thanks,
>>>>
>>>> -JB-
>>> Just so I understand, the issue is that RemoteServer.getClientHost is
>>> returning a String with an IPv6 literal address so you need to enclose
>>> it in [] when building the connection id. That seems reasonable to me.
>> Exactly.
>>
>>> A minor comment on the wording of the comment it that it would be
>>> clear if there was a comma after "package description".
>> Fixed.
>>
>>> The test looks okay to me although I had to read it a few times to
>>> understand that<proto>:// was being removed from s.
>> I've improved the client address detection - in addition to being more
>> readable it handles properly the<host_id>:<port>  form of the IPv4
>> address.
>>
>> Update webrev @
>> http://cr.openjdk.java.net/~jbachorik/JDK-7199324/webrev.02
>>
> This looks okay to me. A minor comment on the test is that we usually
> put the "final" after the "private static". Also constants are usually
> in upper case.

Thanks Alan, the comments are addressed in 
http://cr.openjdk.java.net/~jbachorik/JDK-7199324/webrev.03

-JB-

>
> -Alan.



From Alan.Bateman at oracle.com  Thu May  2 03:54:38 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 02 May 2013 11:54:38 +0100
Subject: jmx-dev [PING] Re: [PATCH] JDK-7199324: IPv6
 JMXConnectorServer.getConnectionIDs() return IDs contradicting address
 grammar
In-Reply-To: <51824571.6010702@oracle.com>
References: <50D302B1.7080203@oracle.com> <50D86A01.2060703@oracle.com>
	<51793F3B.9020303@oracle.com> <51794290.7050806@oracle.com>
	<51824261.9060100@oracle.com> <51824466.2020905@oracle.com>
	<51824571.6010702@oracle.com>
Message-ID: <518245EE.4050407@oracle.com>

On 02/05/2013 11:52, Jaroslav Bachorik wrote:
> :
> Thanks Alan, the comments are addressed in
> http://cr.openjdk.java.net/~jbachorik/JDK-7199324/webrev.03
>
> -JB-
>

Looks good to me.

-Alan

From jaroslav.bachorik at oracle.com  Fri May  3 06:41:16 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Fri, 03 May 2013 15:41:16 +0200
Subject: jmx-dev [PATCH] JDK-8005472:
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh
 failed on windows
In-Reply-To: <511529DA.3050901@oracle.com>
References: <50E16BA8.40203@oracle.com>
	<682D734D-2021-48DE-844D-C55A52D27EBD@oracle.com>
	<50EAB014.30805@oracle.com> <50EE813A.1020501@oracle.com>
	<50EEDC23.5080005@oracle.com> <50EF3622.9050500@oracle.com>
	<511119DA.5060806@oracle.com> <51118BEC.7000204@oracle.com>
	<511529DA.3050901@oracle.com>
Message-ID: <5183BE7C.5060708@oracle.com>

Please re-review the updated webrev
http://cr.openjdk.java.net/~jbachorik/8005472/webrev.06

I've replaced the shell script with the plain java test. The javac API
is used to compile the the auxiliary classes as was recommended. This
allowed to simplify the test.

The test does not check for a certain string in the standard output
anymore - it turns out that it is possible to count the number of all
the received JMX notifications (even though some notifications can be
lost, we receive a special notification with the number of the lost
regular notifications). It is then possible to match the actual number
of processed notifications (received + lost) against the expected number
- different numbers mean that the notification processing thread had
been interrupted unexpectedly.

Thanks,

-JB-

On 8.2.2013 17:37, Chris Hegarty wrote:
> 
>> Jon Gibbons suggested invoking the compiler API directly from java
>> instead of writing a shell script. Doing this seems fairly simple, and I
>> think it would be advantageous to keep things entirely in Java. I may
>> attempt to rewrite the defaultSVID test using the compiler API.
> 
> Here's a test that does just that.
> 
> http://hg.openjdk.java.net/jdk8/tl/jdk/file/2de8c6c2d652/test/sun/misc/JarIndex/metaInfFilenames/Basic.java
> 
> 
> -Chris.


From daniel.fuchs at oracle.com  Fri May  3 07:16:53 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 03 May 2013 16:16:53 +0200
Subject: jmx-dev [PATCH] JDK-8005472:
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh
 failed on windows
In-Reply-To: <5183BE7C.5060708@oracle.com>
References: <50E16BA8.40203@oracle.com>
	<682D734D-2021-48DE-844D-C55A52D27EBD@oracle.com>
	<50EAB014.30805@oracle.com> <50EE813A.1020501@oracle.com>
	<50EEDC23.5080005@oracle.com> <50EF3622.9050500@oracle.com>
	<511119DA.5060806@oracle.com> <51118BEC.7000204@oracle.com>
	<511529DA.3050901@oracle.com> <5183BE7C.5060708@oracle.com>
Message-ID: <5183C6D5.8070302@oracle.com>

Hi Jaroslav,

In Client.java - you could consider replacing the AtomicLong
with a CountDownLatch.

This would allow you to remove the various Thread.sleep() in the
code (in particular the one at the end).

You could use CountDownLatch.await(long timeout, TimeUnit unit) to
avoid waiting for ever in case of bugs, and the advantage is that
the test would be able to exit as soon as the count down latch
reaches 0, without having to wait for an arbitrary timeout.

Very nice to see a shell test go away :-)

-- daniel


On 5/3/13 3:41 PM, Jaroslav Bachorik wrote:
> Please re-review the updated webrev
> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.06
>
> I've replaced the shell script with the plain java test. The javac API
> is used to compile the the auxiliary classes as was recommended. This
> allowed to simplify the test.
>
> The test does not check for a certain string in the standard output
> anymore - it turns out that it is possible to count the number of all
> the received JMX notifications (even though some notifications can be
> lost, we receive a special notification with the number of the lost
> regular notifications). It is then possible to match the actual number
> of processed notifications (received + lost) against the expected number
> - different numbers mean that the notification processing thread had
> been interrupted unexpectedly.
>
> Thanks,
>
> -JB-
>
> On 8.2.2013 17:37, Chris Hegarty wrote:
>>
>>> Jon Gibbons suggested invoking the compiler API directly from java
>>> instead of writing a shell script. Doing this seems fairly simple, and I
>>> think it would be advantageous to keep things entirely in Java. I may
>>> attempt to rewrite the defaultSVID test using the compiler API.
>>
>> Here's a test that does just that.
>>
>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/2de8c6c2d652/test/sun/misc/JarIndex/metaInfFilenames/Basic.java
>>
>>
>> -Chris.
>


From jaroslav.bachorik at oracle.com  Mon May  6 02:04:04 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 06 May 2013 11:04:04 +0200
Subject: jmx-dev [PATCH] JDK-8005472:
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh
 failed on windows
In-Reply-To: <5183C6D5.8070302@oracle.com>
References: <50E16BA8.40203@oracle.com>
	<682D734D-2021-48DE-844D-C55A52D27EBD@oracle.com>
	<50EAB014.30805@oracle.com> <50EE813A.1020501@oracle.com>
	<50EEDC23.5080005@oracle.com> <50EF3622.9050500@oracle.com>
	<511119DA.5060806@oracle.com> <51118BEC.7000204@oracle.com>
	<511529DA.3050901@oracle.com> <5183BE7C.5060708@oracle.com>
	<5183C6D5.8070302@oracle.com>
Message-ID: <51877204.8000104@oracle.com>

On P??3.?kv?ten?2013,?16:16:53?CEST, Daniel Fuchs wrote:
> Hi Jaroslav,
>
> In Client.java - you could consider replacing the AtomicLong
> with a CountDownLatch.
>
> This would allow you to remove the various Thread.sleep() in the
> code (in particular the one at the end).
>
> You could use CountDownLatch.await(long timeout, TimeUnit unit) to
> avoid waiting for ever in case of bugs, and the advantage is that
> the test would be able to exit as soon as the count down latch
> reaches 0, without having to wait for an arbitrary timeout.

Great, thanks for the pointer! I've changed the test to use the 
CountDownLatch.

http://cr.openjdk.java.net/~jbachorik/8005472/webrev.08/

-JB-

>
> Very nice to see a shell test go away :-)
>
> -- daniel
>
>
> On 5/3/13 3:41 PM, Jaroslav Bachorik wrote:
>> Please re-review the updated webrev
>> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.06
>>
>> I've replaced the shell script with the plain java test. The javac API
>> is used to compile the the auxiliary classes as was recommended. This
>> allowed to simplify the test.
>>
>> The test does not check for a certain string in the standard output
>> anymore - it turns out that it is possible to count the number of all
>> the received JMX notifications (even though some notifications can be
>> lost, we receive a special notification with the number of the lost
>> regular notifications). It is then possible to match the actual number
>> of processed notifications (received + lost) against the expected number
>> - different numbers mean that the notification processing thread had
>> been interrupted unexpectedly.
>>
>> Thanks,
>>
>> -JB-
>>
>> On 8.2.2013 17:37, Chris Hegarty wrote:
>>>
>>>> Jon Gibbons suggested invoking the compiler API directly from java
>>>> instead of writing a shell script. Doing this seems fairly simple,
>>>> and I
>>>> think it would be advantageous to keep things entirely in Java. I may
>>>> attempt to rewrite the defaultSVID test using the compiler API.
>>>
>>> Here's a test that does just that.
>>>
>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/2de8c6c2d652/test/sun/misc/JarIndex/metaInfFilenames/Basic.java
>>>
>>>
>>>
>>> -Chris.
>>
>



From stuart.marks at oracle.com  Tue May  7 16:50:22 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 07 May 2013 16:50:22 -0700
Subject: jmx-dev [PATCH] JDK-8005472:
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh
 failed on windows
In-Reply-To: <51877204.8000104@oracle.com>
References: <50E16BA8.40203@oracle.com>
	<682D734D-2021-48DE-844D-C55A52D27EBD@oracle.com>
	<50EAB014.30805@oracle.com> <50EE813A.1020501@oracle.com>
	<50EEDC23.5080005@oracle.com> <50EF3622.9050500@oracle.com>
	<511119DA.5060806@oracle.com> <51118BEC.7000204@oracle.com>
	<511529DA.3050901@oracle.com> <5183BE7C.5060708@oracle.com>
	<5183C6D5.8070302@oracle.com> <51877204.8000104@oracle.com>
Message-ID: <5189933E.40702@oracle.com>

Hi Jaroslav,

Great to see this shell test get rewritten!

Looks like you're avoiding multiple JVM processes as well, by loading the 
different versions of the classes into different classloaders. It looks like a 
bit of trouble, but probably less than the amount of trouble caused by the 
shell script.

I have a couple minor points.

The timeout value of one second seems quite low. Under normal operation, 
spawning a couple threads and should proceed very quickly. However, our testing 
environment is quite hostile, and things that seem like they ought to proceed 
quickly often take considerably longer than one might think. Since you're 
counting notifications, and in normal operation they all come in, we don't wait 
for the actual timeout unless there's a failure. So it might make sense to 
raise the timeout to 10 or perhaps 30 seconds.

On the other hand, I have a question about whether counting the number of 
notifications is correct. Would it be possible for there to be a bug where an 
extra notification is sent? If so, this might mean that the test would exit 
prematurely, indicating success?

s'marks

On 5/6/13 2:04 AM, Jaroslav Bachorik wrote:
> On P? 3. kv?ten 2013, 16:16:53 CEST, Daniel Fuchs wrote:
>> Hi Jaroslav,
>>
>> In Client.java - you could consider replacing the AtomicLong
>> with a CountDownLatch.
>>
>> This would allow you to remove the various Thread.sleep() in the
>> code (in particular the one at the end).
>>
>> You could use CountDownLatch.await(long timeout, TimeUnit unit) to
>> avoid waiting for ever in case of bugs, and the advantage is that
>> the test would be able to exit as soon as the count down latch
>> reaches 0, without having to wait for an arbitrary timeout.
>
> Great, thanks for the pointer! I've changed the test to use the
> CountDownLatch.
>
> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.08/
>
> -JB-
>
>>
>> Very nice to see a shell test go away :-)
>>
>> -- daniel
>>
>>
>> On 5/3/13 3:41 PM, Jaroslav Bachorik wrote:
>>> Please re-review the updated webrev
>>> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.06
>>>
>>> I've replaced the shell script with the plain java test. The javac API
>>> is used to compile the the auxiliary classes as was recommended. This
>>> allowed to simplify the test.
>>>
>>> The test does not check for a certain string in the standard output
>>> anymore - it turns out that it is possible to count the number of all
>>> the received JMX notifications (even though some notifications can be
>>> lost, we receive a special notification with the number of the lost
>>> regular notifications). It is then possible to match the actual number
>>> of processed notifications (received + lost) against the expected number
>>> - different numbers mean that the notification processing thread had
>>> been interrupted unexpectedly.
>>>
>>> Thanks,
>>>
>>> -JB-
>>>
>>> On 8.2.2013 17:37, Chris Hegarty wrote:
>>>>
>>>>> Jon Gibbons suggested invoking the compiler API directly from java
>>>>> instead of writing a shell script. Doing this seems fairly simple,
>>>>> and I
>>>>> think it would be advantageous to keep things entirely in Java. I may
>>>>> attempt to rewrite the defaultSVID test using the compiler API.
>>>>
>>>> Here's a test that does just that.
>>>>
>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/2de8c6c2d652/test/sun/misc/JarIndex/metaInfFilenames/Basic.java
>>>>
>>>>
>>>>
>>>> -Chris.
>>>
>>
>
>

From jaroslav.bachorik at oracle.com  Thu May  9 02:25:32 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 09 May 2013 11:25:32 +0200
Subject: jmx-dev [PATCH] JDK-8005472:
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh
 failed on windows
In-Reply-To: <5189933E.40702@oracle.com>
References: <50E16BA8.40203@oracle.com>
	<682D734D-2021-48DE-844D-C55A52D27EBD@oracle.com>
	<50EAB014.30805@oracle.com> <50EE813A.1020501@oracle.com>
	<50EEDC23.5080005@oracle.com> <50EF3622.9050500@oracle.com>
	<511119DA.5060806@oracle.com> <51118BEC.7000204@oracle.com>
	<511529DA.3050901@oracle.com> <5183BE7C.5060708@oracle.com>
	<5183C6D5.8070302@oracle.com> <51877204.8000104@oracle.com>
	<5189933E.40702@oracle.com>
Message-ID: <518B6B8C.2080506@oracle.com>

Hi Stuart,

On St 8. kv?ten 2013, 01:50:22 CEST, Stuart Marks wrote:
> Hi Jaroslav,
>
> Great to see this shell test get rewritten!
>
> Looks like you're avoiding multiple JVM processes as well, by loading
> the different versions of the classes into different classloaders. It
> looks like a bit of trouble, but probably less than the amount of
> trouble caused by the shell script.
>
> I have a couple minor points.
>
> The timeout value of one second seems quite low. Under normal
> operation, spawning a couple threads and should proceed very quickly.
> However, our testing environment is quite hostile, and things that
> seem like they ought to proceed quickly often take considerably longer
> than one might think. Since you're counting notifications, and in
> normal operation they all come in, we don't wait for the actual
> timeout unless there's a failure. So it might make sense to raise the
> timeout to 10 or perhaps 30 seconds.

I've adjusted the timeout for 30 seconds. Hopefully, it will be enough.

>
> On the other hand, I have a question about whether counting the number
> of notifications is correct. Would it be possible for there to be a
> bug where an extra notification is sent? If so, this might mean that
> the test would exit prematurely, indicating success?

It would be a severe error in the notification system implementation.
However, I've added a check for duplicated notifications (each
notification carries its sequence number) which makes the test fail in
case of duplication. But I don't expect it to happen.

The updated webrev is at
http://cr.openjdk.java.net/~jbachorik/8005472/webrev.09


-JB-

>
> s'marks
>
> On 5/6/13 2:04 AM, Jaroslav Bachorik wrote:
>> On P? 3. kv?ten 2013, 16:16:53 CEST, Daniel Fuchs wrote:
>>> Hi Jaroslav,
>>>
>>> In Client.java - you could consider replacing the AtomicLong
>>> with a CountDownLatch.
>>>
>>> This would allow you to remove the various Thread.sleep() in the
>>> code (in particular the one at the end).
>>>
>>> You could use CountDownLatch.await(long timeout, TimeUnit unit) to
>>> avoid waiting for ever in case of bugs, and the advantage is that
>>> the test would be able to exit as soon as the count down latch
>>> reaches 0, without having to wait for an arbitrary timeout.
>>
>> Great, thanks for the pointer! I've changed the test to use the
>> CountDownLatch.
>>
>> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.08/
>>
>> -JB-
>>
>>>
>>> Very nice to see a shell test go away :-)
>>>
>>> -- daniel
>>>
>>>
>>> On 5/3/13 3:41 PM, Jaroslav Bachorik wrote:
>>>> Please re-review the updated webrev
>>>> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.06
>>>>
>>>> I've replaced the shell script with the plain java test. The javac API
>>>> is used to compile the the auxiliary classes as was recommended. This
>>>> allowed to simplify the test.
>>>>
>>>> The test does not check for a certain string in the standard output
>>>> anymore - it turns out that it is possible to count the number of all
>>>> the received JMX notifications (even though some notifications can be
>>>> lost, we receive a special notification with the number of the lost
>>>> regular notifications). It is then possible to match the actual number
>>>> of processed notifications (received + lost) against the expected
>>>> number
>>>> - different numbers mean that the notification processing thread had
>>>> been interrupted unexpectedly.
>>>>
>>>> Thanks,
>>>>
>>>> -JB-
>>>>
>>>> On 8.2.2013 17:37, Chris Hegarty wrote:
>>>>>
>>>>>> Jon Gibbons suggested invoking the compiler API directly from java
>>>>>> instead of writing a shell script. Doing this seems fairly simple,
>>>>>> and I
>>>>>> think it would be advantageous to keep things entirely in Java. I
>>>>>> may
>>>>>> attempt to rewrite the defaultSVID test using the compiler API.
>>>>>
>>>>> Here's a test that does just that.
>>>>>
>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/2de8c6c2d652/test/sun/misc/JarIndex/metaInfFilenames/Basic.java
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -Chris.
>>>>
>>>
>>
>>


From stuart.marks at oracle.com  Tue May 14 15:44:57 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 14 May 2013 15:44:57 -0700
Subject: jmx-dev [PATCH] JDK-8005472:
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh
 failed on windows
In-Reply-To: <518B6B8C.2080506@oracle.com>
References: <50E16BA8.40203@oracle.com>
	<682D734D-2021-48DE-844D-C55A52D27EBD@oracle.com>
	<50EAB014.30805@oracle.com> <50EE813A.1020501@oracle.com>
	<50EEDC23.5080005@oracle.com> <50EF3622.9050500@oracle.com>
	<511119DA.5060806@oracle.com> <51118BEC.7000204@oracle.com>
	<511529DA.3050901@oracle.com> <5183BE7C.5060708@oracle.com>
	<5183C6D5.8070302@oracle.com> <51877204.8000104@oracle.com>
	<5189933E.40702@oracle.com> <518B6B8C.2080506@oracle.com>
Message-ID: <5192BE69.4020003@oracle.com>

Hi, sorry for the delay in my reply, and thanks for the update.

A timeout of 30 seconds should be sufficient.

Regarding duplicates: I was just thinking, if you're expecting exactly 10 
notifications, you should ensure that you receive exactly 10 notifications, and 
they're the right ones. But if duplicates is the only possible way that more 
than 10 notifications could occur, then that's probably fine. I just don't know 
enough about JMX to know.

Now... I took a look at the Client.java implementation, and ... groan (sorry) 
... I see you're using the single-element array trick to work around the 
inability to mutate local variables from an anonymous inner class.

I strongly recommend that you avoid using this trick.

I don't know what thread the notification callbacks run on. If they are on 
different threads, then there are inherent memory visibility problems, since 
array elements cannot be declared volatile. There is also potential concurrent 
access to seqSet, since it's accessed from both callbacks.

(Hm, seqSet isn't modified anywhere. Should the notification sequence numbers 
be added to the set somewhere?)

One approach for dealing with this is to make all the mutable data structures 
thread-safe, e.g. by wrapping seqSet using Collections.synchronizedSet() and 
using an AtomicBoolean instead of boolean[1].

Another approach would be to have the callbacks just append the notification 
objects to a synchronized list, and then have the main test thread do 
postprocessing on the list to ensure that it got the notifications it expected 
and that there were no duplicates.

Either way is fine, in order to avoid the threading issues.

Thanks, and sorry to belabor this review.

s'marks



On 5/9/13 2:25 AM, Jaroslav Bachorik wrote:
> Hi Stuart,
>
> On St 8. kv?ten 2013, 01:50:22 CEST, Stuart Marks wrote:
>> Hi Jaroslav,
>>
>> Great to see this shell test get rewritten!
>>
>> Looks like you're avoiding multiple JVM processes as well, by loading
>> the different versions of the classes into different classloaders. It
>> looks like a bit of trouble, but probably less than the amount of
>> trouble caused by the shell script.
>>
>> I have a couple minor points.
>>
>> The timeout value of one second seems quite low. Under normal
>> operation, spawning a couple threads and should proceed very quickly.
>> However, our testing environment is quite hostile, and things that
>> seem like they ought to proceed quickly often take considerably longer
>> than one might think. Since you're counting notifications, and in
>> normal operation they all come in, we don't wait for the actual
>> timeout unless there's a failure. So it might make sense to raise the
>> timeout to 10 or perhaps 30 seconds.
>
> I've adjusted the timeout for 30 seconds. Hopefully, it will be enough.
>
>>
>> On the other hand, I have a question about whether counting the number
>> of notifications is correct. Would it be possible for there to be a
>> bug where an extra notification is sent? If so, this might mean that
>> the test would exit prematurely, indicating success?
>
> It would be a severe error in the notification system implementation.
> However, I've added a check for duplicated notifications (each
> notification carries its sequence number) which makes the test fail in
> case of duplication. But I don't expect it to happen.
>
> The updated webrev is at
> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.09
>
>
> -JB-
>
>>
>> s'marks
>>
>> On 5/6/13 2:04 AM, Jaroslav Bachorik wrote:
>>> On P? 3. kv?ten 2013, 16:16:53 CEST, Daniel Fuchs wrote:
>>>> Hi Jaroslav,
>>>>
>>>> In Client.java - you could consider replacing the AtomicLong
>>>> with a CountDownLatch.
>>>>
>>>> This would allow you to remove the various Thread.sleep() in the
>>>> code (in particular the one at the end).
>>>>
>>>> You could use CountDownLatch.await(long timeout, TimeUnit unit) to
>>>> avoid waiting for ever in case of bugs, and the advantage is that
>>>> the test would be able to exit as soon as the count down latch
>>>> reaches 0, without having to wait for an arbitrary timeout.
>>>
>>> Great, thanks for the pointer! I've changed the test to use the
>>> CountDownLatch.
>>>
>>> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.08/
>>>
>>> -JB-
>>>
>>>>
>>>> Very nice to see a shell test go away :-)
>>>>
>>>> -- daniel
>>>>
>>>>
>>>> On 5/3/13 3:41 PM, Jaroslav Bachorik wrote:
>>>>> Please re-review the updated webrev
>>>>> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.06
>>>>>
>>>>> I've replaced the shell script with the plain java test. The javac API
>>>>> is used to compile the the auxiliary classes as was recommended. This
>>>>> allowed to simplify the test.
>>>>>
>>>>> The test does not check for a certain string in the standard output
>>>>> anymore - it turns out that it is possible to count the number of all
>>>>> the received JMX notifications (even though some notifications can be
>>>>> lost, we receive a special notification with the number of the lost
>>>>> regular notifications). It is then possible to match the actual number
>>>>> of processed notifications (received + lost) against the expected
>>>>> number
>>>>> - different numbers mean that the notification processing thread had
>>>>> been interrupted unexpectedly.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -JB-
>>>>>
>>>>> On 8.2.2013 17:37, Chris Hegarty wrote:
>>>>>>
>>>>>>> Jon Gibbons suggested invoking the compiler API directly from java
>>>>>>> instead of writing a shell script. Doing this seems fairly simple,
>>>>>>> and I
>>>>>>> think it would be advantageous to keep things entirely in Java. I
>>>>>>> may
>>>>>>> attempt to rewrite the defaultSVID test using the compiler API.
>>>>>>
>>>>>> Here's a test that does just that.
>>>>>>
>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/2de8c6c2d652/test/sun/misc/JarIndex/metaInfFilenames/Basic.java
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Chris.
>>>>>
>>>>
>>>
>>>
>

From jaroslav.bachorik at oracle.com  Wed May 15 13:12:00 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 15 May 2013 22:12:00 +0200
Subject: jmx-dev [PATCH] JDK-8005472:
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh
 failed on windows
In-Reply-To: <5192BE69.4020003@oracle.com>
References: <50E16BA8.40203@oracle.com>
	<682D734D-2021-48DE-844D-C55A52D27EBD@oracle.com>
	<50EAB014.30805@oracle.com> <50EE813A.1020501@oracle.com>
	<50EEDC23.5080005@oracle.com> <50EF3622.9050500@oracle.com>
	<511119DA.5060806@oracle.com> <51118BEC.7000204@oracle.com>
	<511529DA.3050901@oracle.com> <5183BE7C.5060708@oracle.com>
	<5183C6D5.8070302@oracle.com> <51877204.8000104@oracle.com>
	<5189933E.40702@oracle.com> <518B6B8C.2080506@oracle.com>
	<5192BE69.4020003@oracle.com>
Message-ID: <5193EC10.3050705@oracle.com>

On Wed 15 May 2013 12:44:57 AM CEST, Stuart Marks wrote:
> Hi, sorry for the delay in my reply, and thanks for the update.
>
> A timeout of 30 seconds should be sufficient.
>
> Regarding duplicates: I was just thinking, if you're expecting exactly
> 10 notifications, you should ensure that you receive exactly 10
> notifications, and they're the right ones. But if duplicates is the
> only possible way that more than 10 notifications could occur, then
> that's probably fine. I just don't know enough about JMX to know.

According to the JMX specification you must receive each notification 
at most once so the duplicate check will detect a possible bug.

>
> Now... I took a look at the Client.java implementation, and ... groan
> (sorry) ... I see you're using the single-element array trick to work
> around the inability to mutate local variables from an anonymous inner
> class.
>
> I strongly recommend that you avoid using this trick.
>
> I don't know what thread the notification callbacks run on. If they
> are on different threads, then there are inherent memory visibility
> problems, since array elements cannot be declared volatile. There is
> also potential concurrent access to seqSet, since it's accessed from
> both callbacks.

Ok. I've changed it to use AtomicBoolean Thanks for pointing this out. 
Even though it's rather obvious I got so used to using the final array 
in anonymous inner classes that I didn't even stop and think. BTW, 
there are a lot of places in the tests using this idiom in potentially 
multithreaded environment :(

>
> (Hm, seqSet isn't modified anywhere. Should the notification sequence
> numbers be added to the set somewhere?)

Yes, my bad. Instead of *.contains() I should have used *.add(). Fixed 
now.

>
> One approach for dealing with this is to make all the mutable data
> structures thread-safe, e.g. by wrapping seqSet using
> Collections.synchronizedSet() and using an AtomicBoolean instead of
> boolean[1].

Yep, the set is synchronized. I was thinking about 
ConcurrentSkipListSet but for the sakes of the test I think the 
Collections.synchronizedSet() is just fine.

>
> Another approach would be to have the callbacks just append the
> notification objects to a synchronized list, and then have the main
> test thread do postprocessing on the list to ensure that it got the
> notifications it expected and that there were no duplicates.
>
> Either way is fine, in order to avoid the threading issues.
>
> Thanks, and sorry to belabor this review.

NP. I don't want to get imperfect code to the repo either. Thanks for 
taking your time.

Updated webrev  - 
http://cr.openjdk.java.net/~jbachorik/8005472/webrev.10


-JB-


>
> s'marks
>
>
>
> On 5/9/13 2:25 AM, Jaroslav Bachorik wrote:
>> Hi Stuart,
>>
>> On St 8. kv?ten 2013, 01:50:22 CEST, Stuart Marks wrote:
>>> Hi Jaroslav,
>>>
>>> Great to see this shell test get rewritten!
>>>
>>> Looks like you're avoiding multiple JVM processes as well, by loading
>>> the different versions of the classes into different classloaders. It
>>> looks like a bit of trouble, but probably less than the amount of
>>> trouble caused by the shell script.
>>>
>>> I have a couple minor points.
>>>
>>> The timeout value of one second seems quite low. Under normal
>>> operation, spawning a couple threads and should proceed very quickly.
>>> However, our testing environment is quite hostile, and things that
>>> seem like they ought to proceed quickly often take considerably longer
>>> than one might think. Since you're counting notifications, and in
>>> normal operation they all come in, we don't wait for the actual
>>> timeout unless there's a failure. So it might make sense to raise the
>>> timeout to 10 or perhaps 30 seconds.
>>
>> I've adjusted the timeout for 30 seconds. Hopefully, it will be enough.
>>
>>>
>>> On the other hand, I have a question about whether counting the number
>>> of notifications is correct. Would it be possible for there to be a
>>> bug where an extra notification is sent? If so, this might mean that
>>> the test would exit prematurely, indicating success?
>>
>> It would be a severe error in the notification system implementation.
>> However, I've added a check for duplicated notifications (each
>> notification carries its sequence number) which makes the test fail in
>> case of duplication. But I don't expect it to happen.
>>
>> The updated webrev is at
>> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.09
>>
>>
>> -JB-
>>
>>>
>>> s'marks
>>>
>>> On 5/6/13 2:04 AM, Jaroslav Bachorik wrote:
>>>> On P? 3. kv?ten 2013, 16:16:53 CEST, Daniel Fuchs wrote:
>>>>> Hi Jaroslav,
>>>>>
>>>>> In Client.java - you could consider replacing the AtomicLong
>>>>> with a CountDownLatch.
>>>>>
>>>>> This would allow you to remove the various Thread.sleep() in the
>>>>> code (in particular the one at the end).
>>>>>
>>>>> You could use CountDownLatch.await(long timeout, TimeUnit unit) to
>>>>> avoid waiting for ever in case of bugs, and the advantage is that
>>>>> the test would be able to exit as soon as the count down latch
>>>>> reaches 0, without having to wait for an arbitrary timeout.
>>>>
>>>> Great, thanks for the pointer! I've changed the test to use the
>>>> CountDownLatch.
>>>>
>>>> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.08/
>>>>
>>>> -JB-
>>>>
>>>>>
>>>>> Very nice to see a shell test go away :-)
>>>>>
>>>>> -- daniel
>>>>>
>>>>>
>>>>> On 5/3/13 3:41 PM, Jaroslav Bachorik wrote:
>>>>>> Please re-review the updated webrev
>>>>>> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.06
>>>>>>
>>>>>> I've replaced the shell script with the plain java test. The
>>>>>> javac API
>>>>>> is used to compile the the auxiliary classes as was recommended.
>>>>>> This
>>>>>> allowed to simplify the test.
>>>>>>
>>>>>> The test does not check for a certain string in the standard output
>>>>>> anymore - it turns out that it is possible to count the number of
>>>>>> all
>>>>>> the received JMX notifications (even though some notifications
>>>>>> can be
>>>>>> lost, we receive a special notification with the number of the lost
>>>>>> regular notifications). It is then possible to match the actual
>>>>>> number
>>>>>> of processed notifications (received + lost) against the expected
>>>>>> number
>>>>>> - different numbers mean that the notification processing thread had
>>>>>> been interrupted unexpectedly.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -JB-
>>>>>>
>>>>>> On 8.2.2013 17:37, Chris Hegarty wrote:
>>>>>>>
>>>>>>>> Jon Gibbons suggested invoking the compiler API directly from java
>>>>>>>> instead of writing a shell script. Doing this seems fairly simple,
>>>>>>>> and I
>>>>>>>> think it would be advantageous to keep things entirely in Java. I
>>>>>>>> may
>>>>>>>> attempt to rewrite the defaultSVID test using the compiler API.
>>>>>>>
>>>>>>> Here's a test that does just that.
>>>>>>>
>>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/2de8c6c2d652/test/sun/misc/JarIndex/metaInfFilenames/Basic.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -Chris.
>>>>>>
>>>>>
>>>>
>>>>
>>



From stuart.marks at oracle.com  Fri May 17 17:09:49 2013
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 17 May 2013 17:09:49 -0700
Subject: jmx-dev [PATCH] JDK-8005472:
 com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh
 failed on windows
In-Reply-To: <5193EC10.3050705@oracle.com>
References: <50E16BA8.40203@oracle.com>
	<682D734D-2021-48DE-844D-C55A52D27EBD@oracle.com>
	<50EAB014.30805@oracle.com> <50EE813A.1020501@oracle.com>
	<50EEDC23.5080005@oracle.com> <50EF3622.9050500@oracle.com>
	<511119DA.5060806@oracle.com> <51118BEC.7000204@oracle.com>
	<511529DA.3050901@oracle.com> <5183BE7C.5060708@oracle.com>
	<5183C6D5.8070302@oracle.com> <51877204.8000104@oracle.com>
	<5189933E.40702@oracle.com> <518B6B8C.2080506@oracle.com>
	<5192BE69.4020003@oracle.com> <5193EC10.3050705@oracle.com>
Message-ID: <5196C6CD.3070209@oracle.com>

On 5/15/13 1:12 PM, Jaroslav Bachorik wrote:
> Ok. I've changed it to use AtomicBoolean Thanks for pointing this out.
> Even though it's rather obvious I got so used to using the final array
> in anonymous inner classes that I didn't even stop and think. BTW,
> there are a lot of places in the tests using this idiom in potentially
> multithreaded environment :(

Hrrm. OK, well, let's fix one test at a time. :-)

> Updated webrev  -
> http://cr.openjdk.java.net/~jbachorik/8005472/webrev.10

Thanks for the update. I took a quick look at it seems fine now.

I think Chris may need to be the OpenJDK Reviewer on this one.

s'marks

From jaroslav.bachorik at oracle.com  Tue May 28 06:04:05 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 28 May 2013 15:04:05 +0200
Subject: jmx-dev RFR: 8002307
 javax.management.modelmbean.ModelMBeanInfoSupport may expose internal
 representation by storing an externally mutable object
Message-ID: <51A4AB45.4070100@oracle.com>

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.

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 staffan.larsen at oracle.com  Tue May 28 06:25:23 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 28 May 2013 15:25:23 +0200
Subject: jmx-dev RFR: 8002307
	javax.management.modelmbean.ModelMBeanInfoSupport may expose
	internal representation by storing an externally mutable object
In-Reply-To: <51A4AB45.4070100@oracle.com>
References: <51A4AB45.4070100@oracle.com>
Message-ID: <ED53C3FE-1E80-45AA-84F9-AB4FA81D926E@oracle.com>

Looks good.

/Staffan

On 28 maj 2013, at 15:04, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> 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.
> 
> 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 jaroslav.bachorik at oracle.com  Tue May 28 07:22:16 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 28 May 2013 16:22:16 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
Message-ID: <51A4BD98.1040704@oracle.com>

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  Tue May 28 07:55:18 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Tue, 28 May 2013 16:55:18 +0200
Subject: jmx-dev RFR: 8002307
 javax.management.modelmbean.ModelMBeanInfoSupport may expose internal
 representation by storing an externally mutable object
In-Reply-To: <51A4AB45.4070100@oracle.com>
References: <51A4AB45.4070100@oracle.com>
Message-ID: <51A4C556.5070107@oracle.com>

Jaroslav,

The fix is OK for me.
The class MBeanInfo could be simplified because the constructors ensure 
that attributes, constructors, operations and notifications are not 
null, then we can remove all those nonNullxxx methods.

Shanliang

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.
>
> 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 daniel.fuchs at oracle.com  Tue May 28 09:34:24 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 28 May 2013 18:34:24 +0200
Subject: jmx-dev RFR: 8002307
 javax.management.modelmbean.ModelMBeanInfoSupport may expose internal
 representation by storing an externally mutable object
In-Reply-To: <51A4AB45.4070100@oracle.com>
References: <51A4AB45.4070100@oracle.com>
Message-ID: <51A4DC90.7050809@oracle.com>

Hi Jaroslav,


in ModelMBeanInfoSupport:

  328         modelMBeanAttributes = getAttributes();
  329         modelMBeanConstructors = getConstructors();
  330         modelMBeanOperations = getOperations();
  331         modelMBeanNotifications = getNotifications();

I think you should call super.getXxxx() here rather than
plain getXxxx() - it would be cleaner - especially since
ModelMBeanInfoSupport is not final.

I also wonder whether lines 224-227 should be similarly modified...

-- daniel


On 5/28/13 3:04 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.
>
> 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 jaroslav.bachorik at oracle.com  Tue May 28 12:32:35 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 28 May 2013 21:32:35 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51A4BD98.1040704@oracle.com>
References: <51A4BD98.1040704@oracle.com>
Message-ID: <51A50653.9080901@oracle.com>

And the webrev would come handy, of course.

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

-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 david.holmes at oracle.com  Wed May 29 01:09:38 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 29 May 2013 18:09:38 +1000
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51A50653.9080901@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A50653.9080901@oracle.com>
Message-ID: <51A5B7C2.1050009@oracle.com>

Hi Jaroslav,

Just wondering why this needs to be public:

+     public static void testComplianceMBeanInterface(Class<?> 
interfaceClass)
+             throws NotCompliantMBeanException{
+ 
StandardMBeanIntrospector.getInstance().getAnalyzer(interfaceClass);
+     }

Same question goes for the existing testComplianceMXBeanInterface. These 
are public methods on public classes but have no specification written 
for them. ???

David

On 29/05/2013 5:32 AM, Jaroslav Bachorik wrote:
> And the webrev would come handy, of course.
>
> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.00/
>
> -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  Wed May 29 02:04:06 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 29 May 2013 11:04:06 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51A5B7C2.1050009@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A50653.9080901@oracle.com>
	<51A5B7C2.1050009@oracle.com>
Message-ID: <51A5C486.9010502@oracle.com>

On Wed 29 May 2013 10:09:38 AM CEST, David Holmes wrote:
> Hi Jaroslav,
>
> Just wondering why this needs to be public:
>
> +     public static void testComplianceMBeanInterface(Class<?>
> interfaceClass)
> +             throws NotCompliantMBeanException{
> + StandardMBeanIntrospector.getInstance().getAnalyzer(interfaceClass);
> +     }
>
> Same question goes for the existing testComplianceMXBeanInterface.
> These are public methods on public classes but have no specification
> written for them. ???

The problem is that those methods need to be accessible from 
javax.management.JMX - the package private access would not work. Even 
though they are not meant to be used outside of the JDK code we can not 
prevent it and adding javadocs to them is definitely needed.

-JB-

>
> David
>
> On 29/05/2013 5:32 AM, Jaroslav Bachorik wrote:
>> And the webrev would come handy, of course.
>>
>> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.00/
>>
>> -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 May 29 04:18:50 2013
From: shanliang.jiang at oracle.com (shanliang)
Date: Wed, 29 May 2013 13:18:50 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51A50653.9080901@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A50653.9080901@oracle.com>
Message-ID: <51A5E41A.7010601@oracle.com>

Jaroslav,

Introspector.java
---------------------
Line 496 - 515
It is good to do check:
    (Modifier.isPublic(c.getModifiers()) || 
MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN)
but it is not necessary if an interface is not equal to clMBeanName.

is it possible to simplify the method as:
     private static <T> Class<? super T> implementsMBean(Class<T> c, 
String clName) {
        Class<T> ret = null;

        try {
            Class clMBeanClass = Class.forName(clName + "MBean");
            List list = Arrays.asList(c.getInterfaces());
           
            if (list.contains(clMBeanClass)
                    && (Modifier.isPublic(clMBeanClass.getModifiers()) 
|| MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN)) {
                ret = clMBeanClass;
            }
        } catch (ClassNotFoundException cne) {
            // clMBeanClass does not exist?
        }

        return ret;
    }

Is there any special reason to not have a unit test?

Shanliang


Jaroslav Bachorik wrote:
> And the webrev would come handy, of course.
>
> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.00/
>
> -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/20130529/17c0f066/attachment.html 

From jaroslav.bachorik at oracle.com  Wed May 29 05:53:50 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 29 May 2013 14:53:50 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51A5E41A.7010601@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A50653.9080901@oracle.com>
	<51A5E41A.7010601@oracle.com>
Message-ID: <51A5FA5E.8060403@oracle.com>

On Wed 29 May 2013 01:18:50 PM CEST, shanliang wrote:
> Jaroslav,
>
> Introspector.java
> ---------------------
> Line 496 - 515
> It is good to do check:
>     (Modifier.isPublic(c.getModifiers()) ||
> MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN)
> but it is not necessary if an interface is not equal to clMBeanName.

This is being checked within the same condition.

>
> is it possible to simplify the method as:
>      private static <T> Class<? super T> implementsMBean(Class<T> c,
> String clName) {
>         Class<T> ret = null;
>
>         try {
>             Class clMBeanClass = Class.forName(clName + "MBean");
>             List list = Arrays.asList(c.getInterfaces());
>
>             if (list.contains(clMBeanClass)
>                     && (Modifier.isPublic(clMBeanClass.getModifiers())
> || MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN)) {
>                 ret = clMBeanClass;
>             }
>         } catch (ClassNotFoundException cne) {
>             // clMBeanClass does not exist?
>         }
>
>         return ret;
>     }
>

This would not be the best for the current situation - when I took a 
closer look at the code it seems to contain a bug that makes searching 
for an associate MBean interface much more complex than necessary 
(getStandardMBeanInterface() walks up the class hierarchy and calls 
findMBeanInterface() which does its own hierarchy crawl for the same 
classes). I will try to fix and optimize the code - the Class.forName() 
seems to be a rather good approach.

> Is there any special reason to not have a unit test?

Nope. They were not finished - they will be the part of the next update 
to the webrev.

-JB-

>
> Shanliang
>
>
> Jaroslav Bachorik wrote:
>> And the webrev would come handy, of course.
>>
>> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.00/
>>
>> -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 May 29 06:38:59 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 May 2013 15:38:59 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51A5E41A.7010601@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A50653.9080901@oracle.com>
	<51A5E41A.7010601@oracle.com>
Message-ID: <51A604F3.8040207@oracle.com>

On 5/29/13 1:18 PM, shanliang wrote:
> Jaroslav,
>
> Introspector.java
> ---------------------
> Line 496 - 515
> It is good to do check:
>      (Modifier.isPublic(c.getModifiers()) ||
> MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN)
> but it is not necessary if an interface is not equal to clMBeanName.
>
> is it possible to simplify the method as:
>       private static <T> Class<? super T> implementsMBean(Class<T> c,
> String clName) {
>          Class<T> ret = null;
>
>          try {
>              Class clMBeanClass = Class.forName(clName + "MBean");

Hi Shanliang,

I 'm not sure whether that would actually simplify anything.
Is attempting to load a class (which BTW would require to pass
the appropriate ClassLoader to Class.forName) faster or simpler
than using the current algorithm?

But you're right - in isMBeanInterface the first check should
probably be c.getName().equals(clMBeanName).

-- daniel

>              List list = Arrays.asList(c.getInterfaces());
>
>              if (list.contains(clMBeanClass)
>                      && (Modifier.isPublic(clMBeanClass.getModifiers())
> || MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN)) {
>                  ret = clMBeanClass;
>              }
>          } catch (ClassNotFoundException cne) {
>              // clMBeanClass does not exist?
>          }
>
>          return ret;
>      }
>
> Is there any special reason to not have a unit test?
>
> Shanliang
>
>
> Jaroslav Bachorik wrote:
>> And the webrev would come handy, of course.
>>
>> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.00/
>>
>> -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  Wed May 29 07:44:49 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 29 May 2013 16:44:49 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51A604F3.8040207@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A50653.9080901@oracle.com>
	<51A5E41A.7010601@oracle.com> <51A604F3.8040207@oracle.com>
Message-ID: <51A61461.1050903@oracle.com>

On Wed 29 May 2013 03:38:59 PM CEST, Daniel Fuchs wrote:
> On 5/29/13 1:18 PM, shanliang wrote:
>> Jaroslav,
>>
>> Introspector.java
>> ---------------------
>> Line 496 - 515
>> It is good to do check:
>>      (Modifier.isPublic(c.getModifiers()) ||
>> MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN)
>> but it is not necessary if an interface is not equal to clMBeanName.
>>
>> is it possible to simplify the method as:
>>       private static <T> Class<? super T> implementsMBean(Class<T> c,
>> String clName) {
>>          Class<T> ret = null;
>>
>>          try {
>>              Class clMBeanClass = Class.forName(clName + "MBean");
>
> Hi Shanliang,
>
> I 'm not sure whether that would actually simplify anything.
> Is attempting to load a class (which BTW would require to pass
> the appropriate ClassLoader to Class.forName) faster or simpler
> than using the current algorithm?

Well, it seems to simplify the algorithm a bit. Currently, the run 
includes walking up the class hierarchy, retrieving all the interfaces 
for a class being inspected and the superinterfaces of the interfaces 
recursively, to check if any of them complies with the MBean interface 
naming. This can turn out to be a quite expensive process. 
Additionally, the current implementation seems to go through only 2 
levels of interfaces (the interfaces implemented by the inspected class 
and their direct super interfaces) and it can fail to resolve an MBean 
interface in some corner cases.

On the other hand, when using the Class.forName() it is enough to walk 
up the super class hierarchy, try to load a <className>MBean class for 
each inspected class and determine whether such interface exists and is 
a valid MBean interface. I am not sure how expensive is trying to load 
a non-existent class but Class.getInterfaces() is a native method as 
well as Class.forName0() generating the same JNI overhead.

-JB-

>
> But you're right - in isMBeanInterface the first check should
> probably be c.getName().equals(clMBeanName).
>
> -- daniel
>
>>              List list = Arrays.asList(c.getInterfaces());
>>
>>              if (list.contains(clMBeanClass)
>>                      && (Modifier.isPublic(clMBeanClass.getModifiers())
>> || MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN)) {
>>                  ret = clMBeanClass;
>>              }
>>          } catch (ClassNotFoundException cne) {
>>              // clMBeanClass does not exist?
>>          }
>>
>>          return ret;
>>      }
>>
>> Is there any special reason to not have a unit test?
>>
>> Shanliang
>>
>>
>> Jaroslav Bachorik wrote:
>>> And the webrev would come handy, of course.
>>>
>>> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.00/
>>>
>>> -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  Wed May 29 07:56:30 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 29 May 2013 16:56:30 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51A4BD98.1040704@oracle.com>
References: <51A4BD98.1040704@oracle.com>
Message-ID: <51A6171E.8040606@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 May 29 08:03:47 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 May 2013 17:03:47 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51A61461.1050903@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A50653.9080901@oracle.com>
	<51A5E41A.7010601@oracle.com> <51A604F3.8040207@oracle.com>
	<51A61461.1050903@oracle.com>
Message-ID: <51A618D3.6070200@oracle.com>

On 5/29/13 4:44 PM, Jaroslav Bachorik wrote:
> On Wed 29 May 2013 03:38:59 PM CEST, Daniel Fuchs wrote:
>> On 5/29/13 1:18 PM, shanliang wrote:
>>> Jaroslav,
>>>
>>> Introspector.java
>>> ---------------------
>>> Line 496 - 515
>>> It is good to do check:
>>>       (Modifier.isPublic(c.getModifiers()) ||
>>> MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN)
>>> but it is not necessary if an interface is not equal to clMBeanName.
>>>
>>> is it possible to simplify the method as:
>>>        private static <T> Class<? super T> implementsMBean(Class<T> c,
>>> String clName) {
>>>           Class<T> ret = null;
>>>
>>>           try {
>>>               Class clMBeanClass = Class.forName(clName + "MBean");
>>
>> Hi Shanliang,
>>
>> I 'm not sure whether that would actually simplify anything.
>> Is attempting to load a class (which BTW would require to pass
>> the appropriate ClassLoader to Class.forName) faster or simpler
>> than using the current algorithm?
>
> Well, it seems to simplify the algorithm a bit. Currently, the run
> includes walking up the class hierarchy, retrieving all the interfaces
> for a class being inspected and the superinterfaces of the interfaces
> recursively, to check if any of them complies with the MBean interface
> naming. This can turn out to be a quite expensive process.
> Additionally, the current implementation seems to go through only 2
> levels of interfaces (the interfaces implemented by the inspected class
> and their direct super interfaces) and it can fail to resolve an MBean
> interface in some corner cases.
>
> On the other hand, when using the Class.forName() it is enough to walk
> up the super class hierarchy, try to load a <className>MBean class for
> each inspected class and determine whether such interface exists and is
> a valid MBean interface. I am not sure how expensive is trying to load
> a non-existent class but Class.getInterfaces() is a native method as
> well as Class.forName0() generating the same JNI overhead.
>
> -JB-

I would be wary of changing this code without extensive testing.
You will have to read the spec in details and make sure that you
haven't forgotten anything.

For a given implementation class <a.AImpl> there may be
several interfaces that match the MBean interface pattern - and
the spec clearly defines which should have precedence.
For instance if you have:

a.AImpl extends a.A extends b.BImpl extends b.B extends c.C
    implements a.AMBean {
}

with c.C implements c.CMBean, b.BMBean { }

then which is the MBean interface for a.AImpl?

I think it's b.BMBean - although I would have to read the spec twice
to be really sure ;-)

-- daniel



>
>>
>> But you're right - in isMBeanInterface the first check should
>> probably be c.getName().equals(clMBeanName).
>>
>> -- daniel
>>
>>>               List list = Arrays.asList(c.getInterfaces());
>>>
>>>               if (list.contains(clMBeanClass)
>>>                       && (Modifier.isPublic(clMBeanClass.getModifiers())
>>> || MBeanAnalyzer.ALLOW_NONPUBLIC_MBEAN)) {
>>>                   ret = clMBeanClass;
>>>               }
>>>           } catch (ClassNotFoundException cne) {
>>>               // clMBeanClass does not exist?
>>>           }
>>>
>>>           return ret;
>>>       }
>>>
>>> Is there any special reason to not have a unit test?
>>>
>>> Shanliang
>>>
>>>
>>> Jaroslav Bachorik wrote:
>>>> And the webrev would come handy, of course.
>>>>
>>>> http://cr.openjdk.java.net/~jbachorik/8010285/webrev.00/
>>>>
>>>> -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 eamonn at mcmanus.net  Wed May 29 08:33:21 2013
From: eamonn at mcmanus.net (Eamonn McManus)
Date: Wed, 29 May 2013 08:33:21 -0700
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51A6171E.8040606@oracle.com>
References: <51A4BD98.1040704@oracle.com>
	<51A6171E.8040606@oracle.com>
Message-ID: <CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>

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.

?amonn


2013/5/29 Jaroslav Bachorik <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/20130529/a219eadc/attachment.html 

From jaroslav.bachorik at oracle.com  Wed May 29 10:17:35 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Wed, 29 May 2013 19:17:35 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
Message-ID: <51A6382F.3000204@oracle.com>

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.

-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 May 29 10:44:34 2013
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 29 May 2013 19:44:34 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51A6382F.3000204@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com>
Message-ID: <51A63E82.4050505@oracle.com>

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.

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  Thu May 30 00:32:17 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 30 May 2013 09:32:17 +0200
Subject: jmx-dev RFR: 8010285 Enforce the requirement of Management
 Interfaces being public
In-Reply-To: <51A63E82.4050505@oracle.com>
References: <51A4BD98.1040704@oracle.com> <51A6171E.8040606@oracle.com>
	<CACBEn44CB3yw3rCs8k8CKVzVuTGubK2mSiFgqrmgspiba1=pGg@mail.gmail.com>
	<51A6382F.3000204@oracle.com> <51A63E82.4050505@oracle.com>
Message-ID: <51A70081.5050203@oracle.com>

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.

-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  Thu May 30 04:42:32 2013
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Thu, 30 May 2013 13:42:32 +0200
Subject: jmx-dev RFR: 8015627
Message-ID: <51A73B28.9050600@oracle.com>

JMX related tests have hard time running in "agentvm" mode because they
need a set of privileges which are not granted by the default security
manager. For this reason all the tests from javax/management are forced
to run in "othervm" mode.

com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java
must also be forced to run in "othervm" mode.

Webrev: http://cr.openjdk.java.net/~jbachorik/8015627/webrev.00

-JB-

From Alan.Bateman at oracle.com  Thu May 30 04:44:59 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 30 May 2013 12:44:59 +0100
Subject: jmx-dev RFR: 8015627
In-Reply-To: <51A73B28.9050600@oracle.com>
References: <51A73B28.9050600@oracle.com>
Message-ID: <51A73BBB.5030805@oracle.com>

On 30/05/2013 12:42, Jaroslav Bachorik wrote:
> JMX related tests have hard time running in "agentvm" mode because they
> need a set of privileges which are not granted by the default security
> manager. For this reason all the tests from javax/management are forced
> to run in "othervm" mode.
>
> com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java
> must also be forced to run in "othervm" mode.
>
> Webrev: http://cr.openjdk.java.net/~jbachorik/8015627/webrev.00
>
> -JB-
Thanks, this looks fine.

-Alan.