[wildfly-dev] Re: Request for a feature team -- Platform MBean evolution

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.

> 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