On Mon, 4 Nov 2024 18:15:37 GMT, Kevin Walls wrote:
> This test is sensitive to timing, and should not run with -Xcomp (like
> NotifReconnectDeadlockTest.java).
>
> With -Xcomp, this test can fail on the the conn.getDefaultDomain() call, but
> if we handle that, it can also fa
On Mon, 4 Nov 2024 18:15:37 GMT, Kevin Walls wrote:
> This test is sensitive to timing, and should not run with -Xcomp (like
> NotifReconnectDeadlockTest.java).
>
> With -Xcomp, this test can fail on the the conn.getDefaultDomain() call, but
> if we handle that, it can also fa
On Thu, 7 Nov 2024 16:09:22 GMT, Chris Plummer wrote:
> What changed that caused it to suddenly start failing a lot?
This is the test I changed recently in JDK-8343378 -- it used to not fail even
if it threw an Exception. So I make that change, test, and see no failures.
But of course -Xcomp
This test is sensitive to timing, and should not run with -Xcomp (like
NotifReconnectDeadlockTest.java).
With -Xcomp, this test can fail on the the conn.getDefaultDomain() call, but if
we handle that, it can also fail on the first iteration through the loop, at
the call: JMXConnector client = J
On Fri, 1 Nov 2024 17:18:50 GMT, Chris Plummer wrote:
>> Right, it is the repetition that makes me want the comma. There are other
>> ways of phrasing this which would not need the comma. Even then, I still
>> might introduce one to imply a pause, which I still think helps make it
>> unambig
On Thu, 31 Oct 2024 12:11:41 GMT, Kevin Walls wrote:
> Test update: fail when it hits an Exception.
>
> This test still references jmxmp and iiop, which are of course redundant,
> there are various tests that still do this.
> I am working on http, so we may revisit these tes
On Thu, 31 Oct 2024 12:11:41 GMT, Kevin Walls wrote:
> Test update: fail when it hits an Exception.
>
> This test still references jmxmp and iiop, which are of course redundant,
> there are various tests that still do this.
> I am working on http, so we may revisit these tes
On Thu, 31 Oct 2024 21:57:10 GMT, Chris Plummer wrote:
>> I actually think it's more readable with the comma.
>> If there is (one protocol failure), then that (fails the test).
>> Without the comma, "failure fails" runs together, but the failure did not
>> fail, it was a perfectly good failure.
On Thu, 31 Oct 2024 19:10:38 GMT, Chris Plummer wrote:
>> Test update: fail when it hits an Exception.
>>
>> This test still references jmxmp and iiop, which are of course redundant,
>> there are various tests that still do this.
>> I am working on http, so we may revisit these tests in future
Test update: fail when it hits an Exception.
This test still references jmxmp and iiop, which are of course redundant, there
are various tests that still do this.
I am working on http, so we may revisit these tests in future to change their
list of protocols.
For now, I'd like to simply make th
On Mon, 21 Oct 2024 09:21:35 GMT, Kevin Walls wrote:
> Test update: HashedPasswordFileTest.java was using
> System.getProperty("test.src") as a place to _create_ a file.
>
> jtreg gives us the current working directory for the test invocation as a
> scratch direc
On Mon, 21 Oct 2024 09:21:35 GMT, Kevin Walls wrote:
> Test update: HashedPasswordFileTest.java was using
> System.getProperty("test.src") as a place to _create_ a file.
>
> jtreg gives us the current working directory for the test invocation as a
> scratch direc
Test update: HashedPasswordFileTest.java was using
System.getProperty("test.src") as a place to _create_ a file.
jtreg gives us the current working directory for the test invocation as a
scratch directory. Create files there, without reading any property to find
another location.
On Wed, 16 Oct 2024 11:14:44 GMT, Kevin Walls wrote:
> This test has been "skipping" since IIOP was removed (jdk 9). Should be
> removed, no impact.
This pull request has now been integrated.
Changeset: 8862ca07
Author:Kevin Walls
URL:
https://git.openjd
On Wed, 16 Oct 2024 11:14:44 GMT, Kevin Walls wrote:
> This test has been "skipping" since IIOP was removed (jdk 9). Should be
> removed, no impact.
Thanks for the reviews!
-
PR Comment: https://git.openjdk.org/jdk/pull/21534#issuecomment-2418837171
This test has been "skipping" since IIOP was removed (jdk 9). Should be
removed, no impact.
-
Commit messages:
- 8342338: Remove redundant IIOPURLTest.java
Changes: https://git.openjdk.org/jdk/pull/21534/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21534&range=00
Iss
On Tue, 17 Sep 2024 14:10:07 GMT, Kevin Walls wrote:
> DiagnosticCommandImpl should only publish parameter types in a known standard
> set, and use "STRING" on anything else.
> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but
> DiagnosticCommandImpl should only publish parameter types in a known standard
> set, and use "STRING" on anything else.
> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but
> the MBean parameter info should contain "STRING&q
On Thu, 10 Oct 2024 08:51:38 GMT, Kevin Walls wrote:
>> DiagnosticCommandImpl should only publish parameter types in a known
>> standard set, and use "STRING" on anything else.
>> e.g. We can say "FILE" in the help output for jcmd, as that's for huma
On Thu, 10 Oct 2024 08:51:38 GMT, Kevin Walls wrote:
>> DiagnosticCommandImpl should only publish parameter types in a known
>> standard set, and use "STRING" on anything else.
>> e.g. We can say "FILE" in the help output for jcmd, as that's for huma
> DiagnosticCommandImpl should only publish parameter types in a known standard
> set, and use "STRING" on anything else.
> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but
> the MBean parameter info should contain "STRING&q
On Wed, 9 Oct 2024 20:36:07 GMT, Chris Plummer wrote:
>> DiagnosticCommandImpl should only publish parameter types in a known
>> standard set, and use "STRING" on anything else.
>> e.g. We can say "FILE" in the help output for jcmd, as that's for humans,
>> but the MBean parameter info should c
On Tue, 17 Sep 2024 14:10:07 GMT, Kevin Walls wrote:
> DiagnosticCommandImpl should only publish parameter types in a known standard
> set, and use "STRING" on anything else.
> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but
On Tue, 17 Sep 2024 14:10:07 GMT, Kevin Walls wrote:
> DiagnosticCommandImpl should only publish parameter types in a known standard
> set, and use "STRING" on anything else.
> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but
DiagnosticCommandImpl should only publish parameter types in a known standard
set, and use "STRING" on anything else.
e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but
the MBean parameter info should contain "STRING".
-
Commit messages:
- Test update
-
On Fri, 13 Sep 2024 09:47:07 GMT, Kevin Walls wrote:
> JDP tests only make 3 attempts to find a free port, using getFreePort().
> We know getFreePort() is racy and you need to make sure the port really is
> fee when trying to use it.
>
> Make 10 attempts. Leave the logic uncha
On Fri, 13 Sep 2024 09:47:07 GMT, Kevin Walls wrote:
> JDP tests only make 3 attempts to find a free port, using getFreePort().
> We know getFreePort() is racy and you need to make sure the port really is
> fee when trying to use it.
>
> Make 10 attempts. Leave the logic uncha
JDP tests only make 3 attempts to find a free port, using getFreePort().
We know getFreePort() is racy and you need to make sure the port really is fee
when trying to use it.
Make 10 attempts. Leave the logic unchanged. Also fix a typo in another test.
-
Commit messages:
- 831052
On Tue, 10 Sep 2024 13:47:47 GMT, Kevin Walls wrote:
>> Remove very very old serialization compatibility logic from JMX.
>>
>> This relates to keeping the JDK's JMX implementation compatible with JMX
>> versions from when JMX was a separate component, before be
On Wed, 4 Sep 2024 16:27:51 GMT, Kevin Walls wrote:
> Remove very very old serialization compatibility logic from JMX.
>
> This relates to keeping the JDK's JMX implementation compatible with JMX
> versions from when JMX was a separate component, before being integrated i
On Tue, 10 Sep 2024 13:06:25 GMT, Kevin Walls wrote:
>> Remove very very old serialization compatibility logic from JMX.
>>
>> This relates to keeping the JDK's JMX implementation compatible with JMX
>> versions from when JMX was a separate component, before be
> Remove very very old serialization compatibility logic from JMX.
>
> This relates to keeping the JDK's JMX implementation compatible with JMX
> versions from when JMX was a separate component, before being integrated into
> JDK 5. It should all be removed.
Kevin Walls
> Remove very very old serialization compatibility logic from JMX.
>
> This relates to keeping the JDK's JMX implementation compatible with JMX
> versions from when JMX was a separate component, before being integrated into
> JDK 5. It should all be removed.
Kevin Walls
> Remove very very old serialization compatibility logic from JMX.
>
> This relates to keeping the JDK's JMX implementation compatible with JMX
> versions from when JMX was a separate component, before being integrated into
> JDK 5. It should all be removed.
Kevin Walls
On Thu, 5 Sep 2024 14:57:16 GMT, Daniel Fuchs wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test
>
> Wow. I hadn't realized so many classes were impacted. I thought there w
Remove very very old serialization compatibility logic from JMX.
This relates to keeping the JDK's JMX implementation compatible with JMX
versions from when JMX was a separate component, before being integrated into
JDK 5. It should all be removed.
-
Commit messages:
- whitespace
On Mon, 2 Sep 2024 15:52:27 GMT, Kevin Walls wrote:
> Trivial "since" tag addition in javadoc: since 1.6
Thanks Alan!
-
PR Comment: https://git.openjdk.org/jdk/pull/20823#issuecomment-2325836707
On Mon, 2 Sep 2024 15:52:27 GMT, Kevin Walls wrote:
> Trivial "since" tag addition in javadoc: since 1.6
This pull request has now been integrated.
Changeset: 288fa60e
Author: Kevin Walls
URL:
https://git.openjdk.org/jdk/commit/288fa60ebee445bb2835f096d144b9c6dea98df6
Trivial "since" tag addition in javadoc: since 1.6
-
Commit messages:
- 8338891: HotSpotDiagnosticsMXBean missing @since tag
Changes: https://git.openjdk.org/jdk/pull/20823/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20823&range=00
Issue: https://bugs.openjdk.org/brow
On Fri, 23 Aug 2024 08:49:38 GMT, Joakim Nordström
wrote:
>> Can I get a review of this documentation update to clarify the usage of
>> GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and
>> GetProcessCpuLoad.
>>
>> Calling either of these methods in quick succession can lead to
>> u
On Wed, 21 Aug 2024 11:35:26 GMT, Alan Bateman wrote:
>> src/jdk.management/share/classes/com/sun/management/OperatingSystemMXBean.java
>> line 142:
>>
>>> 140: * negative value.
>>> 141: *
>>> 142: * This method is not idempotent. The recent period of
>>> observation
>>
>> I
On Mon, 12 Aug 2024 12:33:04 GMT, Joakim Nordström
wrote:
> Can I get a review of this documentation update to clarify the usage of
> GetCpuLoad (and inherently deprecated GetSystemCpuLoad) and GetProcessCpuLoad.
>
> Calling either of these methods in quick succession can lead to
> unrepresen
On Fri, 5 Jul 2024 14:06:39 GMT, Kevin Walls wrote:
> The test
> test/jdk/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
> should be removed.
>
> This test was added when 6984520 was fixed in 6u25. It has been
> problemlisted since JDK-8267123 remo
On Fri, 5 Jul 2024 14:06:39 GMT, Kevin Walls wrote:
> The test
> test/jdk/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
> should be removed.
>
> This test was added when 6984520 was fixed in 6u25. It has been
> problemlisted since JDK-8267123 remo
On Thu, 11 Jul 2024 14:51:18 GMT, Kevin Walls wrote:
> Follow-on from JDK-8207908.
>
> Two tests are broken by that change:
> sun/management/jmxremote/startstop/JMXStartStopTest.java
> sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java
>
> These are a
On Thu, 11 Jul 2024 15:38:29 GMT, Kevin Walls wrote:
>> Follow-on from JDK-8207908.
>>
>> Two tests are broken by that change:
>> sun/management/jmxremote/startstop/JMXStartStopTest.java
>> sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java
>
On Thu, 11 Jul 2024 15:22:54 GMT, Chris Plummer wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> line
>
> test/jdk/sun/management/jmxremote/startstop/JMXStartSto
pattern to
> find a process.
> They should use the PID to avoid finding a process from some other concurrent
> test invocation.
> So it's good to have the same kind of change applied here too.
Kevin Walls has updated the pull request incrementally with one additional
c
Follow-on from JDK-8207908.
Two tests are broken by that change:
sun/management/jmxremote/startstop/JMXStartStopTest.java
sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java
These are additional tests which use jcmd and an application name pattern to
find a process.
They sh
On Thu, 4 Jul 2024 14:39:50 GMT, Kevin Walls wrote:
> Test failure, reproducible running batches of tests at the same time on the
> same machine.
> The use of "jcmd TestApp ..." gathers more output than the test wants and
> than its regexes can handle.
>
> Usi
On Thu, 4 Jul 2024 14:39:50 GMT, Kevin Walls wrote:
> Test failure, reproducible running batches of tests at the same time on the
> same machine.
> The use of "jcmd TestApp ..." gathers more output than the test wants and
> than its regexes can handle.
>
> Usi
On Wed, 3 Jul 2024 08:24:43 GMT, Kevin Walls wrote:
> Clean backport to jdk23 of a simple test update, to try and avoid spurious
> failures.
This pull request has now been integrated.
Changeset: 70ad622b
Author: Kevin Walls
URL:
https://git.openjdk.org/jdk/
On Thu, 27 Jun 2024 15:53:09 GMT, Kevin Walls wrote:
> Disable running this test with -Xcomp.
>
> The NPE seen in this test is due to a timeout establishing the connection.
> ServerCommunicatorAdmin hits its timeout, during an addNotificationListener
> call on a new connecti
On Fri, 28 Jun 2024 18:14:59 GMT, Kevin Walls wrote:
>> Disable running this test with -Xcomp.
>>
>> The NPE seen in this test is due to a timeout establishing the connection.
>> ServerCommunicatorAdmin hits its timeout, during an addNotificationListener
>
The test
test/jdk/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
should be removed.
This test was added when 6984520 was fixed in 6u25. It has been problemlisted
since JDK-8267123 removed RMI Activation (it does not use RMI Activation, it
just wanted something "RMI" to
Test failure, reproducible running batches of tests at the same time on the
same machine.
The use of "jcmd TestApp ..." gathers more output that the test wants.
Using the PID to match only the wanted process, my batches of 25 tests at the
same time run in parallel without failure.
-
Clean backport to jdk23 of a simple test update, to try and avoid spurious
failures.
-
Commit messages:
- Backport 79a3554e1da604627b3a010dc269c1bd914c79d3
Changes: https://git.openjdk.org/jdk/pull/1/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=1&range=00
Issu
On Thu, 27 Jun 2024 08:54:16 GMT, Kevin Walls wrote:
> This test has had occasional failures for years, possibly forever.
> A previous update made the test "othervm" which removed some interruptions,
> but a time accounting problem remains.
>
> This change adds a sim
On Fri, 28 Jun 2024 18:14:59 GMT, Kevin Walls wrote:
>> Disable running this test with -Xcomp.
>>
>> The NPE seen in this test is due to a timeout establishing the connection.
>> ServerCommunicatorAdmin hits its timeout, during an addNotificationListener
>
ilure is reproducible. There is no
> need to test this test with -Xcomp, we should exclude it as we do for various
> other tests.
Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision:
comment
-
Changes:
- all: https://git
On Thu, 27 Jun 2024 08:54:16 GMT, Kevin Walls wrote:
> This test has had occasional failures for years, possibly forever.
> A previous update made the test "othervm" which removed some interruptions,
> but a time accounting problem remains.
>
> This change adds a sim
Disable running this test with -Xcomp.
The NPE seen in this test is due to a timeout establishing the connection.
ServerCommunicatorAdmin hits its timeout, during an addNotificationListener
call on a new connection.
-Xcomp causes this slowdown and the failure is reproducible. There is no need
This test has had occasional failures for years, possibly forever.
A previous update made the test "othervm" which removed some interruptions, but
a time accounting problem remains.
This change adds a simple sleep after observing that the test threads are all
sleeping.
The idea is that threads
On Thu, 27 Jun 2024 08:54:16 GMT, Kevin Walls wrote:
> This test has had occasional failures for years, possibly forever.
> A previous update made the test "othervm" which removed some interruptions,
> but a time accounting problem remains.
>
> This change adds a sim
On Thu, 20 Jun 2024 15:24:35 GMT, Kevin Walls wrote:
> 844: JMX attaching of Subject does not work when security manager not
> allowed
This pull request has now been integrated.
Changeset: 23f2c97f
Author: Kevin Walls
URL:
https://git.openjdk.org/jdk/
On Thu, 20 Jun 2024 15:24:35 GMT, Kevin Walls wrote:
> 844: JMX attaching of Subject does not work when security manager not
> allowed
Thanks Daniel. Testing automated and manual looks good in 24 and in this 23
backport, so I'll get this integrated.
-
PR Com
844: JMX attaching of Subject does not work when security manager not
allowed
-
Commit messages:
- Backport bcf4bb4882e06d8c52f6eb4e9c4e027ba0622c5f
Changes: https://git.openjdk.org/jdk/pull/19810/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19810&range=00
Issue:
On Tue, 18 Jun 2024 12:17:46 GMT, Kevin Walls wrote:
>> JMX uses APIs related to the Security Mananger which are deprecated. Use of
>> AccessControlContext will be removed when Security Manager is removed.
>>
>> Until then, updates are neede
On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls wrote:
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
> -Djava.s
On Wed, 19 Jun 2024 11:21:45 GMT, Daniel Fuchs wrote:
> The code changes look good to me (if a bit verbose) and the test changes look
> reasonable. It could be beneficial to add some more tests in the future
> involving monitoring and getting the subject from within a monitored MBean.
Yes, agr
On Tue, 18 Jun 2024 11:33:51 GMT, Daniel Fuchs wrote:
>> Agree with Kevin. To minimize risk, especially since this is to fix a
>> significant regression and we are in RDP1, we are really trying to preserve
>> the existing code as much as possible, even though it could be improved.
>
> It is als
On Mon, 17 Jun 2024 20:51:34 GMT, Kevin Walls wrote:
>> JMX uses APIs related to the Security Mananger which are deprecated. Use of
>> AccessControlContext will be removed when Security Manager is removed.
>>
>> Until then, updates are neede
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
> -Djava.security.manager=allow to use JMX authentication.
Kevin Wa
On Mon, 17 Jun 2024 20:51:34 GMT, Kevin Walls wrote:
>> JMX uses APIs related to the Security Mananger which are deprecated. Use of
>> AccessControlContext will be removed when Security Manager is removed.
>>
>> Until then, updates are neede
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
> -Djava.security.manager=allow to use JMX authentication.
Kevin Wa
On Mon, 17 Jun 2024 13:58:11 GMT, Daniel Fuchs wrote:
>> Kevin Walls has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - style update
>> - whitespace
>
> src/java.management.rmi/share
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
> -Djava.security.manager=allow to use JMX authentication.
Kevin Wa
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
> -Djava.security.manager=allow to use JMX authentication.
Kevin Wa
On Mon, 17 Jun 2024 12:33:08 GMT, Weijun Wang wrote:
>> Kevin Walls has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - leave noPermissionsACC in place for now
>> - leave noPermissionsACC in place for n
On Mon, 17 Jun 2024 12:33:47 GMT, Weijun Wang wrote:
>> Kevin Walls has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - leave noPermissionsACC in place for now
>> - leave noPermissionsACC in place for now
On Fri, 14 Jun 2024 14:48:14 GMT, Weijun Wang wrote:
> > Does noPermissionsACC add anything?
>
> I don't know. My principal for this code change is that nothing is changed
> for the SM-is-allowed case.
I've put back the noPermissionsACC for this change, it does not have to be
removed in this
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
> -Djava.security.manager=allow to use JMX authentication.
Kevin Wa
On Sun, 16 Jun 2024 01:54:34 GMT, Weijun Wang wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Unnecessary catches to remove
>
> src/java.management/share/classes/javax/management/mon
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
> -Djava.security.manager=allow to use JMX authentication.
Kevin Wa
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
> -Djava.security.manager=allow to use JMX authentication.
Kevin Wa
On Fri, 14 Jun 2024 14:51:53 GMT, Weijun Wang wrote:
>> It needs to recognise and throw RuntimeException so that a SecurityException
>> isn't wrapped in a PrivilegedActionException (which gets caught by those
>> blocks of code which call extractException(pe) and look at what Exception
>> it c
On Fri, 14 Jun 2024 12:03:07 GMT, Weijun Wang wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Separate SM allowed and not allowed cases
>
> src/java.management.rmi/share/class
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
> -Djava.security.manager=allow to use JMX authentication.
Kevin Wa
On Wed, 12 Jun 2024 20:52:51 GMT, Sean Mullan wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>>Undo test policy updates
>
> src/java.management/share/classes/javax/management/mon
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
> -Djava.security.manager=allow to use JMX authentication.
Kevin Wa
On Fri, 14 Jun 2024 12:44:17 GMT, Kevin Walls wrote:
>> src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java
>> line 353:
>>
>>> 351: } else {
>>> 352: return Subject.getSubject(Acc
On Fri, 14 Jun 2024 12:04:06 GMT, Weijun Wang wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Separate SM allowed and not allowed cases
>
> src/java.management/share/class
On Fri, 14 Jun 2024 12:09:46 GMT, Weijun Wang wrote:
> I don't quite understand why there is no more `noPermissionsACC` in
> `Monotor.java`. This looks like the only behavior change when SM is allowed.
> The other source change looks fine to me.
Does noPermissionsACC add anything? Maybe I'm r
On Wed, 12 Jun 2024 21:03:17 GMT, Sean Mullan wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>>Undo test policy updates
>
> src/java.management.rmi/share/classes/javax/management/rem
On Tue, 11 Jun 2024 19:01:45 GMT, Weijun Wang wrote:
>> Thanks I'll go through the above comments and update - some of the changes I
>> see are unnecessary and from when I was trying migrating to callAs, and
>> doPrivileged, and yes they can be simpler.
>>
>> On the allowSecurityMananger check
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
> -Djava.security.manager=allow to use JMX authentication.
Kevin Wa
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
> -Djava.security.manager=allow to use JMX authentication.
Kevin Wa
On Wed, 12 Jun 2024 16:41:36 GMT, Daniel Fuchs wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>>Undo test policy updates
>
> src/java.management.rmi/share/classes/javax/management/rem
> JMX uses APIs related to the Security Mananger which are deprecated. Use of
> AccessControlContext will be removed when Security Manager is removed.
>
> Until then, updates are needed to not require setting
> -Djava.security.manager=allow to use JMX authentication.
Kevin Wa
On Wed, 12 Jun 2024 20:42:27 GMT, Sean Mullan wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>>Undo test policy updates
>
> src/java.management/share/class
1 - 100 of 346 matches
Mail list logo
