I am working on a legacy Java Enterprise server project, and currently I am trying to set up nightly builds. We are using Maven 2, JBoss 4.2 and Bamboo. The idea is that we have a Bamboo agent on one of our dev servers, and the Maven build is configured to hard deploy the resulting .ear file, then restart the server. (We can’t use soft deploy because our legacy application uses a library which causes an exception during undeploy… we will get rid of that damn library at some point, but not just yet.) This works nicely when I run a Maven build on my own machine: the server is stopped and restarted with the latest build.
However, on the dev server we have multiple JBoss server instances, bound to different IP addresses. And the Maven JBoss plugin I use can only start and stop a server bound to localhost (the default). I just downloaded the source code for it and it simply executes the run and shutdown scripts in the JBoss bin directory, like this:
launch( "run", "-c " + serverName );
and
launch( "shutdown", "-S" );
respectively.
So as you see, no host binding (-b) parameter is used for startup, neither can the shutdown kill any other server than the one listening at port localhost:1099 (the default JNDI port).
I figure that a workaround for startup would be to directly configure the desired host address in the JBoss config files. (The default behaviour is that those config files contain a system property like ${jboss.bind.address}, and at startup, JBoss dynamically replaces these with the actual host address specified as the -b parameter of the run script, or localhost by default). So if I put the exact IP directly in those config files instead, in theory the server would bind to that IP regardless of the missing -b command line parameter. Moreover, I guess that using 0.0.0.0 as host name would solve the stopping problem too… if we didn’t have those other servers on the same machine. However, that might work on another server reserved entirely for the nightly build. We just need to migrate the Bamboo agent etc… a couple hours of extra work. And we do not have an endless supply of unused servers of course, so we may get back to square 1 once we need another nightly build for our release branch…
An alternative would be to try and look into using the Cargo plugin instead… I have no idea as yet, whether it is capable of this trick.
Last but not least, I could actually extend the JBoss plugin to handle host binding – I assume that would take a few active hours of mine altogether, but solved the problem once and for all. So far this seems to me the most viable alternative.
Can anyone offer any concrete experiences / comments on these, or alternative solutions?
Well, I extended the plugin to deal with nondefault hostname and naming port as well. At least this particular problem is now solved.
I committed the patch to Codehaus.
Update: it is going to be officially released in version 1.4.1.
In the meantime, if anyone urgently needs the patched plugin version, please let me know.