Wildfly 27.0.01 (JMX Configuration)

85 views
Skip to first unread message

Tushal Joggesser

unread,
Feb 18, 2025, 6:42:53 AMFeb 18
to WildFly
Hi Team, 

I'm trying to configure JMX for local profiling but could not find any proper resource to get it working with JMC.
Currently the application is deployed on wildfly on a docker container. 

Can anyone advise? 

The current configuration: 
<subsystem xmlns="urn:jboss:domain:jmx:1.3">
<expose-resolved-model/>
<expose-expression-model/>
<remoting-connector use-management-endpoint="true"/>
</subsystem>

Kindly advise if there's any proper documentation i need to follow.

Brian Stansberry

unread,
Feb 19, 2025, 5:04:37 PMFeb 19
to WildFly
Hi,

What JMC version are you using, and what Java SE version, both for the JMC process and the WildFly?

I'm asking because we've learned of some issue with using JMC 9 with WildFly.

I want to write up some general instructions about this, but would also like to know your details.

Best regards,
Brian

Brian Stansberry

unread,
Feb 19, 2025, 6:52:51 PMFeb 19
to WildFly
What I'll describe below doesn't work with JMC 9, but it works fine with JMC 8.3. Apologies in advance if this gets into too much detail about things you already know. This post is a rough draft of a blog post, so I'll be a bit overly detailed.

The most fundamental point is people may be accustomed to using JMC or JConsole with a locally running WildFly, and it 'just works'. But that's because it's using a local JMX connection. That won't work when WildFly is in a container; a remote connection is required.

Also, WildFly's OOTB config is configured to support a custom 'LOCAL' authentication scheme, where a network client can authenticate by demonstrating it can read a file owned by the WildFly process. This allows things like a CLI process running on the same machine to connect without requiring a username or password. That also won't work with WildFly in a container, as the container filesystem is not accessible to the JMC process.

So, WildFly needs to be configured with a management user. I set that up by using a WildFly installation's $WILDFLY_HOME/bin/add-user.sh tool and adding a management user. I then grabbed the $WILDFLY_HOME/standalone/configuration/mgmt-users.properties and mgmt-groups.properties that add-user.sh updated for inclusion in my WildFly podman image. (You can substitute 'docker' for 'podman' anywhere in this post.)

So a simple Dockerfile

FROM quay.io/wildfly/wildfly:27.0.1.Final-jdk17
COPY --chown=jboss:root mgmt-users.properties $JBOSS_HOME/standalone/configuration/
COPY --chown=jboss:root mgmt-groups.properties $JBOSS_HOME/standalone/configuration/

I imagine you already do more than that, e.g. adding an actual deployment. :)

To build:

podman build -t jmc_wildfly:latest

To run the container:

podman run --rm -p 8080:8080 -p 127.0.0.1:9990:9990 --name=jmc_wildfly jmc_wildfly /opt/jboss/wildfly/bin/standalone.sh -bmanagement 0.0.0.0

The '-p 127.0.0.1:9990:9990' is important to expose the management port so JMC can connect. The '/opt/jboss/wildfly/bin/standalone.sh -bmanagement 0.0.0.0' is to tell WildFly to bind the management interface to 0.0.0.0 instead of the default 127.0.0.1. Binding to 127.0.0.1 doesn't work, as the WildFly container won't see traffic coming from outside the container as arriving on *its* localhost, so it won't receive it. The '/opt/jboss/wildfly/bin/standalone.sh -bmanagement 0.0.0.0' bit is not needed if your standalone.xml already has the management interface configured to bind to 0.0.0.0.


Okay, now the tricky part.


You go into JMC and go to File / Connect / Create a new connection

In the JVM Connection dialog you select 'Custom JMX service URL'

In the JMX service URL, put in: service:jmx:remote+http://localhost:9990

Fill in the User and Password fields with the info for the management user.

And.... it doesn't work. When you try to connect it fails with an 'Unsupported protocol: remote+http' failure message.


To fix that you need to update JMC so it understands the JBoss Remoting 'remote+http' protocol that WildFly uses. To do that you need to copy the $WILDFLY_HOME/bin/client/jboss-client.jar jar to the 'dropins' directory in your JMC installation. Exactly where that is varies. On the OSX machine I'm using this afternoon it's in /Applications/JDK\ Mission\ Control.app/Contents/Eclipse/dropins/.

Once that's there, restart JMC and you can connect to your WildFly container!

Again, this doesn't work with JMC 9. The jboss-client.jar's MANIFEST.mf includes some attributes to allow integration with JMC, and it seems that JMC 9 requires a different value for one of them than it needed before.

HTH.

Best regards,
Brian

tus...@softconnectltd.com

unread,
Feb 20, 2025, 12:06:23 AMFeb 20
to Brian Stansberry, WildFly

Hi Brian,

Thanks for the details.
I have tried the steps you’ve shared and it worked.
I was using JMC 9 with Java SE 17.

Thank you. J

 

Regards,

Tushal

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wildfly/7b6779a1-1d98-47e4-9734-979a8308d3c5n%40googlegroups.com.

Brian Stansberry

unread,
Feb 20, 2025, 10:01:56 AMFeb 20
to WildFly
Oh; great!  Maybe I did something wrong with JMC 9. We had reports of problems with JMC 9 and I experienced what was described in those reports, but maybe it was resolved and I just did something wrong.

I got the current JMC 9 from Adoptium so it's also possible it works in one from Oracle; I'll try that.

Reply all
Reply to author
Forward
0 new messages