JBoss AS 5 - Trivadis

seedjaggedInternet and Web Development

Nov 12, 2013 (3 years and 9 months ago)


JBoss AS 5 – New Features
Godefroy Riegler, Olivier Guitard . Consultants . 29th May 2009
Open source applications servers are more and more used in production environments and
JBoss is one of the most used. One of its key advantages is that support can be provided by a
reputed vendor. In this paper we present the key features of the very last release of JBoss
Application Server: version 5.
1 Introduction & brief history
This new release of Red Hat JBoss Application Server is a huge big bang in the history of this
application server. In fact a complete rewriting occurred during 5 years of research and
development which started in 2005.
As any Java application server, each new version comes with its set of innovations, in this new
version you will find:
• Inversion of Control configuration of the kernel
• Extensive usage of POJOs (Plain Old Java Objects)
• New configuration possibilities
• Open and configurable deployment possibilities
• The adoption of the OSGi model
1.1 Brief history
Along all versions, developers of JBoss took care of providing up-to-date technology to the
application server. From the beginning, the newly JMX technology has been integrated in the
kernel of JBoss.
When the EJB 3.0 specifications were released, the JBoss team provided a way to benefit from the
ease of use of EJB 3.0 in the versions from 4.2 of the application server. Since 2003, the
integration of aspect programming principles inside the server have raised and we will show its
huge importance in this release.
The following timeline shows the evolution of technology adoption during most of JBoss AS life.
info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 1 / 18

info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 2 / 18

Evolution of technology inside JBoss
(Source: Red Hat JBoss 2008, All Rights Reserved.)
1.2 Version goals
With this version, the development team had established the following goals to reach regarding
the design of the whole software:
• Increase adaptability
The application server internals should be quickly adapted to specifications changes and
new specification releases (like external constrains as from the Java Enterprise Edition).
• Gain in modularity
The design of the software should allow easy extensibility trough the usage of modules or
plug-ins. For instance, previous versions of the kernel were not easily extensible.
To apply these principles, many parts of the application server have split in smaller projects and
the kernel has been redesigned to realize this modularity objective.
1.3 Red Hat and Open Source Software
As the provider of many open source software, Red Hat is one of the most important OSS vendor
on the market and more specifically the one behind JBoss products.
Today, open source software is impossible to avoid and drains very high motivation among
developers. Open source software is also the basis of many shared part among software. The
integration of the reference web container for Java web archives – namely Apache Tomcat – is
one of the best examples of this parts’ sharing.
Furthermore, RedHat JBoss AS is now an important actor on the market. Showing a current high
market share, in a survey conducted by BZ Research / BZ Media in October 2007, 32 % of
respondents said JBoss was in use at their company. This shows that just after Tomcat and IBM
WebSphere, JBoss has a huge user base (where developers are considered as users).

The goal of Red Hat is to be in 1 of 2 of every new middleware deployment in 2015. This is
currently estimated to around 30 %. With the consolidation of the market, there are less and less
vendors and the more consolidation, the less choice. JBoss is clearly an option to be considered
in new developments and older applications consolidation.
1.4 JBoss AS 5 Summary card
Product type
Java Application Server
Red Hat
License type
Available versions
3.2, 4.0, 4.2, 5.0
Last stable version
JEE Compliance level
JEE 5 (since v5.0.0)
Available since
5.12.2008 (5.0.0)
Part of a closed source product
Embeds Apache Tomcat
Provides many standard APIs and Frameworks (JBoss Seam, Hibernate…)
Supports OSGi™ model
1.5 Specific JBoss AS 5 Goals
In order to cope with the evolving standards of the Java Enterprise Edition plat-form, the JBoss AS
team had to implement a certified version of the last JEE specifications. Hence the main goal of
JBoss AS 5 was to provide a JEE 5 certified Java application server.
Furthermore, they wanted to provide an advanced server runtime architecture by providing the
following new technologies in the same release:
• POJO-based kernel
• Aspectized deployers
• Configuration API
• New classloading architecture
• Support for other component models
In the mean time, the all libraries and subsystems have evolved to their very last compatible
releases: clustering, messaging, security, transaction manager, web services stack, web server…
2 New features & improvements
Version 5 of JBoss AS is a major release; in this section we present an overview of the new
features and a high level view of the architecture.
2.1 Overview of new features
One the most expected benefit of this new release is the certification of the application server
against the JEE specifications version 5. To achieve this goal, the development team has rebuilt
the micro-kernel entirely providing a flexible basis for all new developments.
info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 3 / 18

Thus, many components of the Application Server have been split and have been newly reborn as
JBoss community projects: JBoss EJB3, JBoss Messaging, JBoss AOP, JBoss Transactions, JBoss
Web Services to name a few. These new modules have been added to this release with the latest
possible compatible version.
The following mind map presents an overview of all the new features and components related to
this new version of the application server:

Figure 1 - Overview of main new features of JBoss AS 5
Around the new features available, please note the new version of JBoss Tools which takes
advantage of the new features of this version.
2.2 Architecture
Like in previous releases 3.x and 4.x, principles of the current architecture of JBoss AS remain
unchanged. As shown in the following diagram, the architecture is made of four main layers each
of whom using the underneath layers.

Figure 2 - Internal layered architecture of JBoss AS
info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 4 / 18

At the base of the application server, a kernel is still present and provides easy management
through JMX-based interfaces in a small memory footprint. This part is responsible for the
deployment and life-cycle management of all other constituents of the application server.
The services layer contains components providing services to applications and aspects. These are
the basis implementations of transactions, messaging, mailing, and database connections services.
The aspect Layer provides interceptors adding behaviors and features to services and kernel
This is the layer where applications are deployed and make extensive use of services and aspects.
Java Enterprise Applications and Web Application reside in this layer.
2.3 Modeling components as services
Most of JBoss AS features and functionalities are provided as services for the application and
management point of view. In this section, we present these concepts.
2.3.1 Definition of a service
The specification of a service is summarized in 3 points:
• A service should perform work that is useful to multiple clients, thereby preventing each
client from having to perform the work himself.
• A service should have a name that clients can look up at runtime to gain access. This
provides a standard way to access different kinds of services and removes the need for
clients to explicitly create them before they can be used.
• Internal changes to a service should not affect any clients. In practice this means that
clients should access a service using a well-defined interface so that the implementation
can be changed without having to recompile any clients.
2.3.2 Implementation
A service can be implemented by one of the following ways:
• POJO Service implementation:
The simplest way is to develop POJOs (interface
implementation is not mandatory). These POJOs will contain the required methods and
fields to perform the required functionalities.
A naming mechanism allows registering a reference to the POJO instance with a name in
multiple clients or other POJO references can retrieve this POJO instance. When a service
is implemented by several POJOs, they can be wired together with an XML file that is very
similar to what is proposed by the Spring Framework. Injecting references between
Using POJO instances is one way of configuring a service however we can also inject
values into POJO properties.
info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 5 / 18

Here is a sample of a configuration injection:

<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

xsi:schemaLocation="urn:jboss:bean-deployer:2.0 bean-deployer_2_0.xsd"

<bean name="HRService" class="org.jboss.example.service.HRManager">
<property name="salaryStrategy"><inject bean="AgeBasedSalary"/></property>

<bean name="AgeBasedSalary"

• MBean Service Implementation:
For compatibility reasons with JBoss AS 4, a service can
be developed by implementing a POJO that is based on a MBean interface (create, start,
stop methods have to be implemented).
2.3.3 Packaging and deployment
A JAR (Java ARchive) file is the standard way to package the POJOs to implement the service. It is
possible to choose to include a deployment descriptor if there is a sensible default way to
configure the service but this is not required. To do so, you have to provide the standard file
jboss-beans.xml (which replaces the obsolete jboss-service.xml) in the standard META-INF
directory with a POJO compliant description with the XML standard described before.
To deploy the service or the application contained in the jar file, the JAR file has to be copied in
the directory “deploy”. This directory named “deploy” (see Figure 4) is periodically scanned.
When there is a new file or directory, a specific service is invoked (called a deployer). This
service is in charge of the installation and the bootstrap of the newly installed service or
Existing Deployers are:
• SARdeployer (service archive deployer)
The SAR file format was already defined in previous JBoss versions. This is an archive
format which represents an independent component (without being dependent to other
Typically a SAR file contains the suitable files (XML and Java code) to deploy a service.
This service will launch a thread as a child of the main server program.
• WARDeployer, EARDeployer and JARDepoyer are defined by their name.
2.3.4 Configuration
A configuration is a consistent set of services. It contains the required services (and deployers of
services) to match functionality (J2EE server, HTTP server, OSGi container, Rich client application
container etc).
Each configuration is represented as a sub directory located under the “server” directory (see
Figure 3). Some configurations are provided with the JBoss distribution: default, all, and minimal,
standard and web.
info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 6 / 18

The following figure (figure 3) illustrates this standard directory resource:

Figure 3 - Configuration directory resource
Each configuration contains the following mandatory subdirectories:
• Conf: contains the configuration file of services
• Deploy: a subdirectory containing the applications or services to be deployed. The kind of
deployment is automatically recognized. The suitable deployer service (see below) is
called in order to deploy the service or the application
• Deployers: This directory contains exclusively services in charge of the deployment of
services, applications. In the previous version of JBoss this specific deployer services were
identified by the suffix (*.deployer). In version 5 of JBoss AS, deployers services are
contained in a separate dedicated directory called “deployers”.
• Lib: subdirectory containing the libraries (JARs) used by one or several service(s).
The following figure illustrates this typical tree structure:

Figure 4 – A typical tree structure of a configuration
2.3.5 Extensibility
Dependencies between services are determined dynamically. Services can resolve and update
automatically dependencies with other services. POJOs can be extended by aspect injection.
info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 7 / 18

Typically an extension of JBoss 5 is provided either by new service deployment or by aspect
2.4 New AOP features
2.4.1 JBoss AOP is integrated in the microcontainer
The new JBoss AOP (weaver and aspect compiler) module is fully integrated in the
microcontainer. Dependencies between POJOs and aspects are managed by the microcontainer.
2.4.2 Aspects can be bound to POJO lifecycle
For example, an aspect can bind a proxy (with JNDI) only when the POJO enters the deployed
2.4.3 JBoss AOP integrates plain AOP features
JBoss AOP weaver has been improved in order to provide larger pointcut description.
Interception can be locating before, after, while throwing an exception, or when a finally
statement is executed.
Moreover, the weaving can be performed when classes are loaded. This new weaver is actually a
standalone project JBoss AOP. The current version of this project is 2.0.
2.4.4 Other improvements
Improvements of JBoss AOP 2.0 also concern:
• Lightweight advices
• Larger pointcut definition before/after/../finally
• Dynamic AOP definition (thanks to load time weaving)
• Fine grained aspect definition
2.5 JBoss Web
Apache Tomcat is the current web container of JBoss AS. But instead of using a straight embedded
Tomcat container, JBoss teams have create a specific project which purpose is to deliver a version
tailored to the needs of JBoss AS.
This is why we find a special version of Tomcat 6 inside JBoss AS provided for code stability and
easier maintenance. JBoss provides native libraries leveraging Apache APR and OpenSSL for
optional performance and scalability of the web container. This allows the web container to
perform nearly as Apache httpd. These packages are available in 32 or 64 bits for Windows,
Linux, Sun Solaris, HP-UX and even Mac OS X (Intel only).
Another important feature is provided: the advanced event driven Servlet API which includes non-
blocking IO based on the Apache Tomcat 6.0 Comet API (using Apache Tomcat Bayeux API).
Among other noticeable features, we find: a PHP mode for PHP scripts support, the improved IO
with NIO and the support of mod_cluster.
2.6 JBoss Messaging
By default JBoss 5 propose a service dedicated to message management. This service is an
implementation of the SUN JMS J2EE 1.4 -5 specification. When this service is registered in the
JBoss 5 server, applications hosted by the JBoss server can send and consume messages with the
following characteristics:
• JMS transactions are based on XA standard transaction API
info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 8 / 18

• Managed Driven Beans used to send and receive messages are compliant with the EJB
specification in version 3.0
• Clustering capabilities are proposed with:
o Fully clustered durable subscriptions
o Fully clustered temporary queues
o Smart clustering
• Messages are automatically moved between different nodes of the cluster if consumers are
faster on one node than another
• Message order protection
• Fully transparent failover: messages are “frozen” and stored while the JBoss Messaging is
JBoss Messaging is a JBoss 5 service. So, its parameterization is based on POJO.
2.7 JBoss Tools
This release of JBoss AS takes along a new release of JBoss Tools: 3.0. JBoss Tools software is an
IDE based on Eclipse IDE as a complete stand-alone product or as a set of plug-ins. It allows the
integration of the development environment, the tooling and the runtime components in the same
In the set of tools, you will find plug-ins and features for:
• Hibernate
• JBoss Seam
• RichFaces
• JBoss Drools
• JBoss jBPM
• JBoss ESB
• JBoss Portal
• JMX management
• BIRT integration
• TPTP Server profiling
• JST / JSF Tool
• Visual Page Editor
• JBoss Web services
• Servers views (logs…)
info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 9 / 18

The following screenshot shows a typical configuration interface with direct access to
configuration of services, view of the current logs of the server, MBeans edition and JMX
configuration edition.

Figure 5 - Screenshot of JBoss Tools 3.0 UI
Another advantage of this set of tools is that it is available as a fully supported product by Red Hat
through an offering named Red Hat JBoss Developer Studio. It provides support for a coherent
and sanitized version of the tools and is included in Red Hat JBoss Enterprise Application
2.8 JEE Certification
One of the most expected improvement of this release of JBoss AS is the certification and
compliance to the JEE specifications release 5.
This has been possible thanks to the more modular components as before providing an easier
development of these modules (we named them earlier) and a shorter release cycle. The support
of EJB 3.0 was already available as plug-in for previous release of JBoss AS leaving the time to
have a well tested implementation.
Furthermore, the integration of the reference implementation of the web containers – namely
Apache Tomcat – helped JBoss to achieve more easily the certification while providing a tailored
version of this container to give improved performances and flexibility.
Now, as another benefit of this certification, web services managed in the application server can
be JAX-WS-2.0 compliant.
3 New microcontainer structure
The emergence of a new kernel structure is one of the fundamental new features of this release
and is the basis for all new evolutions of the application server.
info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 10 / 18

3.1 From micro-kernel to microcontainer
As presented in the brief historical description in the beginning of this document, since the early
times of JBoss AS, JMX was used as the basis for the kernel. But building the kernel with JMX has
many drawbacks as explored in the following table:
Very easy to extend the server No native support for POJOs
A big part already implemented No configuration API
JMX management included for free Ad-hoc extensibility
Poor runtime embedability
The lack of configuration API made it difficult to persist JMX configuration changes and to provide
advanced tool support. Furthermore, the existence of ad-hoc extensibility in JBoss was preventing
extensibility. This was magnified by implicit and hidden dependencies and very few clean
internal API / SPIs. The runtime embedability was also poor due to JMX dependency and
constraints: limited environments were available (no JMX in J2ME env.) and therefore left no
possibilities for standalone projects.
All these constraints have led to create a new version of the kernel which will keep the JMX
configuration capabilities for backward compatibility.
3.2 Microcontainer design objectives
The main goals of the redesign of the kernel are:
• To introduce the usage of Plain Old Java Objects (POJOs)
o Services should be created by wiring POJOs together
o Improve the kernel behavior using AOP on POJOs
o Have built-in support for the management of POJOs
• To improve the usage of dependency injection
o Allow more kinds of dependencies
o Improve the lifecycle management and classloading capabilities
o Allow services deployment from other application servers using their classloading
Some other objectives retained for this new release are:
• Maintain a small memory footprint
• Reproduce features of the microkernel: JMX for backward compatibility for instance
• Provide abstract resources location
• Be able to support OSGi model and Java 7 modules
• Allow the project to be used stand-alone (this is the JBoss Microcontainer project).
info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 11 / 18

3.3 Microcontainer structure
3.3.1 Overview
The following diagram presents an overview of all the components of the microcontainer.

Figure 6 - Microcontainer internal components
Apart from the core components, the optional packages include deployers which are responsible
for the deployment of installed components.
3.3.2 Core components
The JBoss Microcontainer contains three core components:
• The Kernel
o Provides the bus and the registry of services
o Provides an event manager
o Deployer install / uninstall
• The Container module aka joinpoint
o This is the wrapper for POJOs, joinpoints, and reflection on the actual service
implementation POJOs
• The Dependency module
o An abstract state machine that manages service dependencies
 Extension (states, transitions, controller, callbacks)
o Keeps track of POJOs and services contexts
3.3.3 Role of the microcontainer in the application server
The role of the microcontainer in the application server is to wire together runtime components
with dependencies and aspects applied across component models.
To accomplish that it provides a framework that moves POJOs through a linear set of states in
order to control their lifecycle, configuration and dependencies.
The advantages of such approach are:
• Everything in Java can be reduced to a POJO: the JBoss Microcontainer can be used to
implement practically any type of application, service or component model…
info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 12 / 18

• Provide JBoss AS 5.x new standalone implementations: these are available for many
purposes: JBoss Messaging (replaces old JBoss MQ), JBoss Security, JBoss Federated SSO…
3.4 Deployers
As presented earlier, the deployers play a huge role in this new kernel structure: their role is to
manage the deployment of a runtime component on the server. They are the processing pipelines
that transform input to output metadata used to create a runtime component.
They primarily manipulate deployment metadata called attachments and from the component
description they provide a runtime component in the application server according to the
deployment strategy they implement. For instance, a Spring deployer can deploy Spring
applications knowing their inside metadata and the way dependencies are managed in such
There are two kinds of deployer types:
• Structural deployers
o Recognize deployment types (JAR, WAR, EAR, user defined…)
o Structure is defined (XSD, specific configuration files or data, dependencies…)
• Aspectized deployers
o Operate in a chain over a VFS
o Analyze deployments
o Produce metadata to be used by the JBoss MC
o Four classes of aspectized deployers: parsing, class loading, components, real
3.5 Profile service
The profile service is another component of the microcontainer and has the responsibility to
manage the POJOs and to define the POJOs to be activated. It was formerly based on the JMX
This service has a list of POJOs and their required state and knows the location of configuration
for each POJO. Each POJO has a profile. A profile contents includes deployments with a
queryable management interface, is versioned (thus providing rollback or select a specific version)
and can be propagated to remote servers.
The Profile service also binds the services together and resides on top of the JBoss
In the current version (5.0.x.GA) of the JBoss Application Server, only a basic bootstrap
implementation can be chosen. In future releases such as versions 5.1.x there will be the
possibility to have more active profiles and also the ability to define dependencies/relationships
between profiles with sub-profiles.
This ability to provide support for multiple profiles and the setup of the microcontainer as the
core of JBoss AS will ease the development of Java EE 6 compliant versions.
4 Being an OSGi™ container
OSGi (Open Service Gateway Interface) is a specification dedicated to container application. This
specification defines a framework where applications will be considered as a module (called a
bundle in the OSGi terminology) to be integrated in an OSGi container.
info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 13 / 18

This OSGi container will manage:
• A runtime execution environment of this module
• A module registry
• Lifecycle of an application
• Dependencies between modules
These 4 features are organized as layer as described in the following figure:

Concerning objectives and extensibility, OSGi extension scheme is similar to the services
principle previously described in JBoss server (see 2.3.1). Nevertheless, OSGi covers a larger
spectrum of features which are deployed as layers.
The first layer manages bundles:
• Class loading and package sharing between bundles
• Constraints versions between modules can also be managed

The second layer manages the lifecycle of a bundle according to the following scheme:

The third layer manages the registry service. The goal of this registry is to name services which
can be invoked by bundles hosted by the OSGi container. JBoss AS is not an OSGi container.
Therefore, the OSGi specification is not by default implemented in JBOSS 5 server. Nevertheless,
the JBoss community has initiated the JBossOSGi project which provides a configuration (a set of
services) implementing OSGi configuration.
info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 14 / 18

The OSGi implementation (Apache Felix, Equinox) can be selected when JBossOSGi is installed.
JBossOSGi deploy services to manage HTTP request. This feature enables the JBossOSGi server
to manage hosted OSGi bundles by a web interface.
5 Virtual File System
VFS is the most suitable file representation of the Virtual Deployment Framework. In term of Java
development, VFS is an API to be implemented which abstracts a directory of packaged resources
(jar, war directories, ZIP archive, LDAP URL, etc…). The goal of it is to propose an interface to be
implemented for the basic repositories objects (children, parent, root, etc).
The VFS is an archive abstraction that hides from the deployment services whether the archive is
an exploded directory, a JAR file, or regular text file. One of the features of the VFS is that it
allows you to create virtual archives in memory based on classpath resources or even raw bytes.
Typical applications of VFS are:
• Unit testing: Memory or raw byte based archives can be loaded in memory instead of real
files without requiring developing a complicated and context specific method to remove a
real file.
• Ship applications that are not broken up into individual Java EE packages.
6 Future directions
6.1 Available versions
JBoss Application server 5 is available in two versions:
• JBoss AS Community edition
This is the version straight from the Open Source Community and it allows the
exploitation of innovation at a faster pace.
• JBoss Enterprise Application Platform (EAP)
This is the commercial offering by Red Hat which is part of an integrated solution: JBoss
Enterprise Middleware. The advantage of this version is to bundle other technologies
(available separately) in a coherent package: JBoss Clustering, JBoss Cache, JBoss Seam,
Hibernate, JBoss Messaging, JBoss Transactions…
This version is rigorously tested (performance, scalability…), is certified on 17 operating
systems, JVM combinations and 5 database engines. Therefore, technical support is
available with a professional release and version management: versions are supported
5 years after their release date; 3 months cumulative patch cycles
6.2 Release 5.1
The release 5.1 of JBoss AS is expected to provide better clustering capabilities or clustering at all.
This is in fact the long awaited release of JBoss AS 5 with all it’s features and especially a
centralization of clustering configuration.
It should also bring more stability and some startup time improvement of the application server.
6.3 JBoss Enterprise Applications Platform 5
The Red Hat JBoss EAP version 5 is the commercial edition of JBoss AS 5 with supplemental
features bundled as a coherent, robust, supported solution, rigorously tested and supported for 5
years. The release of version 5 is expected for September 2009.
info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 15 / 18

6.4 JOPR
JOPR is an open source solution for supervision and monitoring of the JBoss Server as a plug-in of
the multi-vendor RHQ management project.
6.4.1 RHQ
RHQ is an infrastructure management application developed by Red Hat. Infrastructures managed
by RHQ can be supervised and monitored. To monitor and supervise an infrastructure by RHQ;
Data (alert, measure, etc…) can be collected by RHQ agent and are exposed by RHQ server.
It provides support for monitoring base operating system information on six operating systems as
well as management of Apache, JBoss Application Server and other related projects.
6.4.2 JON
JON (stand for JBoss Operation Network) was a commercial plug-in hosted by RHQ and
dedicated to JBoss server infrastructure management. JON was mainly dedicated to supervise and
JBoss as a JEE platform implementation (EJB, WEB or JMS infrastructure).
6.4.3 JOPR
JOPR is an open source project related to JON to present an administrative user interface for
JBoss AS (i.e., JOPR is upstream to JON). JOPR contains the JBoss middleware specific plug-ins
that are deploying within JON, such as the JBoss AS plug-in, Tomcat plug-in, et. al.
JOPR follows the same licensing agreement as the RHQ project.
JOPR includes the following features:
• Automatic discovery of resources
• Inventory
• Monitoring for availability and performance
• Complex alerting
• Fine grained security
• Configuration management
• Auditing
• Log tracking
• Content distribution
info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 16 / 18

The following figure illustrate the graphical interface of JOPR r which is dedicated to JBoss server
supervision (recent alerts, recent operations, resources threshold monitoring).

7 Conclusion
This new release of JBoss Application Server 5 has been expected for a long time and brings many
new features, new concepts and is very promising.
But we still miss huge necessary improvements such as a management console which its’
competitors provide or the integration of multiple profiles with the Microcontainer. Another
necessary feature is the existence of documentation: for too many components manuals are
If you have some projects with a due delivery date before the end of 2009, stick with versions 4.2
of the application server. On the other hand, if have new projects starting this year, you can start
with release 5.0.x while expecting release 5.1 which will provide the stability anyone would
expect for a application server.

Godefroy Riegler
Olivier Guitard
Trivadis S.A.
Rue Marterey 5 Tel: +41-21-321 47 00
CH-1005 Lausanne Fax: +41-21-321 47 01
Internet: www.trivadis.com Mail: info@trivadis.com

info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 17 / 18

info@trivadis.com . www.trivadis.com . Info-Tel. 0800 87 482 347 . Date 22.10.2009 . Page 18 / 18
Links and documentation
Red Hat JBoss AS
JBoss in Action (Manning)