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 directory. Create files there, with
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 being integrated
>> into JDK 5. It
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 being integrated
>> into JDK 5. It
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 being integrated
>> into JDK 5. It
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 being integrated
>> into JDK 5. It
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 being integrated
>> into JDK 5. It
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 being integrated
>> into JDK 5. It
On Thu, 5 Sep 2024 17:03:37 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
>> into JDK 5. It
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 into
> JDK 5. It shoul
On Wed, 21 Aug 2024 13:42:18 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 Thu, 20 Jun 2024 15:24:35 GMT, Kevin Walls wrote:
> 844: JMX attaching of Subject does not work when security manager not
> allowed
LGTM
-
Marked as reviewed by dfuchs (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19810#pullrequestreview-2132226211
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 needed to not require setting
>> -Djava.security.manager
On Mon, 17 Jun 2024 20:27:05 GMT, Sean Mullan wrote:
>> Hi,
>> We almost always check
>> !SharedSecrets.getJavaLangAccess().allowSecurityManager() (except in the
>> RMIConnectionImpl contstructor)
>>
>> This keeps the "modern" case first (except in that constructor, where it is
>> only one li
On Mon, 17 Jun 2024 12:54:44 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.security.manager
On Fri, 14 Jun 2024 15:26:54 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.security.manager
On Wed, 12 Jun 2024 16:11: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.security.manager
On Wed, 12 Jun 2024 14:44:56 GMT, Kevin Walls wrote:
>> I think Daniel is right, can you remove this permission and paste in the
>> debug output to see where this is happening?
>
> Hmm I may have fixed that since changing the policy files, as I'm not seeing
> the problem without that AuthPermis
On Wed, 12 Jun 2024 14:01:40 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.security.manager
On Thu, 16 May 2024 20:17:18 GMT, Kevin Walls wrote:
>> Running JConsole from a previous JDK, and attaching to jdk-23 (after
>> [JDK-832](https://bugs.openjdk.org/browse/JDK-832): Remove the Java
>> Management Extension (JMX) Subject Delegation feature), the MBean tab is
>> blank.
>>
On Thu, 16 May 2024 10:37:36 GMT, Kevin Walls wrote:
>> This shows that when SubjectDelegation was not used, a null-filled array of
>> the same length as the two other arrays was expected before (in previous
>> versions of the JDK where SubjectDelegation was supported, but in the case
>> where
On Thu, 16 May 2024 10:16:58 GMT, Kevin Walls wrote:
>> Well my thinking was this: the fact that the jconsole tab was blank shows
>> that the array may being passed. The previous code verified that all three
>> arrays had the same length - so it would have failed if the array had a
>> length d
On Wed, 15 May 2024 20:02:26 GMT, Kevin Walls wrote:
>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
>> line 984:
>>
>>> 982: }
>>> 983: if (names.length != filters.length) {
>>> 984: final String msg = "The lengths of name
On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls wrote:
> Running JConsole from a previous JDK, and attaching to jdk-23 (after
> [JDK-832](https://bugs.openjdk.org/browse/JDK-832): Remove the Java
> Management Extension (JMX) Subject Delegation feature), the MBean tab is
> blank.
>
> In
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Mon, 25 Mar 2024 22:46:47 GMT, Kevin Walls wrote:
>> Test uses jdk.test.lib.Utils.getFreePort() when launching a new Java
>> command.
>> Looks like it already recognises "java.rmi.server.ExportException: Port
>> already in use: " and retries, but there is a long-standing typo in the
>> che
On Thu, 14 Mar 2024 21:44:52 GMT, Kevin Walls wrote:
>> The deprecated Subject Delegation feature in JMX will be removed.
>>
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional
> commit since the la
On Thu, 14 Mar 2024 11:53:11 GMT, Kevin Walls wrote:
>> The deprecated Subject Delegation feature in JMX will be removed.
>>
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with two additional
> commits since the l
On Mon, 11 Mar 2024 18:39:38 GMT, Daniel Fuchs wrote:
>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java
>> line 126:
>>
>>> 124: * @param className The class name of the MBean to be instantiated.
>>> 125:
On Mon, 11 Mar 2024 17:56:50 GMT, Mandy Chung wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> (C) oops
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java
> line 126:
>
>> 124:
On Mon, 11 Mar 2024 10:09:28 GMT, Kevin Walls wrote:
>> The deprecated Subject Delegation feature in JMX will be removed.
>>
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional
> commit since the la
On Fri, 8 Mar 2024 10:20:36 GMT, Kevin Walls wrote:
> Is there any value in keeping `SubjectDelegationPermission` after this
> change? If so, I would mark that API deprecated for removal, so that it can
> be removed in the next release or two.
No issue with deprecation. I guess it can be remov
On Tue, 5 Mar 2024 19:53:46 GMT, Weijun Wang wrote:
>> Subject is stored in the RMIConnectionImpl:
>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
>>
>> (That is complicated by SubjectDelegation, which we deprecated for removal.
>> I have the PR out
On Mon, 4 Mar 2024 13:24:05 GMT, Kevin Walls wrote:
>> The deprecated Subject Delegation feature in JMX will be removed.
>>
>> This was marked in JDK 21 as deprecated for removal (JDK-8298966).
>
> Kevin Walls has updated the pull request incrementally with one additional
> commit since the las
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don't get spurious
> trailin
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don't get spurious
> trailin
On Tue, 30 Jan 2024 13:53:37 GMT, Daniel Fuchs wrote:
>> This code change adds an alternative implementation of user-based
>> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
>> Depending on if the Security Manager is allowed, the methods store
On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang wrote:
> This code change adds an alternative implementation of user-based
> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
> Depending on if the Security Manager is allowed, the methods store the
> current subject diffe
On Wed, 17 Jan 2024 23:41:53 GMT, Weijun Wang wrote:
> This code change adds an alternative implementation of user-based
> authorization `Subject` APIs that doesn't depend on Security Manager APIs.
> Depending on if the Security Manager is allowed, the methods store the
> current subject diffe
On Thu, 11 Jan 2024 20:59:05 GMT, Kevin Walls wrote:
>> Remove the MLet feature and its tests.
>>
>> Some tests use MLet classes but are not testing MLets. These are updated,
>> to use another test MBean or an MBean which is a URLClassLoader, e.g.
>> test/jdk/javax/management/MBeanServer/PostE
On Thu, 11 Jan 2024 11:31:07 GMT, Kevin Walls wrote:
>> Yes, that's the whole point of the test. Without using an MBean which is a
>> ClassLoader the fix cannot be tested.
>> 1. you need to create an MBean which is an URLClassLoader, and it needs to
>> be a PrivateClassLoader so that it's not a
On Wed, 10 Jan 2024 16:50:22 GMT, Kevin Walls wrote:
>> My thinking is that this tests for a leak when an MBean is created using a
>> ClassLoader which is also an MBean. MLet was such a ready-to-use
>> ClassLoader. We no longer have MLets, but it's still possible to register an
>> MBean that i
On Wed, 10 Jan 2024 15:15:36 GMT, Kevin Walls wrote:
>> test/jdk/javax/management/Introspector/ClassLeakTest.java line 55:
>>
>>> 53: ObjectName testName = new ObjectName("x:name=Test");
>>> 54: Test mbean = new Test();
>>> 55: mbs.registerMBean(mbean, testName);
>>
>> I
On Thu, 4 Jan 2024 10:48:38 GMT, Kevin Walls wrote:
>> Remove the MLet feature and its tests.
>>
>> Some tests use MLet classes but are not testing MLets. These are updated,
>> to use another test MBean or an MBean which is a URLClassLoader, e.g.
>> test/jdk/javax/management/MBeanServer/PostEx
On Mon, 11 Dec 2023 12:50:38 GMT, Kevin Walls wrote:
> Tidyup change, looks like this field was not removed when IIOP was removed
> from RMIConnector.
>
> The field is not required for interoperability:
> with the field removed, I can still connect an older JMX client to a running
> app with
On Tue, 28 Nov 2023 16:21:29 GMT, Kevin Walls wrote:
> JMX RMI Connections should use a timeout on the Socket connect call by
> default.
>
> JMX Connections use RMI and some connection failures never terminate. The
> hang described in 8316649 is hard to reproduce manually: the description says
On Mon, 6 Nov 2023 06:55:21 GMT, Jaikiran Pai wrote:
> Can I please get a review of this PR which fixes the typos in the method
> javadocs of com.sun.management.OperatingSystemMXBean?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8319465, this PR replaces the
> word "betweens" by "betwe
On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson wrote:
> There are a number of files in the `test` directory that have an incorrect
> copyright header, which includes the "classpath" exception text. This patch
> removes that text from all test files that I could find it in. I did this
> using a
On Tue, 2 May 2023 17:57:14 GMT, Kevin Walls wrote:
> Removal of class, looks like it was missed in the JDK9 removal of RMIIIOP.
> This class is not referenced by other classes or tests.
Marked as reviewed by dfuchs (Reviewer).
Looks good to me. I probably wouldn't have bothered with removing t
On Fri, 3 Mar 2023 11:46:49 GMT, Kevin Walls wrote:
>> Deprecate the Java Management Extension (JMX) Subject Delegation feature for
>> removal in a future release.
>>
>> Given no known usage, there is no replacement feature for JMX Subject
>> Delegation.
>>
>> CSR is https://bugs.openjdk.org/
On Wed, 18 Jan 2023 17:56:43 GMT, Kevin Walls wrote:
>> The default setting for the ObjectInputFilter for JMX, introduced in jdk20,
>> is too restrictive.
>> javax.management.Attribute and AttributeList classes are also needed, and
>> Query related classes.
>>
>> There are a number of Query-re
On Wed, 11 Jan 2023 09:40:11 GMT, Kevin Walls wrote:
> The default setting for the ObjectInputFilter for JMX, introduced in jdk20,
> is too restrictive.
> javax.management.Attribute and AttributeList classes are also needed, and
> Query related classes.
>
> There are a number of Query-relate c
On Wed, 30 Nov 2022 20:37:38 GMT, Kevin Walls wrote:
>> Deprecate the Java Management Extension (JMX) Management Applet (m-let)
>> feature for removal.
>>
>> This deprecation will have no impact on users of other JMX features, the
>> JDK's built-in instrumentation, or any of the observability
On Wed, 30 Nov 2022 17:02:45 GMT, Kevin Walls wrote:
>> Deprecate the Java Management Extension (JMX) Management Applet (m-let)
>> feature for removal.
>>
>> This deprecation will have no impact on users of other JMX features, the
>> JDK's built-in instrumentation, or any of the observability
On Wed, 30 Nov 2022 14:24:36 GMT, Kevin Walls wrote:
> MLetObjectInputStream and MLetParser are not public classes, so thinking they
> are not part of the public API we need to deprecate before removal.
Whether a class is public exported or not has no real relationship with whether
it should h
On Wed, 30 Nov 2022 12:08:22 GMT, Kevin Walls wrote:
> Deprecate the Java Management Extension (JMX) Management Applet (m-let)
> feature for removal.
>
> This deprecation will have no impact on users of other JMX features, the
> JDK's built-in instrumentation, or any of the observability tools
On Mon, 14 Nov 2022 19:04:49 GMT, Pavel Rappo wrote:
> Please review this trivial documentation change that fixes a typo
> accidentally found while comparing javadoc output for an unrelated change in
> jdk.javadoc.
Marked as reviewed by dfuchs (Reviewer).
-
PR: https://git.openjd
On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote:
>> Properties files is essentially source code. It should have the same
>> whitespace checks as all other source code, so we don't get spurious
>> trailing whitespace changes.
>>
>> With the new Skara jcheck, it is possible to increas
On Fri, 21 Oct 2022 09:59:15 GMT, Kevin Walls wrote:
>> src/jdk.management.agent/share/conf/management.properties line 306:
>>
>>> 304: # Otherwise, the status is UNDECIDED.
>>> 305:
>>> com.sun.management.jmxremote.serial.filter.pattern=java.lang.*;java.math.BigInteger;java.math.BigDecimal;j
On Wed, 19 Oct 2022 17:54:02 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.
>> Serializ
On Wed, 19 Oct 2022 17:54:02 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.
>> Serializ
On Wed, 19 Oct 2022 16:14:16 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.
>> Serializ
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
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
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
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 in
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
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 f
On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeliński wrote:
>> This patch removes many unused variables and one unused label reported by
>> the compilers when relevant warnings are enabled.
>>
>> The unused code was found by compiling after removing `unused` from the list
>> of disabled warnings
68 matches
Mail list logo
