From Alan.Bateman at Sun.COM  Wed Oct 21 03:23:44 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Wed, 21 Oct 2009 11:23:44 +0100
Subject: jmx-dev Need reviewer for 6888179: Separate out dependency on CORBA
Message-ID: <4ADEE130.8030505@sun.com>


As you know, we need to do some re-organization of code in preparation 
for the jdk build generating modules. One dependency that I would like 
to separate out is the dependency on RMI-IIOP and CORBA in the JSR-160 
implementation. The motivation is a possible "management" module that 
wouldn't require "corba" to be installed. The webrev with the proposed 
changes is here:
  http://cr.openjdk.java.net/~alanb/6888179/webrev.00/

In summary, the RMI connectors are changed to use a helper class for 
RMI-IIOP and CORBA. The methods defined by the helper class have all 
CORBA types erased and they simply delegate to a proxy which has an 
implementation in the com.sun.jmx.remote.protocol.iiop package that is 
either present or not present. When not present then methods requiring 
the transport fail gracefully indicating that the iiop protocol is not 
supported.

I ran into two issues that I should point:

1. The bytecode for ProxyStub._releaseReply in RMIConnector didn't match 
the source in the comments. The actual code has a null check that was 
missing from the source. I've updated this for any future maintainers.

2. RMIConnector.findRMIServerJRMP used PortableRemoteObject.narrow to 
check the stub type, which I'm sure was an oversight.

I've run all the tests in test/javax/management/remote (good test 
coverage btw) and don't see any regressions.

?amonn, Daniel - would you have cycles to review?

-Alan.

From Eamonn.McManus at Sun.COM  Wed Oct 21 08:51:30 2009
From: Eamonn.McManus at Sun.COM (Eamonn McManus)
Date: Wed, 21 Oct 2009 17:51:30 +0200
Subject: jmx-dev [Fwd: hg: jdk7/tl/jdk: 6851617: Remove JSR 255 (JMX API
 2.0) from JDK 7]
Message-ID: <4ADF2E02.7040205@sun.com>

An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20091021/f47e9404/attachment-0001.html 
-------------- next part --------------
An embedded message was scrubbed...
From: Eamonn.McManus at Sun.COM
Subject: hg: jdk7/tl/jdk: 6851617: Remove JSR 255 (JMX API 2.0) from JDK 7
Date: Wed, 21 Oct 2009 15:34:04 +0000
Size: 24132
Url: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20091021/f47e9404/attachment-0001.nws 

From Daniel.Fuchs at Sun.COM  Mon Oct 26 04:38:26 2009
From: Daniel.Fuchs at Sun.COM (daniel fuchs)
Date: Mon, 26 Oct 2009 12:38:26 +0100
Subject: jmx-dev Need reviewer for 6888179: Separate out dependency on
	CORBA
In-Reply-To: <4ADEE130.8030505@sun.com>
References: <4ADEE130.8030505@sun.com>
Message-ID: <4AE58A32.4000804@sun.com>

Hi Alan,

This looks OK to me.

Cheers,

-- daniel
JMX, SNMP, Java, etc... http://blogs.sun.com/jmxetc

Alan Bateman wrote:
> 
> As you know, we need to do some re-organization of code in preparation 
> for the jdk build generating modules. One dependency that I would like 
> to separate out is the dependency on RMI-IIOP and CORBA in the JSR-160 
> implementation. The motivation is a possible "management" module that 
> wouldn't require "corba" to be installed. The webrev with the proposed 
> changes is here:
>  http://cr.openjdk.java.net/~alanb/6888179/webrev.00/
> 
> In summary, the RMI connectors are changed to use a helper class for 
> RMI-IIOP and CORBA. The methods defined by the helper class have all 
> CORBA types erased and they simply delegate to a proxy which has an 
> implementation in the com.sun.jmx.remote.protocol.iiop package that is 
> either present or not present. When not present then methods requiring 
> the transport fail gracefully indicating that the iiop protocol is not 
> supported.
> 
> I ran into two issues that I should point:
> 
> 1. The bytecode for ProxyStub._releaseReply in RMIConnector didn't match 
> the source in the comments. The actual code has a null check that was 
> missing from the source. I've updated this for any future maintainers.
> 
> 2. RMIConnector.findRMIServerJRMP used PortableRemoteObject.narrow to 
> check the stub type, which I'm sure was an oversight.
> 
> I've run all the tests in test/javax/management/remote (good test 
> coverage btw) and don't see any regressions.
> 
> ?amonn, Daniel - would you have cycles to review?
> 
> -Alan.