I recently set up JBoss 4.2 on a Staging environment. The Production environment uses JBoss 4.0.3 SP1 and there was a hanging question of whether the application could be transferred to the newer series or not. The obvious advantage of the migration would be to move EJB3.

Well it took a lot of work but I am happy to say that if you have a J2EE 1.4 application you can move it to JBoss 4.2 and EJB 2 and 3 deployments all live together happily in the container.

However there is an important bit of behaviour that has changed and that is that JBoss no longer binds to all adaptors automatically. Instead it binds to localhost by default (I think). My deployment machine was a virtual server with a NAT internal IP and an external IP linked to its DNS alias. Therefore I knew I had issues with binding as in addition to the different IPs I also do not actually have any physical network I’m binding too.

However despite noting the issue in the JBoss wiki documentation I then proceeded to fluff the configuration. Despite having the web containers up and running, along with the JMX Beans I could not get my web tier to talk to my service tier. Instead I was getting obscure messages like Object not in table or a connection timeout.

What I had failed to realise from the documentation is that specifying the --host parameter to the run.sh script is not like defining the system property jboss.bind.address. Superficially they may seem the same, indeed they are so similar that you can in fact stop and start JBoss quite happily using this parameter. However your RMI connector will have be been bound to something else and therefore all RMI calls from outside the server will get routed to /dev/null (geek joke; I have no idea what happens to them but judging from the error message the JNDI lookup fails to connect to any object in the pool capable of servicing the request, the handle lookup probably returns null).

Essentially on a non-production machine you always want to pass

--host=0.0.0.0

to the start script otherwise the services will bind to different addresses and you will have erratic behaviour where connecting to your host by it’s DNS name, the localhost alias and by 127.0.0.1 will all have different results (normally only one of them will actually have the service).

The only other issue is that the AS Log4J configuration has been renamed to jboss-log4j.xml. While this causes some short term pain it was only when I read the release note that I thought: “hey it is weird that we configure all our logging via the container’s configuration file”.