====== [[http://www.jboss.org/|JBoss]] ======

  * [[http://labs.jboss.com/jbossas/downloads|JBoss release notes]]


===== Questions answered =====

=== How to connect to JBoss via JMX? ===

<note tip>
<note>
First of all JBoss 6 uses [[https://jcp.org/en/jsr/detail?id=160|JSR-160]] extension for JMX protocol, and in order to enable support of it, copy the files:
  * ''jboss-cli-client.jar'' from JBoss AS 7.x / JBoss EAP 6.x ''bin/client/'' folder
  * ''jboss-cli-client.jar'' and ''jboss-modules.jar'' from JBoss 4 ''bin/'' folder
and include them into the classpath to start JConsole and JVisualVM like in the following scripts:

<code dos|jconsole.bat>
@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
</code>

<code dos|jvisualvm.bat>
@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
</code>
</note>

**The native endpoint** is configured using the following configuration snippet:

<code xml>
<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>
</code>

''%%<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
<folded|the tunnel>''ssh -L9999:127.0.0.1:9999 10.0.0.1''</folded>
<folded|the tunnelled X protocol>
  - Start local X server: \\
    {{jboss_xserver.png|Start local X server}}
  - Enable X11 forwarding: \\
    {{jboss_xforwarding.png|Enable X11 forwarding for SSH session}}
  - Start SSH session and launch jConsole: \\
    ''user@server:/local/jboss/bin> ./jconsole.sh'' \\
    {{ jboss_jconsole_remote.png?500|jConsole running remotely}} {{jboss_jconsole_remote_start.png|jConsole running remotely}}
</folded>

To enable access for remote users, one should create/use management user.

<note>
When adding a user make sure it is added to correct realm:

<code console>
$ ./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
</code>
</note>

**The remoting endpoint** is configured using the following configuration snippet:

<code xml>
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
  <connector name="remoting-connector" security-realm="ApplicationRealm" socket-binding="remoting"/>
</subsystem>
</code>

For simplicity one may wish to remove authentication (less hassle with adding users via ''bin/add-user.sh''):

<code diff>
--- 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"/>  
</code>

To enable remoting endpoint, apply the following patch (if not yet applied):

<code diff>
--- 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"> 
</code>

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%%''

<note>
If JBoss server is not directly accessible but there is SSH-access to the zone, one can use socks proxy:

<code console>
> ssh -D 1080 184.3.2.1
> jconsole.bat -J-DsocksProxyHost=localhost -J-DsocksProxyPort=1080 service:jmx:remoting-jmx://10.0.0.1:4447
</code>
</note>

{{ jboss_jconsole_local.png?500}}

**Troubleshooting:**

From [[http://planet.jboss.org/post/jmx_connections_to_jboss_as|JMX connections to JBoss AS]]:

<blockquote>
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.
</blockquote>

See also:
  * [[https://blogs.oracle.com/jmxetc/entry/troubleshooting_connection_problems_in_jconsole|Troubleshooting connection problems in JConsole]]
  * [[https://docs.oracle.com/javase/7/docs/technotes/guides/security/troubleshooting-security.html|Troubleshooting Security]]
  * [[stackoverflow>25046317|JConsole remote connection to JBoss EAP]]

<note>
The given exception
<code>
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)
</code>
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).
</note>

<note>
To start JConsole with logging enabled use this:

''%%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%%''

<code properties|logging.properties>
# 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
</code>
</note>

<note>
If Visual VM fails with such log:

<code console|jvisualvm.log>
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
</code>

try to enable //Do not require SSL connection// option in //Add JMX Connection// dialog.
</note>

</note> <!-- end of <note tip> -->


=== How to enable Reasteasy 3 on JBoss 6 running Reasteasy 2? ===

<note tip>
Two prerequisites:
  * 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
    <code java5>
org.jboss.resteasy.plugins.providers.jaxb.AbstractJAXBProvider<T> extends AbstractEntityProvider<T> { ... }

org.jboss.resteasy.plugins.providers.AbstractEntityProvider<T> implements MessageBodyReader<T>, MessageBodyWriter<T> { ... }
</code> 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:

<code xml>
<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>
</code>

References:
  * [[http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s|JBoss Modules Suck, It’s Impossible To Use Custom Resteasy/JAX-RS Under JBoss 7]]
  * [[https://community.jboss.org/thread/241502#877023|You cannot do much if the JBoss server modules cannot be updated]]
  * [[https://access.redhat.com/site/discussions/711843|Impossible to ignore module javax.ws.rs.api and use other than bundled RestEasy]]
  * [[stackoverflowa>17872480/267197|RestEasy 3.0 keeps throwing NoSuchMethodError]]
</note>


=== How to import Sun JDK packages into classpath? ===

<note question>
When deploying the application with included dependency ''com.sun.xml.messaging.saaj:saaj-impl'', the following exception is thrown:

<code>
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]
</code>
</note>
<note tip>
Use the following ''jboss-deployment-structure.xml'':

<code 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>
</code>

or better remove this dependency and export it from module:

<code xml|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>
</code>

References:
  * [[http://openam.forgerock.org/openam-documentation/openam-doc-source/doc/webhelp/install-guide/prepare-jboss-7.html|Preparing OpenAM & JBoss AS 7 / EAP 6]]
  * [[stackoverflowa>14892892/267197|java.lang.NoClassDefFoundError com/sun/net/ssl/internal/ssl/Provider in Jboss 7]]
  * [[http://gis.stackexchange.com/a/95037|Deploying Geoserver 2.5 using JBoss 7.1.1]]
  * [[https://community.jboss.org/message/641326#723349|JBoss 7.1 Beta1 no longer has the system module]]
</note>


{{tag>JBoss}}