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!
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 Java Application Server Report where we discuss the pros and cons of App servers such as: Tomcat, Jetty, GlassFish, IBM WAS Liberty Profile and JBoss (aka WildFly):
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.
- Go to the JBoss AS download page, or try the first hit on google for “jboss application server download”
- Click on zip link
- You’re good to go.
If you have any experience with AS7, you’ll go straight for the bin/standalone.sh 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/standalone.sh:
14:04:17,580 INFO [org.jboss.as] (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 “add-user.sh” 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 [org.jboss.as.server.deployment] (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 [org.jboss.as.server] (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 [org.jboss.as.server.deployment] JBAS015877: Stopped deployment jenkins.war in 286ms 14:18:19,819 INFO [org.jboss.as] 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 [org.jboss.as] (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="example.com"/> </virtual-server> </subsystem>
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