While the name may have changed, WildFly application server is the eighth version of the project previously known as JBoss AS. Picking up where JBoss AS 7 left off, Wildfly 8 is JBoss' new community project for driving forward Java application server innovation.

I decided it was time to find out more by talking to Stian Thorgersen, the JBoss Developer that put together a step-by-step guide to deploying WildFly on OpenShift as a DIY Cartridge.

Along with the "re-branding" came a new release, and lots of new enhancements. This latest WildFly offers a 10-fold reduction in startup time over previous versions. WildFly uses JBoss Modules to provide true application isolation, hiding server implementation classes from the application and only loading the classes your application needs. Modules, packaged as collections of classes, are peers that remain isolated unless explicitly defined as a dependency of another module.

Stian Thorgersen in action

Stian on Wildfly

How long have you been working at Red Hat as a JBoss Developer?

Stian: I've been at Red Hat for just over a year now. It's a great environment to work in, and it's amazing to see how many truly brilliant projects there are under the JBoss umbrella.

What do you see as best enhancement in this new Wildfly release and why?

Stian: That is definitively support for Java EE 7! Java EE 7 brings several improvements to increase productivity, such as JAX-RS 2.0 and JMS 2.0. There's also a range of new exiting features including HTML5 support, Batch, JSON processing and WebSockets. Anyone that has in the past had doubt on Java EE should really have a second look! With the huge improvements that's been made through version 5, 6 and now 7, it's becoming a very mature and highly productive platform for producing enterprise ready services and applications.

What drove you to write-up the instructions for deploying Wildfly on OpenShift?

Stian: I've been involved in a new project, which will be announced soon so I can't go into details. For this project we required WildFly on OpenShift, and I wanted to share how simple it was with everyone.

Can you share your experience deploying on OpenShift?

Stian: It's impressive how simple and quick it is to deploy Java EE applications to the cloud using the JBoss AS and EAP cartridges. In the past I've used Amazon EC2, which requires a lot more effort to achieve the same end result. I hope that there will soon be a WildFly cartridge available for OpenShift to make it as simple to deploy Java EE 7 applications as it is to deploy Java EE 6 applications.

Deploy WildFly on OpenShift using the DIY cartridge

At the time this writing, a WildFly 8 cartridge is not available on OpenShift. However, there is community-supported one in the works. In the interim, thanks to Stian's initiative, it's relatively simple to get Wildfly running using the DIY cartridge. I've included his guide with a few tweeks below. If you don't already have an OpenShift account go to and create one now.

Create a new application

First step to doing this is to create a new application on OpenShift using the DIY cartridge. This can either be done through the web console or using the rhc command line tool.

To create the application using the web interface open and select add application. Select the Do-It-Yourself cartridge. Insert a name for the application and click on Create Application. On the next page follow the instructions to clone the Git repository for the application.

Install WildFly

Download WildFly from and extract it into the directory where you cloned the applications Git repository.

To make WildFly run on OpenShift you'll need to do a few minor configuration changes. Open the wildfly-8.0.0.Alpha1/standalone/configuration/standalone.xml in your favourite text editor.
First thing to do is to set the interfaces to use loopback addresses. Search for and replace inet-address with loopback-address. The result should be:

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

Next, if your application is using the example datasource you may want to configure this to be persisted. Search for for the ExampleDS datasource entry replace the value of the connection-url with:


Finally, the timeout for a deployment is set to 60 seconds by default, and if you're using the free gear this may cause deployments to fail. To increase the deployment timeout search for deployment-scanner and set the deployment-timeout attribute. For 300 seconds timeout it would be:

<deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" deployment-timeout="300"/>  

Edit start and stop scripts

Open .openshift/action_hooks/start   in a text editor and replace the contents with:

ln -s $OPENSHIFT_DATA_DIR $OPENSHIFT_REPO_DIR/wildfly-8.0.0.Alpha1/standalone/data  
cd $OPENSHIFT_REPO_DIR/wildfly-8.0.0.Alpha1  
nohup bin/ -b $OPENSHIFT_DIY_IP -bmanagement=$OPENSHIFT_DIY_IP > $OPENSHIFT_DIY_DIR/logs/server.log 2>&1 &  

Then open .openshift/action_hooks/stop and replace the contents with:

jps | grep jboss-modules.jar | cut -d ' ' -f 1 | xargs kill  
exit 0  

Push changes to Openshift

Now it's time to commit and push the changes to OpenShift. Run:

git commit -m "Added WildFly" -a
git push

Once the data has been sent to OpenShift the application will be restarted and you should have a running instance of WildFly on OpenShift. To deploy your applications to the WildFly instance simply copy them to standalone/deployments and use git commit/push to upload to OpenShift.

Now go spread the word about Wildfly on OpenShift and be sure to tell us all about it!

What's Next?

< Back to the blog