JBoss

@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

@echo off
 
set CLASSPATH=%JAVA_HOME%\lib\tools.jar;jboss-cli-client.jar;jboss-modules.jar
 
"%JAVA_HOME%\bin\jvisualvm.exe" "-cp:a" "%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

the tunnel

the tunnelled X protocol

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:

• Troubleshooting connection problems in JConsole
• Troubleshooting Security
• JConsole remote connection to JBoss EAP

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)

# 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

• Module javaee.api has to be excluded, because that module explicitly depends on javax.ws.rs.api (and many others).
• All providers (even those which are not used by the application) have to be excluded. The problem is that during the application startup, RESTEasy scans the classpath for 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:

• JBoss Modules Suck, It’s Impossible To Use Custom Resteasy/JAX-RS Under JBoss 7
• You cannot do much if the JBoss server modules cannot be updated
• Impossible to ignore module javax.ws.rs.api and use other than bundled RestEasy
• RestEasy 3.0 keeps throwing NoSuchMethodError

<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:

<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:

• Preparing OpenAM & JBoss AS 7 / EAP 6
• java.lang.NoClassDefFoundError com/sun/net/ssl/internal/ssl/Provider in Jboss 7
• Deploying Geoserver 2.5 using JBoss 7.1.1
• JBoss 7.1 Beta1 no longer has the system module