From jaroslav.bachorik at oracle.com Tue Dec 1 10:06:55 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 1 Dec 2015 11:06:55 +0100 Subject: jmx-dev [pong] Re: RFR 8142398: ManagementAgent.status diagnostic command only outputs the specifically set properties In-Reply-To: <5643644B.2080102@oracle.com> References: <5643644B.2080102@oracle.com> Message-ID: <565D713F.20407@oracle.com> On 11.11.2015 16:52, Jaroslav Bachorik wrote: > Please, review the following change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8142398 > Webrev: http://cr.openjdk.java.net/~jbachorik/8142398/webrev.00 > > This patch adds the list of the default agent properties with the info > whether the default value has been overridden to the > ManagementAgent.status DCMD output. > > Thanks, > > -JB- From sgehwolf at redhat.com Tue Dec 1 10:17:09 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Dec 2015 11:17:09 +0100 Subject: jmx-dev [PING] RFR 6425769: jmx remote bind address In-Reply-To: <1447061525.3551.3.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> Message-ID: <1448965029.4309.10.camel@redhat.com> On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > Hi, > > > > Updated webrev with jtreg test in Java: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ > > bug:?https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > I believe this updated webrev addresses all concerns and > > incorporates > > suggestions brought up by Jaroslav and Daniel. > > > > I'm still looking for a sponsor and a hotspot/servicability-dev > > reviewer. Could somebody maintaining javax.rmi.ssl have a look at > > this > > as well? Thank you! > > Ping? Friendly reminder that I still need reviewers and a sponsor for > this. Anyone? > Thanks, > Severin > > > Cheers, > > Severin > > > > On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote: > > > On 2.11.2015 19:06, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Thanks Jaroslav and Daniel for the reviews! Comments inline. > > > > > > > > On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: > > > > > Hi, > > > > > > > > > > On 2.11.2015 16:19, Daniel Fuchs wrote: > > > > > > Hi Severin, > > > > > > > > > > > > Adding serviceability-dev at openjdk.java.net into the loop - > > > > > > that's > > > > > > a better alias than hotspot-dev for this kind of changes - > > > > > > maybe > > > > > > someone from serviceability-dev will offer to sponsor :-) > > > > > > > > > > > > I will let serviceability team members comment on the > > > > > > hotspot > > > > > > changes. > > > > > > > > > > > > ConnectorBootstrap.java > > > > > > > > > > > > I have one suggestion and one concern: > > > > > > > > > > > > Suggestion: I would suggest to reuse 'csf' (Client Socket > > > > > > Factory) > > > > > > and > > > > > > ssf??(Server Socket Factory) variables rather than > > > > > > introduce > > > > > > the > > > > > > two > > > > > > new variables rmiServerSocketFactory and > > > > > > rmiClientSocketFactory. > > > > > > You might want to create a new boolean 'useSocketFactory' > > > > > > variable, > > > > > > if that makes the code more readable. > > > > > > > > > > > > Concern: If I understand correctly how RMI socket factories > > > > > > work, > > > > > > the client socket factory will be serialized and sent to > > > > > > the > > > > > > client > > > > > > side. This is problematic for interoperability, as the > > > > > > class > > > > > > may > > > > > > not > > > > > > present in the remote client - if the remote client is e.g. > > > > > > jdk > > > > > > 8. > > > > > > > > > > > > As far as I can see, your new DefaultClientSocketFactory > > > > > > doesn't do > > > > > > anything useful - so I would suggest to simply get rid of > > > > > > it, > > > > > > and > > > > > > only > > > > > > set the Server Socket Factory when SSL is not involved. > > > > > > > > Thanks. Fixed in updated webrev. > > > > > > > > > > Tests: > > > > > > > > > > > > Concerning the tests - we're trying to get rid of shell > > > > > > scripts > > > > > > rather than introducing new ones :-) > > > > > > Could the test be rewritten in pure java using the Process > > > > > > API? > > > > > > > > > > > > I believe there's even a test library that will let you do > > > > > > that > > > > > > easily jdk/test/lib/testlibrary/jdk/testlibrary/ > > > > > > (see ProcessTools.java) > > > > > > > > It'll take me a bit to rewrite the test in pure Java, but > > > > should > > > > be > > > > fine. This is not yet fixed in the updated webrev. > > > > > > > > > > Other: > > > > > > > > > > > > Also - I believe the new option should be documented in: > > > > > > src/java.management/share/conf/management.properties > > > > > > > > Docs have been updated > > > > in src/java.management/share/conf/management.properties. > > > > > > > > > I share Daniel's concerns. Also, the part of the changeset is > > > > > related > > > > > to javax.rmi.ssl - someone maintaining this library should > > > > > also > > > > > comment here. > > > > > > > > > > Also, the change is introducing new API (system property) and > > > > > changing the existing one (adding SslRmiServerSocketFactory > > > > > public > > > > > constructors) so compatibility review process will have to be > > > > > involved. > > > > > > > > OK. What exactly is there for me to do? I'm not familiar with > > > > this > > > > process. Note that the intent would be to get this backported > > > > to > > > > JDK 8. > > > Not much for you. But for the potential Oracle sponsor this means > > > she > > > will have to remember to go through some extra hoops before > > > integrating your patch. > > > > I see. Thanks for clarifying it. > > > > > -JB- > > > > > > > > > > > New webrev at: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/ > > > > > > > > Thanks, > > > > Severin > > > > > > > > > -JB- > > > > > > > > > > > > best regards, > > > > > > > > > > > > -- daniel > > > > > > > > > > > > On 02/11/15 11:38, Severin Gehwolf wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Here is a patch addressing JDK-6425769. The issue is that > > > > > > > the > > > > > > > JMX > > > > > > > agent > > > > > > > binds to the wildcard address by default, preventing > > > > > > > users > > > > > > > to > > > > > > > use > > > > > > > system properties for JMX agents on multi-homed hosts. > > > > > > > Given > > > > > > > a > > > > > > > host > > > > > > > with local network interfaces, 192.168.0.1 and > > > > > > > 192.168.0.2 > > > > > > > say, > > > > > > > it's > > > > > > > impossible to start two JMX agents binding to fixed ports > > > > > > > but > > > > > > > to > > > > > > > different network interfaces, 192.168.0.1:{9111,9112} and > > > > > > > 192.168.0.2:{9111,9112} say. > > > > > > > > > > > > > > The JDK would bind to all local interfaces by default. In > > > > > > > the > > > > > > > above > > > > > > > example to 192.168.0.1 *and* 192.168.0.2. The effect is > > > > > > > that > > > > > > > the > > > > > > > second > > > > > > > Java process would get a "Connection refused" error > > > > > > > because > > > > > > > another > > > > > > > process has already been bound to the specified JMX/RMI > > > > > > > port > > > > > > > pairs. > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > > > > > 64 > > > > > > > 25 > > > > > > > 769/ > > > > > > > 00/ > > > > > > > > > > > > > > Testing done: > > > > > > > jdk_jmx and jdk_management tests all pass after this > > > > > > > change > > > > > > > (no > > > > > > > regressions). There is also a new JTREG test which fails > > > > > > > prior > > > > > > > this > > > > > > > change and passes after. Updates to the diagnostic > > > > > > > command > > > > > > > have > > > > > > > been > > > > > > > tested manually. > > > > > > > > > > > > > > I understand that, if approved, the JDK and hotspot > > > > > > > changes > > > > > > > should get > > > > > > > pushed together? Hotspot changes are fairly trivial since > > > > > > > it's > > > > > > > only a > > > > > > > doc-update for the new JDK property in the relevant > > > > > > > diagnostic > > > > > > > command. > > > > > > > > > > > > > > Could someone please review and sponsor this change? > > > > > > > Please > > > > > > > let > > > > > > > me know > > > > > > > if there are questions. > > > > > > > > > > > > > > Thanks, > > > > > > > Severin > > > > > > > > > > > > > > > > > > > > > > > > > > > > From jaroslav.bachorik at oracle.com Tue Dec 1 11:33:38 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 1 Dec 2015 12:33:38 +0100 Subject: jmx-dev [PING] RFR 6425769: jmx remote bind address In-Reply-To: <1448965029.4309.10.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> Message-ID: <565D8592.6020701@oracle.com> On 1.12.2015 11:17, Severin Gehwolf wrote: > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: >> On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: >>> Hi, >>> >>> Updated webrev with jtreg test in Java: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-6425769 >>> >>> I believe this updated webrev addresses all concerns and >>> incorporates >>> suggestions brought up by Jaroslav and Daniel. >>> >>> I'm still looking for a sponsor and a hotspot/servicability-dev >>> reviewer. Could somebody maintaining javax.rmi.ssl have a look at >>> this >>> as well? Thank you! >> >> Ping? Friendly reminder that I still need reviewers and a sponsor for >> this. > > Anyone? I'm sorry for not spotting this earlier: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi-ssl-factory-changes/jdk/src/java.management/share/classes/sun/management/jmxremote/ConnectorBootstrap.java.sdiff.html * L442 - the log would contain 'com.sun.management.jmxremote.host = null' if host is not specified; might be better not to print this out at all Other than that the change looks good to me. If no one else is volunteering I may sponsor this change. Cheers, -JB- > >> Thanks, >> Severin >> >>> Cheers, >>> Severin >>> >>> On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote: >>>> On 2.11.2015 19:06, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Thanks Jaroslav and Daniel for the reviews! Comments inline. >>>>> >>>>> On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: >>>>>> Hi, >>>>>> >>>>>> On 2.11.2015 16:19, Daniel Fuchs wrote: >>>>>>> Hi Severin, >>>>>>> >>>>>>> Adding serviceability-dev at openjdk.java.net into the loop - >>>>>>> that's >>>>>>> a better alias than hotspot-dev for this kind of changes - >>>>>>> maybe >>>>>>> someone from serviceability-dev will offer to sponsor :-) >>>>>>> >>>>>>> I will let serviceability team members comment on the >>>>>>> hotspot >>>>>>> changes. >>>>>>> >>>>>>> ConnectorBootstrap.java >>>>>>> >>>>>>> I have one suggestion and one concern: >>>>>>> >>>>>>> Suggestion: I would suggest to reuse 'csf' (Client Socket >>>>>>> Factory) >>>>>>> and >>>>>>> ssf (Server Socket Factory) variables rather than >>>>>>> introduce >>>>>>> the >>>>>>> two >>>>>>> new variables rmiServerSocketFactory and >>>>>>> rmiClientSocketFactory. >>>>>>> You might want to create a new boolean 'useSocketFactory' >>>>>>> variable, >>>>>>> if that makes the code more readable. >>>>>>> >>>>>>> Concern: If I understand correctly how RMI socket factories >>>>>>> work, >>>>>>> the client socket factory will be serialized and sent to >>>>>>> the >>>>>>> client >>>>>>> side. This is problematic for interoperability, as the >>>>>>> class >>>>>>> may >>>>>>> not >>>>>>> present in the remote client - if the remote client is e.g. >>>>>>> jdk >>>>>>> 8. >>>>>>> >>>>>>> As far as I can see, your new DefaultClientSocketFactory >>>>>>> doesn't do >>>>>>> anything useful - so I would suggest to simply get rid of >>>>>>> it, >>>>>>> and >>>>>>> only >>>>>>> set the Server Socket Factory when SSL is not involved. >>>>> >>>>> Thanks. Fixed in updated webrev. >>>>> >>>>>>> Tests: >>>>>>> >>>>>>> Concerning the tests - we're trying to get rid of shell >>>>>>> scripts >>>>>>> rather than introducing new ones :-) >>>>>>> Could the test be rewritten in pure java using the Process >>>>>>> API? >>>>>>> >>>>>>> I believe there's even a test library that will let you do >>>>>>> that >>>>>>> easily jdk/test/lib/testlibrary/jdk/testlibrary/ >>>>>>> (see ProcessTools.java) >>>>> >>>>> It'll take me a bit to rewrite the test in pure Java, but >>>>> should >>>>> be >>>>> fine. This is not yet fixed in the updated webrev. >>>>> >>>>>>> Other: >>>>>>> >>>>>>> Also - I believe the new option should be documented in: >>>>>>> src/java.management/share/conf/management.properties >>>>> >>>>> Docs have been updated >>>>> in src/java.management/share/conf/management.properties. >>>>> >>>>>> I share Daniel's concerns. Also, the part of the changeset is >>>>>> related >>>>>> to javax.rmi.ssl - someone maintaining this library should >>>>>> also >>>>>> comment here. >>>>>> >>>>>> Also, the change is introducing new API (system property) and >>>>>> changing the existing one (adding SslRmiServerSocketFactory >>>>>> public >>>>>> constructors) so compatibility review process will have to be >>>>>> involved. >>>>> >>>>> OK. What exactly is there for me to do? I'm not familiar with >>>>> this >>>>> process. Note that the intent would be to get this backported >>>>> to >>>>> JDK 8. >>>> Not much for you. But for the potential Oracle sponsor this means >>>> she >>>> will have to remember to go through some extra hoops before >>>> integrating your patch. >>> >>> I see. Thanks for clarifying it. >>> >>>> -JB- >>>> >>>>> >>>>> New webrev at: >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/ >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>>> -JB- >>>>>>> >>>>>>> best regards, >>>>>>> >>>>>>> -- daniel >>>>>>> >>>>>>> On 02/11/15 11:38, Severin Gehwolf wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Here is a patch addressing JDK-6425769. The issue is that >>>>>>>> the >>>>>>>> JMX >>>>>>>> agent >>>>>>>> binds to the wildcard address by default, preventing >>>>>>>> users >>>>>>>> to >>>>>>>> use >>>>>>>> system properties for JMX agents on multi-homed hosts. >>>>>>>> Given >>>>>>>> a >>>>>>>> host >>>>>>>> with local network interfaces, 192.168.0.1 and >>>>>>>> 192.168.0.2 >>>>>>>> say, >>>>>>>> it's >>>>>>>> impossible to start two JMX agents binding to fixed ports >>>>>>>> but >>>>>>>> to >>>>>>>> different network interfaces, 192.168.0.1:{9111,9112} and >>>>>>>> 192.168.0.2:{9111,9112} say. >>>>>>>> >>>>>>>> The JDK would bind to all local interfaces by default. In >>>>>>>> the >>>>>>>> above >>>>>>>> example to 192.168.0.1 *and* 192.168.0.2. The effect is >>>>>>>> that >>>>>>>> the >>>>>>>> second >>>>>>>> Java process would get a "Connection refused" error >>>>>>>> because >>>>>>>> another >>>>>>>> process has already been bound to the specified JMX/RMI >>>>>>>> port >>>>>>>> pairs. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6425769 >>>>>>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- >>>>>>>> 64 >>>>>>>> 25 >>>>>>>> 769/ >>>>>>>> 00/ >>>>>>>> >>>>>>>> Testing done: >>>>>>>> jdk_jmx and jdk_management tests all pass after this >>>>>>>> change >>>>>>>> (no >>>>>>>> regressions). There is also a new JTREG test which fails >>>>>>>> prior >>>>>>>> this >>>>>>>> change and passes after. Updates to the diagnostic >>>>>>>> command >>>>>>>> have >>>>>>>> been >>>>>>>> tested manually. >>>>>>>> >>>>>>>> I understand that, if approved, the JDK and hotspot >>>>>>>> changes >>>>>>>> should get >>>>>>>> pushed together? Hotspot changes are fairly trivial since >>>>>>>> it's >>>>>>>> only a >>>>>>>> doc-update for the new JDK property in the relevant >>>>>>>> diagnostic >>>>>>>> command. >>>>>>>> >>>>>>>> Could someone please review and sponsor this change? >>>>>>>> Please >>>>>>>> let >>>>>>>> me know >>>>>>>> if there are questions. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Severin >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From sgehwolf at redhat.com Tue Dec 1 13:19:05 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Dec 2015 14:19:05 +0100 Subject: jmx-dev [PING] RFR 6425769: jmx remote bind address In-Reply-To: <565D8592.6020701@oracle.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> <565D8592.6020701@oracle.com> Message-ID: <1448975945.4309.16.camel@redhat.com> Hi Jaroslav, On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: > On 1.12.2015 11:17, Severin Gehwolf wrote: > > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > > > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Updated webrev with jtreg test in Java: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ > > > > bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > > I believe this updated webrev addresses all concerns and > > > > incorporates > > > > suggestions brought up by Jaroslav and Daniel. > > > > > > > > I'm still looking for a sponsor and a hotspot/servicability-dev > > > > reviewer. Could somebody maintaining javax.rmi.ssl have a look at > > > > this > > > > as well? Thank you! > > > > > > Ping? Friendly reminder that I still need reviewers and a sponsor for > > > this. > > > > Anyone? > > I'm sorry for not spotting this earlier: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi-ssl-factory-changes/jdk/src/java.management/share/classes/sun/management/jmxremote/ConnectorBootstrap.java.sdiff.html > * L442 - the log would contain 'com.sun.management.jmxremote.host =? > null' if host is not specified; might be better not to print this out at all Updated webrev which does not print 'com.sun.management.jmxremote.host = null' if unset: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/ > Other than that the change looks good to me. If no one else is > volunteering I may sponsor this change. Thank you! Cheers, Severin > Cheers, > > -JB- From sgehwolf at redhat.com Wed Dec 9 13:55:02 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 Dec 2015 14:55:02 +0100 Subject: jmx-dev [PING-2] RFR 6425769: jmx remote bind address In-Reply-To: <1448975945.4309.16.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> <565D8592.6020701@oracle.com> <1448975945.4309.16.camel@redhat.com> Message-ID: <1449669302.3543.62.camel@redhat.com> On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote: > Hi Jaroslav, > > On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: > > On 1.12.2015 11:17, Severin Gehwolf wrote: > > > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > > > > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > Updated webrev with jtreg test in Java: > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ > > > > > bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > > > > I believe this updated webrev addresses all concerns and > > > > > incorporates > > > > > suggestions brought up by Jaroslav and Daniel. > > > > > > > > > > I'm still looking for a sponsor and a hotspot/servicability- > > > > > dev > > > > > reviewer. Could somebody maintaining javax.rmi.ssl have a > > > > > look at > > > > > this > > > > > as well? Thank you! > > > > > > > > Ping? Friendly reminder that I still need reviewers and a > > > > sponsor for > > > > this. > > > > > > Anyone? > > > > I'm sorry for not spotting this earlier: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi- > > ssl-factory- > > changes/jdk/src/java.management/share/classes/sun/management/jmxrem > > ote/ConnectorBootstrap.java.sdiff.html > > * L442 - the log would contain 'com.sun.management.jmxremote.host > > =? > > null' if host is not specified; might be better not to print this > > out at all > > Updated webrev which does not print > 'com.sun.management.jmxremote.host = null' if unset: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/ > > > Other than that the change looks good to me. If no one else is > > volunteering I may sponsor this change. > > Thank you! Jaroslav, are you still willing to sponsor this? There hasn't been much movement :-/ Thanks, Severin From jaroslav.bachorik at oracle.com Wed Dec 9 13:58:02 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 9 Dec 2015 14:58:02 +0100 Subject: jmx-dev [PING-2] RFR 6425769: jmx remote bind address In-Reply-To: <1449669302.3543.62.camel@redhat.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> <565D8592.6020701@oracle.com> <1448975945.4309.16.camel@redhat.com> <1449669302.3543.62.camel@redhat.com> Message-ID: <5668336A.3010406@oracle.com> On 9.12.2015 14:55, Severin Gehwolf wrote: > On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote: >> Hi Jaroslav, >> >> On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: >>> On 1.12.2015 11:17, Severin Gehwolf wrote: >>>> On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: >>>>> On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: >>>>>> Hi, >>>>>> >>>>>> Updated webrev with jtreg test in Java: >>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6425769 >>>>>> >>>>>> I believe this updated webrev addresses all concerns and >>>>>> incorporates >>>>>> suggestions brought up by Jaroslav and Daniel. >>>>>> >>>>>> I'm still looking for a sponsor and a hotspot/servicability- >>>>>> dev >>>>>> reviewer. Could somebody maintaining javax.rmi.ssl have a >>>>>> look at >>>>>> this >>>>>> as well? Thank you! >>>>> >>>>> Ping? Friendly reminder that I still need reviewers and a >>>>> sponsor for >>>>> this. >>>> >>>> Anyone? >>> >>> I'm sorry for not spotting this earlier: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi- >>> ssl-factory- >>> changes/jdk/src/java.management/share/classes/sun/management/jmxrem >>> ote/ConnectorBootstrap.java.sdiff.html >>> * L442 - the log would contain 'com.sun.management.jmxremote.host >>> = >>> null' if host is not specified; might be better not to print this >>> out at all >> >> Updated webrev which does not print >> 'com.sun.management.jmxremote.host = null' if unset: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/ >> >>> Other than that the change looks good to me. If no one else is >>> volunteering I may sponsor this change. >> >> Thank you! > > Jaroslav, are you still willing to sponsor this? There hasn't been much > movement :-/ Sure. I need to start the compatibility review process before integration and it might take some time. -JB- > > Thanks, > Severin > From sgehwolf at redhat.com Wed Dec 9 14:13:01 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 Dec 2015 15:13:01 +0100 Subject: jmx-dev [PING-2] RFR 6425769: jmx remote bind address In-Reply-To: <5668336A.3010406@oracle.com> References: <1446460682.10865.20.camel@redhat.com> <56377F17.4050006@oracle.com> <5637871B.30705@oracle.com> <1446487615.10865.57.camel@redhat.com> <5638C89F.2090406@oracle.com> <1446634476.3554.8.camel@redhat.com> <1447061525.3551.3.camel@redhat.com> <1448965029.4309.10.camel@redhat.com> <565D8592.6020701@oracle.com> <1448975945.4309.16.camel@redhat.com> <1449669302.3543.62.camel@redhat.com> <5668336A.3010406@oracle.com> Message-ID: <1449670381.3543.63.camel@redhat.com> On Wed, 2015-12-09 at 14:58 +0100, Jaroslav Bachorik wrote: > On 9.12.2015 14:55, Severin Gehwolf wrote: > > On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote: > > > Hi Jaroslav, > > > > > > On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: > > > > On 1.12.2015 11:17, Severin Gehwolf wrote: > > > > > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > > > > > > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Updated webrev with jtreg test in Java: > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/ > > > > > > > 02/ > > > > > > > bug: https://bugs.openjdk.java.net/browse/JDK-6425769 > > > > > > > > > > > > > > I believe this updated webrev addresses all concerns and > > > > > > > incorporates > > > > > > > suggestions brought up by Jaroslav and Daniel. > > > > > > > > > > > > > > I'm still looking for a sponsor and a > > > > > > > hotspot/servicability- > > > > > > > dev > > > > > > > reviewer. Could somebody maintaining javax.rmi.ssl have a > > > > > > > look at > > > > > > > this > > > > > > > as well? Thank you! > > > > > > > > > > > > Ping? Friendly reminder that I still need reviewers and a > > > > > > sponsor for > > > > > > this. > > > > > > > > > > Anyone? > > > > > > > > I'm sorry for not spotting this earlier: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no- > > > > rmi- > > > > ssl-factory- > > > > changes/jdk/src/java.management/share/classes/sun/management/jm > > > > xrem > > > > ote/ConnectorBootstrap.java.sdiff.html > > > > * L442 - the log would contain > > > > 'com.sun.management.jmxremote.host > > > > = > > > > null' if host is not specified; might be better not to print > > > > this > > > > out at all > > > > > > Updated webrev which does not print > > > 'com.sun.management.jmxremote.host = null' if unset: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/ > > > > > > > Other than that the change looks good to me. If no one else is > > > > volunteering I may sponsor this change. > > > > > > Thank you! > > > > Jaroslav, are you still willing to sponsor this? There hasn't been > > much > > movement :-/ > > Sure. I need to start the compatibility review process before > integration and it might take some time. OK. Thanks for the heads-up! Cheers, Severin > -JB- > > > > > Thanks, > > Severin > > > From jaroslav.bachorik at oracle.com Mon Dec 14 12:36:13 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 14 Dec 2015 13:36:13 +0100 Subject: jmx-dev RFR - JDK-7065236 : To interpret case-insensitive string locale independently In-Reply-To: <566E6C8E.3020409@oracle.com> References: <566E6C8E.3020409@oracle.com> Message-ID: <566EB7BD.8020409@oracle.com> On 14.12.2015 08:15, Harsha Wardhana B wrote: > Hello, > > Please review the fix for bug JDK-7065236. > > Issue : > https://bugs.openjdk.java.net/browse/JDK-7065236 > Webrev : http://cr.openjdk.java.net/~jbachorik/sponsorship/7065236/webrev.00 > > In order to fix the bug, below were the list of occurrences that needed > to be examined for Locale sensitive case conversions. > > ./javax/management/modelmbean/DescriptorSupport.java: final String > lowerInStr = inStr.toLowerCase(); ---- Yes > ./javax/management/modelmbean/DescriptorSupport.java: > descriptor.put(entry.getKey().toLowerCase(), entry.getValue()); ---- No > ./javax/management/remote/JMXServiceURL.java: > serviceURL.substring(protoStart, protoEnd).toLowerCase(); ---- Yes > ./javax/management/remote/JMXServiceURL.java: this.protocol = > protocol.toLowerCase(); ---- Yes > ./javax/management/loading/MLetParser.java: atts.put(att.toLowerCase(), > val); ---- Yes > ./javax/management/loading/MLetContent.java: return > attributes.get(name.toLowerCase()); ---- Private > Method. Not required > > ./com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java: return > name.substring(0, offset1).toLowerCase() + ---- No > ./com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java: return > name.substring(0, offset1).toUpperCase() + ---- No > ./com/sun/jmx/mbeanserver/Util.java: hash += > names[i].toLowerCase().hashCode(); ---- No > > The occurrences of case conversions marked as 'Yes' were deemed to be > Locale Insensitive and hence only those were fixed. Please review and > let me know if any other occurrences marked as 'No' also needs to be fixed. The fix looks good. -JB- > > Thanks > Harsha > > From jaroslav.bachorik at oracle.com Tue Dec 22 16:50:17 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 22 Dec 2015 17:50:17 +0100 Subject: jmx-dev RFR 8145982: JMXInterfaceBindingTest is failing intermittently Message-ID: <56797F49.5060107@oracle.com> Please, review this trivial test change Issue : https://bugs.openjdk.java.net/browse/JDK-8145982 Webrev: http://cr.openjdk.java.net/~jbachorik/8145982/webrev.00 The test calls System.exit(0) in case when it is not applicable (due to HW configuration). This call is forbidden by the test harness and the test fails. The solution is to replace it with 'return'. Thanks! -JB- From sgehwolf at redhat.com Tue Dec 22 17:01:31 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 22 Dec 2015 18:01:31 +0100 Subject: jmx-dev RFR 8145982: JMXInterfaceBindingTest is failing intermittently In-Reply-To: <56797F49.5060107@oracle.com> References: <56797F49.5060107@oracle.com> Message-ID: <1450803691.3742.21.camel@redhat.com> On Tue, 2015-12-22 at 17:50 +0100, Jaroslav Bachorik wrote: > Please, review this trivial test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8145982 > Webrev: http://cr.openjdk.java.net/~jbachorik/8145982/webrev.00 > > The test calls System.exit(0) in case when it is not applicable (due to? > HW configuration). This call is forbidden by the test harness and the? > test fails. The solution is to replace it with 'return'. Looks fine to me (not a Reviewer). Sorry about this. Cheers, Severin > Thanks! > > -JB- From olivier.lagneau at oracle.com Tue Dec 22 17:25:36 2015 From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com) Date: Tue, 22 Dec 2015 18:25:36 +0100 Subject: jmx-dev RFR 8145982: JMXInterfaceBindingTest is failing intermittently In-Reply-To: <56797F49.5060107@oracle.com> References: <56797F49.5060107@oracle.com> Message-ID: <56798790.8080602@oracle.com> Hi Jaroslav, Looks good. Not a reviewer however. Olivier. On 22/12/2015 17:50, Jaroslav Bachorik wrote: > Please, review this trivial test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8145982 > Webrev: http://cr.openjdk.java.net/~jbachorik/8145982/webrev.00 > > The test calls System.exit(0) in case when it is not applicable (due > to HW configuration). This call is forbidden by the test harness and > the test fails. The solution is to replace it with 'return'. > > Thanks! > > -JB- -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Tue Dec 22 17:34:07 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Dec 2015 17:34:07 +0000 Subject: jmx-dev RFR 8145982: JMXInterfaceBindingTest is failing intermittently In-Reply-To: <56798790.8080602@oracle.com> References: <56797F49.5060107@oracle.com> <56798790.8080602@oracle.com> Message-ID: <84CB7512-79B8-47FB-AD9B-A9D792D34627@oracle.com> On 22 Dec 2015, at 17:25, olivier.lagneau at oracle.com wrote: > Hi Jaroslav, > > Looks good. Not a reviewer however. +1 -Chris. > Olivier. > > On 22/12/2015 17:50, Jaroslav Bachorik wrote: >> Please, review this trivial test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8145982 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8145982/webrev.00 >> >> The test calls System.exit(0) in case when it is not applicable (due to HW configuration). This call is forbidden by the test harness and the test fails. The solution is to replace it with 'return'. >> >> Thanks! >> >> -JB- > From jaroslav.bachorik at oracle.com Wed Dec 23 10:26:07 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 23 Dec 2015 11:26:07 +0100 Subject: jmx-dev RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses Message-ID: <567A76BF.5090305@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8146015 Webrev: http://cr.openjdk.java.net/~jbachorik/8146015/webrev.00 The test fails for IPv6 addresses since the RMI expects an IPv6 address to be properly wrapped in '[]'. In addition to that the logic for selecting IP addresses to bind is flawed - it does not check for IP addresses of multiple adapters but for multiple IP addresses assigned to 'localhost'. In combination with IPv4 & IPv6 this will cause the test to attempt binding to IPv4 and IPv6 address of the same adapter simultaneously and the test will fail. The fix adds the requested wrapping for IPv6 addresses and adjusts the IP selection logic to iterate over distinct adapters first and prevent IPv4 and IPv6 address of the same adapter being treated as two addresses (for the purposes of the test). Thanks, -JB-