From lmesnik at openjdk.org Fri Sep 2 18:11:43 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 2 Sep 2022 18:11:43 GMT Subject: jmx-dev RFR: JDK-8292067 Convert test/sun/management/jmxremote/bootstrap shell tests to java version [v3] In-Reply-To: References:

Message-ID: On Tue, 30 Aug 2022 22:39:15 GMT, Bill Huang wrote: >> This task convert 3 shell tests below to java version. >> test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh >> test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Implemented more review comments. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9973 From duke at openjdk.org Fri Sep 2 18:14:33 2022 From: duke at openjdk.org (Bill Huang) Date: Fri, 2 Sep 2022 18:14:33 GMT Subject: jmx-dev Integrated: JDK-8292067 Convert test/sun/management/jmxremote/bootstrap shell tests to java version In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 22:51:50 GMT, Bill Huang wrote: > This task convert 3 shell tests below to java version. > test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh > test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh This pull request has now been integrated. Changeset: 3993a1f9 Author: Bill Huang Committer: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/3993a1f9eaa8353ab8b24fe56c870580ef34fb52 Stats: 1641 lines in 9 files changed: 591 ins; 728 del; 322 mod 8292067: Convert test/sun/management/jmxremote/bootstrap shell tests to java version Reviewed-by: lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/9973 From duke at openjdk.org Fri Sep 9 16:18:17 2022 From: duke at openjdk.org (Bill Huang) Date: Fri, 9 Sep 2022 16:18:17 GMT Subject: jmx-dev RFR: JDK-8293343 sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java failed with "Agent communication error: java.io.EOFException" Message-ID: This task provides a fix for java.io.EOFException on RmiSslNoKeyStoreTest and RmiBootstrapTest. The EOFException is only seen when tests are run in concurrent mode. It could be caused by a bug in prepareTestFiles() which creates a race condition that RmiBootstrapTest/RmiSslNoKeyStoreTest changes the file permissions while the other one reading the same files. In addition, tests are failing intermittently for SocketException with agentvm mode. ------------- Commit messages: - Removed RmiBootstrapTest and RmiSslNoKeyStoreTest from ProblemList. - Made tests run in othervm mode. - Fixed prepareTestFile() to return property files in the test folder. Changes: https://git.openjdk.org/jdk/pull/10224/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10224&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293343 Stats: 6 lines in 4 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10224.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10224/head:pull/10224 PR: https://git.openjdk.org/jdk/pull/10224 From kevinw at openjdk.org Fri Sep 9 16:18:17 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Sep 2022 16:18:17 GMT Subject: jmx-dev RFR: JDK-8293343 sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java failed with "Agent communication error: java.io.EOFException" In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 23:20:19 GMT, Bill Huang wrote: > This task provides a fix for java.io.EOFException on RmiSslNoKeyStoreTest and RmiBootstrapTest. > > The EOFException is only seen when tests are run in concurrent mode. It could be caused by a bug in prepareTestFiles() which creates a race condition that RmiBootstrapTest/RmiSslNoKeyStoreTest changes the file permissions while the other one reading the same files. > > In addition, tests are failing intermittently for SocketException with agentvm mode. Looks good, I've tested othervm and had success also. One more thing - these tests are now in the problemlist, so we need to remove them from test/jdk/ProblemList.txt: 527 sun/management/jmxremote/bootstrap/RmiBootstrapTest.java 8293335 linux-x64 528 sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java 8293343 linux-aarch64,macosx-x64 ------------- PR: https://git.openjdk.org/jdk/pull/10224 From kevinw at openjdk.org Fri Sep 9 16:22:39 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Sep 2022 16:22:39 GMT Subject: jmx-dev RFR: JDK-8293343 sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java failed with "Agent communication error: java.io.EOFException" In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 23:20:19 GMT, Bill Huang wrote: > This task provides a fix for java.io.EOFException on RmiSslNoKeyStoreTest and RmiBootstrapTest. > > The EOFException is only seen when tests are run in concurrent mode. It could be caused by a bug in prepareTestFiles() which creates a race condition that RmiBootstrapTest/RmiSslNoKeyStoreTest changes the file permissions while the other one reading the same files. > > In addition, tests are failing intermittently for SocketException with agentvm mode. Looks good! ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.org/jdk/pull/10224 From cjplummer at openjdk.org Fri Sep 9 18:03:37 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Sep 2022 18:03:37 GMT Subject: jmx-dev RFR: JDK-8293343 sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java failed with "Agent communication error: java.io.EOFException" In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 23:20:19 GMT, Bill Huang wrote: > This task provides a fix for java.io.EOFException on RmiSslNoKeyStoreTest and RmiBootstrapTest. > > The EOFException is only seen when tests are run in concurrent mode. It could be caused by a bug in prepareTestFiles() which creates a race condition that RmiBootstrapTest/RmiSslNoKeyStoreTest changes the file permissions while the other one reading the same files. > > In addition, tests are failing intermittently for SocketException with agentvm mode. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10224 From duke at openjdk.org Mon Sep 12 13:12:52 2022 From: duke at openjdk.org (Bill Huang) Date: Mon, 12 Sep 2022 13:12:52 GMT Subject: jmx-dev Integrated: JDK-8293343 sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java failed with "Agent communication error: java.io.EOFException" In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 23:20:19 GMT, Bill Huang wrote: > This task provides a fix for java.io.EOFException on RmiSslNoKeyStoreTest and RmiBootstrapTest. > > The EOFException is only seen when tests are run in concurrent mode. It could be caused by a bug in prepareTestFiles() which creates a race condition that RmiBootstrapTest/RmiSslNoKeyStoreTest changes the file permissions while the other one reading the same files. > > In addition, tests are failing intermittently for SocketException with agentvm mode. This pull request has now been integrated. Changeset: 91c9091d Author: Bill Huang Committer: Kevin Walls URL: https://git.openjdk.org/jdk/commit/91c9091d7e64ba0bdb257521bd15ff183c6839fa Stats: 6 lines in 4 files changed: 0 ins; 2 del; 4 mod 8293343: sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java failed with "Agent communication error: java.io.EOFException" 8293335: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1failed with "Agent communication error: java.io.EOFException" Reviewed-by: kevinw, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/10224 From jpai at openjdk.org Sun Sep 18 12:05:10 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 18 Sep 2022 12:05:10 GMT Subject: jmx-dev RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port Message-ID: Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616? The test has been intermittently failing with `cannot find a free port after 10 tries`. The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`. Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address. The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free. The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does. Multiple test runs after this change hasn't yet run into the failure. ------------- Commit messages: - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port Changes: https://git.openjdk.org/jdk/pull/10322/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10322&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8030616 Stats: 7 lines in 3 files changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10322.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10322/head:pull/10322 PR: https://git.openjdk.org/jdk/pull/10322 From jpai at openjdk.org Sun Sep 18 13:08:18 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 18 Sep 2022 13:08:18 GMT Subject: jmx-dev RFR: 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake" Message-ID: Can I please get a review of this change which proposes to fix the intermittent failures noted in https://bugs.openjdk.org/browse/JDK-8293657? There are two parts to this fix. One is straightforward fix in the test configuration file where it uses an incompatible cipher suite with the enabled protocols. The details of that are noted in my comment in the JBS https://bugs.openjdk.org/browse/JDK-8293657?focusedCommentId=14524400&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14524400. The fix for that resides solely in `management_ssltest07_ok.properties.in` file. The more curious part was why this specific test configuration is ever passing instead of always failing. That turned out to be a bug in the `sun.management.jmxremote.HostAwareSslSocketFactory`. The (internal implementation detail) in `sun.rmi.transport.tcp.TCPEndpoint` holds a cache of `localEndpoints` which effectively are server and client socket factories that get used when creating the corresponding socket/server sockets. The cache uses a key, whose one component is the `HostAwareSslSocketFactory` instance. This class extends from `javax.rmi.ssl.SslRMIServerSocketFactory` which is where the `equals()` is implemented for the `HostAwareSslSocketFactory` instances. The bug resides in the fact that the current implementation of the `HostAwareSslSocketFactory` constructor doesn't pass to its `super` the `enabledCipherSuites`, `enabledProtocols` and `needClientAuth` values with which the `HostAwareSslSocketFactory` was constructed with. Instead it stores these values as private memb ers and thus the `SslRMIServerSocketFactory` has its own version of these members as `null`. The `SslRMIServerSocketFactory` uses these values in its `equals` implementation and thus ends up computing a wrong output from the `equals` call. This ultimately ends up with the (internal) `TCPEndpoint` returning an incorrect (server) socket factory that gets used during the client/server communication. What this means is that the restrictions imposed on enabled protocols and enabled cipher suites in `management_ssltest07_ok.properties.in` aren't taken into account and instead a different set of (lenient) configurations for these attributes gets used (because of the cached socket factory constructed for a previous run of a different test configuration). The commit in this PR fixes the `HostAwareSslSocketFactory` to correctly pass to its `super` the enabled protocols, enabled cipher suites and the client auth mode, instead of saving that state (only) in `HostAwareSslSocketFactory`. Additionally the commit removes this test from the problem listing. ------------- Commit messages: - 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake" Changes: https://git.openjdk.org/jdk/pull/10323/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10323&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293657 Stats: 16 lines in 3 files changed: 1 ins; 7 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/10323.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10323/head:pull/10323 PR: https://git.openjdk.org/jdk/pull/10323 From msheppar at openjdk.org Sun Sep 18 22:03:38 2022 From: msheppar at openjdk.org (Mark Sheppard) Date: Sun, 18 Sep 2022 22:03:38 GMT Subject: jmx-dev RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai wrote: > Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616? > > The test has been intermittently failing with `cannot find a free port after 10 tries`. The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`. > > Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address. > > The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free. > > The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does. > > Multiple test runs after this change hasn't yet run into the failure. While the change is reasonable, I?m not sure about your rationale. The contributing factors to the intermittent failures are due to the flawed ephemeral port allocation strategy, that incurs a race condition to use the selected ephemeral port within the test before the OS uses it. So from the time that the port has been acquired, then released via the autoclose of the serversocket, and then reused in the test, it is possible that the OS may have also relocated that ephemeral port. This change doesn?t alter this race condition. The are a number of significant attributes to the port allocation strategy: The port allocation strategy acquires an ephemeral port from the OS while binding it to a ServerSocket. The significance of ServerSocket is it surreptitiously sets SO_REUSEADDR socket option on the server socket (Net.socket0() == Java_sun_nio_ch_Net_socket0). The fact that SO_REUSEADDR is set is important in this scenario. The objective with using SO_REUSEADDR on a serversocket is allow for efficient server restarts due to a shutdown for whatever reason. With SO_REUSEADDR set the restarting server, which typically uses a well known port, won?t get a BindException, while the port may still be associated with the ?terminating? server i.e. it may not have been fully released by the OS, for general reuse. Thus, this has a number of favourable consequences with your proposed change, as the address binding is the same as that used for acquiring the port, so it is essential a ?server restart scenario?, albeit with an Ephemeral port. As such, there still exists the possibility that the port will be reused by the OS, where conditions of heavy ephemeral port allocation is occurring. As such, the change may reduce the rate of intermittent failure, but it won?t solve the issue fully. There is a possibility that it may increase the rate of failure as many network tests now use Loopback address rather than the local host address i.e. the primary configured IP address. This will depend on the load on a test system, and the amount of concurrently executing network tests, with the corresponding high volume of ephemeral port allocation. Nonetheless, it is a reasonable change, provided there is no subtle change in test semantics. I think it will ameliorate the intermittent failures. ------------- PR: https://git.openjdk.org/jdk/pull/10322 From jpai at openjdk.org Mon Sep 19 00:44:40 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 Sep 2022 00:44:40 GMT Subject: jmx-dev RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai wrote: > Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616? > > The test has been intermittently failing with `cannot find a free port after 10 tries`. The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`. > > Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address. > > The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free. > > The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does. > > Multiple test runs after this change hasn't yet run into the failure. Hello Mark, this specific change is merely meant to address the specific test case which is running into this problem. As you note the free port identification logic has and will continue to have the race condition. It will be applicable to all tests that use that utility. This change doesn't propose to do anything for such cases. However, in this specific case it wasn't the race condition which was causing the issue. Data that was collected from those failures shows that the issue was because of using the wrong address while trying to bind the free port that was identified. The data collected from these failed runs has been added to the linked JBS issue as a comment to show the port usage. ------------- PR: https://git.openjdk.org/jdk/pull/10322 From kevinw at openjdk.org Wed Sep 21 11:12:45 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 21 Sep 2022 11:12:45 GMT Subject: jmx-dev RFR: 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake" In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 12:57:28 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the intermittent failures noted in https://bugs.openjdk.org/browse/JDK-8293657? > > There are two parts to this fix. One is straightforward fix in the test configuration file where it uses an incompatible cipher suite with the enabled protocols. The details of that are noted in my comment in the JBS https://bugs.openjdk.org/browse/JDK-8293657?focusedCommentId=14524400&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14524400. The fix for that resides solely in `management_ssltest07_ok.properties.in` file. > > The more curious part was why this specific test configuration is ever passing instead of always failing. That turned out to be a bug in the `sun.management.jmxremote.HostAwareSslSocketFactory`. The (internal implementation detail) in `sun.rmi.transport.tcp.TCPEndpoint` holds a cache of `localEndpoints` which effectively are server and client socket factories that get used when creating the corresponding socket/server sockets. The cache uses a key, whose one component is the `HostAwareSslSocketFactory` instance. This class extends from `javax.rmi.ssl.SslRMIServerSocketFactory` which is where the `equals()` is implemented for the `HostAwareSslSocketFactory` instances. The bug resides in the fact that the current implementation of the `HostAwareSslSocketFactory` constructor doesn't pass to its `super` the `enabledCipherSuites`, `enabledProtocols` and `needClientAuth` values with which the `HostAwareSslSocketFactory` was constructed with. Instead it stores these values as private me mbers and thus the `SslRMIServerSocketFactory` has its own version of these members as `null`. The `SslRMIServerSocketFactory` uses these values in its `equals` implementation and thus ends up computing a wrong output from the `equals` call. This ultimately ends up with the (internal) `TCPEndpoint` returning an incorrect (server) socket factory that gets used during the client/server communication. What this means is that the restrictions imposed on enabled protocols and enabled cipher suites in `management_ssltest07_ok.properties.in` aren't taken into account and instead a different set of (lenient) configurations for these attributes gets used (because of the cached socket factory constructed for a previous run of a different test configuration). > > The commit in this PR fixes the `HostAwareSslSocketFactory` to correctly pass to its `super` the enabled protocols, enabled cipher suites and the client auth mode, instead of saving that state (only) in `HostAwareSslSocketFactory`. > > Additionally the commit removes this test from the problem listing. Marked as reviewed by kevinw (Committer). Great investigation, of what must be a long-standing issue. Looks good. ------------- PR: https://git.openjdk.org/jdk/pull/10323 From jpai at openjdk.org Thu Sep 22 09:43:15 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 Sep 2022 09:43:15 GMT Subject: jmx-dev RFR: 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake" In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 12:57:28 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the intermittent failures noted in https://bugs.openjdk.org/browse/JDK-8293657? > > There are two parts to this fix. One is straightforward fix in the test configuration file where it uses an incompatible cipher suite with the enabled protocols. The details of that are noted in my comment in the JBS https://bugs.openjdk.org/browse/JDK-8293657?focusedCommentId=14524400&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14524400. The fix for that resides solely in `management_ssltest07_ok.properties.in` file. > > The more curious part was why this specific test configuration is ever passing instead of always failing. That turned out to be a bug in the `sun.management.jmxremote.HostAwareSslSocketFactory`. The (internal implementation detail) in `sun.rmi.transport.tcp.TCPEndpoint` holds a cache of `localEndpoints` which effectively are server and client socket factories that get used when creating the corresponding socket/server sockets. The cache uses a key, whose one component is the `HostAwareSslSocketFactory` instance. This class extends from `javax.rmi.ssl.SslRMIServerSocketFactory` which is where the `equals()` is implemented for the `HostAwareSslSocketFactory` instances. The bug resides in the fact that the current implementation of the `HostAwareSslSocketFactory` constructor doesn't pass to its `super` the `enabledCipherSuites`, `enabledProtocols` and `needClientAuth` values with which the `HostAwareSslSocketFactory` was constructed with. Instead it stores these values as private me mbers and thus the `SslRMIServerSocketFactory` has its own version of these members as `null`. The `SslRMIServerSocketFactory` uses these values in its `equals` implementation and thus ends up computing a wrong output from the `equals` call. This ultimately ends up with the (internal) `TCPEndpoint` returning an incorrect (server) socket factory that gets used during the client/server communication. What this means is that the restrictions imposed on enabled protocols and enabled cipher suites in `management_ssltest07_ok.properties.in` aren't taken into account and instead a different set of (lenient) configurations for these attributes gets used (because of the cached socket factory constructed for a previous run of a different test configuration). > > The commit in this PR fixes the `HostAwareSslSocketFactory` to correctly pass to its `super` the enabled protocols, enabled cipher suites and the client auth mode, instead of saving that state (only) in `HostAwareSslSocketFactory`. > > Additionally the commit removes this test from the problem listing. Thank you Kevin for the review. ------------- PR: https://git.openjdk.org/jdk/pull/10323 From dfuchs at openjdk.org Thu Sep 22 11:05:18 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 22 Sep 2022 11:05:18 GMT Subject: jmx-dev RFR: 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake" In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 12:57:28 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the intermittent failures noted in https://bugs.openjdk.org/browse/JDK-8293657? > > There are two parts to this fix. One is straightforward fix in the test configuration file where it uses an incompatible cipher suite with the enabled protocols. The details of that are noted in my comment in the JBS https://bugs.openjdk.org/browse/JDK-8293657?focusedCommentId=14524400&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14524400. The fix for that resides solely in `management_ssltest07_ok.properties.in` file. > > The more curious part was why this specific test configuration is ever passing instead of always failing. That turned out to be a bug in the `sun.management.jmxremote.HostAwareSslSocketFactory`. The (internal implementation detail) in `sun.rmi.transport.tcp.TCPEndpoint` holds a cache of `localEndpoints` which effectively are server and client socket factories that get used when creating the corresponding socket/server sockets. The cache uses a key, whose one component is the `HostAwareSslSocketFactory` instance. This class extends from `javax.rmi.ssl.SslRMIServerSocketFactory` which is where the `equals()` is implemented for the `HostAwareSslSocketFactory` instances. The bug resides in the fact that the current implementation of the `HostAwareSslSocketFactory` constructor doesn't pass to its `super` the `enabledCipherSuites`, `enabledProtocols` and `needClientAuth` values with which the `HostAwareSslSocketFactory` was constructed with. Instead it stores these values as private me mbers and thus the `SslRMIServerSocketFactory` has its own version of these members as `null`. The `SslRMIServerSocketFactory` uses these values in its `equals` implementation and thus ends up computing a wrong output from the `equals` call. This ultimately ends up with the (internal) `TCPEndpoint` returning an incorrect (server) socket factory that gets used during the client/server communication. What this means is that the restrictions imposed on enabled protocols and enabled cipher suites in `management_ssltest07_ok.properties.in` aren't taken into account and instead a different set of (lenient) configurations for these attributes gets used (because of the cached socket factory constructed for a previous run of a different test configuration). > > The commit in this PR fixes the `HostAwareSslSocketFactory` to correctly pass to its `super` the enabled protocols, enabled cipher suites and the client auth mode, instead of saving that state (only) in `HostAwareSslSocketFactory`. > > Additionally the commit removes this test from the problem listing. I had a look at the RMIServerSocketFactory hierarchy and the proposed changes look reasonable. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/10323 From jpai at openjdk.org Fri Sep 23 04:54:17 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 23 Sep 2022 04:54:17 GMT Subject: jmx-dev RFR: 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake" In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 12:57:28 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the intermittent failures noted in https://bugs.openjdk.org/browse/JDK-8293657? > > There are two parts to this fix. One is straightforward fix in the test configuration file where it uses an incompatible cipher suite with the enabled protocols. The details of that are noted in my comment in the JBS https://bugs.openjdk.org/browse/JDK-8293657?focusedCommentId=14524400&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14524400. The fix for that resides solely in `management_ssltest07_ok.properties.in` file. > > The more curious part was why this specific test configuration is ever passing instead of always failing. That turned out to be a bug in the `sun.management.jmxremote.HostAwareSslSocketFactory`. The (internal implementation detail) in `sun.rmi.transport.tcp.TCPEndpoint` holds a cache of `localEndpoints` which effectively are server and client socket factories that get used when creating the corresponding socket/server sockets. The cache uses a key, whose one component is the `HostAwareSslSocketFactory` instance. This class extends from `javax.rmi.ssl.SslRMIServerSocketFactory` which is where the `equals()` is implemented for the `HostAwareSslSocketFactory` instances. The bug resides in the fact that the current implementation of the `HostAwareSslSocketFactory` constructor doesn't pass to its `super` the `enabledCipherSuites`, `enabledProtocols` and `needClientAuth` values with which the `HostAwareSslSocketFactory` was constructed with. Instead it stores these values as private me mbers and thus the `SslRMIServerSocketFactory` has its own version of these members as `null`. The `SslRMIServerSocketFactory` uses these values in its `equals` implementation and thus ends up computing a wrong output from the `equals` call. This ultimately ends up with the (internal) `TCPEndpoint` returning an incorrect (server) socket factory that gets used during the client/server communication. What this means is that the restrictions imposed on enabled protocols and enabled cipher suites in `management_ssltest07_ok.properties.in` aren't taken into account and instead a different set of (lenient) configurations for these attributes gets used (because of the cached socket factory constructed for a previous run of a different test configuration). > > The commit in this PR fixes the `HostAwareSslSocketFactory` to correctly pass to its `super` the enabled protocols, enabled cipher suites and the client auth mode, instead of saving that state (only) in `HostAwareSslSocketFactory`. > > Additionally the commit removes this test from the problem listing. Thank you Daniel for your review. My tier1,tier2,tier3 testing which change went fine without any issues. ------------- PR: https://git.openjdk.org/jdk/pull/10323 From jpai at openjdk.org Fri Sep 23 04:57:36 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 23 Sep 2022 04:57:36 GMT Subject: jmx-dev Integrated: 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake" In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 12:57:28 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the intermittent failures noted in https://bugs.openjdk.org/browse/JDK-8293657? > > There are two parts to this fix. One is straightforward fix in the test configuration file where it uses an incompatible cipher suite with the enabled protocols. The details of that are noted in my comment in the JBS https://bugs.openjdk.org/browse/JDK-8293657?focusedCommentId=14524400&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14524400. The fix for that resides solely in `management_ssltest07_ok.properties.in` file. > > The more curious part was why this specific test configuration is ever passing instead of always failing. That turned out to be a bug in the `sun.management.jmxremote.HostAwareSslSocketFactory`. The (internal implementation detail) in `sun.rmi.transport.tcp.TCPEndpoint` holds a cache of `localEndpoints` which effectively are server and client socket factories that get used when creating the corresponding socket/server sockets. The cache uses a key, whose one component is the `HostAwareSslSocketFactory` instance. This class extends from `javax.rmi.ssl.SslRMIServerSocketFactory` which is where the `equals()` is implemented for the `HostAwareSslSocketFactory` instances. The bug resides in the fact that the current implementation of the `HostAwareSslSocketFactory` constructor doesn't pass to its `super` the `enabledCipherSuites`, `enabledProtocols` and `needClientAuth` values with which the `HostAwareSslSocketFactory` was constructed with. Instead it stores these values as private me mbers and thus the `SslRMIServerSocketFactory` has its own version of these members as `null`. The `SslRMIServerSocketFactory` uses these values in its `equals` implementation and thus ends up computing a wrong output from the `equals` call. This ultimately ends up with the (internal) `TCPEndpoint` returning an incorrect (server) socket factory that gets used during the client/server communication. What this means is that the restrictions imposed on enabled protocols and enabled cipher suites in `management_ssltest07_ok.properties.in` aren't taken into account and instead a different set of (lenient) configurations for these attributes gets used (because of the cached socket factory constructed for a previous run of a different test configuration). > > The commit in this PR fixes the `HostAwareSslSocketFactory` to correctly pass to its `super` the enabled protocols, enabled cipher suites and the client auth mode, instead of saving that state (only) in `HostAwareSslSocketFactory`. > > Additionally the commit removes this test from the problem listing. This pull request has now been integrated. Changeset: f6d78cda Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/f6d78cda853ce6ec6fdda845f1799253461fc618 Stats: 16 lines in 3 files changed: 1 ins; 7 del; 8 mod 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake" Reviewed-by: kevinw, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/10323 From mernst at openjdk.org Sun Sep 25 17:04:38 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:38 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue. Done: https://bugs.openjdk.org/browse/SKARA-1566 ------------- PR: https://git.openjdk.org/jdk/pull/10029 From jpai at openjdk.org Sun Sep 25 17:04:38 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 25 Sep 2022 17:04:38 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> References: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> Message-ID: On Thu, 25 Aug 2022 19:55:47 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > >> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue. > > Done: https://bugs.openjdk.org/browse/SKARA-1566 Hello Michael @mernst, these changes are mostly fine. However, they are spread across files which reside in different areas of the JDK. For changes like these, we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs. Would you be willing to split this PR into separate ones. I would recommend starting with one PR which includes changes that are part of `test/jdk/java`, `test/jdk/jdk` and `test/jdk/jni`. If you can come up with that PR, then I'll go ahead and create a JBS issue for it and you can then link the PR against that issue. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:38 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:38 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Message-ID: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni ------------- Commit messages: - Remove file that was removed upstream - Fix inconsistency in capitalization - Undo change in zlip - Fix typos Changes: https://git.openjdk.org/jdk/pull/10029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294321 Stats: 317 lines in 108 files changed: 0 ins; 195 del; 122 mod Patch: https://git.openjdk.org/jdk/pull/10029.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029 PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:38 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:38 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> Message-ID: On Mon, 5 Sep 2022 06:32:44 GMT, Jaikiran Pai wrote: > these changes are mostly fine. Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? It doesn't seem useful to make a pull request with known deficiencies. > we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs. Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From duke at openjdk.org Sun Sep 25 17:04:39 2022 From: duke at openjdk.org (SWinxy) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com>

Message-ID: On Mon, 5 Sep 2022 14:54:50 GMT, Michael Ernst wrote: > Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? These changes are fine. I don't see an instance where the duplicated words would mean a change in the specification. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From jpai at openjdk.org Sun Sep 25 17:04:39 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Hello Michael, > > these changes are mostly fine. > > Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? It doesn't seem useful to make a pull request with known deficiencies. I wasn't implying this PR had deficiencies. What I meant was, to be able to have this reviewed, in addition to code changes this will also need a issue to be created and linked to this PR (and the PR title changed to the form `: `). I have now created https://bugs.openjdk.org/browse/JDK-8294321. Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:39 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References:

Message-ID: On Sat, 24 Sep 2022 10:41:05 GMT, Jaikiran Pai wrote: > Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers. OK. I'll repeat my comment from before: > Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From duke at openjdk.org Sun Sep 25 17:04:39 2022 From: duke at openjdk.org (SWinxy) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Oh no what happened ![image](https://user-images.githubusercontent.com/8303399/192155378-4bb439fa-d27a-417d-8a3c-cf7f7329458f.png) src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053: > 1051: * fetch will take place at index 1. > 1052: * > 1053: * @return The current position index. Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:39 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References:

Message-ID: On Sun, 25 Sep 2022 16:51:27 GMT, SWinxy wrote: > Oh no what happened Oops! Thanks for pointing out the goof. It seems to be fixed now. It has now been a month since I opened the pull request, and I have responded to each substantive comment promptly. It would be great to merge this pull request to avoid the need for more merges. > src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053: > >> 1051: * fetch will take place at index 1. >> 1052: * >> 1053: * @return The current position index. > > Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here. Thanks for pointing out the inconsistency. I have fixed it. (I noticed many violations of the official Javadoc style, but this is not the right pull request to fix them.) ------------- PR: https://git.openjdk.org/jdk/pull/10029 From alanb at openjdk.org Sun Sep 25 17:04:40 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 25 Sep 2022 17:04:40 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni src/java.base/share/native/libzip/zlib/zlib.h line 756: > 754: If this is done, the old level and strategy will be applied to the data > 755: compressed before deflateParams(), and the new level and strategy will be > 756: applied to the data compressed after deflateParams(). This is an issue for the upstream zlib project, we probably don't want to change it here. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From lancea at openjdk.org Sun Sep 25 17:04:40 2022 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 25 Sep 2022 17:04:40 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References:

Message-ID: On Tue, 30 Aug 2022 09:31:07 GMT, Alan Bateman wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > src/java.base/share/native/libzip/zlib/zlib.h line 756: > >> 754: If this is done, the old level and strategy will be applied to the data >> 755: compressed before deflateParams(), and the new level and strategy will be >> 756: applied to the data compressed after deflateParams(). > > This is an issue for the upstream zlib project, we probably don't want to change it here. Agree. See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:40 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:40 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References:

Message-ID: On Tue, 30 Aug 2022 09:55:18 GMT, Lance Andersen wrote: >> src/java.base/share/native/libzip/zlib/zlib.h line 756: >> >>> 754: If this is done, the old level and strategy will be applied to the data >>> 755: compressed before deflateParams(), and the new level and strategy will be >>> 756: applied to the data compressed after deflateParams(). >> >> This is an issue for the upstream zlib project, we probably don't want to change it here. > > Agree. See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos. OK. I backed out the change to zlib. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From duke at openjdk.org Sun Sep 25 17:23:28 2022 From: duke at openjdk.org (SWinxy) Date: Sun, 25 Sep 2022 17:23:28 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni I'm not a committer (yet) so I can't [sponsor](https://openjdk.org/sponsor/) this PR, even though I would. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From joehw at openjdk.org Mon Sep 26 16:16:34 2022 From: joehw at openjdk.org (Joe Wang) Date: Mon, 26 Sep 2022 16:16:34 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni We have discussed several times in the past that we don't touch upstream (in this case, Apache) code unless the change is essential. In general, if you fix a bug in a class, it's fine to fix other non-essential things within the class, such as code styles, javadocs, typos as in this case, etc. Otherwise, I would suggest you contribute such changes to the upstream projects. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Mon Sep 26 16:51:36 2022 From: mernst at openjdk.org (Michael Ernst) Date: Mon, 26 Sep 2022 16:51:36 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Reinstate typos in Apache code that is copied into the JDK - Merge ../jdk-openjdk into typos-typos - Remove file that was removed upstream - Fix inconsistency in capitalization - Undo change in zlip - Fix typos ------------- Changes: https://git.openjdk.org/jdk/pull/10029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=01 Stats: 85 lines in 76 files changed: 0 ins; 0 del; 85 mod Patch: https://git.openjdk.org/jdk/pull/10029.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029 PR: https://git.openjdk.org/jdk/pull/10029 From joehw at openjdk.org Mon Sep 26 17:04:25 2022 From: joehw at openjdk.org (Joe Wang) Date: Mon, 26 Sep 2022 17:04:25 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References:

Message-ID: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com> On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Thank you for your efforts on the cleaning up these typos I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review. I realize the changes are fairly trivial but this will most likely expedite getting your changes back ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Tue Sep 27 23:16:16 2022 From: mernst at openjdk.org (Michael Ernst) Date: Tue, 27 Sep 2022 23:16:16 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com> References:

<3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com> Message-ID: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com> On Mon, 26 Sep 2022 19:36:02 GMT, Lance Andersen wrote: > Thank you for your efforts on the cleaning up these typos > > I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review. > > I realize the changes are fairly trivial but this will most likely expedite getting your changes back Feel free to break up the pull request if that is what is needed to free it from red tape. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From dfuchs at openjdk.org Wed Sep 28 13:24:26 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 28 Sep 2022 13:24:26 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com> References:

<3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com> <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com> Message-ID: On Tue, 27 Sep 2022 23:12:43 GMT, Michael Ernst wrote: > Feel free to break up the pull request if that is what is needed to free it from red tape. Only you can do that @mernst ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Wed Sep 28 14:49:20 2022 From: mernst at openjdk.org (Michael Ernst) Date: Wed, 28 Sep 2022 14:49:20 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References:

Message-ID: On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Regarding breaking up the pull request: * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape. * I have spent a nontrivial amount of time on these fixes. There have been long delays, which forced me to resolve merge conflicts. I was told that the changes are "mostly fine" without any indication of what is wrong. I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted. * No one has explained what to do. "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is. I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to corrections. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From dfuchs at openjdk.org Wed Sep 28 15:13:39 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 28 Sep 2022 15:13:39 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References:

Message-ID: On Wed, 28 Sep 2022 14:45:54 GMT, Michael Ernst wrote: >> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Reinstate typos in Apache code that is copied into the JDK >> - Merge ../jdk-openjdk into typos-typos >> - Remove file that was removed upstream >> - Fix inconsistency in capitalization >> - Undo change in zlip >> - Fix typos > > Regarding breaking up the pull request: > * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape. > * Despite my repeated requests, no one has justified that *this particular pull request* needs the expertise of different teams. The only reasons stated have been custom and bureaucracy. > * I have spent a nontrivial amount of time on these fixes. There have been long delays, which forced me to resolve merge conflicts. I was told that the changes are "mostly fine" without any indication of what is wrong. I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted. > * I was condescendingly told "We have discussed several times in the past ..." even though I was not privy to those discussions. No pointer to documentation in the JDK itself, about pull requests, was given. > * No one has explained what to do. "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is. > > I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to contributions. Hi @mernst, sorry if this is how it appears. Pull requests that involve changes spanning a large set of files are notoriously harder to review since they require a reviewer from each different area to chime in. Basically you will need one reviewer from each of these areas: - client - compiler - core-libs - hotspot - i18n - javadoc - jmx - net - nio - security - serviceability Jaikiran suggested to reduce the scope of this PR in his first comment: https://github.com/openjdk/jdk/pull/10029#issuecomment-1236588632 as did several other reviewers. Sorry if the meaning (or reason) was not clear. best regards, ------------- PR: https://git.openjdk.org/jdk/pull/10029 From aivanov at openjdk.org Wed Sep 28 15:28:24 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 28 Sep 2022 15:28:24 GMT Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References:

Message-ID: On Wed, 28 Sep 2022 15:26:13 GMT, Alexey Ivanov wrote: > The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`. The title was edited by someone other than me, as you can see from the PR history. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From darcy at openjdk.org Fri Sep 30 00:40:24 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 00:40:24 GMT Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net => openjdk.org Message-ID: With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. Updates were made using a shell script. I"ll run a copyright updater before any push. ------------- Commit messages: - JDK-8294618: Update openjdk.java.net => openjdk.org Changes: https://git.openjdk.org/jdk/pull/10501/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294618 Stats: 79 lines in 39 files changed: 0 ins; 0 del; 79 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 00:54:05 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 00:54:05 GMT Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2] In-Reply-To: References: Message-ID: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com> > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: - Update copyright. - Revert unintended update to binary file. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/b12d774f..2f257762 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=00-01 Stats: 10 lines in 11 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From mikael at openjdk.org Fri Sep 30 00:54:06 2022 From: mikael at openjdk.org (Mikael Vidstedt) Date: Fri, 30 Sep 2022 00:54:06 GMT Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2] In-Reply-To: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com> References: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com> Message-ID: On Fri, 30 Sep 2022 00:50:13 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright. > - Revert unintended update to binary file. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10501 From mikael at openjdk.org Fri Sep 30 00:54:08 2022 From: mikael at openjdk.org (Mikael Vidstedt) Date: Fri, 30 Sep 2022 00:54:08 GMT Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net => openjdk.org In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 00:33:57 GMT, Joe Darcy wrote: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Switch to https where needed/applicable while at it? ------------- PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 01:01:29 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 01:01:29 GMT Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v3] In-Reply-To: References: Message-ID: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Undo manpage update. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/2f257762..04dfc3ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 01:11:45 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 01:11:45 GMT Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net => openjdk.org In-Reply-To: References:

Message-ID: On Fri, 30 Sep 2022 00:48:02 GMT, Mikael Vidstedt wrote: > Switch to https where needed/applicable while at it? Good idea; might as well do the update in a single changeset. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 01:11:45 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 01:11:45 GMT Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: http -> https ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/04dfc3ef..cee96d0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=02-03 Stats: 22 lines in 6 files changed: 0 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From iris at openjdk.org Fri Sep 30 04:11:19 2022 From: iris at openjdk.org (Iris Clark) Date: Fri, 30 Sep 2022 04:11:19 GMT Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References:

Message-ID: On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > http -> https Marked as reviewed by iris (Reviewer). src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34: > 32: * the following link: > 33: * > 34: * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c The domain for hg wasn't changed to openjdk.org. The original URL is correct. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From kevinw at openjdk.org Fri Sep 30 12:55:43 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 30 Sep 2022 12:55:43 GMT Subject: jmx-dev RFR: 8283093: JMX connections should default to using an ObjectInputFilter Message-ID: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com> Set the management.properties "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized. Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication. The sun/management tests run OK with this change. The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive. ------------- Commit messages: - 8283093: JMX connections should default to using an ObjectInputFilter Changes: https://git.openjdk.org/jdk/pull/10507/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10507&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8283093 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10507.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10507/head:pull/10507 PR: https://git.openjdk.org/jdk/pull/10507 From ihse at openjdk.org Fri Sep 30 14:01:18 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 30 Sep 2022 14:01:18 GMT Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References:

Message-ID: On Fri, 30 Sep 2022 04:05:51 GMT, Iris Clark wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> http -> https > > src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34: > >> 32: * the following link: >> 33: * >> 34: * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c > > The domain for hg wasn't changed to openjdk.org. The original URL is correct. Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`? ------------- PR: https://git.openjdk.org/jdk/pull/10501 From dfuchs at openjdk.org Fri Sep 30 15:15:21 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 30 Sep 2022 15:15:21 GMT Subject: jmx-dev RFR: 8283093: JMX connections should default to using an ObjectInputFilter In-Reply-To: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com> References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com> Message-ID: On Fri, 30 Sep 2022 11:00:28 GMT, Kevin Walls wrote: > Set the management.properties "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized. > > Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication. > > The sun/management tests run OK with this change. The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive. Hi Kevin - have you tried connecting with jconsole to a java program (you can e.g. connect jconsole to itself) and verified that all looked OK and that there wasn't any exception logged while clicking through the various MBeans it exposes? ------------- PR: https://git.openjdk.org/jdk/pull/10507 From kevinw at openjdk.org Fri Sep 30 16:44:23 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 30 Sep 2022 16:44:23 GMT Subject: jmx-dev RFR: 8283093: JMX connections should default to using an ObjectInputFilter In-Reply-To: References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com> Message-ID: On Fri, 30 Sep 2022 15:11:26 GMT, Daniel Fuchs wrote: > Hi Kevin - have you tried connecting with jconsole to a java program (you can e.g. connect jconsole to itself) and verified that all looked OK and that there wasn't any exception logged while clicking through the various MBeans it exposes? Yes, all looks good in a manual test with jconsole. (I did use jconsole to experiment with a too-restrictive filter, to see what errors it causes.) ------------- PR: https://git.openjdk.org/jdk/pull/10507 From prr at openjdk.org Fri Sep 30 17:42:29 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 30 Sep 2022 17:42:29 GMT Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References:

Message-ID: On Fri, 30 Sep 2022 14:16:24 GMT, Weijun Wang wrote: >> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34: >> >>> 32: * the following link: >>> 33: * >>> 34: * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c >> >> The domain for hg wasn't changed to openjdk.org. The original URL is correct. > > Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`? This is correct. AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../" ------------- PR: https://git.openjdk.org/jdk/pull/10501 From joehw at openjdk.org Fri Sep 30 18:12:25 2022 From: joehw at openjdk.org (Joe Wang) Date: Fri, 30 Sep 2022 18:12:25 GMT Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References:

Message-ID: On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > http -> https The ones in java.xml look good to me. ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 20:29:20 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 20:29:20 GMT Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v5] In-Reply-To: References: Message-ID: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Update hg URLs to git. - Merge branch 'master' into JDK-8294618 - http -> https - Undo manpage update. - Update copyright. - Revert unintended update to binary file. - JDK-8294618: Update openjdk.java.net => openjdk.org ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/cee96d0a..fbaf3d4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=03-04 Stats: 2670 lines in 133 files changed: 1729 ins; 406 del; 535 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 20:29:21 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 20:29:21 GMT Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References:

Message-ID: On Fri, 30 Sep 2022 13:59:12 GMT, Magnus Ihse Bursie wrote: > Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..? Yes; I think it is sufficient to update src and doc with this PR. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 20:29:22 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 20:29:22 GMT Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References:

Message-ID: On Fri, 30 Sep 2022 17:38:54 GMT, Phil Race wrote: > This is correct. AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../" Update to persistent git links. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From joe.darcy at oracle.com Fri Sep 30 04:41:06 2022 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 29 Sep 2022 21:41:06 -0700 Subject: jmx-dev RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References:

Message-ID: <857259f1-daa2-46a0-ded8-24d866482707@oracle.com> Thanks for catching that Iris; I'll changes those to git URLs. -Joe On 9/29/2022 9:11 PM, Iris Clark wrote: > On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy wrote: > >>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >>> >>> Updates were made using a shell script. I"ll run a copyright updater before any push. >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> http -> https > Marked as reviewed by iris (Reviewer). > > src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34: > >> 32: * the following link: >> 33: * >> 34: * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c > The domain for hg wasn't changed to openjdk.org. The original URL is correct. > > ------------- > > PR: https://git.openjdk.org/jdk/pull/10501