From jmatsuoka at openjdk.org Wed May 1 17:14:06 2024 From: jmatsuoka at openjdk.org (Joshua Matsuoka) Date: Wed, 1 May 2024 17:14:06 GMT Subject: RFR: 7948: Update ASM to 9.7 so the agent can build and run with JDK17 Message-ID: Addresses JMC-7948 (Update ASM version in the agent). The agent currently uses a very old version of ASM that doesn't support more recent JDK versions (most notably JDK17). This PR bumps the ASM version up to 9.7 which was released in March and supports up to JDK23. It also bumps the agent build up to JDK17. ------------- Commit messages: - Update ASM to 9.7 so the agent can build and run with JDK17 Changes: https://git.openjdk.org/jmc/pull/561/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=561&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7948 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jmc/pull/561.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/561/head:pull/561 PR: https://git.openjdk.org/jmc/pull/561 From jmatsuoka at openjdk.org Wed May 1 17:43:27 2024 From: jmatsuoka at openjdk.org (Joshua Matsuoka) Date: Wed, 1 May 2024 17:43:27 GMT Subject: RFR: 7948: Update ASM to 9.7 so the agent can build and run with JDK17 [v2] In-Reply-To: References: Message-ID: > Addresses JMC-7948 (Update ASM version in the agent). > > The agent currently uses a very old version of ASM that doesn't support more recent JDK versions (most notably JDK17). > > This PR bumps the ASM version up to 9.7 which was released in March and supports up to JDK23. It also bumps the agent build up to JDK17. Joshua Matsuoka has updated the pull request incrementally with one additional commit since the last revision: Bump copyright year ------------- Changes: - all: https://git.openjdk.org/jmc/pull/561/files - new: https://git.openjdk.org/jmc/pull/561/files/f77c6f02..17e8d0f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=561&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=561&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/561.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/561/head:pull/561 PR: https://git.openjdk.org/jmc/pull/561 From aptmac at openjdk.org Wed May 1 18:59:58 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Wed, 1 May 2024 18:59:58 GMT Subject: RFR: 7948: Update ASM to 9.7 so the agent can build and run with JDK17 [v2] In-Reply-To: References: Message-ID: On Wed, 1 May 2024 17:43:27 GMT, Joshua Matsuoka wrote: >> Addresses JMC-7948 (Update ASM version in the agent). >> >> The agent currently uses a very old version of ASM that doesn't support more recent JDK versions (most notably JDK17). >> >> This PR bumps the ASM version up to 9.7 which was released in March and supports up to JDK23. It also bumps the agent build up to JDK17. > > Joshua Matsuoka has updated the pull request incrementally with one additional commit since the last revision: > > Bump copyright year Was trying to figure out why the check license script wasn't happy, turns out there's also a license in the actual pom here at: https://github.com/openjdk/jmc/blob/master/agent/pom.xml#L52 So the script is happy with the license header, but upset at the licenses information. I feel like this should probably updated too, now that there are new changes to bring it up to 2024. It looks like you'll either need to update the jira issue title to be the same as this PR, or visa-versa; there's a mismatch. Otherwise this looks good to go. ------------- PR Comment: https://git.openjdk.org/jmc/pull/561#issuecomment-2088926250 From jmatsuoka at openjdk.org Wed May 1 21:18:11 2024 From: jmatsuoka at openjdk.org (Joshua Matsuoka) Date: Wed, 1 May 2024 21:18:11 GMT Subject: RFR: 7948: Update ASM version in the Agent [v3] In-Reply-To: References: Message-ID: > Addresses JMC-7948 (Update ASM version in the agent). > > The agent currently uses a very old version of ASM that doesn't support more recent JDK versions (most notably JDK17). > > This PR bumps the ASM version up to 9.7 which was released in March and supports up to JDK23. It also bumps the agent build up to JDK17. Joshua Matsuoka has updated the pull request incrementally with one additional commit since the last revision: Fix copyright in the pom ------------- Changes: - all: https://git.openjdk.org/jmc/pull/561/files - new: https://git.openjdk.org/jmc/pull/561/files/17e8d0f6..37f96aec Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=561&range=02 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=561&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/561.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/561/head:pull/561 PR: https://git.openjdk.org/jmc/pull/561 From aptmac at openjdk.org Thu May 2 01:43:59 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 2 May 2024 01:43:59 GMT Subject: RFR: 7948: Update ASM version in the Agent [v3] In-Reply-To: References: Message-ID: On Wed, 1 May 2024 21:18:11 GMT, Joshua Matsuoka wrote: >> Addresses JMC-7948 (Update ASM version in the agent). >> >> The agent currently uses a very old version of ASM that doesn't support more recent JDK versions (most notably JDK17). >> >> This PR bumps the ASM version up to 9.7 which was released in March and supports up to JDK23. It also bumps the agent build up to JDK17. > > Joshua Matsuoka has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright in the pom Marked as reviewed by aptmac (Reviewer). ------------- PR Review: https://git.openjdk.org/jmc/pull/561#pullrequestreview-2034687365 From clanger at openjdk.org Thu May 2 08:47:59 2024 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 2 May 2024 08:47:59 GMT Subject: RFR: 7948: Update ASM version in the Agent [v3] In-Reply-To: References: Message-ID: On Wed, 1 May 2024 21:18:11 GMT, Joshua Matsuoka wrote: >> Addresses JMC-7948 (Update ASM version in the agent). >> >> The agent currently uses a very old version of ASM that doesn't support more recent JDK versions (most notably JDK17). >> >> This PR bumps the ASM version up to 9.7 which was released in March and supports up to JDK23. It also bumps the agent build up to JDK17. > > Joshua Matsuoka has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright in the pom Marked as reviewed by clanger (Reviewer). ------------- PR Review: https://git.openjdk.org/jmc/pull/561#pullrequestreview-2035168728 From jmatsuoka at openjdk.org Thu May 2 14:21:06 2024 From: jmatsuoka at openjdk.org (Joshua Matsuoka) Date: Thu, 2 May 2024 14:21:06 GMT Subject: Integrated: 7948: Update ASM version in the Agent In-Reply-To: References: Message-ID: On Wed, 1 May 2024 17:10:58 GMT, Joshua Matsuoka wrote: > Addresses JMC-7948 (Update ASM version in the agent). > > The agent currently uses a very old version of ASM that doesn't support more recent JDK versions (most notably JDK17). > > This PR bumps the ASM version up to 9.7 which was released in March and supports up to JDK23. It also bumps the agent build up to JDK17. This pull request has now been integrated. Changeset: 57e386ad Author: Joshua Matsuoka URL: https://git.openjdk.org/jmc/commit/57e386adb82b81d228a5f5ab114ef02c28cc8930 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod 7948: Update ASM version in the Agent Reviewed-by: aptmac, clanger ------------- PR: https://git.openjdk.org/jmc/pull/561 From aptmac at openjdk.org Thu May 2 18:20:15 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 2 May 2024 18:20:15 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v12] In-Reply-To: References: Message-ID: On Thu, 2 May 2024 18:17:29 GMT, Martin Skarsaune wrote: >> Replaces parts of https://github.com/openjdk/jmc/pull/332 > > Martin Skarsaune has updated the pull request incrementally with 10 additional commits since the last revision: > > - JMC-7455: Updated copyright in coverage pom.xml > - JMC-7455: Added jolokia to coverage > - JMC-7455: Remove mess of jolokia versions in pom files > - JMC-7455: Upgrade to latest jolokia (and give up on JVM discovery for now) > - JMC-7455: Fix for linux. Handle invoke with no parameters > - JMC-7455: Work around another Jolokia exception observed from MBean console in Linux > - JMC-7455: Work around Jolokia issues seen from MBean console > - JMC-7455: Review: restriction warning > - JMC-7455: Fixes for review comments, copyright notices and other improvements > - JMC-7455: Fix Eclipse warning Overall this is looking nice. The tests pass and I was able to connect over Jolokia to the test jvm and verify that the mbean browser & recordings work as expected. To test I added this to the test class: diff --git a/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java b/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java index 7b65e835..a245f4b1 100644 --- a/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java +++ b/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java @@ -81,7 +81,11 @@ public class JolokiaTest { Awaitility.await().atMost(Duration.ofSeconds(15))//Note: hard code property to avoid module dependency on agent .until(() -> (jolokiaUrl = System.getProperty("jolokia.agent")) != null); jolokiaConnection = getJolokiaMBeanConnector(); - + try { + Thread.sleep(500000000); + } catch (Exception e) { + // do nothing, let's take a look at the jolokia .. + } } @Test and then added a new connection and connected using the custom jmx service url. What is your current plans for this PR? Did you want to try and get the JVM Discovery working before turning it from draft to ready for review? Or is the current functionality what you're currently hoping to have integrated? application/tests/org.openjdk.jmc.jolokia.test/pom.xml line 51: > 49: > 50: > 51: Tried running the tests but was missing this dependency. The root pom has `jolokia.version` as 1.7.2, and the releng/third-party pom has it as 2.0.2, did you mean to mix the two versions? diff --git a/application/tests/org.openjdk.jmc.jolokia.test/pom.xml b/application/tests/org.openjdk.jmc.jolokia.test/pom.xml index 79fc76f4..f46397fa 100644 --- a/application/tests/org.openjdk.jmc.jolokia.test/pom.xml +++ b/application/tests/org.openjdk.jmc.jolokia.test/pom.xml @@ -54,6 +54,11 @@ awaitility 4.0.0 + + org.jolokia + jolokia-jvm + ${jolokia.version} + ------------- PR Review: https://git.openjdk.org/jmc/pull/548#pullrequestreview-2029352280 PR Review Comment: https://git.openjdk.org/jmc/pull/548#discussion_r1583593940 From aptmac at openjdk.org Thu May 2 18:20:16 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 2 May 2024 18:20:16 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v8] In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 21:05:21 GMT, Alex Macdonald wrote: >> Update 2: So https://github.com/openjdk/jmc/blob/master/application/org.openjdk.jmc.rjmx.ext/META-INF/services/javax.management.remote.JMXConnectorProvider is not detected by `javax.management.remote.JMXConnectorFactory`' s classloader. >> I also tried to use `org.openjdk.jmc.rjmx.common.internal.RJMXConnection` 's classloader, but that no longer works as the `.ext` module is not visible from `rjmx.common` (?). >> >> Map envCopy = new HashMap<>(env); >> envCopy.put(JMXConnectorFactory.PROTOCOL_PROVIDER_CLASS_LOADER, this.getClass().getClassLoader()); >> >> >> >> Bottom line seems to me that the JMX protocol extension mechanism no longer works in JMC 9 (?) > >> Update 2: So https://github.com/openjdk/jmc/blob/master/application/org.openjdk.jmc.rjmx.ext/META-INF/services/javax.management.remote.JMXConnectorProvider is not detected by `javax.management.remote.JMXConnectorFactory`' s classloader. I also tried to use `org.openjdk.jmc.rjmx.common.internal.RJMXConnection` 's classloader, but that no longer works as the `.ext` module is not visible from `rjmx.common` (?). >> >> ``` >> Map envCopy = new HashMap<>(env); >> envCopy.put(JMXConnectorFactory.PROTOCOL_PROVIDER_CLASS_LOADER, this.getClass().getClassLoader()); >> ``` >> >> Bottom line seems to me that the JMX protocol extension mechanism no longer works in JMC 9 (?) > > Hi! What you mentioned about how the `.ext` module is not visible from common is what I think the issue here is. When bringing over the bulk of the rjmx code from jmc/application to jmc/core one of the problems I faced was how to get the Services loaded by the core-side code if they are only visible in jmc/application. For the rjmx services, I came up with an initializer class [[0]](https://github.com/openjdk/jmc/blob/master/application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/internal/ServiceFactoryInitializer.java#L49) that looks at the `rjmx.service` extension and adds them to a List to be consumed by `ServerHandle` when creating a `ConnectionHandle`. This way the services can be passed from jmc/application into jmc/core through the ConnectionHandle. > > Unfortunately it looks like I only considered the case of the rjmx.service extension, and not rjmx.ext. I think the `ServiceFactoryInitializer` is probably the best place to start looking to fix this, and making sure it can also handle the other valid extension points. > > Edit: I've opened a bug for this on the JMC jira: https://bugs.openjdk.org/browse/JMC-8178 > > [0] https://github.com/openjdk/jmc/blob/master/application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/internal/ServiceFactoryInitializer.java#L49 > @aptmac : I believe I have addressed all comments so far, apart from enabling coverage test (next on my list). Status: Test connection ? Do flight recording ? Open JMX console ? - here I only get a spinner. I have tried to debug, but I'm struggling a bit with my debug setup Nice! I gave this a bit of a look and something interesting is going on but I can't tell just what yet. If I'm running the built application and connecting to jolokia I can confirm that JFR looks to be working correctly, and that the JMX Console pages are working. But, if I'm running it through Eclipse using our run configurations then the JMX Console pages are all blank (and this is true for any JVM and not just the one with jolokia attached to it). At the moment it's not obvious to me what's happening, the ConsoleEditor is running through the code okay to create the pages but for some reason nothing is showing up. I'll poke around a bit more when I can find some time. ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-1988772063 From duke at openjdk.org Thu May 2 18:20:16 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Thu, 2 May 2024 18:20:16 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v8] In-Reply-To: References: Message-ID: <2MX04WuSZp0WYAviDtTa5mIaks9kNyzCJhpJqI4Yq0U=.7f0ce463-df45-435c-8ecb-f4f184c8a73a@github.com> On Tue, 6 Feb 2024 21:05:21 GMT, Alex Macdonald wrote: >> Update 2: So https://github.com/openjdk/jmc/blob/master/application/org.openjdk.jmc.rjmx.ext/META-INF/services/javax.management.remote.JMXConnectorProvider is not detected by `javax.management.remote.JMXConnectorFactory`' s classloader. >> I also tried to use `org.openjdk.jmc.rjmx.common.internal.RJMXConnection` 's classloader, but that no longer works as the `.ext` module is not visible from `rjmx.common` (?). >> >> Map envCopy = new HashMap<>(env); >> envCopy.put(JMXConnectorFactory.PROTOCOL_PROVIDER_CLASS_LOADER, this.getClass().getClassLoader()); >> >> >> >> Bottom line seems to me that the JMX protocol extension mechanism no longer works in JMC 9 (?) > >> Update 2: So https://github.com/openjdk/jmc/blob/master/application/org.openjdk.jmc.rjmx.ext/META-INF/services/javax.management.remote.JMXConnectorProvider is not detected by `javax.management.remote.JMXConnectorFactory`' s classloader. I also tried to use `org.openjdk.jmc.rjmx.common.internal.RJMXConnection` 's classloader, but that no longer works as the `.ext` module is not visible from `rjmx.common` (?). >> >> ``` >> Map envCopy = new HashMap<>(env); >> envCopy.put(JMXConnectorFactory.PROTOCOL_PROVIDER_CLASS_LOADER, this.getClass().getClassLoader()); >> ``` >> >> Bottom line seems to me that the JMX protocol extension mechanism no longer works in JMC 9 (?) > > Hi! What you mentioned about how the `.ext` module is not visible from common is what I think the issue here is. When bringing over the bulk of the rjmx code from jmc/application to jmc/core one of the problems I faced was how to get the Services loaded by the core-side code if they are only visible in jmc/application. For the rjmx services, I came up with an initializer class [[0]](https://github.com/openjdk/jmc/blob/master/application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/internal/ServiceFactoryInitializer.java#L49) that looks at the `rjmx.service` extension and adds them to a List to be consumed by `ServerHandle` when creating a `ConnectionHandle`. This way the services can be passed from jmc/application into jmc/core through the ConnectionHandle. > > Unfortunately it looks like I only considered the case of the rjmx.service extension, and not rjmx.ext. I think the `ServiceFactoryInitializer` is probably the best place to start looking to fix this, and making sure it can also handle the other valid extension points. > > Edit: I've opened a bug for this on the JMC jira: https://bugs.openjdk.org/browse/JMC-8178 > > [0] https://github.com/openjdk/jmc/blob/master/application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/internal/ServiceFactoryInitializer.java#L49 @aptmac : I believe I have addressed all comments so far, apart from enabling coverage test (next on my list). Status: Test connection ? Do flight recording ? Open JMX console ? - here I only get a spinner. I have tried to debug, but I'm struggling a bit with my debug setup ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-1986831677 From aptmac at openjdk.org Thu May 2 18:20:16 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 2 May 2024 18:20:16 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v8] In-Reply-To: References: Message-ID: On Mon, 11 Mar 2024 15:52:18 GMT, Alex Macdonald wrote: > > @aptmac : I believe I have addressed all comments so far, apart from enabling coverage test (next on my list). Status: Test connection ? Do flight recording ? Open JMX console ? - here I only get a spinner. I have tried to debug, but I'm struggling a bit with my debug setup > > Nice! I gave this a bit of a look and something interesting is going on but I can't tell just what yet. If I'm running the built application and connecting to jolokia I can confirm that JFR looks to be working correctly, and that the JMX Console pages are working. > > But, if I'm running it through Eclipse using our run configurations then the JMX Console pages are all blank (and this is true for any JVM and not just the one with jolokia attached to it). At the moment it's not obvious to me what's happening, the ConsoleEditor is running through the code okay to create the pages but for some reason nothing is showing up. I'll poke around a bit more when I can find some time. I think this may end up being due to the Eclipse 2023-12 update..? I've been using Eclipse 2023-03 IDE this whole time (quite a bit behind ..) and just noticed that even on the master branch it wasn't showing the JMX Console when running JMC using a run configuration. I updated to 2023-12 IDE and now the JMX Console pages are showing as normal, both on the master branch and with this PR applied. The only thing I can think of right now is that Eclipse 2023-12 had changes to use `jakarta.inject` (https://eclipse.dev/eclipse/news/4.30/platform.php#support-jakarta-annotations), and the Console pages make use of the `@Inject` annotation to create the page content. When using a debugger, I can see that the console pages are created but the `createPageContent` is never hit. However, the other methods in the page class (OverviewTab.java for example) do get hit. This makes me think that the injection isn't working properly in versions prior to 2023-12 when running from Eclipse. Try using the latest Eclipse and see if that fixes the problem for you. This might need an issue to be created for it on the JMC Jira. ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-1989331436 From duke at openjdk.org Thu May 2 18:20:15 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Thu, 2 May 2024 18:20:15 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v12] In-Reply-To: References: Message-ID: > Replaces parts of https://github.com/openjdk/jmc/pull/332 Martin Skarsaune has updated the pull request incrementally with 10 additional commits since the last revision: - JMC-7455: Updated copyright in coverage pom.xml - JMC-7455: Added jolokia to coverage - JMC-7455: Remove mess of jolokia versions in pom files - JMC-7455: Upgrade to latest jolokia (and give up on JVM discovery for now) - JMC-7455: Fix for linux. Handle invoke with no parameters - JMC-7455: Work around another Jolokia exception observed from MBean console in Linux - JMC-7455: Work around Jolokia issues seen from MBean console - JMC-7455: Review: restriction warning - JMC-7455: Fixes for review comments, copyright notices and other improvements - JMC-7455: Fix Eclipse warning ------------- Changes: - all: https://git.openjdk.org/jmc/pull/548/files - new: https://git.openjdk.org/jmc/pull/548/files/449a7ec1..a4ac785e Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=11 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=10-11 Stats: 918 lines in 30 files changed: 39 ins; 849 del; 30 mod Patch: https://git.openjdk.org/jmc/pull/548.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/548/head:pull/548 PR: https://git.openjdk.org/jmc/pull/548 From duke at openjdk.org Thu May 2 18:20:16 2024 From: duke at openjdk.org (=?UTF-8?B?SMOpbGlvcw==?= GILLES) Date: Thu, 2 May 2024 18:20:16 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v11] In-Reply-To: References: Message-ID: <6I2GxV5urSiSOyQOdwoD2e2YZ45st0cxkqiOLLskZcE=.a88fe120-1fcf-4b04-a2f5-4e9f2377ca63@github.com> On Thu, 7 Mar 2024 07:21:11 GMT, Martin Skarsaune wrote: >> Replaces parts of https://github.com/openjdk/jmc/pull/332 > > Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision: > > JMC-7455: Pick up protocol extension and use it Any chance to see this feature in the next release ? ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-2017863821 From aptmac at openjdk.org Thu May 2 18:20:16 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 2 May 2024 18:20:16 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v11] In-Reply-To: <6I2GxV5urSiSOyQOdwoD2e2YZ45st0cxkqiOLLskZcE=.a88fe120-1fcf-4b04-a2f5-4e9f2377ca63@github.com> References: <6I2GxV5urSiSOyQOdwoD2e2YZ45st0cxkqiOLLskZcE=.a88fe120-1fcf-4b04-a2f5-4e9f2377ca63@github.com> Message-ID: On Mon, 25 Mar 2024 12:10:44 GMT, H?lios GILLES wrote: > Any chance to see this feature in the next release ? This would be included in the next release when it's available, version 9.X.0 ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-2017973933 From duke at openjdk.org Thu May 2 18:20:16 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Thu, 2 May 2024 18:20:16 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v11] In-Reply-To: References: <6I2GxV5urSiSOyQOdwoD2e2YZ45st0cxkqiOLLskZcE=.a88fe120-1fcf-4b04-a2f5-4e9f2377ca63@github.com> Message-ID: On Mon, 25 Mar 2024 13:08:37 GMT, Alex Macdonald wrote: >> Any chance to see this feature in the next release ? > >> Any chance to see this feature in the next release ? > > This would be included in the next release when it's available, version 9.X.0 @aptmac : I have now upgraded to the latest version of Jolokia (whole new stream) , to make it easier to take advantage of upstream dependencies. In the process I was not able to get the discovery mechanism in as an OSGi dependency, however I felt it was better to cut scope and focus on the basics. Would you be able to help me look at coverage support? If that is in place, then I think I can mark it as ready for review again. I have been clicking around the different ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-2027600299 From aptmac at openjdk.org Thu May 2 18:20:16 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 2 May 2024 18:20:16 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v11] In-Reply-To: References: <6I2GxV5urSiSOyQOdwoD2e2YZ45st0cxkqiOLLskZcE=.a88fe120-1fcf-4b04-a2f5-4e9f2377ca63@github.com> Message-ID: On Mon, 25 Mar 2024 13:08:37 GMT, Alex Macdonald wrote: >> Any chance to see this feature in the next release ? > >> Any chance to see this feature in the next release ? > > This would be included in the next release when it's available, version 9.X.0 > @aptmac : I have now upgraded to the latest version of Jolokia (whole new stream) , to make it easier to take advantage of upstream dependencies. In the process I was not able to get the discovery mechanism in as an OSGi dependency, however I felt it was better to cut scope and focus on the basics. > > Would you be able to help me look at coverage support? If that is in place, then I think I can mark it as ready for review again. I have been clicking around the different Sounds good, I'll re-run this PR again next week and post back about the coverage and/or anything else that comes up. ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-2027607293 From duke at openjdk.org Thu May 2 18:20:16 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Thu, 2 May 2024 18:20:16 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v11] In-Reply-To: References: Message-ID: On Thu, 7 Mar 2024 07:21:11 GMT, Martin Skarsaune wrote: >> Replaces parts of https://github.com/openjdk/jmc/pull/332 > > Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision: > > JMC-7455: Pick up protocol extension and use it I guess another note: The current way to hook the connector into `RJMXConnection` does work, and it was the cleanest way to hook it in that I came up with. However currently `RJMXConnection` does quite a lot based on the fact that it usually is an RMI connection. I suppose at some point it would be nice to better separate the protocol specific concerns. ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-2027963837 From duke at openjdk.org Thu May 2 18:20:16 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Thu, 2 May 2024 18:20:16 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v11] In-Reply-To: References: <6I2GxV5urSiSOyQOdwoD2e2YZ45st0cxkqiOLLskZcE=.a88fe120-1fcf-4b04-a2f5-4e9f2377ca63@github.com> Message-ID: On Fri, 29 Mar 2024 18:55:18 GMT, Alex Macdonald wrote: >>> Any chance to see this feature in the next release ? >> >> This would be included in the next release when it's available, version 9.X.0 > >> @aptmac : I have now upgraded to the latest version of Jolokia (whole new stream) , to make it easier to take advantage of upstream dependencies. In the process I was not able to get the discovery mechanism in as an OSGi dependency, however I felt it was better to cut scope and focus on the basics. >> >> Would you be able to help me look at coverage support? If that is in place, then I think I can mark it as ready for review again. I have been clicking around the different > > Sounds good, I'll re-run this PR again next week and post back about the coverage and/or anything else that comes up. @aptmac : Did you get any time to look at it? I could have a crack at the coverage tests myself, if I could get some pointers or be directed to some doc. Primarily: What is the best way to run the coverage tests? ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-2066059755 From duke at openjdk.org Thu May 2 18:20:16 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Thu, 2 May 2024 18:20:16 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v12] In-Reply-To: References: Message-ID: On Mon, 29 Apr 2024 19:02:36 GMT, Alex Macdonald wrote: > Overall this is looking nice. The tests pass and I was able to connect over Jolokia to the test jvm and verify that the mbean browser & recordings work as expected. To test I added this to the test class: > > ``` > diff --git a/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java b/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java > index 7b65e835..a245f4b1 100644 > --- a/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java > +++ b/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java > @@ -81,7 +81,11 @@ public class JolokiaTest { > Awaitility.await().atMost(Duration.ofSeconds(15))//Note: hard code property to avoid module dependency on agent > .until(() -> (jolokiaUrl = System.getProperty("jolokia.agent")) != null); > jolokiaConnection = getJolokiaMBeanConnector(); > - > + try { > + Thread.sleep(500000000); > + } catch (Exception e) { > + // do nothing, let's take a look at the jolokia .. > + } > } > > @Test > ``` > > and then added a new connection and connected using the custom jmx service url. > > What is your current plans for this PR? Did you want to try and get the JVM Discovery working before turning it from draft to ready for review? Or is the current functionality what you're currently hoping to have integrated? Just to be sure I understood the code change: That was in order to manually test, right? It seems some people would be very happy to have Jolokia support, so I suggest we push ahead with the connectivity. Discovery is more of a niche feature that I can continue working on (ran into some issues with the new 2.x modules there). I will mark as ready for review once I sorted the jolokia version issue you noticed and added coverage. > application/tests/org.openjdk.jmc.jolokia.test/pom.xml line 51: > >> 49: >> 50: >> 51: > > Tried running the tests but was missing this dependency. The root pom has `jolokia.version` as 1.7.2, and the releng/third-party pom has it as 2.0.2, did you mean to mix the two versions? > > diff --git a/application/tests/org.openjdk.jmc.jolokia.test/pom.xml b/application/tests/org.openjdk.jmc.jolokia.test/pom.xml > index 79fc76f4..f46397fa 100644 > --- a/application/tests/org.openjdk.jmc.jolokia.test/pom.xml > +++ b/application/tests/org.openjdk.jmc.jolokia.test/pom.xml > @@ -54,6 +54,11 @@ > awaitility > 4.0.0 > > + > + org.jolokia > + jolokia-jvm > + ${jolokia.version} > + > > > Nice catch, thanks. I will fix the root POM. However for the test I may have to use the 1.7.2 agent as I am struggling with the 2.0.2. Will have a look. ? ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-2084614003 PR Review Comment: https://git.openjdk.org/jmc/pull/548#discussion_r1584285351 From aptmac at openjdk.org Thu May 2 18:20:16 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 2 May 2024 18:20:16 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v12] In-Reply-To: References: Message-ID: <0oQ3UqJGfdUubME8K1uVxOVOKKIXPFkRF7tEEZI9C50=.9aafd81b-4819-465f-84c4-c3de06cd01fc@github.com> On Tue, 30 Apr 2024 07:45:39 GMT, Martin Skarsaune wrote: > > Overall this is looking nice. The tests pass and I was able to connect over Jolokia to the test jvm and verify that the mbean browser & recordings work as expected. To test I added this to the test class: > > ``` > > diff --git a/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java b/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java > > index 7b65e835..a245f4b1 100644 > > --- a/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java > > +++ b/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java > > @@ -81,7 +81,11 @@ public class JolokiaTest { > > Awaitility.await().atMost(Duration.ofSeconds(15))//Note: hard code property to avoid module dependency on agent > > .until(() -> (jolokiaUrl = System.getProperty("jolokia.agent")) != null); > > jolokiaConnection = getJolokiaMBeanConnector(); > > - > > + try { > > + Thread.sleep(500000000); > > + } catch (Exception e) { > > + // do nothing, let's take a look at the jolokia .. > > + } > > } > > > > @Test > > ``` > > > > > > > > > > > > > > > > > > > > > > > > and then added a new connection and connected using the custom jmx service url. > > What is your current plans for this PR? Did you want to try and get the JVM Discovery working before turning it from draft to ready for review? Or is the current functionality what you're currently hoping to have integrated? > > Just to be sure I understood the code change: That was in order to manually test, right? Yeah, just incase anyone coming in wants to try it out/review without doing configuration locally. It was just a hack on my side to test this out a bit faster. > It seems some people would be very happy to have Jolokia support, so I suggest we push ahead with the connectivity. Discovery is more of a niche feature that I can continue working on (ran into some issues with the new 2.x modules there). I will mark as ready for review once I sorted the jolokia version issue you noticed and added coverage. Sounds good to me, and just the connectivity would be enough to satisfy the description of JMC-7455, we can make another jira ticket to track the discover-ability afterwards. ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-2085232419 From aptmac at openjdk.org Thu May 2 18:20:16 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 2 May 2024 18:20:16 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v11] In-Reply-To: References: <6I2GxV5urSiSOyQOdwoD2e2YZ45st0cxkqiOLLskZcE=.a88fe120-1fcf-4b04-a2f5-4e9f2377ca63@github.com> Message-ID: On Fri, 29 Mar 2024 18:55:18 GMT, Alex Macdonald wrote: >>> Any chance to see this feature in the next release ? >> >> This would be included in the next release when it's available, version 9.X.0 > >> @aptmac : I have now upgraded to the latest version of Jolokia (whole new stream) , to make it easier to take advantage of upstream dependencies. In the process I was not able to get the discovery mechanism in as an OSGi dependency, however I felt it was better to cut scope and focus on the basics. >> >> Would you be able to help me look at coverage support? If that is in place, then I think I can mark it as ready for review again. I have been clicking around the different > > Sounds good, I'll re-run this PR again next week and post back about the coverage and/or anything else that comes up. > @aptmac : Did you get any time to look at it? I could have a crack at the coverage tests myself, if I could get some pointers or be directed to some doc. Primarily: What is the best way to run the coverage tests? Ah, no I hadn't found the time to look at it. I tried giving it a run but I seem to be running into some issues running the jolokia-jvm jar, I'll try to check it out again next week. For the test coverage, you'll have to use the coverage maven profile to run it, so it'll be: `mvn clean verify -P coverage` and then the coverage report will be in jmc/application/coverage. In order for the jolokia test coverage to be included both `org.openjdk.jmc.jolokia` and `org.openjdk.jmc.jolokia.test` will need to be added to the coverage pom.xml. `org.openjdk.jmc.jolokia` under here: https://github.com/openjdk/jmc/blob/master/application/coverage/pom.xml#L54, and `org.openjdk.jmc.jolokia.test` under here: https://github.com/openjdk/jmc/blob/master/application/coverage/pom.xml#L353, and then hopefully the coverage report should work using the maven profile. ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-2067142723 From duke at openjdk.org Thu May 2 19:00:27 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Thu, 2 May 2024 19:00:27 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v13] In-Reply-To: References: Message-ID: > Replaces parts of https://github.com/openjdk/jmc/pull/332 Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision: JMC-7455: Externalize one more string ------------- Changes: - all: https://git.openjdk.org/jmc/pull/548/files - new: https://git.openjdk.org/jmc/pull/548/files/a4ac785e..889290d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=12 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=11-12 Stats: 25 lines in 4 files changed: 22 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jmc/pull/548.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/548/head:pull/548 PR: https://git.openjdk.org/jmc/pull/548 From aptmac at openjdk.org Fri May 3 15:15:06 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Fri, 3 May 2024 15:15:06 GMT Subject: RFR: 8219: Missing coverage in application reports Message-ID: This PR fixes (&cleans up) the coverage reports under jmc/application. The argLine was being set in a handful of the application test packages without the surefireArgLine that's required to have jacoco run coverage. Additionally I've removed a bunch of the feature packages from the report (as there isn't anything to scan), and included missing packages that have been added in the last few years. There were also a handful of versions that needed to be updated as well. The Jacoco version in core was bumped to 8.0.10, but the application version stayed at 8.0.7, this has been updated. ------------- Commit messages: - 8219: Missing coverage in application reports Changes: https://git.openjdk.org/jmc/pull/562/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=562&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8219 Stats: 109 lines in 5 files changed: 6 ins; 83 del; 20 mod Patch: https://git.openjdk.org/jmc/pull/562.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/562/head:pull/562 PR: https://git.openjdk.org/jmc/pull/562 From aptmac at openjdk.org Fri May 3 16:00:59 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Fri, 3 May 2024 16:00:59 GMT Subject: RFR: 8219: Missing coverage in application reports In-Reply-To: References: Message-ID: <4nt_6iJ7jSPGuK9BtZ3uWCwHyQ6kEgau4UVoKbHAx4w=.e1e8cd50-08ba-4b55-85a8-592c2ce7d74a@github.com> On Fri, 3 May 2024 15:10:53 GMT, Alex Macdonald wrote: > This PR fixes (&cleans up) the coverage reports under jmc/application. > > The argLine was being set in a handful of the application test packages without the surefireArgLine that's required to have jacoco run coverage. > > Additionally I've removed a bunch of the feature packages from the report (as there isn't anything to scan), and included missing packages that have been added in the last few years. There were also a handful of versions that needed to be updated as well. > > The Jacoco version in core was bumped to 8.0.10, but the application version stayed at 8.0.7, this has been updated. Ah right, no surefireargline if it's being run without coverage, so that's tanking the tests. ------------- PR Comment: https://git.openjdk.org/jmc/pull/562#issuecomment-2093294484 From duke at openjdk.org Fri May 3 18:12:25 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Fri, 3 May 2024 18:12:25 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v14] In-Reply-To: References: Message-ID: <3GYl1JTxT4pKuEC8Gu-BgDj6cM3AjABPUP5DBLWBWhY=.4a457734-5aed-484f-a1ef-dec787f05a20@github.com> > Replaces parts of https://github.com/openjdk/jmc/pull/332 Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision: JMC-7455: Actually measure coverage of jolokia ------------- Changes: - all: https://git.openjdk.org/jmc/pull/548/files - new: https://git.openjdk.org/jmc/pull/548/files/889290d2..17a7eaf8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=13 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/548.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/548/head:pull/548 PR: https://git.openjdk.org/jmc/pull/548 From duke at openjdk.org Fri May 3 18:48:10 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Fri, 3 May 2024 18:48:10 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v15] In-Reply-To: References: Message-ID: > Replaces parts of https://github.com/openjdk/jmc/pull/332 Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision: JMC-7455: Attempt to use late property resolution for surefireArgLine ------------- Changes: - all: https://git.openjdk.org/jmc/pull/548/files - new: https://git.openjdk.org/jmc/pull/548/files/17a7eaf8..13210f66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=14 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=13-14 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/548.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/548/head:pull/548 PR: https://git.openjdk.org/jmc/pull/548 From duke at openjdk.org Sat May 4 08:26:29 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Sat, 4 May 2024 08:26:29 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v16] In-Reply-To: References: Message-ID: > Replaces parts of https://github.com/openjdk/jmc/pull/332 Martin Skarsaune has updated the pull request incrementally with two additional commits since the last revision: - Revert "JMC-7455: Actually measure coverage of jolokia" This reverts commit 17a7eaf8e3e8c4da828633d2d0e1484a47cb4ad3. - Revert "JMC-7455: Attempt to use late property resolution for surefireArgLine" This reverts commit 13210f66dcf56f7790d26397ca00ae86acfb58ed. ------------- Changes: - all: https://git.openjdk.org/jmc/pull/548/files - new: https://git.openjdk.org/jmc/pull/548/files/13210f66..24c3c1c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=15 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/548.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/548/head:pull/548 PR: https://git.openjdk.org/jmc/pull/548 From duke at openjdk.org Mon May 6 13:48:00 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Mon, 6 May 2024 13:48:00 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v16] In-Reply-To: <0oQ3UqJGfdUubME8K1uVxOVOKKIXPFkRF7tEEZI9C50=.9aafd81b-4819-465f-84c4-c3de06cd01fc@github.com> References: <0oQ3UqJGfdUubME8K1uVxOVOKKIXPFkRF7tEEZI9C50=.9aafd81b-4819-465f-84c4-c3de06cd01fc@github.com> Message-ID: On Tue, 30 Apr 2024 12:43:18 GMT, Alex Macdonald wrote: >>> Overall this is looking nice. The tests pass and I was able to connect over Jolokia to the test jvm and verify that the mbean browser & recordings work as expected. To test I added this to the test class: >>> >>> ``` >>> diff --git a/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java b/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java >>> index 7b65e835..a245f4b1 100644 >>> --- a/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java >>> +++ b/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java >>> @@ -81,7 +81,11 @@ public class JolokiaTest { >>> Awaitility.await().atMost(Duration.ofSeconds(15))//Note: hard code property to avoid module dependency on agent >>> .until(() -> (jolokiaUrl = System.getProperty("jolokia.agent")) != null); >>> jolokiaConnection = getJolokiaMBeanConnector(); >>> - >>> + try { >>> + Thread.sleep(500000000); >>> + } catch (Exception e) { >>> + // do nothing, let's take a look at the jolokia .. >>> + } >>> } >>> >>> @Test >>> ``` >>> >>> and then added a new connection and connected using the custom jmx service url. >>> >>> What is your current plans for this PR? Did you want to try and get the JVM Discovery working before turning it from draft to ready for review? Or is the current functionality what you're currently hoping to have integrated? >> >> Just to be sure I understood the code change: That was in order to manually test, right? >> >> It seems some people would be very happy to have Jolokia support, so I suggest we push ahead with the connectivity. Discovery is more of a niche feature that I can continue working on (ran into some issues with the new 2.x modules there). >> I will mark as ready for review once I sorted the jolokia version issue you noticed and added coverage. > >> > Overall this is looking nice. The tests pass and I was able to connect over Jolokia to the test jvm and verify that the mbean browser & recordings work as expected. To test I added this to the test class: >> > ``` >> > diff --git a/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java b/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java >> > index 7b65e835..a245f4b1 100644 >> > --- a/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java >> > +++ b/application/tests/org.openjdk.jmc.jolokia.test/src/test/java/org/openjdk/jmc/jolokia/JolokiaTest.java >> > @@ -81,7 +81,11 @@ public class JolokiaTest { >> > Awaitility.await().atMost(Duration.ofSeconds(15))//Note: hard code property to avoid module dependency on agent >> > .until(() -> (jolokiaUrl = System.getProperty("jolokia.agent")) != null); >> > jolokiaConnection = getJolokiaMBeanConnector(); >> > - >> > + try { >> > + Thread.sleep(500000000); >> > + } catch (Exception e) { >> > + // do nothing, let's take a look at the jolokia .. >> > + } >> > } >> > >> > @Test >> > ``` >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > and then added a new connection and connected using the custom jmx service url. >> > What is your current plans for this PR? Did you want to try and get the JVM Discovery working before turning it from draft to ready for review? Or is the current functionality what you're currently hoping to have integrated? >> >> Just to be sure I understood the code change: That was in order to manually test, right? > > Yeah, just incase anyone coming in wants to try it out/review without doing configuration locally. It was just a hack on my side to test this out a bit faster. > >> It seems some people would be very happy to have Jolokia support, so I suggest we push ahead with the connectivity. Discovery is more of a niche feature that I can continue working on (ran into some issues with the new 2.x modules there). I will mark as ready for review once I sorted the jolokia version issue you noticed and added coverage. > > Sounds good to me, and just the connectivity would be enough to satisfy the description of JMC-7455, we can make another jira ticket to track the discover-ability afterwards. @aptmac : Marked it as ready for review. You may see from the last commits that when I tried to get test coverage it broke the regular test run. Hence I reverted back. I see you are working on that in #562 . ------------- PR Comment: https://git.openjdk.org/jmc/pull/548#issuecomment-2096057627 From hirt at openjdk.org Wed May 8 22:21:06 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Wed, 8 May 2024 22:21:06 GMT Subject: RFR: 8220: Make LocalJVMToolkit reflective Message-ID: Less painful from within Eclipse. ------------- Commit messages: - 8220: Make LocalJVMToolkit reflective Changes: https://git.openjdk.org/jmc/pull/563/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=563&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8220 Stats: 373 lines in 4 files changed: 302 ins; 43 del; 28 mod Patch: https://git.openjdk.org/jmc/pull/563.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/563/head:pull/563 PR: https://git.openjdk.org/jmc/pull/563 From aptmac at openjdk.org Fri May 10 13:51:10 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Fri, 10 May 2024 13:51:10 GMT Subject: RFR: 8220: Make LocalJVMToolkit reflective In-Reply-To: References: Message-ID: <5IjD552-4BRyVYvf0diqMF_I4rHjWt1GJ_IqeDZAUJw=.14ce2854-8198-4fa7-bd52-9dcf9b185f0b@github.com> On Wed, 8 May 2024 22:17:32 GMT, Marcus Hirt wrote: > Less painful from within Eclipse. Marked as reviewed by aptmac (Reviewer). ------------- PR Review: https://git.openjdk.org/jmc/pull/563#pullrequestreview-2050118266 From jbachorik at openjdk.org Sat May 11 20:22:36 2024 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Sat, 11 May 2024 20:22:36 GMT Subject: RFR: 7992: Add API to easily write annotated Java JFR events [v3] In-Reply-To: References: Message-ID: On Thu, 14 Mar 2024 11:06:15 GMT, Jaroslav Bachorik wrote: >> This PR extends the JFR Writer API with the ability to use the custom JFR event types (eg. classes extending `jdk.jfr.Event`) and register new writer type for them and also directly accept the instances of those types to write them in the recording. > > Jaroslav Bachorik 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 five additional commits since the last revision: > > - Merge branch 'master' into jb/JMC-7992 > - Add more explanatory comments > - Add javadoc for the new public methods > - Update copyright year > - JMC-7992: Add API to easily write annotated Java JFR events A gentle ping ... ------------- PR Comment: https://git.openjdk.org/jmc/pull/457#issuecomment-2106010156 From clanger at openjdk.org Mon May 13 13:18:03 2024 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 13 May 2024 13:18:03 GMT Subject: RFR: 8220: Make LocalJVMToolkit reflective In-Reply-To: References: Message-ID: On Wed, 8 May 2024 22:17:32 GMT, Marcus Hirt wrote: > Less painful from within Eclipse. Hm, I didn't follow up on the root cause for this quite some time. However, wouldn't it be better to fix tycho compilation to allow add-exports? ------------- PR Comment: https://git.openjdk.org/jmc/pull/563#issuecomment-2107549241 From hirt at openjdk.org Tue May 14 13:49:43 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 14 May 2024 13:49:43 GMT Subject: RFR: 8220: Make LocalJVMToolkit reflective [v2] In-Reply-To: References: Message-ID: > Less painful from within Eclipse. Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Error message and null check ------------- Changes: - all: https://git.openjdk.org/jmc/pull/563/files - new: https://git.openjdk.org/jmc/pull/563/files/5f1b51b5..10f2a532 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=563&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=563&range=00-01 Stats: 8 lines in 2 files changed: 3 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jmc/pull/563.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/563/head:pull/563 PR: https://git.openjdk.org/jmc/pull/563 From hirt at openjdk.org Tue May 14 13:56:14 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 14 May 2024 13:56:14 GMT Subject: RFR: 8220: Make LocalJVMToolkit reflective [v2] In-Reply-To: References: Message-ID: <-KERp92gHDMhP5wy3CHHU37E-Y0S6rafduKwrtm-n3w=.59288714-be44-49dd-99a0-5a014f2ec3ea@github.com> On Tue, 14 May 2024 13:49:43 GMT, Marcus Hirt wrote: >> Less painful from within Eclipse. > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Error message and null check If someone has the stomach and stamina for that. This is a pretty simple fix that mitigates any trouble in a part of the code base that is really only used by JMC, for nefarious purposes that the Java platform team would rather have the world stop doing altogether. As a matter of fact, these days you need to explicitly start the JVMs with a flag for JMC to be able to do local attach at all. Since this is making onboarding of new contributors harder right now, I would rather take this fix for now. Once Tycho behaves, we can decide if we want to undo this fix. ------------- PR Comment: https://git.openjdk.org/jmc/pull/563#issuecomment-2110307244 From hirt at openjdk.org Tue May 14 14:00:30 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 14 May 2024 14:00:30 GMT Subject: RFR: 8220: Make LocalJVMToolkit reflective [v3] In-Reply-To: References: Message-ID: <1DKC9DboqKgSVWY3owPCdE-nOkNWlcdPEvrh91t9DvE=.8d1e790d-e1f4-4cde-bdec-96ce2a7171b7@github.com> > Less painful from within Eclipse. Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Fixing logging levels ------------- Changes: - all: https://git.openjdk.org/jmc/pull/563/files - new: https://git.openjdk.org/jmc/pull/563/files/10f2a532..8681c3a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=563&range=02 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=563&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jmc/pull/563.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/563/head:pull/563 PR: https://git.openjdk.org/jmc/pull/563 From hirt at openjdk.org Tue May 14 16:34:10 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 14 May 2024 16:34:10 GMT Subject: Integrated: 8220: Make LocalJVMToolkit reflective In-Reply-To: References: Message-ID: On Wed, 8 May 2024 22:17:32 GMT, Marcus Hirt wrote: > Less painful from within Eclipse. This pull request has now been integrated. Changeset: 92750098 Author: Marcus Hirt URL: https://git.openjdk.org/jmc/commit/92750098a2deac54b8165ec5c6d368be00707856 Stats: 377 lines in 4 files changed: 305 ins; 43 del; 29 mod 8220: Make LocalJVMToolkit reflective Reviewed-by: aptmac ------------- PR: https://git.openjdk.org/jmc/pull/563 From bdutheil at openjdk.org Fri May 17 11:38:08 2024 From: bdutheil at openjdk.org (Brice Dutheil) Date: Fri, 17 May 2024 11:38:08 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC [v3] In-Reply-To: References: Message-ID: On Fri, 29 Mar 2024 02:57:30 GMT, Suchita Chaturvedi wrote: >> This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. >> >> As part of this PR we have introduced a new aggregator JVM_PID_ID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page so that formatting is not applied as per NUMBER formatting rules. >> >> JVM PID before the change: >> image >> >> JVM PID after the change: >> image >> >> The issue is more prominent when the identifier value is converted to exponential. > > Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: > > Used changed pid datatype from NUMBER to LONG as per review comment This mostly looks good to me. Maybe add a log when the pid is encountered twice and if it changes. core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/Aggregators.java line 1068: > 1066: Iterator itr = source.iterator(); > 1067: while (itr.hasNext()) { > 1068: value = (Long) itr.next(); **question:** Should there be at least a log if the value is seen more than once ? ------------- Marked as reviewed by bdutheil (Committer). PR Review: https://git.openjdk.org/jmc/pull/557#pullrequestreview-2063119965 PR Review Comment: https://git.openjdk.org/jmc/pull/557#discussion_r1604832497 From bdutheil at openjdk.org Fri May 17 11:41:13 2024 From: bdutheil at openjdk.org (Brice Dutheil) Date: Fri, 17 May 2024 11:41:13 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC [v2] In-Reply-To: <5BJzHKIvnZz3VWfueZNjWC5krQshH8Ay1e9cu8ae0uY=.e96faa2b-d90e-4afe-9786-20939e8b21a5@github.com> References: <5BJzHKIvnZz3VWfueZNjWC5krQshH8Ay1e9cu8ae0uY=.e96faa2b-d90e-4afe-9786-20939e8b21a5@github.com> Message-ID: On Mon, 25 Mar 2024 05:15:44 GMT, Suchita Chaturvedi wrote: >> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed the pid formatting issue on Event Browser and Properties section also > > For the JVM PID 2177: > ![image](https://github.com/openjdk/jmc/assets/11155712/1a7ee492-a970-4c1c-826d-93b36be297c0) > > **Before the Change:** > JVM Internal Page > Screenshot 2024-03-25 103611 > > Event Browser Page > Screenshot 2024-03-25 104001 > > **After the Change:** > JVM Internal Page > Screenshot 2024-03-25 104207 > > Event Browser Page > Screenshot 2024-03-25 104343 > I posted a diff for an alternative solution for this in the JMC slack. @Suchitainf is looking at it. Oh I missed that message. ------------- PR Comment: https://git.openjdk.org/jmc/pull/557#issuecomment-2117405851 From schaturvedi at openjdk.org Sun May 19 20:49:17 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Sun, 19 May 2024 20:49:17 GMT Subject: RFR: 7263: JMC displaying long value in scientific notation [v2] In-Reply-To: <7r8isvwpJPwHWACQiSJqHwegzFbpsLmkDMlq63IVohA=.83f9b828-3cce-47a0-9ecf-0f8006632f04@github.com> References: <7r8isvwpJPwHWACQiSJqHwegzFbpsLmkDMlq63IVohA=.83f9b828-3cce-47a0-9ecf-0f8006632f04@github.com> Message-ID: <7f8umVEkcVLXpv9julrEYyyYUPmrU96GX6gUXHBSZHg=.9465d272-0c44-45fe-9f2c-f68614a005fd@github.com> > This PR addresses the formatting issue for the certificate Ids for X509 Certificate events. > > Before the fix: > image (3) > > After the fix: > Screenshot 2024-04-01 222303 Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: Corrected the content type from Long to String for certificate Id. ------------- Changes: - all: https://git.openjdk.org/jmc/pull/559/files - new: https://git.openjdk.org/jmc/pull/559/files/717201bd..4da9005c Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=559&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=559&range=00-01 Stats: 53 lines in 7 files changed: 47 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jmc/pull/559.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/559/head:pull/559 PR: https://git.openjdk.org/jmc/pull/559 From schaturvedi at openjdk.org Mon May 20 10:01:33 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Mon, 20 May 2024 10:01:33 GMT Subject: RFR: 7263: JMC displaying long value in scientific notation [v3] In-Reply-To: <7r8isvwpJPwHWACQiSJqHwegzFbpsLmkDMlq63IVohA=.83f9b828-3cce-47a0-9ecf-0f8006632f04@github.com> References: <7r8isvwpJPwHWACQiSJqHwegzFbpsLmkDMlq63IVohA=.83f9b828-3cce-47a0-9ecf-0f8006632f04@github.com> Message-ID: <7bameoVcVqEsw3jS0xH4sBXcGScqU6Jm8BejyDbgh5A=.cb489c27-5d52-4aae-930b-7f06599f375a@github.com> > This PR addresses the formatting issue for the certificate Ids for X509 Certificate events. > > Before the fix: > image (3) > > After the fix: > Screenshot 2024-04-01 222303 Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: Adding check for jdk.X509Validation event also where certificateId exists ------------- Changes: - all: https://git.openjdk.org/jmc/pull/559/files - new: https://git.openjdk.org/jmc/pull/559/files/4da9005c..8c1ee1af Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=559&range=02 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=559&range=01-02 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/559.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/559/head:pull/559 PR: https://git.openjdk.org/jmc/pull/559 From schaturvedi at openjdk.org Wed May 22 17:45:34 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Wed, 22 May 2024 17:45:34 GMT Subject: RFR: 7263: JMC displaying long value in scientific notation [v4] In-Reply-To: <7r8isvwpJPwHWACQiSJqHwegzFbpsLmkDMlq63IVohA=.83f9b828-3cce-47a0-9ecf-0f8006632f04@github.com> References: <7r8isvwpJPwHWACQiSJqHwegzFbpsLmkDMlq63IVohA=.83f9b828-3cce-47a0-9ecf-0f8006632f04@github.com> Message-ID: > This PR addresses the formatting issue for the certificate Ids for X509 Certificate events. > > Before the fix: > image (3) > > After the fix: > Screenshot 2024-04-01 222303 Suchita Chaturvedi has updated the pull request incrementally with two additional commits since the last revision: - Revert "Corrected the content type from Long to String for certificate Id." This reverts commit 4da9005c4974596eb04ac9a5833ba81a08980bcb. - Revert "Adding check for jdk.X509Validation event also where certificateId exists" This reverts commit 8c1ee1af56bfca0d3a471349709bfd6a18560d1b. ------------- Changes: - all: https://git.openjdk.org/jmc/pull/559/files - new: https://git.openjdk.org/jmc/pull/559/files/8c1ee1af..5a724c25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=559&range=03 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=559&range=02-03 Stats: 55 lines in 7 files changed: 2 ins; 49 del; 4 mod Patch: https://git.openjdk.org/jmc/pull/559.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/559/head:pull/559 PR: https://git.openjdk.org/jmc/pull/559 From schaturvedi at openjdk.org Wed May 22 18:04:41 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Wed, 22 May 2024 18:04:41 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC [v4] In-Reply-To: References: Message-ID: > This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. > > As part of this PR we have introduced a new aggregator JVM_PID_ID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page so that formatting is not applied as per NUMBER formatting rules. > > JVM PID before the change: > image > > JVM PID after the change: > image > > The issue is more prominent when the identifier value is converted to exponential. Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: Implemented the new content type approach Co-authored-by: Marcus Hirt ------------- Changes: - all: https://git.openjdk.org/jmc/pull/557/files - new: https://git.openjdk.org/jmc/pull/557/files/43abce3a..ac80167c Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=557&range=03 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=557&range=02-03 Stats: 78 lines in 6 files changed: 40 ins; 30 del; 8 mod Patch: https://git.openjdk.org/jmc/pull/557.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/557/head:pull/557 PR: https://git.openjdk.org/jmc/pull/557 From hirt at openjdk.org Wed May 22 18:56:09 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Wed, 22 May 2024 18:56:09 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC [v4] In-Reply-To: References: Message-ID: On Wed, 22 May 2024 18:04:41 GMT, Suchita Chaturvedi wrote: >> This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. >> >> As part of this PR we have introduced a new aggregator JVM_PID_ID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page so that formatting is not applied as per NUMBER formatting rules. >> >> JVM PID before the change: >> image >> >> JVM PID after the change: >> image >> >> The issue is more prominent when the identifier value is converted to exponential. > > Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: > > Implemented the new content type approach > > Co-authored-by: Marcus Hirt MIght want to check so that there isn't any use (except for the attribute in the SyntheticAttributeExtension) of JVM_PID (attribute or aggregator) anywhere else in JMC. For example in the JVMInformationPage at 237. ------------- PR Comment: https://git.openjdk.org/jmc/pull/557#issuecomment-2125534347 From schaturvedi at openjdk.org Wed May 22 20:52:08 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Wed, 22 May 2024 20:52:08 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC [v4] In-Reply-To: References: Message-ID: On Wed, 22 May 2024 18:53:55 GMT, Marcus Hirt wrote: > MIght want to check so that there isn't any use (except for the attribute in the SyntheticAttributeExtension) of JVM_PID (attribute or aggregator) anywhere else in JMC. For example in the JVMInformationPage at 237. There is only one usage of JVM_PID which is in JVMInformationPage at 237. I have searched entire workspace on eclipse. ------------- PR Comment: https://git.openjdk.org/jmc/pull/557#issuecomment-2125721120 From aptmac at openjdk.org Thu May 23 18:44:09 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 23 May 2024 18:44:09 GMT Subject: RFR: 7263: JMC displaying long value in scientific notation [v4] In-Reply-To: References: <7r8isvwpJPwHWACQiSJqHwegzFbpsLmkDMlq63IVohA=.83f9b828-3cce-47a0-9ecf-0f8006632f04@github.com> Message-ID: On Wed, 22 May 2024 17:45:34 GMT, Suchita Chaturvedi wrote: >> This PR addresses the formatting issue for the certificate Ids for X509 Certificate events. >> >> Before the fix: >> image (3) >> >> After the fix: >> Screenshot 2024-04-01 222303 > > Suchita Chaturvedi has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Corrected the content type from Long to String for certificate Id." > > This reverts commit 4da9005c4974596eb04ac9a5833ba81a08980bcb. > - Revert "Adding check for jdk.X509Validation event also where certificateId exists" > > This reverts commit 8c1ee1af56bfca0d3a471349709bfd6a18560d1b. This looks okay to me, there is a comment about changing the variable name, I believe it should be `CERTIFICATE_ID_ID` going off of similar variables. I took a quick look at the check copyright script, if you rebase your changes on top of master then it will pass. Basically the script at the moment compares all of your changes against the upstream/master branch using a git diff, so if your branch is not up-to-date you may throw off the script with files that it already expects to have. ------------- PR Review: https://git.openjdk.org/jmc/pull/559#pullrequestreview-2074754106 From aptmac at openjdk.org Thu May 23 20:04:08 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 23 May 2024 20:04:08 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC [v4] In-Reply-To: References: Message-ID: On Wed, 22 May 2024 18:04:41 GMT, Suchita Chaturvedi wrote: >> This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. >> >> As part of this PR we have introduced a new aggregator JVM_PID_ID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page so that formatting is not applied as per NUMBER formatting rules. >> >> JVM PID before the change: >> image >> >> JVM PID after the change: >> image >> >> The issue is more prominent when the identifier value is converted to exponential. > > Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: > > Implemented the new content type approach > > Co-authored-by: Marcus Hirt These changes look okay to me, similar to my comment on the other PR (https://github.com/openjdk/jmc/pull/559#pullrequestreview-2074754106) if you rebase this ontop of master the copyright check script should work properly. ------------- PR Review: https://git.openjdk.org/jmc/pull/557#pullrequestreview-2074891546 From hirt at openjdk.org Thu May 23 20:25:08 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Thu, 23 May 2024 20:25:08 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC [v4] In-Reply-To: References: Message-ID: On Wed, 22 May 2024 20:49:37 GMT, Suchita Chaturvedi wrote: > > MIght want to check so that there isn't any use (except for the attribute in the SyntheticAttributeExtension) of JVM_PID (attribute or aggregator) anywhere else in JMC. For example in the JVMInformationPage at 237. > > There is only one usage of JVM_PID which is in JVMInformationPage at 237. I have searched entire workspace on eclipse. One could argue that there should be a PID aggregator, and that the JVM_PID one should be deprecated. ------------- PR Comment: https://git.openjdk.org/jmc/pull/557#issuecomment-2127956574 From bdutheil at openjdk.org Fri May 24 16:35:09 2024 From: bdutheil at openjdk.org (Brice Dutheil) Date: Fri, 24 May 2024 16:35:09 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC [v4] In-Reply-To: References: Message-ID: On Wed, 22 May 2024 18:04:41 GMT, Suchita Chaturvedi wrote: >> This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. >> >> As part of this PR we have introduced a new aggregator JVM_PID_ID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page so that formatting is not applied as per NUMBER formatting rules. >> >> JVM PID before the change: >> image >> >> JVM PID after the change: >> image >> >> The issue is more prominent when the identifier value is converted to exponential. > > Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: > > Implemented the new content type approach > > Co-authored-by: Marcus Hirt Looks ok to me. PID Aggregator looks like a good idea. ------------- PR Review: https://git.openjdk.org/jmc/pull/557#pullrequestreview-2077386831 From schaturvedi at openjdk.org Fri May 24 19:01:22 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Fri, 24 May 2024 19:01:22 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC [v5] In-Reply-To: References: Message-ID: > This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. > > As part of this PR we have introduced a new aggregator JVM_PID_ID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page so that formatting is not applied as per NUMBER formatting rules. > > JVM PID before the change: > image > > JVM PID after the change: > image > > The issue is more prominent when the identifier value is converted to exponential. Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: Updating the aggregator name from JVM_PID to PID ------------- Changes: - all: https://git.openjdk.org/jmc/pull/557/files - new: https://git.openjdk.org/jmc/pull/557/files/ac80167c..e488abb2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=557&range=04 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=557&range=03-04 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jmc/pull/557.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/557/head:pull/557 PR: https://git.openjdk.org/jmc/pull/557 From schaturvedi at openjdk.org Sat May 25 20:52:12 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Sat, 25 May 2024 20:52:12 GMT Subject: RFR: 7263: JMC displaying long value in scientific notation [v4] In-Reply-To: References: <7r8isvwpJPwHWACQiSJqHwegzFbpsLmkDMlq63IVohA=.83f9b828-3cce-47a0-9ecf-0f8006632f04@github.com> Message-ID: On Wed, 22 May 2024 17:45:34 GMT, Suchita Chaturvedi wrote: >> This PR addresses the formatting issue for the certificate Ids for X509 Certificate events. >> >> Before the fix: >> image (3) >> >> After the fix: >> Screenshot 2024-04-01 222303 > > Suchita Chaturvedi has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Corrected the content type from Long to String for certificate Id." > > This reverts commit 4da9005c4974596eb04ac9a5833ba81a08980bcb. > - Revert "Adding check for jdk.X509Validation event also where certificateId exists" > > This reverts commit 8c1ee1af56bfca0d3a471349709bfd6a18560d1b. Closing this PR and raising a new one with latest updated code of 9.1.0. ------------- PR Comment: https://git.openjdk.org/jmc/pull/559#issuecomment-2131436267 From schaturvedi at openjdk.org Sat May 25 20:52:12 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Sat, 25 May 2024 20:52:12 GMT Subject: Withdrawn: 7263: JMC displaying long value in scientific notation In-Reply-To: <7r8isvwpJPwHWACQiSJqHwegzFbpsLmkDMlq63IVohA=.83f9b828-3cce-47a0-9ecf-0f8006632f04@github.com> References: <7r8isvwpJPwHWACQiSJqHwegzFbpsLmkDMlq63IVohA=.83f9b828-3cce-47a0-9ecf-0f8006632f04@github.com> Message-ID: On Mon, 1 Apr 2024 16:56:04 GMT, Suchita Chaturvedi wrote: > This PR addresses the formatting issue for the certificate Ids for X509 Certificate events. > > Before the fix: > image (3) > > After the fix: > Screenshot 2024-04-01 222303 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jmc/pull/559 From schaturvedi at openjdk.org Sat May 25 21:03:10 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Sat, 25 May 2024 21:03:10 GMT Subject: Withdrawn: 7506: Incorrect numeric formatting of PID by JMC In-Reply-To: References: Message-ID: On Fri, 15 Mar 2024 14:28:33 GMT, Suchita Chaturvedi wrote: > This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. > > As part of this PR we have introduced a new aggregator JVM_PID_ID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page so that formatting is not applied as per NUMBER formatting rules. > > JVM PID before the change: > image > > JVM PID after the change: > image > > The issue is more prominent when the identifier value is converted to exponential. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jmc/pull/557 From schaturvedi at openjdk.org Sat May 25 21:11:28 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Sat, 25 May 2024 21:11:28 GMT Subject: RFR: 7263: JMC displaying long value in scientific notation Message-ID: <9CRXwgKD0JNMm2YW6RkJYge0bxaXraK1eoY-0gYttEE=.aaac02c4-2346-4f22-96f9-48a8dc8a1d5f@github.com> This PR addresses the formatting issue for the certificate Ids for X509 Certificate and X509 Validation events. ------------- Commit messages: - 7263: JMC displaying long value in scientific notation Changes: https://git.openjdk.org/jmc/pull/564/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=564&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7263 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jmc/pull/564.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/564/head:pull/564 PR: https://git.openjdk.org/jmc/pull/564 From schaturvedi at openjdk.org Sat May 25 21:29:08 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Sat, 25 May 2024 21:29:08 GMT Subject: RFR: 7263: JMC displaying long value in scientific notation [v4] In-Reply-To: References: <7r8isvwpJPwHWACQiSJqHwegzFbpsLmkDMlq63IVohA=.83f9b828-3cce-47a0-9ecf-0f8006632f04@github.com> Message-ID: On Wed, 22 May 2024 17:45:34 GMT, Suchita Chaturvedi wrote: >> This PR addresses the formatting issue for the certificate Ids for X509 Certificate events. >> >> Before the fix: >> image (3) >> >> After the fix: >> Screenshot 2024-04-01 222303 > > Suchita Chaturvedi has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Corrected the content type from Long to String for certificate Id." > > This reverts commit 4da9005c4974596eb04ac9a5833ba81a08980bcb. > - Revert "Adding check for jdk.X509Validation event also where certificateId exists" > > This reverts commit 8c1ee1af56bfca0d3a471349709bfd6a18560d1b. New PR https://github.com/openjdk/jmc/pull/564 ------------- PR Comment: https://git.openjdk.org/jmc/pull/559#issuecomment-2131470578 From schaturvedi at openjdk.org Sat May 25 21:29:29 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Sat, 25 May 2024 21:29:29 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC Message-ID: This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. The PID (Process Id) attribute is present in JMC as part of System Process event also where the data type is correct i.e. String. So in order to maintain consistency, we have made the content type of PID attribute of JVM Information event also as String. We are converting the number value of PID to string and then storing it. We have also introduced a new aggregator PID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page. ------------- Commit messages: - 7506: Incorrect numeric formatting of PID by JMC Changes: https://git.openjdk.org/jmc/pull/565/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=565&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7506 Stats: 46 lines in 3 files changed: 40 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jmc/pull/565.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/565/head:pull/565 PR: https://git.openjdk.org/jmc/pull/565 From schaturvedi at openjdk.org Sat May 25 21:30:10 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Sat, 25 May 2024 21:30:10 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC [v5] In-Reply-To: References: Message-ID: On Fri, 24 May 2024 19:01:22 GMT, Suchita Chaturvedi wrote: >> This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. >> >> As part of this PR we have introduced a new aggregator JVM_PID_ID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page so that formatting is not applied as per NUMBER formatting rules. >> >> JVM PID before the change: >> image >> >> JVM PID after the change: >> image >> >> The issue is more prominent when the identifier value is converted to exponential. > > Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: > > Updating the aggregator name from JVM_PID to PID New PR https://github.com/openjdk/jmc/pull/565 ------------- PR Comment: https://git.openjdk.org/jmc/pull/557#issuecomment-2131472022 From bdutheil at openjdk.org Sun May 26 08:13:06 2024 From: bdutheil at openjdk.org (Brice Dutheil) Date: Sun, 26 May 2024 08:13:06 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC In-Reply-To: References: Message-ID: <5QcWDPZz-iOXYAvnQeJiKoGQqrgFQU1jjQlJ3-SHtks=.424301a4-293c-4fcd-9daa-ac9fea72819b@github.com> On Sat, 25 May 2024 21:25:09 GMT, Suchita Chaturvedi wrote: > This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. > > The PID (Process Id) attribute is present in JMC as part of System Process event also where the data type is correct i.e. String. So in order to maintain consistency, we have made the content type of PID attribute of JVM Information event also as String. We are converting the number value of PID to string and then storing it. > > We have also introduced a new aggregator PID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page. Marked as reviewed by bdutheil (Committer). ------------- PR Review: https://git.openjdk.org/jmc/pull/565#pullrequestreview-2079501418 From vpurnam at openjdk.org Mon May 27 07:16:09 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Mon, 27 May 2024 07:16:09 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC In-Reply-To: References: Message-ID: On Sat, 25 May 2024 21:25:09 GMT, Suchita Chaturvedi wrote: > This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. > > The PID (Process Id) attribute is present in JMC as part of System Process event also where the data type is correct i.e. String. So in order to maintain consistency, we have made the content type of PID attribute of JVM Information event also as String. We are converting the number value of PID to string and then storing it. > > We have also introduced a new aggregator PID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page. LGTM ------------- Marked as reviewed by vpurnam (Committer). PR Review: https://git.openjdk.org/jmc/pull/565#pullrequestreview-2080157199 From vpurnam at openjdk.org Mon May 27 07:17:08 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Mon, 27 May 2024 07:17:08 GMT Subject: RFR: 7263: JMC displaying long value in scientific notation In-Reply-To: <9CRXwgKD0JNMm2YW6RkJYge0bxaXraK1eoY-0gYttEE=.aaac02c4-2346-4f22-96f9-48a8dc8a1d5f@github.com> References: <9CRXwgKD0JNMm2YW6RkJYge0bxaXraK1eoY-0gYttEE=.aaac02c4-2346-4f22-96f9-48a8dc8a1d5f@github.com> Message-ID: <-70HkRSNWqu5UXuslsINuq6_yFwaLQIH56QTEw0aOOI=.93361572-21de-436c-8224-af03f41a62f0@github.com> On Sat, 25 May 2024 21:06:38 GMT, Suchita Chaturvedi wrote: > This PR addresses the formatting issue for the certificate Ids for X509 Certificate and X509 Validation events. Marked as reviewed by vpurnam (Committer). ------------- PR Review: https://git.openjdk.org/jmc/pull/564#pullrequestreview-2080158585 From hirt at openjdk.org Mon May 27 11:58:10 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Mon, 27 May 2024 11:58:10 GMT Subject: RFR: 7992: Add API to easily write annotated Java JFR events [v3] In-Reply-To: References: Message-ID: On Sat, 11 May 2024 20:19:05 GMT, Jaroslav Bachorik wrote: >> Jaroslav Bachorik 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 five additional commits since the last revision: >> >> - Merge branch 'master' into jb/JMC-7992 >> - Add more explanatory comments >> - Add javadoc for the new public methods >> - Update copyright year >> - JMC-7992: Add API to easily write annotated Java JFR events > > A gentle ping ... Hi @jbachorik! Some tests verifying the registering of some subclass of jdk.jfr.Event, and that also have annotations in it, and that creates a few events of it, would be good. ------------- PR Comment: https://git.openjdk.org/jmc/pull/457#issuecomment-2133323097 From hirt at openjdk.org Mon May 27 12:02:10 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Mon, 27 May 2024 12:02:10 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC In-Reply-To: References: Message-ID: On Sat, 25 May 2024 21:25:09 GMT, Suchita Chaturvedi wrote: > This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. > > The PID (Process Id) attribute is present in JMC as part of System Process event also where the data type is correct i.e. String. So in order to maintain consistency, we have made the content type of PID attribute of JVM Information event also as String. We are converting the number value of PID to string and then storing it. > > We have also introduced a new aggregator PID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page. core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAggregators.java line 118: > 116: // VM Info > 117: public static final IAggregator JVM_NAME = distinctAsString(VM_INFO, JdkAttributes.JVM_NAME); > 118: public static final IAggregator JVM_PID = min(JdkAttributes.JVM_PID.getName(), null, VM_INFO, Part of the public API. Perhaps better to deprecate? ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/565#discussion_r1615954310 From hirt at openjdk.org Mon May 27 12:03:19 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Mon, 27 May 2024 12:03:19 GMT Subject: RFR: 7263: JMC displaying long value in scientific notation In-Reply-To: <9CRXwgKD0JNMm2YW6RkJYge0bxaXraK1eoY-0gYttEE=.aaac02c4-2346-4f22-96f9-48a8dc8a1d5f@github.com> References: <9CRXwgKD0JNMm2YW6RkJYge0bxaXraK1eoY-0gYttEE=.aaac02c4-2346-4f22-96f9-48a8dc8a1d5f@github.com> Message-ID: On Sat, 25 May 2024 21:06:38 GMT, Suchita Chaturvedi wrote: > This PR addresses the formatting issue for the certificate Ids for X509 Certificate and X509 Validation events. Marked as reviewed by hirt (Lead). ------------- PR Review: https://git.openjdk.org/jmc/pull/564#pullrequestreview-2080767792 From aptmac at openjdk.org Mon May 27 21:17:30 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Mon, 27 May 2024 21:17:30 GMT Subject: RFR: 8219: Missing coverage in application reports [v2] In-Reply-To: References: Message-ID: > This PR fixes (&cleans up) the coverage reports under jmc/application. > > The argLine was being set in a handful of the application test packages without the surefireArgLine that's required to have jacoco run coverage. > > Additionally I've removed a bunch of the feature packages from the report (as there isn't anything to scan), and included missing packages that have been added in the last few years. There were also a handful of versions that needed to be updated as well. > > The Jacoco version in core was bumped to 8.0.10, but the application version stayed at 8.0.7, this has been updated. Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - update license header - adjust the argline for tycho-maven-plugin - 8219: Missing coverage in application reports ------------- Changes: https://git.openjdk.org/jmc/pull/562/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=562&range=01 Stats: 118 lines in 6 files changed: 10 ins; 87 del; 21 mod Patch: https://git.openjdk.org/jmc/pull/562.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/562/head:pull/562 PR: https://git.openjdk.org/jmc/pull/562 From schaturvedi at openjdk.org Tue May 28 06:13:08 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Tue, 28 May 2024 06:13:08 GMT Subject: Integrated: 7263: JMC displaying long value in scientific notation In-Reply-To: <9CRXwgKD0JNMm2YW6RkJYge0bxaXraK1eoY-0gYttEE=.aaac02c4-2346-4f22-96f9-48a8dc8a1d5f@github.com> References: <9CRXwgKD0JNMm2YW6RkJYge0bxaXraK1eoY-0gYttEE=.aaac02c4-2346-4f22-96f9-48a8dc8a1d5f@github.com> Message-ID: On Sat, 25 May 2024 21:06:38 GMT, Suchita Chaturvedi wrote: > This PR addresses the formatting issue for the certificate Ids for X509 Certificate and X509 Validation events. This pull request has now been integrated. Changeset: ad0ef9e7 Author: Suchita Chaturvedi URL: https://git.openjdk.org/jmc/commit/ad0ef9e72d6a6495ad63a629ce83958e1a44876b Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod 7263: JMC displaying long value in scientific notation Reviewed-by: vpurnam, hirt ------------- PR: https://git.openjdk.org/jmc/pull/564 From schaturvedi at openjdk.org Tue May 28 06:14:09 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Tue, 28 May 2024 06:14:09 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC In-Reply-To: References: Message-ID: On Mon, 27 May 2024 11:59:15 GMT, Marcus Hirt wrote: >> This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. >> >> The PID (Process Id) attribute is present in JMC as part of System Process event also where the data type is correct i.e. String. So in order to maintain consistency, we have made the content type of PID attribute of JVM Information event also as String. We are converting the number value of PID to string and then storing it. >> >> We have also introduced a new aggregator PID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page. > > core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAggregators.java line 118: > >> 116: // VM Info >> 117: public static final IAggregator JVM_NAME = distinctAsString(VM_INFO, JdkAttributes.JVM_NAME); >> 118: public static final IAggregator JVM_PID = min(JdkAttributes.JVM_PID.getName(), null, VM_INFO, > > Part of the public API. Perhaps better to deprecate? Do you mean to use @deprecated tag here instead of deleting it completely? ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/565#discussion_r1616646286 From bdutheil at openjdk.org Tue May 28 08:41:09 2024 From: bdutheil at openjdk.org (Brice Dutheil) Date: Tue, 28 May 2024 08:41:09 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC In-Reply-To: References: Message-ID: <8rYtE7jF9KtigoqnOUYFIBqWFjzWvBxm2ICl6qN9rNo=.40f47561-db56-40c8-b601-5bad95c0b473@github.com> On Tue, 28 May 2024 06:11:10 GMT, Suchita Chaturvedi wrote: >> core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/jdk/JdkAggregators.java line 118: >> >>> 116: // VM Info >>> 117: public static final IAggregator JVM_NAME = distinctAsString(VM_INFO, JdkAttributes.JVM_NAME); >>> 118: public static final IAggregator JVM_PID = min(JdkAttributes.JVM_PID.getName(), null, VM_INFO, >> >> Part of the public API. Perhaps better to deprecate? > > Do you mean to use @deprecated tag here instead of deleting it completely? Yeh otherwise, this would be a breaking change for consumer of the flight recorder libraries. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/565#discussion_r1616830005 From hirt at openjdk.org Tue May 28 11:32:29 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 28 May 2024 11:32:29 GMT Subject: RFR: 8215: Update platform to 2024-03 Message-ID: Platform update. ------------- Commit messages: - Merge branch 'openjdk:master' into 8215-update-2024-03 - Merge pull request #2 from viragpurnam/8215-modified - 8215: Update platform to 2024-03 - 8215: Update platform to 2024-03 Changes: https://git.openjdk.org/jmc/pull/566/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=566&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8215 Stats: 192 lines in 11 files changed: 168 ins; 4 del; 20 mod Patch: https://git.openjdk.org/jmc/pull/566.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/566/head:pull/566 PR: https://git.openjdk.org/jmc/pull/566 From hirt at openjdk.org Tue May 28 12:39:11 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 28 May 2024 12:39:11 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC In-Reply-To: <8rYtE7jF9KtigoqnOUYFIBqWFjzWvBxm2ICl6qN9rNo=.40f47561-db56-40c8-b601-5bad95c0b473@github.com> References: <8rYtE7jF9KtigoqnOUYFIBqWFjzWvBxm2ICl6qN9rNo=.40f47561-db56-40c8-b601-5bad95c0b473@github.com> Message-ID: On Tue, 28 May 2024 08:38:49 GMT, Brice Dutheil wrote: >> Do you mean to use @deprecated tag here instead of deleting it completely? > > Yeh otherwise, this would be a breaking change for consumer of the flight recorder libraries. Precisely. We can remove it in JMC 10. :) ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/565#discussion_r1617170294 From aptmac at openjdk.org Tue May 28 13:19:08 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Tue, 28 May 2024 13:19:08 GMT Subject: RFR: 8215: Update platform to 2024-03 In-Reply-To: References: Message-ID: <2aTFPP7FTRAV2If36WNju1HQ_a41UYMi84gGQibSzt8=.33041fd4-0542-472f-bfae-242b3a7cb725@github.com> On Tue, 28 May 2024 11:28:08 GMT, Marcus Hirt wrote: > Platform update. Left a few comments, I'll give it a more in-depth look but functionally it works well. releng/platform-definitions/pom.xml line 47: > 45: > 46: > 47: platform-definition-2024-03 Should any of the older platforms be removed at this time as well? Or save that for another PR? releng/third-party/pom.xml line 124: > 122: > 123: org.eclipse.jetty.ee9:jetty-ee9-servlet:${jetty.version} > 124: There's some interesting formatting going on in this file, some empty lines and incorrectly tabbing releng/tools/org.openjdk.jmc.util.listversions/src/org/openjdk/jmc/util/listversions/ListVersions.java line 107: > 105: case "org.eclipse.pde.feature.group": > 106: case "org.eclipse.platform.sdk": > 107: case "org.eclipse.equinox.p2.ui.sdk.scheduler": This file will need it's license header updated ------------- PR Review: https://git.openjdk.org/jmc/pull/566#pullrequestreview-2082760575 PR Review Comment: https://git.openjdk.org/jmc/pull/566#discussion_r1617228821 PR Review Comment: https://git.openjdk.org/jmc/pull/566#discussion_r1617227275 PR Review Comment: https://git.openjdk.org/jmc/pull/566#discussion_r1617227744 From hirt at openjdk.org Tue May 28 13:35:39 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 28 May 2024 13:35:39 GMT Subject: RFR: 8215: Update platform to 2024-03 [v2] In-Reply-To: References: Message-ID: > Platform update. Marcus Hirt has updated the pull request incrementally with two additional commits since the last revision: - Merge branch '8215-update-2024-03' of https://github.com/thegreystone/jmc into 8215-update-2024-03 - Fixing formatting ------------- Changes: - all: https://git.openjdk.org/jmc/pull/566/files - new: https://git.openjdk.org/jmc/pull/566/files/37ee73f6..dabca77a Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=566&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=566&range=00-01 Stats: 12 lines in 1 file changed: 4 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jmc/pull/566.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/566/head:pull/566 PR: https://git.openjdk.org/jmc/pull/566 From hirt at openjdk.org Tue May 28 13:35:40 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 28 May 2024 13:35:40 GMT Subject: RFR: 8215: Update platform to 2024-03 [v2] In-Reply-To: <2aTFPP7FTRAV2If36WNju1HQ_a41UYMi84gGQibSzt8=.33041fd4-0542-472f-bfae-242b3a7cb725@github.com> References: <2aTFPP7FTRAV2If36WNju1HQ_a41UYMi84gGQibSzt8=.33041fd4-0542-472f-bfae-242b3a7cb725@github.com> Message-ID: <6EgjloHKZ50DcTacrlUV62Rs9DS7kDfOgWH714kh62g=.24fedc8a-5fe2-4b41-8583-c839da1445e9@github.com> On Tue, 28 May 2024 13:15:38 GMT, Alex Macdonald wrote: >> Marcus Hirt has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge branch '8215-update-2024-03' of https://github.com/thegreystone/jmc into 8215-update-2024-03 >> - Fixing formatting > > releng/platform-definitions/pom.xml line 47: > >> 45: >> 46: >> 47: platform-definition-2024-03 > > Should any of the older platforms be removed at this time as well? Or save that for another PR? I'll do it in a separate PR. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/566#discussion_r1617253551 From hirt at openjdk.org Tue May 28 13:38:21 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 28 May 2024 13:38:21 GMT Subject: RFR: 8215: Update platform to 2024-03 [v3] In-Reply-To: References: Message-ID: > Platform update. Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Update license ------------- Changes: - all: https://git.openjdk.org/jmc/pull/566/files - new: https://git.openjdk.org/jmc/pull/566/files/dabca77a..eac217a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=566&range=02 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=566&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jmc/pull/566.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/566/head:pull/566 PR: https://git.openjdk.org/jmc/pull/566 From aptmac at openjdk.org Tue May 28 16:09:16 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Tue, 28 May 2024 16:09:16 GMT Subject: RFR: 8215: Update platform to 2024-03 [v3] In-Reply-To: References: Message-ID: On Tue, 28 May 2024 13:38:21 GMT, Marcus Hirt wrote: >> Platform update. > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Update license releng/third-party/pom.xml line 62: > 60: 2.1.12 > 61: 2.0.0 > 62: 12.0.6 This is where I think it gets a bit difficult for backwards compatibility. Because we're putting the jetty dependencies into the p2 repository, the changes to this pom affect all the platform definitions we use. So now that this is updated to use 12.0.6 and pull in the jetty ee9 dependencies (which are the 12.X.X), 2023-12 can't build because it's unable to find the 10.0.18 versions of the jetty-related dependencies. This is where I was originally taking a look but didn't get too far, but would it be possible to use the jetty dependencies that are shipped by Eclipse instead ([link](https://download.eclipse.org/releases/2024-03/202403131000/plugins/))? And this way each platform-definition we have could just reference the same version that is shipped by that Eclipse release? ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/566#discussion_r1617564909 From vpurnam at openjdk.org Fri May 31 11:01:10 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Fri, 31 May 2024 11:01:10 GMT Subject: RFR: 8215: Update platform to 2024-03 [v3] In-Reply-To: References: Message-ID: On Tue, 28 May 2024 16:06:29 GMT, Alex Macdonald wrote: > This is where I think it gets a bit difficult for backwards compatibility. Because we're putting the jetty dependencies into the p2 repository, the changes to this pom affect all the platform definitions we use. So now that this is updated to use 12.0.6 and pull in the jetty ee9 dependencies (which are the 12.X.X), 2023-12/2023-09/2023-03 can't build because it's unable to find the 10.0.18 versions of the jetty-related dependencies. > > This is where I was originally taking a look but didn't get too far, but would it be possible to use the jetty dependencies that are shipped by Eclipse instead ([link](https://download.eclipse.org/releases/2024-03/202403131000/plugins/))? And this way each platform-definition we have could just reference the same version that is shipped by that Eclipse release? For the class **WebsocketServer.java**, we need **org.eclipse.jetty.websocket.servlet (Jetty 10.0.18)** or **org.eclipse.jetty.ee9.websocket.servlet (Jetty 12.0.6)**. These are not present in https://download.eclipse.org/releases/2024-03/202403131000/plugins/. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/566#discussion_r1622233682 From vpurnam at openjdk.org Fri May 31 11:14:07 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Fri, 31 May 2024 11:14:07 GMT Subject: RFR: 8215: Update platform to 2024-03 [v3] In-Reply-To: References: Message-ID: On Fri, 31 May 2024 10:57:06 GMT, Virag Purnam wrote: >> releng/third-party/pom.xml line 62: >> >>> 60: 2.1.12 >>> 61: 2.0.0 >>> 62: 12.0.6 >> >> This is where I think it gets a bit difficult for backwards compatibility. Because we're putting the jetty dependencies into the p2 repository, the changes to this pom affect all the platform definitions we use. So now that this is updated to use 12.0.6 and pull in the jetty ee9 dependencies (which are the 12.X.X), 2023-12/2023-09/2023-03 can't build because it's unable to find the 10.0.18 versions of the jetty-related dependencies. >> >> This is where I was originally taking a look but didn't get too far, but would it be possible to use the jetty dependencies that are shipped by Eclipse instead ([link](https://download.eclipse.org/releases/2024-03/202403131000/plugins/))? And this way each platform-definition we have could just reference the same version that is shipped by that Eclipse release? > >> This is where I think it gets a bit difficult for backwards compatibility. Because we're putting the jetty dependencies into the p2 repository, the changes to this pom affect all the platform definitions we use. So now that this is updated to use 12.0.6 and pull in the jetty ee9 dependencies (which are the 12.X.X), 2023-12/2023-09/2023-03 can't build because it's unable to find the 10.0.18 versions of the jetty-related dependencies. >> >> This is where I was originally taking a look but didn't get too far, but would it be possible to use the jetty dependencies that are shipped by Eclipse instead ([link](https://download.eclipse.org/releases/2024-03/202403131000/plugins/))? And this way each platform-definition we have could just reference the same version that is shipped by that Eclipse release? > > > > For the class **WebsocketServer.java**, we need **org.eclipse.jetty.websocket.servlet (Jetty 10.0.18)** or **org.eclipse.jetty.ee9.websocket.servlet (Jetty 12.0.6)**. These are not present in https://download.eclipse.org/releases/2024-03/202403131000/plugins/. And I think this problem was there from the beginning not only for jetty but for other libraries too. Or may be we can have separate **third-party/pom.xml** for each **target platform**. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/566#discussion_r1622266022 From aptmac at openjdk.org Fri May 31 20:31:10 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Fri, 31 May 2024 20:31:10 GMT Subject: RFR: 8215: Update platform to 2024-03 [v3] In-Reply-To: References: Message-ID: On Tue, 28 May 2024 13:38:21 GMT, Marcus Hirt wrote: >> Platform update. > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Update license If we're only looking to support the latest Eclipse platform as mentioned on Slack, then I think these changes are okay, and then a follow-up PR could be made to pull all the old versions. ------------- Marked as reviewed by aptmac (Reviewer). PR Review: https://git.openjdk.org/jmc/pull/566#pullrequestreview-2091667921 From aptmac at openjdk.org Fri May 31 20:31:10 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Fri, 31 May 2024 20:31:10 GMT Subject: RFR: 8215: Update platform to 2024-03 [v3] In-Reply-To: References: Message-ID: <4uYrBHdzHhuVLkk7Gr6fz4oQl5vunt-QrQUYeL_Q62M=.a7c4e782-a516-4905-9709-69bf1ee2192f@github.com> On Fri, 31 May 2024 11:11:27 GMT, Virag Purnam wrote: >>> This is where I think it gets a bit difficult for backwards compatibility. Because we're putting the jetty dependencies into the p2 repository, the changes to this pom affect all the platform definitions we use. So now that this is updated to use 12.0.6 and pull in the jetty ee9 dependencies (which are the 12.X.X), 2023-12/2023-09/2023-03 can't build because it's unable to find the 10.0.18 versions of the jetty-related dependencies. >>> >>> This is where I was originally taking a look but didn't get too far, but would it be possible to use the jetty dependencies that are shipped by Eclipse instead ([link](https://download.eclipse.org/releases/2024-03/202403131000/plugins/))? And this way each platform-definition we have could just reference the same version that is shipped by that Eclipse release? >> >> >> >> For the class **WebsocketServer.java**, we need **org.eclipse.jetty.websocket.servlet (Jetty 10.0.18)** or **org.eclipse.jetty.ee9.websocket.servlet (Jetty 12.0.6)**. These are not present in https://download.eclipse.org/releases/2024-03/202403131000/plugins/. > > And I think this problem was there from the beginning not only for jetty but for other libraries too. Or may be we can have separate **third-party/pom.xml** for each **target platform**. > For the class **WebsocketServer.java**, we need **org.eclipse.jetty.websocket.servlet (Jetty 10.0.18)** or **org.eclipse.jetty.ee9.websocket.servlet (Jetty 12.0.6)**. These are not present in https://download.eclipse.org/releases/2024-03/202403131000/plugins/. Ah right, that's unfortunate. In response to Marcus' comment on Slack maybe it's best to do away with trying to keep all these platforms and just maintain the most current version. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/566#discussion_r1622921999