Hi, the WildFly management resources that expose JVM MXBeans in */core-service=platform-mbean* need a refresh and some evolutions. For full details on what is proposed, you can look at the WildFly proposal: https://github.com/wildfly/wildfly-proposals/pull/729 We have chosen to align to the JDK 11 API (with some exceptions to expose JDK 14 defined attributes that replace attributes introduced in JDK11 but already deprecated). This JDK 11 constraint is to align with WildFly core minimal supported version although the platform-mbean resource is used in WildFly that has a minimal version of JDK 17. We will continue this evolution to follow the minimal versions in order to avoid technical debt. Exposing new standard features We plan to expose new attributes and operations defined in the standard Platform MXBean API . Exposing the read-only attributes of the *PlatformLoggingMXBean* This MXBean is older than JDK 11 but has not been exposed due to potential conflict with the Logging subsystem. Although the management of loggers is done thanks to the logging subsystem, exposing the available loggers in the WildFly management model is a way to discover what are the logger names that one can enable using the logging subsystem. Exposing the attributes and operations defined in the *com.sun.management* package Attributes and operations defined by such MXBeans are aggregated to the existing WildFly resources. No new management resources are added. Although supported by all OpenJDK based JDK, this API is not standard. In order to cope with this, we are using the JMX reflective access to the attributes and operations allowing us to expose a static management model with an implementation that adapts to the JVM capabilities.

The work on this feature is tracked by the PR: https://github.com/wildfly/wildfly-core/pull/6411 Brian (that implemented initially this integration) already volunteered to be an sme. Thank-you. JF _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...

On Fri, May 16, 2025 at 6:01 PM Brian Stansberry <bstansbe(a)redhat.com&gt; wrote: Thanks, Jean Francois. More inline... On Fri, May 16, 2025 at 4:58 AM Jean Francois Denise via wildfly-dev <wildfly-dev(a)lists.jboss.org&gt; wrote: Hi, the WildFly management resources that expose JVM MXBeans in //core-service=platform-mbean/ need a refresh and some evolutions. For full details on what is proposed, you can look at the WildFly proposal: https://github.com/wildfly/wildfly-proposals/pull/729 We have chosen to align to the JDK 11 API (with some exceptions to expose JDK 14 defined attributes that replace attributes introduced in JDK11 but already deprecated). This JDK 11 constraint is to align with WildFly core minimal supported version although the platform-mbean resource is used in WildFly that has a minimal version of JDK 17. We will continue this evolution to follow the minimal versions in order to avoid technical debt. Exposing new standard features We plan to expose new attributes and operations defined in the standard Platform MXBean API . Exposing the read-only attributes of the /PlatformLoggingMXBean/ This MXBean is older than JDK 11 but has not been exposed due to potential conflict with the Logging subsystem. Although the management of loggers is done thanks to the logging subsystem, exposing the available loggers in the WildFly management model is a way to discover what are the logger names that one can enable using the logging subsystem. Exposing the attributes and operations defined in the /com.sun.management/ package Attributes and operations defined by such MXBeans are aggregated to the existing WildFly resources. No new management resources are added. Although supported by all OpenJDK based JDK, this API is not standard. In order to cope with this, we are using the JMX reflective access to the attributes and operations allowing us to expose a static management model with an implementation that adapts to the JVM capabilities. This aspect is one I want to draw attention to, in case anyone has any thoughts. These (and maybe the PlatformLoggingMXBean bit) are what make this a feature, and not just a bug fix to adding missing stuff that's accumulated since the last refresh of this ages ago. Jean Francois, please correct me if I'm wrong about the following: What this proposes doing is exposing attributes/operations that are available via the generic detyped JMX APIs (e.g. MBeanServerConnection) when using an ObjectName used by a platform mbean, e.g. java.lang:type=OperatingSystem. But these APIs are not part of the typed Java APIs in the java.lang.management package; e.g. java.lang.management.OperatingSystemMXBean. Instead they are exposed via APIs in the jdk.management module's com.sun.management package, e.g. com.sun.management.OperatingSystemMXBean. WildFly already depends on the jdk.management module, so whether or not it will be present is not an issue. As Jean Francois noted, all OpenJDK based JDKs expose these attributes and operations via their remote JMX APIs. The risk here is in theory some JDK may not expose these JMX attributes/operations. If so, the WF management API will return undefined as their value. I'm not sure what the plan is for writes to unavailable API. Brian, yes that is correct. I precised in the proposal what happens in case of read/write/invocation for items defined in the management model but not implemented by the underlying JVM. I spotted a leftover in the implementation BTW. * When reading a WildFly model attribute that does exist but is not supported by the JVM, the attribute value is set to /undefined/. * When writing a WildFly model attribute that does exist but is not supported by the JVM, an /OperationFailed/ exception is thrown. * When invoking a WildFly model operation that does exist but is not supported by the JVM, an /OperationFailed/ exception is thrown. We don't depend at all on the/jdk.management /module./jdk.management/ would be needed if we were loading the classes located in the /com.sun.management/ package. We depend on /java.management/ for the JMX API that is part of the standard Java runtime API. The work on this feature is tracked by the PR: https://github.com/wildfly/wildfly-core/pull/6411 Brian (that implemented initially this integration) already volunteered to be an sme. Thank-you. JF _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... -- Brian Stansberry Principal Architect, Red Hat JBoss EAP WildFly Project Lead He/Him/His _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...