Thanks, Jean Francois.More inline...On Fri, May 16, 2025 at 4:58 AM Jean Francois Denise via wildfly-dev <wildfly-dev@lists.jboss.org> 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/729We 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 featuresWe plan to expose new attributes and operations defined in the standard Platform MXBean API .Exposing the read-only attributes of the PlatformLoggingMXBeanThis 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 packageAttributes 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/6411Brian (that implemented initially this integration) already volunteered to be an sme.Thank-you.JF
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@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/K4FZCP37H4D5GY5UDT72CCSQP3BOTWWK/
--Brian StansberryPrincipal Architect, Red Hat JBoss EAPWildFly Project LeadHe/Him/His