This is the final release of the JBoss 5.0 series for the Java EE5 codebase that fully complies with the Java EE5 conformance testing certification requirements. It brings us to the end of a 3+ year marathon of redesigning the most popular open-source application server over a completely new kernel architecture, the JBoss Microcontainer. It also marks the beginning of a new era of innovation for JBoss as we will be exploring the capabilities and limitations of the new architecture in the releases to come. In our view, JBossAS 5 provides a healthy foundation and the most advanced and fully extensible, cross component model, aspect integration, server runtime environment. For information on the APIs that make up Java EE5, see Java EE APIs. A tutorial on Java EE 5 can be found here. Please visit also the JBoss AS docs pages as we'll be updating the documents with the latest information, and post your questions to the JBossAS 5 User Forum.

JBossAS 5 is the next generation of the JBoss Application Server build on top of the new JBoss Microcontainer. The JBoss Microcontainer is a lightweight container for managing POJOs, their deployment, configuration and lifecycle. It is a standalone project that replaces the famous JBoss JMX Microkernel of the 3.x and 4.x JBoss series. The Microcontainer integrates nicely with the JBoss framework for Aspect Oriented Programming, JBoss AOP. Support for JMX in JBoss 5 remains strong and MBean services written against the old Microkernel are expected to work. Further, it lays the groundwork for JavaEE 6 profiles oriented configurations and JBoss AS embedded that will allow for fine grained selection of services for both unit testing and embedded scenarios.

JBossAS 5 is designed around the advanced concept of a Virtual Deployment Framework (VDF), that takes the aspect oriented design of many of the earlier JBoss containers and applies it to the deployment layer. Aspectized Deployers operate in a chain over a Virtual File System (VFS), analyze deployments and produce metadata to be used by the JBoss Microcontainer, which in turn instantiates and wires together the various pieces of a deployment, controlling their lifecycle and dependencies. The VDF allows for both customization of existing component modules including JavaEE and JBoss Microcontainer, as well as introduction of other models such as OSGi and Spring.

Many key features of JBoss 5 are provided by integrating other standalone JBoss projects:

JBossAS 5 includes features and bug fixes, many of them carried over upstream from the 4.x codebase. See the Detailed Release Notes section for the full details, and Section 1.3, “Major Component Upgrades” for the major component versions included in JBossAS as well as their project page locations.

Some rather important JBoss project versions are listed below. You are encouraged to browse the individual project's documentation and view the release notes at www.jboss.org.

For a full list of the JBoss and thirdparty libraries used with JBoss AS 5.0.0.GA check the pom.xml found in the component-matrix directory of the source code distribution. To see the maven dependency tree you can run 'mvn dependency:tree' from the thirdparty directory of the source code distro.

With the reworking of the server kernel and evolution of various JBoss technologies to indepdnent projects, the JBossAS project is moving towards becoming largely an integration project. Many key pieces are now integrated as thirdparty jars that integration code/configuration makes avaialble as part of a server configuration/profile.

A common theme for JBossAS 5 is the breaking out of internal subsystems into stand-alone projects and the introduction of SPIs throughout the server codebase. Those changes should not affect directly the end user but they are an important part of the JBoss strategy for making available the various EE services as independent projects, so that they can be wired-together and be consumed à la carte inside different runtime environments and not only inside the JBoss Application Server. If you are building JBossAS from source you'll notice we are migrating to a maven2 build. At this point the build is a hybrid one because it declares all JBoss dependencies as maven2 artifacts, however after the dependencies are resolved/imported the legacy ant based build is used to compile and build the distribution. This will change to a full maven build at some point in time. The jboss maven repo can be found here. Starting from AS5 CR2, please note how the -sources.jar are also downloaded to thirdparty by default. To disable downloading of the sources to thirdparty, define the property skip-download-sources to true either on the command line or in your maven settings.xml.

This section describes additional changes in JBossAS 5.

JBossAS 5.0.0.GA introduces two new configuration, the standard and the web config. The standard config is the configuration that has been tested for JavaEE compliance. The major differences with the existing configurations is that call-by-value and deployment isolation are enabled by default, along with support for rmiiiop and juddi (taken from the all config). The configurations that are modified include:

The web config is a new experimental lightweight configuration created around JBoss Web that will follow the developments of the JavaEE 6 web profile. Except for the servlet/jsp container it provides support for JTA/JCA and JPA. It also limits itself to allowing access to the server only through the http port. Please note that this configuration is not JavaEE certified and will most likely change in the following releases.

Another notable change is that the majority of the libraries common to the different configurations have moved to a new shared location, JBOSS_HOME/common/lib/. This is so we avoid having multiple copies of the same libraries in the distribution. The location of the common library directory can be controlled by the following properties:

The common library directory is shared by all the configurations except for the minimal config. It is referenced in the very beginning of every configuration's conf/jboss-service.xml:

                
            <classpath codebase="${jboss.server.lib.url}" archives="*"/>
            <classpath codebase="${jboss.common.lib.url}" archives="*"/>
                
            

You can see that the library directory of the individual configurations is still in place, although in some cases it's empty (e.g. JBOSS_HOME/server/default/lib/)