I'll provide the oustide perspective person :)
Cheers,
Emmanuel
Le 19/05/2025 à 10:52, Jean Francois Denise via wildfly-dev a écrit :
On Fri, May 16, 2025 at 6:01 PM Brian Stansberry <bstansbe(a)redhat.com> 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> 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...