jboss-cli-client.jar
from JBoss AS 7.x / JBoss EAP 6.x bin/client/
folderjboss-cli-client.jar
and jboss-modules.jar
from JBoss 4 bin/
folderand include them into the classpath to start JConsole and JVisualVM like in the following scripts:
@echo off set CLASSPATH=%JAVA_HOME%\lib\jconsole.jar;%JAVA_HOME%\lib\tools.jar;jboss-cli-client.jar;jboss-modules.jar "%JAVA_HOME%\bin\jconsole.exe" "-J-Djava.class.path=%CLASSPATH%" %1 %2 %3 %4 %5 %6 %7 %8 %9
The native endpoint is configured using the following configuration snippet:
<security-realms> <security-realm name="ManagementRealm"> <authentication> <local default-user="$local"/> <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/> </authentication> </security-realm> </security-realms> <management-interfaces> <native-interface security-realm="ManagementRealm"> <socket-binding native="management-native"/> </native-interface> </management-interfaces>
<local default-user="$local"/>
configures a special JBOSS-LOCAL-USER SASL mechanism which is based on the client being able to read a challenge file (e.g. jboss6/standalone/tmp/auth/challenge-6842367
) to prove that it is local. That means if you have only that option configured in realm, remote clients are rejected. However they can access endpoint through
To enable access for remote users, one should create/use management user.
$ ./jboss6/bin/add-user.sh What type of user do you wish to add? a) Management User (mgmt-users.properties) b) Application User (application-users.properties) (a): a
The remoting endpoint is configured using the following configuration snippet:
<subsystem xmlns="urn:jboss:domain:remoting:1.1"> <connector name="remoting-connector" security-realm="ApplicationRealm" socket-binding="remoting"/> </subsystem>
For simplicity one may wish to remove authentication (less hassle with adding users via bin/add-user.sh
):
--- jboss6/standalone/configuration/standalone.xml.orig 2015-08-11 19:14:52.000000000 +0200 +++ jboss6/standalone/configuration/standalone.xml 2015-08-11 19:34:12.000000000 +0200 @@ -340,7 +340,7 @@ </subsystem> <subsystem xmlns="urn:jboss:domain:pojo:1.0"/> <subsystem xmlns="urn:jboss:domain:remoting:1.1"> - <connector name="remoting-connector" security-realm="ApplicationRealm" socket-binding="remoting"/> + <connector name="remoting-connector" socket-binding="remoting"/> </subsystem> <subsystem xmlns="urn:jboss:domain:resource-adapters:1.1"/> <subsystem xmlns="urn:jboss:domain:sar:1.0"/>
To enable remoting endpoint, apply the following patch (if not yet applied):
--- jboss6/standalone/configuration/standalone.xml.orig 2015-08-11 19:14:52.000000000 +0200 +++ jboss6/standalone/configuration/standalone.xml 2015-08-11 19:34:12.000000000 +0200 @@ -267,7 +267,7 @@ <subsystem xmlns="urn:jboss:domain:jmx:1.3"> <expose-resolved-model/> <expose-expression-model/> - <remoting-connector/> + <remoting-connector use-management-endpoint="false"/> </subsystem> <subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="udp"> <stack name="udp">
Now the connection should work:
jconsole.bat service:jmx:remoting-jmx://10.0.0.1:4447
jvisualvm.bat --openjmx service:jmx:remoting-jmx://10.0.0.1:4447
> ssh -D 1080 184.3.2.1 > jconsole.bat -J-DsocksProxyHost=localhost -J-DsocksProxyPort=1080 service:jmx:remoting-jmx://10.0.0.1:4447
Troubleshooting:
From JMX connections to JBoss AS:
The native management endpoint is exposed by default on port 9999. The remoting endpoint is exposed by default on port 4447. By default you can connect to JBoss AS to access JMX using the native management interface. To use the remoting interface you need to manually change the JBoss AS configuration.
When you decide to change the configuration and use the remoting endpoint for JMX access, the native management endpoint will stop working. You cannot use both endpoints on one host.
See also:
javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:367) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:229) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180) at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
means that all authentication methods have failed. Make sure that the corresponding security realm has enough means to authenticate the user (e.g. property file is correctly configured).
jconsole.bat -debug -J-Djavax.net.debug=all -J-Djava.security.debug=gssloginconfig,configfile,configparser,logincontext,policy -J-Djava.util.logging.config.file=logging.properties service:jmx:remoting-jmx://10.0.0.1:4447
# Comma separated list of log Handler classes that will be installed during VM startup. #java.util.logging.ConsoleHandler, handlers = java.util.logging.FileHandler # Default global logging level. .level = INFO # Handler specific properties. java.util.logging.FileHandler.level = FINEST java.util.logging.FileHandler.pattern = jconsole.log java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter java.util.logging.ConsoleHandler.level = FINEST java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter java.util.logging.SimpleFormatter.format=%1$tF %1$tT.%1$tL %4$s [%2$s] %5$s%n # Facility specific properties. javax.management.level = FINEST javax.management.remote.level = FINEST #sun.rmi.level = FINEST
TRACE [org.jboss.remoting3.remote.RemoteConnectionProvider connect] Attempting to connect to "/10.0.0.1:4447" with options {org.xnio.Options.SASL_DISALLOWED_MECHANISMS=>[JBOSS-LOCAL-USER],org.xnio.Options.SASL_POLICY_NOANONYMOUS=>false,org.xnio.Options.SASL_PROPERTIES=>[(jboss.sasl.local-user.quiet-auth=>true)],org.xnio.Options.SSL_STARTTLS=>true,org.xnio.Options.SASL_POLICY_NOPLAINTEXT=>false,org.xnio.Options.SSL_ENABLED=>true} TRACE [org.jboss.remoting3.remote.ClientConnectionOpenListener handleEvent] Setting read listener to org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting@74a069ce TRACE [org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting handleEvent] Client received greeting TRACE [org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting handleEvent] Client received server name: 10.0.0.1 TRACE [org.jboss.remoting3.remote.ClientConnectionOpenListener sendCapRequest] Client sending capabilities request TRACE [org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities handleEvent] Client received capabilities response TRACE [org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities handleEvent] Client received capability: version 1 TRACE [org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities handleEvent] Client received capability: SASL mechanism ANONYMOUS TRACE [org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities handleEvent] SASL mechanism ANONYMOUS added to allowed set TRACE [org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities handleEvent] Client received capability: message close protocol supported TRACE [org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities handleEvent] Client received capability: remote version is "3.3.4.Final-redhat-1" TRACE [org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities handleEvent] Client received capability: remote channels in is "40" TRACE [org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities handleEvent] Client received capability: remote channels out is "40" TRACE [org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities handleEvent] Client initiating authentication using mechanism ANONYMOUS TRACE [org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities$2 run] Client authentication failed: javax.security.sasl.SaslException: Authentication name is empty DEBUG [org.jboss.remoting3.remote.RemoteConnection handleException] JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: the server presented no authentication mechanisms
try to enable Do not require SSL connection option in Add JMX Connection dialog.
javaee.api
has to be excluded, because that module explicitly depends on javax.ws.rs.api
(and many others).META-INF\services\javax.ws.rs.ext.Providers
. If JBoss-wide provider is available in classpath, the API 2.x classes this module is compiled against are loaded. Other classes not used by that module but maybe referenced later by 3.x provider will be loaded from application dependency API 3.x. After that happens the classpath contains the deadly mixture of classes from both APIs, hence it might be that for these two classes org.jboss.resteasy.plugins.providers.jaxb.AbstractJAXBProvider<T> extends AbstractEntityProvider<T> { ... } org.jboss.resteasy.plugins.providers.AbstractEntityProvider<T> implements MessageBodyReader<T>, MessageBodyWriter<T> { ... }
the expression MessageBodyReader.class.isAssignableFrom(AbstractJAXBProvider.class)
would be false
, because there are two MessageBodyReader
interfaces (2.x and 3.x) in classpath.
Complete solution:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"> <sub-deployment name="artifact-${project.version}.war"> <exclusions> <!-- This module has to be excluded as it has explicit dependency on javax.ws.rs.api --> <module name="javaee.api" /> <module name="javax.ws.rs.api" /> <!-- org.jboss.resteasy:jaxrs-api --> <module name="org.jboss.resteasy.resteasy-jaxrs" /> <!-- org.jboss.resteasy:resteasy-jaxrs --> <!-- All providers has to be excluded, as otherwise API classes leak through dynamic loading of these providers. --> <module name="org.jboss.resteasy.resteasy-jaxb-provider" /> <!-- org.jboss.resteasy:resteasy-jaxb-provider --> <module name="org.jboss.resteasy.resteasy-jettison-provider" /> <!-- org.jboss.resteasy:resteasy-jettison-provider --> <module name="org.jboss.resteasy.resteasy-atom-provider" /> <module name="org.jboss.resteasy.resteasy-jackson-provider" /> <module name="org.jboss.resteasy.resteasy-hibernatevalidator-provider" /> <module name="org.jboss.resteasy.resteasy-multipart-provider" /> <module name="org.jboss.resteasy.resteasy-yaml-provider" /> </exclusions> </sub-deployment> </jboss-deployment-structure>
References:
com.sun.xml.messaging.saaj:saaj-impl
, the following exception is thrown:Caused by: java.lang.NoClassDefFoundError: com/sun/org/apache/xerces/internal/dom/DocumentImpl at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_24] at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) [rt.jar:1.6.0_24] at java.lang.ClassLoader.defineClass(ClassLoader.java:616) [rt.jar:1.6.0_24]
jboss-deployment-structure.xml
:META-INF/jboss-deployment-structure.xml
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"> <sub-deployment name="${war.artifactId}-${project.version}.war"> <dependencies> <system> <paths> <!-- xerces:xercesImpl --> <path name="com/sun/org/apache/xerces/internal/dom" /> <path name="com/sun/org/apache/xerces/internal/jaxp" /> <path name="com/sun/org/apache/xerces/internal/util" /> </paths> </system> </dependencies> </sub-deployment> </jboss-deployment-structure>
or better remove this dependency and export it from module:
META-INF/jboss-deployment-structure.xml
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"> <sub-deployment name="artifact-${project.version}.war"> <dependencies> <!-- com.sun.xml.messaging.saaj:saaj-impl --> <module name="com.sun.xml.messaging.saaj" /> </dependencies> </sub-deployment> </jboss-deployment-structure>
References: