Tutorial Thursday

7 Reasons to love JBoss AS7


Fast, fast, fast. Blazing fast. No doubt, that’s the main reason to love JBoss AS 7 but Dan Allen explores six more reasons why you should get behind JBoss Application Server 7

The year was 2002. JBoss was busy taking the Java 2 Platform,
Enterprise Edition (J2EE) world by storm, boasting over two million
downloads and earning a position as the de facto standard for
deploying Java-based Web applications.

The secret to the success of JBoss 3 (the version at the time)
was that it was borne out of the developer community and thus
offered all of the things developers love: it was easy to download,
quick to install and simple to run. It was designed around a small
microkernel based on Java Management Extension (JMX) that required
very little memory. It was relatively easy to use, yet endlessly
extensible. It was stable. It had forward-thinking architecture. It
was portable and standards-compliant, capable of competing with the
big boys. It even won “Best Application Server” at the 2001
JavaWorld’s Editors’ Choice awards. And best of all, it was – and
always has been – free.

There’s no denying, though, that in recent years, the
JBoss Application Server was stuck in a compliance “no man’s land”
between J2EE 1.4 and Java EE 6. Configuring the server meant diving
deep into the internals of the bean wiring or selecting from one of
several web-based admin console add-ons. It also wasn’t keeping up
with modern requirements such as usability, embedded mode, an HTTP
API, an interactive command-
line and multi-server
management, to name a few. The startup time was a minute or more
depending on hardware, but was leapfrogged by Servlet containers
like Tomcat and Jetty and even its OSS competitor from Sun/Oracle,
GlassFish V3.

During the summer of 2010, JBoss Application Server
underwent an aggressive transformation to return to its roots. The
project was rebooted and set off on a new path towards JBoss
Application Server 7. A new beginning.

The team built an entirely new, high performing and
manageable core ar
chitecture. With some truly amazing
engineering effort, they were able to go from a tiny prototype on
github to the
full blown Java EE 6 Web Profile certified container in a year’s
time (and the Full Profile is coming soon in 7.1). Keep in mind
they delivered JBoss Application Server 6 in parallel to provide
JBoss users interim access to Java EE 6 technology.

With the JBoss Application Server 7 release, JBoss has its
mojo back! There’s genuine excitement and optimism about this
milestone at Red Hat, a feeling that permeates deep into the
community as well, which brings us to the seven reasons why you’ll
love JBoss Application Server 7.


1) Lightning fast

Fast, fast, fast. #@*%ing fast! No doubt, that’s the main
reason to love JBoss Application Server 7. This release dispels a
long-standing misconception that a Java EE application server is
inherently slow. (Don’t worry, we checked and “slow” is not a
requirement of the specification.)

JBoss Application Server 7 boasts a startup time that’s an order
of magnitude (10x) quicker than previous versions, thanks to a
highly optimized, parallel boot process. This speedy startup earned
it the code name “Lightening.” A modern developer workstation using
a tuned JVM can boot the server in as little as one second!* (A
three second startup time is an indication that your machine is
outdated). Join the
if you’ve found a way to boot it faster. Not only
does this startup time shatter the competition, it even gives
Tomcat and Jetty a run for their money. When comparing JBoss
Application Server 7 to Servlet containers, consider how much
additional, yet essential, functionality you are getting out of the
box, at a marginal cost. The benefits don’t end once the server
starts. The deployment process has also received a speed boost.
Small applications launch almost instantaneously, and medium to
large applications can be deployed or restarted in seconds.

You may be wondering, “Why is it so fast?” The short
answer is that JBoss Application Server 7 designed around Ahmdahl’s
law (effective parallelization of work) as opposed to Moore’s law
(a linear increase in clock speed over time). Almost every CPU
inside desktops, laptops, and servers is now at least dual core,
and the trend is rapidly expanding. It’s time to take advantage of
it. Let’s briefly consider how.

Application servers are tasked with a core problem –
managing services. Nearly all components in a modern application
have some kind of life cycle, meaning there is some point at which
the service must be started, and a later point at which it must be
stopped. JBoss Application Server 7 starts and de- ploys all
services in parallel and keeps non-critical services on ice until
needed. The complex problem of managing these life cycles is solved
by the new Modular Service Container (MSC). MSC is essentially an
advanced concurrent state machine. It analyzes the dependencies
between all services on the fly and attempts to start as many as it
can at the same time, while still adhering to relationship
requirements. This means that not only is startup lightening fast,
you can also deploy multiple applications in parallel too. To
complement parallel services, JBoss Application Server 7 also has
modularity and concurrent classloading, which we’ll cover

Processing an individual deployment is also very
efficient. A key optimization in JBoss Application Server 7 is
indexing annotation information by quickly scanning a subset of the
class file data. For even greater efficiency, it allows modules the
ability to pregenerate a space efficient index which is designed to
be loaded very quickly. Yet another deployment optimization is
carefully caching and reusing reflection data, since the JVM is not
very efficient at doing so. With these optimizations, you can
expect that Application Server 7 will not get slower over time, no
matter how many deployment cycles you throw at it.

The highly optimized startup and deployment processes saves
unnecessary trips to the water cooler, which keeps you in the
zone. It also
has a very small memory footprint, which leaves more headroom for
your application and avoids slowing down other running


2) Exceptionally lightweight

We like to say that JBoss Application Server 7 lives on a
memory diet. The JBoss Application Server 7 team is proudly
“militant” about CPU and memory usage during the startup and
deployment processes by taking an aggressive approach to memory
management primarily to minimize garbage collector pauses. As they
say, it’s all about making good choices starting at the design

While garbage collection is a valuable feature of Java, it’s not
particularly fast when given a lot of garbage to chew. A simple
solution is to give it smaller bites. A couple of ways to
accomplish that is only loading JAR files that are needed, using
indexed metadata to lookup annotations, class structure (reflection
information) and XML data rather than full scans and, finally,
shutting down idle services. These optimizations enable JBoss
Application Server 7 to run with stock JVM settings on even the

smallest devices

An interesting example from the memory diet is the
moratorium on using JAXB (or any other introspection driven binder)
to parse configuration that’s only read once. These frameworks
often spend more time figuring out how to parse than to do the
actual parsing and binding, which itself is time consuming. These
calculations add up. Just the XML processing in JBoss Application
Server 5 and JBoss Application Server 6 takes longer than the
entire JBoss Application Server 7 boot time!

If you want to make the server even more lean beyond what
the Java EE 6 Web Profile affords, you can define a custom server
profile to prune unneeded capabilities. Profiles are easy to
create, since they are defined as an alternative configuration
file, as opposed to having to physically remove files and
directory. Regardless, we’re confident most developers will be
happy with the leanness of the default Web Profile

Being fast and lightweight enhances developer productivity
tremendously, until all those gains are thrown out the window
trying to remedy a leaky classloader that’s exposing the wrong
version of an XML parser. It’s jar hell! Proper modularity keeps
the developer out of the weeds, and JBoss Application Server 7
delivers once again.


3) Core Modularity

Mark Reinhold, Chief Architect of the Java Platform Group
at Oracle, famously stated at JavaOne 2009: “The classpath
 dead.” Experience has taught us that hierarchical
classloaders are problematic, often causing failed deployments and
quirky behavior. They are the equivalent of a waterfall, where
server implementation classes pour into the application’s classpath
below. There’s no question the future of Java is a modular one. The
time has come to say goodbye to the parent delegation model and
find the path to modularity (i.e. sane class-loading). But
first-class modularity in the JVM still remains on the horizon
(planned for Java 8, a year away at least). Is it possible to build
a modular server before then?

One way to achieve modularity is to build the server on top of
OSGi, which offers both a module system and service platform. In
fact, at least one Java EE implementation has taken this approach,
GlassFish 3. In contrast, the Application Server 7 team believed,
with minimal effort, they could intro- duce a solid, usable
modularity standard that’s not burdened with the overhead and
complexity of OSGi. They proved it with JBoss

A module system provides a way to package up classes and
resources into modules, and establish a graph, at runtime, of
classloaders such that all the expressed dependencies are
satisfied. This organization is a contrast to the traditional
method of running an application using the default classpath
mechanism, which produces a single application classloader with all
the resources in those jars concatenated together in one big blob.
In other words, jar
. Modules can greatly alleviate this problem. When all jars
are bundled as modules, a JAR will never see a conflicting version
of a dependency class, or pick up resources from other jar
inadvertently. Also, a module which is never used will never be
loaded which can improve startup time of large applications.

JBoss Modules, the core classloader in JBoss Application
Server 7, provides this modular structure. As a result, it offers
true application isolation, hiding server implementation classes
and only loads the classes your application needs. Every
application acts as a module. Modules, packaged as collections of
classes, are peers that remain isolated unless explicitly defined
as a dependency of another module. Visibility rules have sensible
defaults, yet can be customized. The modular classloader keeps
applications isolated, so you can use your own XML parser or
Hibernate libraries without experiencing jar hell. Not only does
JBoss Modules allow Application Server 7 to do classloading right,
it’s also a key contributor to its lightning speed. It was designed
for a high degree of concurrency. JBoss Modules can load only the
classes you need and does so with extremely fast, O(1) resolution.
In addition, classes can be loaded concurrently, making use of that
multi-core processor once again. By segmenting classes into proper
modules, the app server can naturally optimize access patterns, and
only look in the spot that truly owns the classes. Also, since the
visibility between modules is intentionally limited, searching is

From an engineering standpoint, we can say that JBoss
Application Server 7 is very well designed. This follows a long
tradition of JBoss Application Server being developer-friendly. But
roles have changed since JBoss 3, as Java EE has been widely
adopted by large organizations. That means develop- ers aren’t the
only target audience. In addition to solving en- gineering
challenges, the JBoss Application Server 7 team
focused on making administration elegant (to cater
to managers, the more technically-oriented devops, while still
giving plenty of tools to satisfy developers).


4) Elegant administration

That’s the name of the initiative focused on usability of the JBoss
Enterprise Middleware portfolio. The first goal of this initiative
has been to improve the out-of-the-box experience of JBoss
Application Server by making it easier to setup, configure, manage
and all-round easier to use. In short, equal attention is given to
the experience of administrators, devops and developers. As always,
“installing” JBoss Application Server 7 is just a matter of
downloading the zip file, extracting it and running the startup
command. You can also get it setup from Eclipse via the JBoss Tools
plugin, available in the Eclipse Marketplace. The main improvement,
though, comes in the configuration.

JBoss Application Server 7 is incredibly easy to
configure, more so than any previous version of JBoss Application
Server or its competition. Rather than sending you on a wild goose
chase to change a setting in the application server, configuration
in JBoss Application Server 7 is centralized, simple and
user-focused. The primary configuration file is based on a
straightforward domain model that you can easily comprehend. No
internal wiring is exposed in this file. It also adheres to the DRY
principle. Settings are given canonical names, so that values only
have to be changed in a single location, at the point where the
canonical name is assigned. As an example, you can set main
interface, named public, in one location,

  <interface name="public">
     <inet-address value=""/> 

then change all the port numbers bound to that interface
using a single attribute:

<socket-binding-group name="standard-sockets" default-interface=
                                                        "public" port-offset="100">

<socket-binding name="http" port="8080"/> 
<socket-binding name="jndi" port="1099"/>

JBoss Application Server 7 has consistent and powerful
management available out of the box, including:

  •  a polished, user-friendly web console
  •  a command-line interface (CLI)
  •  a Java API
  •  IDE tooling (via JBoss Tools)
  •  an HTTP API


You’ll appreciate the fact that the web console provides a
clear perspective into the server runtime, while the programmatic
APIs can be leveraged by tools, scripts and geeks alike.

At the end of the day, all of the administrative
interfaces pass through the HTTP API. What makes them especially
useful is that changes are persistent, so you can freely switch
between them and never have to fiddle with the configuration file

Deployment remains as simple as it’s always been. Archives
dropped in the deployment directory are picked up automatically, a
feature known as the (hot) deployment scanning. For applications
deployed as exploded archives, possibly using a flexible deployment
structure, you can edit static resources without redeployment.
What’s changed is that Application Server 7 appoints a dedicated
directory for application deployments, rather than mixing
application deployments with internal service archives,

As a testiment to the usability improvements, Red Hat has made
JBoss Application Server 7 available as a Platform-as-a-Service
(PaaS) through the OpenShift Express and Flex
. OpenShift + JBoss Application Server 7 is the first
PaaS based on the Java EE 6 standard (or any version of Java EE for
that matter). And OpenShift makes it easy to deploy JBoss
Application Server 7 applications to the cloud, and it’s free! The
centralized configuration in JBoss Application Server 7 also
unifies management. A single configuration file and an alternative
startup script can be used to control multiple servers in the new
domain mode.


5) Multi-server topology

One of the primary new features of JBoss Application
Server 7 is the ability to manage multiple server instances from a
single control point (without any special add-ons, such as Jopr). A
collection of such servers is referred to as the members of a
“domain” with a single Domain Controller process acting as the
central management control point. All of the server instances in
the domain share a common management policy, with the Domain
Controller acting to ensure that each server is configured
according to that policy. Domains can span mul
tiple physical
(or virtual) machines, with all server instances on a given host
under the control of a special Host Controller process. One Host
Controller instance is configured to act as the central Domain
Controller. The Host Controller on each host interacts with the
Domain Controller to control the life cycle of the application
server instances running on its host and to assist the Domain
Controller in managing them.

When you launch a JBoss Application Server 7 managed
domain on a host, your intent is to launch a Host Controller and
usually at least one server instance. On one of the hosts the Host
Controller should be configured to act as the Domain

Each “Server” represents an actual application server
instance. The server runs in a separate JVM process from the Host
Controller. The Host Controller is re- sponsible for launching that
process. (In a managed domain the end user cannot directly launch a
server process from the command line.) The Host Controller
synthesizes the server’s configuration by combining elements from
the domain wide configuration (from domain.xml) and the
host-specific con- figuration (from host.xml).

<server name="server-one" group="main-server-group">
     <jvm name="default"/> 
<server name="server-two" group="main-server-group" auto-start="true"> 
<socket-binding-group ref="standard-sockets" port-offset="150"/> 
<jvm name="default">
   <heap size="64m" max-size="256m"/> 
   <server name="server-three" group="other-server-group" auto-start="false">
     <socket-binding-group ref="standard-sockets" port-offset="250"/> 

A managed domain is all about coordinated multi-server
management–with it JBoss Application Server 7 provides a central
point through which users can manage multiple servers, with rich
capabilities to keep those servers’ configurations consistent and
the ability to roll out configuration changes (including rolling
deployments) to the servers in a coordinated fashion. For
multi-server production environments, the choice of running a
managed domain versus standalone servers comes down to whether you
want to use the centralized management capabilities a managed
domain provides. The means of management is orthogonal to HA
functionality, which is available to both standalone and domain

While Java EE servers have always been good at providing
enterprise services, such as a component model, high availability
and server management, testing applications that run in this
environment has always been a challenge for developers. That is,
until now.


6) Testable by design

From the very start, JBoss Application Server 7 has been
designed with testability in mind. The secret to that fidelity is
Arquillian – a component model for integration tests that execute
inside the real runtime environment. Arquillian brings your test to
the runtime rather than requiring you to manage the runtime from
your test. This removes the plumbing (read: clutter) from your
tests and handles deployment and test execution. Consequently, you
can write tests for just about any use case your application
encounters. We like to call those real tests. And thanks to the
speed of JBoss Application Server 7, Arquillian tests run nearly as
fast as unit tests. Since Arquillian was designed for testability,
you can be sure it has been thoroughly tested itself, with very
real and meaningful tests. JBoss Application Server 7 boasts an
internal test suite based on Arquillian that achieves even more
strict compliance to the portability expectations of our community
of users. That means when JBoss Enterprise Application Platform is
shipped, the team is not nervous that some blatant bug is going to
be discovered in the first 24 hours, or even the first week or

Testability is not limited to the development of the
server. It gives you another way to slash cycles from your
development process; in other words, smarter application
development. Using Arquillian for development gives you an
extremely fast change, compile, test cycle for any component model.
This strategy allows you to take Test Driven Development (TDD)
further than ever before, all from the convenience of your IDE or
build tool.

Arquillian is one of many first-class JBoss projects on
which JBoss Application Server 7 is built.


7) First class components

The past few years have seen the JBoss community grow
rapidly in many other directions. You’ll likely recognize this
sampling of JBoss Community projects in JBoss Application Server 7
as first-class citizens in the Java middleware space: These
projects have come into maturity in their own right. That’s one of
the reasons the team was able to create

JBoss Application Server 7 from scratch so quickly. JBoss
Application Server 7 brings these best of breed OSS projects
together as a compliant platform with an elegant, centralized
administration experience. JBoss Application Server 7 is also
proving itself beyond the Java EE domain, offering a compliant OSGi
runtime and the best Ruby server on the plant,


The years between JBoss 3 and JBoss Application Server 7
did prove valuable to this effort. Once again, JBoss Application
Server would grow out of the developer community, but this time
drawing ideas from a much wider field of input, which included
users and administrators in addition to developers. The team
factored in lessons learned about application server architecture
since the development of JBoss Application Server 3 and mixed in
modern requirements such as cloud administration and deployment.
The real key, though, is attributed to a new philosophy for
development. The team recognized that software must adapt, both to
tap into the power of the hardware of today and make use of what’s
coming down the road. The result is a free, Java EE certified
application server which is once again on top…way on

Download JBoss Application Server 7 or get started with
OpenShift to launch your Java EE applications in a

This article first appeared in Java Tech Journal – September
2011. To read more of that issue and others, register and download
the PDF here for

As a Principal Software Engineer at JBoss, by Red Hat, Dan works as the community liaison and member of the Seam, Weld and Arquillian projects. He
comments powered by Disqus