Tag Archives: JBoss

Looking for JBoss Maven Repository?

JBoss has decommissioned their Maven 2 repository (about an year ago according to their site) which was available at http://repository.jboss.org/maven2. But many resources out there still refer to this repository, and many people face the following error when they try to use this repository.

Access denied to: http://repository.jboss.org/maven2

This is because JBoss has deactivated this repository and setup a 403 (HTTP Forbidden) error on this URL. After googling for a while, reading through JIRA entries etc., I found this page which pointed to a new repository from JBoss that contains most (if not all) of the artifacts from the previous one. The new repository URL is http://repository.jboss.org/nexus/content/groups/public-jboss/.

It could have been better if JBoss could have given a hint about this in their old repository URL, instead of sending a 403, which gives no clues.

In fact, as the URL indicates, this is a Nexus Maven Repository instance. You can access the Nexus Repository Manager from http://repository.jboss.org/nexus/ which lists all repositories hosted in it.

JBoss JMX Console Vulnerability – Standard Security Is Not Enough !

On 20th October 2011 JBoss released a Security Alert, informing about the existence of a worm which makes use of a security loophole in JBoss JMX Console to attack servers out there in the web. According to this notice, users running unsecured JMX consoles were vulnerable to this attack.

I’ve been running several JBoss Application Server instances exposed to the web, but I always ensure that JMX Console and other management features of JBoss are secured before exposing it to the web. I usually use the standard Username/Password login module for authentication for these JBoss services (I know it’s not very secure, but that was sufficient). Initially when I was setting this up, I referred to this article from JBoss : http://community.jboss.org/wiki/SecureTheJmxConsole [Note: Now it is updated to include the additional steps to protect against this threat].

According to the security alert, password protected JMX consoles were safe from this threat. Since it was password protected, I thought I was secure against this threat. I couldn’t have been more wrong, and I had to learn it the hard way.
Continue reading

JBoss – Changing RMI Remote Client Callback Address

Recently during a JBoss production deployment (4.2.3.GA) that I had to carry on, I came across a problem with RMI Remoting (EJB3), which gave an exception when remote EJBs are invoked. The exception I got was ‘java.lang.IllegalArgumentException: port out of range:-1’, whenever a Remote EJB call was made.

12:57:58,354 WARN  [ServiceExceptionTranslatorAspect] Unable to Translate Exception : org.jboss.remoting.CannotConnectException
12:57:58,402 ERROR [[default]] Servlet.service() for servlet default threw exception
java.lang.IllegalArgumentException: port out of range:-1
at java.net.InetSocketAddress.<init>(InetSocketAddress.java:118)
at org.jboss.remoting.transport.socket.SocketClientInvoker.createSocket(SocketClientInvoker.java:183)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:827)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:569)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
at org.jboss.remoting.Client.invoke(Client.java:1634)
at org.jboss.remoting.Client.invoke(Client.java:548)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:67)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107)

The application was working fine in our local environments, and this problem happened only in production. This deployment consisted of two JBoss AS instances running two applications, which communicates with each other via EJB Remoting.

Googling did not give me any positive lead, and I was stuck on this problem for a while. So I tried out the only option I was left with, trying to go to detailed log output to see what’s happening under the hood. After changing the log level for CONSOLE and org.jboss category to DEBUG level (if you are new to JBoss, you can change the logging mechanism by modifying jboss-log4j.xml in conf directory of server profile).

This gave me the following output.

12:21:41,049 DEBUG [AuthenticationContextInterceptor] AuthenticationContextInterceptor Intercepting EJB Invocation...
12:21:41,049 DEBUG [AuthenticationContextInterceptor] Setting the authenticated user details in Authentication Context: XXXX
12:21:41,061 DEBUG [AuthenticationContextInterceptor] AuthenticationContextInterceptor Intercepting EJB Invocation...
12:21:41,061 DEBUG [AuthenticationContextInterceptor] Setting the authenticated user details in Authentication Context: XXXX
12:21:43,994 DEBUG [MicroSocketClientInvoker] SocketClientInvoker[b874d2, socket://] constructed
12:21:43,994 DEBUG [MicroRemoteClientInvoker] SocketClientInvoker[b874d2, socket://] connecting
12:21:43,994 DEBUG [MicroSocketClientInvoker] Creating semaphore with size 50
12:21:43,994 DEBUG [MicroRemoteClientInvoker] SocketClientInvoker[b874d2, socket://] connected
12:21:43,995 DEBUG [InvokerRegistry] removed SocketClientInvoker[b874d2, socket://] from registry
12:21:43,995 DEBUG [MicroSocketClientInvoker] SocketClientInvoker[b874d2, socket://] disconnecting ...
12:21:44,946 ERROR [[default]] Servlet.service() for servlet default threw exception
java.lang.IllegalArgumentException: port out of range:-1

As the highlighted line shows, JBoss was trying to communicate to the remote EJB via port -1, which is of course invalid. Also, an interesting observation was that the IP address which JBoss tries to use is not the one I expected it to use. This, was actually due to the network setup of the production environment. The production server in question had two network cards, each having local IPs and The NIC was used to expose the server to Internet via NAT. was used to internally connect to the machine via VPN for maintenance, etc. Since was used for NAT, it was restricted to HTTP traffic on port 8080 only.

So the problem that I was facing was that JBoss was using the to refer to the remote EJB, where as I expected it to use (note that we have to start JBoss bound to all addresses using -b because we access it via multiple NICs). Since JBoss could not get a free port on, it was falling back to port -1.

So I wanted to find out a way to force JBoss to use the IP address I wanted for remote EJB calls (without binding it specifically to one IP using -b). I was already referring to the remote server’s JNDI Registry via the IP I expected ( After trying out various options, finally I found the following in the deploy folder of JBoss.

File: <JBOSS_HOME>/server/xxxx/deploy/ejb3.deployer/META-INF/jboss-service.xml

<mbean code="org.jboss.remoting.transport.Connector"
<attribute name="InvokerLocator">socket://${jboss.bind.address}:13873</attribute>
<attribute name="Configuration">
<handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>

I changed it to the following, so that instead of dynamically resolving the IP address, JBoss will use the IP I wanted when remote client callbacks are created.

<mbean code="org.jboss.remoting.transport.Connector"
<attribute name="InvokerLocator">socket://</attribute>
<attribute name="Configuration">
<handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>

With this in place, the client was able to invoke the remote EJBs without any issues. This is a rare situation, but if anyone else face the same issue, I guess this post would help to get it sorted out.

Changing the default JBossWS (JAX-WS) Web Service End Point Address

If you are working with JAX-WS on JBoss (in my case version 4.2.3.GA) to expose SLSBs as Web Services, you might notice that in the generated WSDL, the end-point address is set as the machine’s name or localhost. The address JBoss uses by default is the ‘bind address’, which you can specify via the -b argument when starting up the container. If you (like me) are specifying it as (which binds it for all interfaces), it generally resolves to the machine name.

This affects a lot if the JBoss instance is published to the web, since we would like to have the WSDL end point mappings via the public IP address. I had this problem for quite a time, and finally managed to find the solution for this in the JBoss Forums. With a slight change in the JBoss configuration, you can get JBoss to use any IP address of your choice in the WSDL.

The steps are as follows:

  1. Goto deploy/jbossws.sar/jbossws.beans/META-INF
  2. Edit the jboss-beans.xml file (the file itself is well commented)
  3. Change the webServiceHost property to the address that you wish to have.

JAAS with Style – IoC with JBoss Login Modules

Majority of the modern Java EE developers appreciate and hug the concept of IoC (Inversion of Control), popularized by Spring Framework. It is not just due to the hype, but because of pragmatic benefits that are achievable through the concept. With IoC, developers can easily swap in and out implementations behind an interface at deployment, without having to compile and re-build the entire project.

However, there are situations where existing IoC frameworks cannot be used. One such situation I recently faced was with JAAS Login Modules.

When authentication is considered, it is a common and secure practice to encrypt (ideally to one way hash) stored passwords. There are dizzillions of different algorithms out there for encryption. Actual algorithm to use for this purpose usually differs from situation to situation, depending on requirements / choices of clients, etc. So this is an ideal situation where the “strategy” design pattern can be applied, and application IoC would rise and shine.

Nevertheless, instantiation of a login module is normally done by the Application Server (JBoss in this example). So it is not straight-forward to utilize a IoC framework at this point. However, the good news is that LoginModules come out with a handy feature which could be easily exploited to facilitate the IoC concept.

The well known module-option feature provides the ground-work for adding up some IoC magic to our old login modules. When mixed up with Java Reflection API, this is more than enough to decouple the login module from implementation details of various encryption algorithms.

Continue reading