11:01 a.m.
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> 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