JBoss — useful configurations

In this article, I will describe how to do various JBoss configurations. These are:

1. Externalise a properties file in JBoss
2. Access JBoss remotely
3. Auto-deploy war to JBoss
4. Re-deploy new version of a war file
5. JBoss acting as a client

All of the below have been tried and tested in EAP7 but there shouldn’t be too much variations in similar versions.

Externalise a properties file in JBoss

There are several tutorials and similar online of how to use external properties files within JBoss. This is the method that I found worked.

Prerequisite: have JBoss EAP 7 installed and working.

So from the standard installation, which by the way in my example is 7.1.0, there is a standard folder structure. Under your <EAP_Home> directory, there should be a “modules” folder. Go there.

The folder structure looks something like this:

<EAP_Home>
├── modules
│ ├── system
│ │ ├── layers

and obviously many more, but “modules” is what we’re interested in.

In “modules”, create “etc” and “config”, and within “etc”, create “jboss”. They’re all folders by the way.

The structure now looks something like:

<EAP_Home>
├── config
├── etc
│ ├── jboss
├── system

Navigate to the newly created “jboss” folder. Create a new .xml file in there called “module.xml”.

Put the following code into that xml file:

<?xml version="1.0" encoding="UTF-8"?>
 <module xmlns="urn:jboss:module:1.1" name="config">
  <resources>
   <resource-root path="."/>
  </resources>
 </module>

Save the file. Just to mention that this is done on Windows, so the following may need to be tweaked if using a different operating system.

Launch cmd as administrator and go to <EAP_Home>/bin.

You then need to create a symlink:

mklink /D <EAP_Home>\modules\config\main ..\etc\jboss

Note the ..\ part of the directory. If you go to the <EAP_Home>/modules folder and click on “main”, it should bring you to where the “module.xml” file is. If it gives an error, saying the path doesn’t exist, you’ll need to delete the main folder, and re-create it with the mklink command again, but give a different relative path (or probably an absolute path would work too). Just to note that the relative path is relative to the symlink, not to the current directory.

Now you need to add something to your standalone.xml (or whichever standalone version you’re using, assuming you’re in standalone mode) — located in <EAP_Home>/standalone/configuration

Locate the following node: <subsystem xmlns=”urn:jboss:domain:ee:4.0″>. With the standard 7.1.0 installation, it should be there with a bunch of properties. If not, you can likely create it manually.

Within that node, add the following sub-nodes:

<global-modules>
  <module name="config"/>
 </global-modules>

Now, put any .properties file you want in <EAP_Home>/modules/etc/jboss and they will be all be included in the JBoss classpath.

That’s it.

Simple test then; run your JBoss application (assuming you have one), and try do something that requires a value in the .properties file and it should be successful.

Access JBoss remotely

In standalone mode, a simple change is needed to the standalone.xml file (or whichever standalone file you’re using).

First, you need to get the IP address of the machine the JBoss instance is running on. This can be got simply by entering ipconfig in a cmd window.

If you look at the default <interface>section, you’ll see it binding to localhost (127.0.0.1). The easiest way here is to remove the colon and IP address (and perhaps add the unsecure section if necessary):

<interface name="management">
  <inet-address value="${jboss.bind.address.management}"/>
 </interface>
 <interface name="public">
  <inet-address value="${jboss.bind.address}"/>
 </interface>
 <interface name="unsecure">
  <inet-address value="${jboss.bind.address.unsecure}"/>
 </interface>

And then you need to add some new nodes into <system-properties>:

<property name="jboss.bind.address" value="1.2.3.4"/>
 <property name="jboss.bind.address.management" value="1.2.3.4"/>
 <property name="jboss.bind.address.unsecure" value="1.2.3.4"/>

Obviously replace the value with the machine’s IP address.

Start JBoss.

Then in the log files, you’ll see two lines along the lines of:

Http management interface listening on http://1.2.3.4:9990/management

Admin console listening on http://1.2.3.4:9990

And you can get to the console from another machine on the network via these URLs.

Auto-deploy war to JBoss

This explains a simple way to auto-deploy a war file to a JBoss server in domain mode.

First step, add this to your pom.xml:

<plugin>
  <groupId>org.wildfly.plugins</groupId>
  <artifactId>wildfly-maven-plugin</artifactId>
  <version>1.2.2.Final</version>
 </plugin>

For some reason, the Wildfly plugin works better than the JBoss plugin. Why? I’ve no idea.

Anyway, then you need to use a Maven command to trigger it (I’m assuming you have a Maven build that can create a war file).

mvn wildfly:deploy -Dwildfly.hostname=<yourServerNameOrIP> -Dwildfly.port=<JBossPort> -Dwildfly.username=<JBossUserName> -Dwildfly.password=<JBossPassword> -Dwildfly.deployment.name=<deploymentName.war> -Dwildfly.serverGroups=<domainServerGroup>

You might notice that this puts your username and password in plain text in your Maven command. There is one way (at least) around this:

1. Open your Maven settings.xml (usually in something like ~/.m2)

2. Locate the <server> section

3. Add a new section (see below), using whatever id you choose

4. Then you can use something like this in your arguments instead of the username and password: -Dwildfly.id=deployment-user

<server>
  <id>deployment-user</id>
  <username>admin</username>
  <password>password</password>
 </server>

And that’s it, the plugin will deploy to your domain server group specified. You can read all the optional arguments on the official docs page.

Re-deploy new version of a war file

This depends on whether you are using standalone mode or domain mode, but either way it’s pretty straightforward.

Standalone Mode:

1. Navigate to <JBoss_Home>/standalone/deployments

2. Remove the existing <fileName>.war file

3. Drop the new <fileName>.war file into the folder

4. JBoss should auto-deploy it

5. If it doesn’t, then rename the <fileName>.war.deployed to <fileName>.war.dodeploy and it should pick it up

6. If that doesn’t work, restart JBoss

Domain Mode:

1. Log on to the management console — you can find the URL in the logs on startup

2. Select Deployments

3. Select Content Repository

4. Click the arrow beside <fileName>.war and select Replace

5. Browse to your file and click Finish

6. JBoss should replace it then — you should see a different sha1 in the <deployments>section of the domain.xmland the log file will say something like “WFLYSRV0016: Replaced deployment "<fileName>.war" with deployment "<fileName>.war"“

7. If this didn’t work, restart the server manually

And that’s it. Both standalone and domain mode make the changes without manually restarting the servers. For new deployments (i.e. not replacing existing ones), a restart may be required.

JBoss acting as a client

When googling for JBoss mutual SSL, it appears the vast majority of the articles show how to configure the mutual SSL, but with JBoss as the server. Which is fine, because JBoss is a server. However, I wanted to configure it when acting as the client, because the URL I was trying to hit, needed a specific cert, and it was coming from JBoss.

In my searches, I learnt a lot about how different versions of JBoss use different ways to set up mutual SSL, namely:

· JBoss EAP 7.0.x — uses the subsystem domain:web

· JBoss EAP 7.1.x — uses the undertow subsystem as it appears domain:web is not longer used.

Despite the fact I basically was on a wild-goose chase for my specific requirements, this could be confusing with such minor differences in JBoss versions. One to note for the future. Maybe you can use domain:web in 7.1.x, but I haven’t ventured down that road yet.

Anyway, the solution was quite simple. Just set some system properties on startup (standalone.xml or domain.xml, depending):

<property name="javax.net.ssl.keyStore" value="C:\path\to\certs\keystore.jks"/>
 <property name="javax.net.ssl.keyStorePassword" value="<keystore_password>"/>

Then when a request is sent from JBoss to another server, that server can look into this keystore, and hey presto, no 400 error or similar when hitting the server. You can also have multiple certs in this keystore, and the called server will just use the one it needs.

After far too much searching (I even started to implement some of this), it turned out the solution was remarkably straightforward. You can also set them as VMargs (JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=... -Djavax.net.ssl.keyStorePassword=...) which you can read about here.

Conclusion

And there you have it. Five different implementations one may wish to use within an environment that uses JBoss as its server.