The latest expert opinions, articles, and guides for the Java professional.

The Great Java Application Server Debate: JBoss AS7 (aka WildFly)

Update: Since this post was published, RebelLabs has completed the full version of The Great Java Application Server Debate with Tomcat, JBoss, GlassFish, Jetty and Liberty Profile. Feel free to check it out!

Download the full PDF report from RebelLabs


This post continues our very popular series called The Great Java Application Server Debate, which has covered IBM’s Liberty Profile, Jetty and Tomcat/TomEE. Our goal is to continue with JBoss AS 7 (this post) as well as Glassfish and maybe even a little WebLogic and WebSphere. We’ll see if we have time to cover the last two behemoths.



In this article, we review JBoss AS 7, recently renamed “WildFly”, from RedHat. The reasoning behind the name is that a wild fly is an extremely agile, lightweight, untamed and truly free animal. But considering that artifacts, packages, configuration properties and APIs won’t be changed, at least now, for compatibility purposes, in this post we still refer to it as JBoss Application Server.

Read the complete Intro

Talking about the latest JBoss Application Server is always tricky. Red Hat simultaneously offers two versions of JBoss: community edition, the current release where is 7.1.1-Final, and Enterprise Application Platform, EAP, edition where JBoss AS component version is 7.1.3-Final. The difference between these is actually a few hundred bug-fixes, which is enormous if you face a specific problem, but doesn’t include a new kernel or anything of a similar scale. So you most probably will be good with the community edition. In fact, I’ve never needed to use a EAP version for any of my mini-projects anyway.

Now, JBoss AS 7 features the third generation of the JBoss kernel, one of the first application servers to achieve auto-wiring modularity and “on-demandness” by using a modular services container architecture. So for you folks who still use the older version, consider upgrading, just purely for getting performance improvements.

First impressions – Download and install

Downloading is extremely simple and I don’t think it will be different for any of the servers we’ll look into across the whole series.

  1. Go to the JBoss AS download page, or try the first hit on google for “jboss application server download”
  2. Click on zip link
  3. Extract
  4. You’re good to go.

If you have any experience with AS7, you’ll go straight for the bin/ script to start your JBoss instance, otherwise you can spend a couple of minutes and two to three google queries to figure out which script you need to run. However if you think about managing a cluster of servers with the same bunch of scripts, name like standalone makes perfect sense.

Also there are several default configuration files in “standalone/configuration” directory, which allow to turn on and off default clustering and choose between web or full EE profiles, so one can pick the closest to what is needed and tweak it minimally.

Startup performance – restart/redeploy

Let’s run a standalone instance in a standalone mode: bin/

14:04:17,580 INFO  [] (Controller Boot Thread) JBAS015874: JBoss AS 7.1.1.Final "Brontes" started in 2757ms - Started 133 of 208 services (74 services are passive or on-demand)

However, and this is extremely annoying, you cannot deploy things right away, at least not through the admin console, and instead of a cozy UI it welcomes you with this banner.

When you run this “” script, you need to answer to a bunch of questions, where defaults work mostly fine.

No need to restart anything though, it works automatically with the running JBoss instance. Now you can go to the web-console and deploy your applications. The JBoss team claims that it’s ultra-fast.

Deploying jenkins.war (51M):
14:13:54,569 INFO  [] (MSC service thread 1-6) JBAS015876: Starting deployment of "jenkins.war"
14:14:01,103 INFO  [org.jboss.web] (MSC service thread 1-8) JBAS018210: Registering web context: /jenkins
14:14:01,140 INFO  [] (HttpManagementService-threads - 2) JBAS018559: Deployed "jenkins.war"

Judging from logs deploying took: 14:14:01.140 – 14:13:54.569 = 6.571 seconds. Not immediate, but quite impressive.

Stopping is blazingly fast though, so when you will estimate your redeploy turnaround time, you only need to take startup into the account.

14:18:19,817 INFO  [] JBAS015877: Stopped deployment jenkins.war in 286ms
14:18:19,819 INFO  [] JBAS015950: JBoss AS 7.1.1.Final "Brontes" stopped in 288ms

Let’s restart it again to see if starting with a pre-deployed application is any faster.

14:19:23,993 INFO  [] (Controller Boot Thread) JBAS015874: JBoss AS 7.1.1.Final "Brontes" started in 9669ms - Started 238 of 315 services (76 services are passive or on-demand)
14:19:30,418 INFO  [hudson.WebAppMain] (hudson initialization thread) Jenkins is fully up and running

Startup time is almost 10 seconds now and it takes 7 more seconds for application to become fully up and running. Considering that stopping was instant, a redeploy cycle can take around 20 seconds, which is acceptable by any standards if you don’t have the luxury of JRebel technology.

Another reason for being quite fast is that JBoss is made with memory footprint in mind. I don’t have any experience of running JBoss in a production environment, and in developement memory usually is not a big issue. However, if you have any data to support or reject the claim that JBoss AS 7 is light on memory, please, share it in the comments section below.

Tooling support – how good is the best, how good is the worst

Like for everything else in this universe, there’s a maven plugin to manage your JBoss instances. Its functionality includes starting and stopping, deploying and redeploying apps, managing resources and executing commands like through a JBoss CLI. (I have no idea what else could be asked from a maven plugin for an application server).

Most probably you won’t use the plugin anyway, because there’s a superior way of managing JBoss in development, in the form of a brilliant artifact in the world of tooling: jboss-tools, which is an umbrella project for multiple Eclipse plugins. It includes among other things JBoss Developer Studio which has a server adaptor for JBoss Servers and allows you to manage it all from your IDE.

N.B.: JBoss tools is a great project, for example, it is the first thing Anton Arhipov, our JRebel product lead and a huge IntelliJ fan, installs onto a fresh Eclipse!

When talking about the tooling for JBoss, I can’t miss Arquillian. It is not directly related to the JBoss AS project, but being created by the same company and headed up by our friends, project lead Aslak Knutsen Aslak Knutsen and Community Catalyst Dan Allen, Arquillian works best with JBoss AS.

If you don’t know it yet, Arquillian is a testing management platform that manages running application servers, deploying artifacts and executing tests inside the container. If you write Java EE applications and haven’t tried it, take a look at it.

Open standard compliance

JBoss AS 7 is fully Java EE compatible. Not much can be said here: JAXB, EJB, CDI, LOL, WTF, anything you throw on it will be handled gracefully. At the same time, it is compliant with OSGi v4.2 and allows you to take the best of both worlds. I think that OSGi 4.3 support is being implemented currently, so if you’re a fan of generics and OSGi at the same time, you have to be patient.

User Interface & Config Change & Turnaround time

Configuration can be managed from the web-console as well as via configuration xml files. The domain model is said to be quite understandable and straightforward. So getting a setup of your dreams is easy. As I mentioned above, I do not manage any production environments, but I know that the JBoss community is extremely supportive and as JBoss installations are used by many corporations, the solution to any question should be somewhere out there.

To be fair to other servers we looked at, here is how one would enable ssl connections on some arbitrary port. So, locate the following part of the standalone/configuration/standalone.xml and add a connector element for “https”.

<subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false">
  <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
  <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" enable-lookups="false" secure="true"></connector>
  <virtual-server name="default-host" enable-welcome-root="true">
    <alias name="localhost"/>
    <alias name=""/>

This will enable connector, but if you also want to change the port where https binds, change “<socket-binding name=”https” port=”8443″/>” element to have the desired value.

The web console looks ok, and it’s much nicer than, for example, Tomcat’s manager application. As you can see, it allows you to configure data sources, webservices, OSGi, jvm parameters and JPA with transactions. That’s a pretty good choice of things to fiddle with and working with the console application itself is pleasant and fast.

However, the functionality is nowhere near the administration consoles of heavy artillery like Weblogic or WebSphere. If JBoss cannot reload the changes that you did in the web-console, it’ll greet you with a message saying that, so you won’t wonder why the new configuration is not applied.

Like any self-respecting application, JBoss AS7 provides HTTP, Java API and a CLI for managing configuration.

Community, Documentation & Support

The JBoss community is one of the best things one can think regarding JBoss AS7. They have a myriads of projects under their wing and they work together well. If not, almost everything can be found on forums or discussion groups. If everything else fails you can read the documentation, which is quite good. You can also get into the paid EAP deal and get an official support for a number of standards.


The sum it all up, JBoss AS7 is an outstanding piece of software. It has both big company support and a superb community behind it. The balance of a fully open-source solution versus subscription-based EAP covers almost all possibilities.  At the same time, this EAP nuance might be a bit confusing; IMHO, holding the bug-fixes in the EAP version and not providing them into the community edition version is questionable.

At the same time, if you only care about the performance and support for standards, JBoss is a safe choice. Hopefully, WildFly will continue to be awesome and, as they say, “#@*%ing fast”.

Thanks for reading, please leave you comments below or give us a shout out on Twitter @Rebel_Labs


Responses (18)

  1. Avatar  


    May 2, 2013 @ 10:27 pm

    Why would I ever need an application server when Tomcat suffices?

  2. Avatar  

    K. Siva Prasad Reddy

    May 3, 2013 @ 2:05 am

    “If everything else fails you can read the documentation, which is quite good.” Really?? JBoss documentation is good???? come on….

  3. Avatar  

    Oleg Shelajev

    May 3, 2013 @ 6:17 am

    Hmm, we may come from different backgrounds, but usually when I need something it’s easily googleable, which makes me believe that things are documented :) However, note that I do that for development purposes not to manage it in some critical environment.

    I can’t say for many other app servers, might be that in comparison it seems poorer.

  4. Avatar  


    May 3, 2013 @ 10:35 am

    if Tomcat covers your needs you do not need the application server

  5. Avatar  


    May 3, 2013 @ 10:45 am

    of course it is all relative, what everyone thinks is a “good documentation”. But I wouldn’t argue the JBoss doc is any bad.
    Although being “in progress” JBoss developer guide is quite OK

  6. Avatar  

    Gavin King

    May 3, 2013 @ 6:12 pm

    But it’s worth pointing out that for very many (probably most) people, Tomcat _doesn’t_ suffice. Almost everyone I know adds other services and frameworks (Spring, or whatever) that duplicate much of the functionality that you get built-in when you go with an option like JBoss or TomEE or whatever. Sure, if Tomcat is the only thing you’re using, then you don’t need an EE application server. But if you’re using Tomcat and adding Spring (or whatever) to it, then you already know the answer to the question of “why would I ever need an application server”.

  7. Avatar  

    Reza Rahman

    May 4, 2013 @ 12:38 am

    Gavin – well said as usual and it’s great to see you around the Java EE ecosystem.

    David Blevins’ discussion on TomEE/Tomcat is worth a read in this context:

  8. Avatar  

    Ray Ploski

    May 7, 2013 @ 1:53 am

    Excellent piece Oleg. The only issue I have is with the summary – “IMHO, holding the bug-fixes in the EAP version and not providing them into the community edition version is questionable.” WildFly (v8+) will become akin to Fedora linux distro and JBoss EAP will be to Red Hat Enterprise Linux – one cutting edge and innovative, the other being stable for many years to come.

    Upstream releases will contain fixes for known problems. New innovations will introduce new bugs. Regardless of your preference, Red Hat is now giving away JBoss EAP to developers wherever possible via its developer program. This is the first time in many years Red Hat has ever freely provided its commercial product for development use.

  9. Avatar  

    Oleg Shelajev

    May 7, 2013 @ 6:17 pm

    thank you for this insightful comment, I don’t know much about developer program, have to look into that. Free JBoss EAP is awesome and dividing a product into a cutting edge and stable branches makes a lot of sense.

  10. Avatar  

    Shahzada Hatim

    May 10, 2013 @ 12:18 am

    There is no system out there with perfect documentation. But systems like Jboss which tend to do too many things will always be worse off at documentation, compared to systems which do less.
    I think that the Jboss eco-system is suffering (will suffer from) lack of third party documentation (books, blogs). Compared to other platforms I see less things for Jboss out there.

  11. Avatar  


    May 10, 2013 @ 8:49 am

    almost every where I’ve worked as consultant Tomcat does not suffice but everything is running on Tomcat and the WAR’s are bloated with frameworks that add EE like capabilities to Tomcat despite of all the available decent EE servers. I believe this is due to that ‘back in the days’ when e.g. Spring was created there was a need to create it and use it, and it did make everything easier then using EJBs. And now, everyone is so used to do everything with frameworks like Spring that we’re all stuck with it.

    I’ve even seen cases where apps are deployed in EE Application Servers, but the only thing used are the datasource capabilities of the server all other stuff came from Spring.
    While I do recognize the good work that the Spring team did and does for the EE community, I believe it’s time that developers and architects should start looking back to EE server more. Converting every one to EJB and other EE components is not easy in a world full of ‘Springies’.

  12. Avatar  

    Toomas Römer

    May 10, 2013 @ 8:53 am

    I guess this is due to the fact that it took longer for App servers to come more lightweight in terms of downloadable size, memory requirements, startup times etc.

    Also I think that using Tomcat or Jetty with bloated wars gives more control. Imagine if you want to upgrade some framework/library/service you are using. If you rely on the version from the app server then you have to upgrade the whole app server rather than just some dependency in your app. It makes upgrading dependencies even harder!

  13. Avatar  

    Egor Kolesnikov

    August 27, 2013 @ 11:15 am

    Gavin, this comment is especially terrific in context of the latest changes to jboss distro. Why use purely opensource Spring when you can have a great choice of either:
    – Dealing with bug-ridden ancient AS version;
    – Pay subscription fees.

  14. Avatar  

    Anirudh Vyas

    February 18, 2014 @ 11:08 pm

    I am Sorry but I HAD to correct you – JBOSS AS 7 is NOT WildFly – JBOSS AS 8 is codenamed wild fly – which recently was released with FINAL version.

  15. Avatar  


    April 3, 2014 @ 5:15 pm

    Hi Ray, so Wildfly is the codename for JBoss AS 8? What was the codename for JBoss AS 7? Is there a comparison out there between AS 7 vs. AS 8?

  16. Avatar  

    Mader Levap

    May 27, 2014 @ 11:20 am

    AFAIK it is not codename. JBoss actually changed name to WildFly, at least free version. Version number (eighth) still reflects legacy of JBoss, though.

  17. Avatar  

    Yashwant Dongre

    August 7, 2014 @ 4:30 am

    My JBoss 7 AS taking infinite time to start using!!

  18. Avatar  

    Lambda Pool

    December 17, 2014 @ 8:27 pm

    a lot of lies here. if you search inside jboss forum you will find a lot of complains there.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.