JBoss.orgCommunity Documentation

JBoss Application Server

Installation And Getting Started Guide

1. Help Contribute
1. What's new In JBossAS 5
1.1. Overview
1.2. Component Highlights
1.3. Major Component Upgrades
1.4. Project Structure Changes
1.4.1. SVN Information
1.4.2. The Project Directories
1.5. Configuration Notes
1.5.1. JBoss VFS
1.5.2. Hibernate Logging
1.5.3. jbossall-client.jar
1.5.4. EJB3
1.5.5. Other JBossAS
1.5.6. Clustering
1.6. New Configurations
2. Getting Started
2.1. Pre-Requisites
2.1.1. Hardware and Operating System Requirements
2.1.2. Configuring Your Java Environment
3. Installation Alternatives
4. Installation With Binary Download
4.1. Download and Installation
5. Installation With Source Download
5.1. Download and Installation
5.2. Installing and configuring ANT
5.3. Building with Apache ANT
5.4. Java6 Notes
6. Setting the JBOSS_HOME variable
6.1. Setting the JBOSS_HOME variable in Linux.
6.2. Setting the JBOSS_HOME variable in Windows.
7. Uninstall JBoss
8. Test your Installation
9. The JBoss Server - A Quick Tour
9.1. Server Structure
9.2. Server Configurations
9.2.1. Server Configuration Directory Structure
9.2.2. The "default" Server Configuration File Set
9.2.3. The "all" Server Configuration File Set
9.2.4. EJB3 Services
9.3. Starting and Stopping the Server
9.3.1. Start the Server
9.3.2. Start the Server With Alternate Configuration
9.3.3. Using run.sh
9.3.4. Stopping the Server
9.3.5. Running as a Service under Microsoft Windows
9.4. The JMX Console
9.5. Hot-deployment of services in JBoss
9.6. Basic Configuration Issues
9.6.1. Bootstrap Configuration
9.6.2. Legacy Core Services
9.6.3. Logging Service
9.6.4. Security Service
9.6.5. Additional Services
10. EJB3 Caveats in JBoss Application Server 5.0.0
10.1. Unimplemented features
10.2. Referencing EJB3 Session Beans from non-EJB3 Beans
11. Sample Applications
12. Sample JSF-EJB3 Application
12.1. Data Model
12.2. JSF Web Pages
12.3. EJB3 Session Beans
12.4. Configuration and Packaging
12.4.1. Building The Application
12.4.2. Configuration Files
12.5. The Database
12.5.1. Creating the Database Schema
12.5.2. The HSQL Database Manager Tool
12.6. Deploying the Application
13. Using Seam
13.1. Data Model
13.2. JSF Web Pages - index.xhtml and create.xhtml
13.3. Data Access using a Session Bean
13.4. JSF Web Pages - todos.xhtml and edit.xhtml
13.5. Xml Files
13.6. Further Information
14. Using other Databases
14.1. DataSource Configuration Files
14.2. Using MySQL as the Default DataSource
14.2.1. Installing the JDBC Driver and Deploying the datasource
14.2.2. Testing the MySQL DataSource
14.3. Configuring a datasource for Oracle DB
14.3.1. Installing the JDBC Driver and Deploying the DataSource
14.3.2. Testing the Oracle DataSource
14.4. Configuring a datasource for Microsoft SQL Server 200x
14.4.1. Installing the JDBC Driver and Deploying the DataSource
14.5. Configuring JBoss Messaging Persistence Manager
14.6. Creating a JDBC client
B. Further Information Sources

JBoss Application Server is the open source implementation of the Java EE suite of services. It comprises a set of offerings for enterprise customers who are looking for preconfigured profiles of JBoss Enterprise Middleware components that have been tested and certified together to provide an integrated experience. It's easy-to-use server architecture and high flexibility makes JBoss the ideal choice for users just starting out with J2EE, as well as senior architects looking for a customizable middleware platform.

Because it is Java-based, JBoss Application Server is cross-platform, easy to install and use on any operating system that supports Java. The readily available source code is a powerful learning tool to debug the server and understand it. It also gives you the flexibility to create customized versions for your personal or business use.

Installing JBoss Application Server is simple and easy. You can have it installed and running in no time. This guide will teach you to install and get started with the JBoss Application Server.

If you find a typographical error in the Installation Guide and Getting Started Guide, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in JIRA: http://jira.jboss.com against the project JBoss Application Server and component Docs/Installation and Getting Started Guide.

If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.


Be sure to give us your name so you can receive full credit.


This content is taken from svn.jboss.org/repos/jbossas/projects/docs/community/5 and has yet to be branched.

To access the content directly and make changes yourself:

			svn co https://svn.jboss.org/repos/jbossas/projects/docs/community/5 --username yourusername

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:

  • JBoss Microcontainer is the next generation POJO based kernel that is used as the core of the server. It supports an extensible deployment model and advanced dependency relationships.

  • The definition of the non-kernel deployers and deployment is now defined a Profile obtained from the ProfileService. The ProfileService also provides the ManagementView for ManagedDeployments/ManagedObjects used by the OpenConsole admin tool.

  • JBoss EJB3 included with JBoss 5 provides the implementation of the latest revision of the Enterprise Java Beans (EJB) specification. EJB 3.0 is a deep overhaul and simplification of the EJB specification. EJB 3.0's goals are to simplify development, facilitate a test driven approach, and focus more on writing plain old java objects (POJOs) rather than coding against complex EJB APIs.

  • JBoss Messaging is a high performance JMS provider in the JBoss Enterprise Middleware Stack (JEMS), included with JBoss 5 as the default messaging provider. It is also the backbone of the JBoss ESB infrastructure. JBoss Messaging is a complete rewrite of JBossMQ, which is the default JMS provider for the JBoss AS 4.x series.

  • JBossCache that comes in two flavors. A traditional tree-structured node-based cache and a PojoCache, an in-memory, transactional, and replicated cache system that allows users to operate on simple POJOs transparently without active user management of either replication or persistency aspects.

  • JBossWS is the web services stack for JBoss 5 providing Java EE compatible web services, JAX-WS-2.0.

  • JBoss Transactions is the default transaction manager for JBoss 5. JBoss Transactions is founded on industry proven technology and 18 year history as a leader in distributed transactions, and is one of the most interoperable implementations available.

  • JBoss Web is the Web container in JBoss 5, an implementation based on Apache Tomcat that includes the Apache Portable Runtime (APR) and Tomcat native technologies to achieve scalability and performance characteristics that match and exceed the Apache Http server.

  • JBoss Security has been updated to support pluggable authorization models including SAML, XACML and federation.

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.

The project source is rooted at Anonymous SVN for public access, and Committer SVN for committer access. The directories under these roots follow the usual svn conventions:

  • trunk - the development branch for the next major version

  • branches - the location for stable branches associated with release series.

  • Branch_5_0 - the branch for 5.0.x series development.

  • tags - locations for tagged releases

  • JBoss_5_0_0_GA - The 5.0.0.GA release tag.

When you checkout the project the resulting subdirectories are:


Server aspects


The server bootstrap that loads the JBoss Microcontainer


The server build directory which contains the main build.xml. See Section 5.3, “Building with Apache ANT”Building with ANT for more on building the server.


A maven project that declares the dependcies for the jboss-all-client.jar


Clustering related services and integration


A maven project the declares the external dependencies consumed by the server. This is used to build the thirdparty/* library structure.


JCA implementation and integration code.


Obsolete admin console. See JBoss Embedded Consoleproject for the future direction of the server admin console.


JSR88 deployment services code.


EJB3 integration code.


Obsolete JBossAS emebedded project that has been moved toSVN embedded for further development. See the Design of Embedded JBoss forum for design discussions.


Hibernate deployment integration code.


JacORB integration code for IIOP support.



JMX remoting and JTS integration code


javax.management.* package implementations


A javax.management.remote.JMXConnector implementation


The main() entry point code


JSR77 mbean view generation code


JBoss JMX extensions


JBoss Messaging integration code


The JBossAS root maven pom


The ProfileService, ManagementView, and DeploymentManager implementations.


JBoss Security integration code


The legacy EJB2 containers, deployers and detached invokers


Spring bean deployment integration


ProfileServiceBootstrap implementation and management code


MBean service component model and deployers


The JBossAS testsuite


The maven2 thirdparty project which builds the local thirdparty jars used by the ant build.


JBossWeb integration code and deployers


build tool jars


Various misc services


JBossWS integration code and deployers

This section describes additional changes in JBossAS 5.

The ClassPathExtension MBean has been replaced with a VFS classloader definition, see JBAS-5446.

The old JMX-based ServiceBindingManager has been replaced by a POJO-based ServiceBindingManager, see AS5ServiceBindingManager Wiki.

The Farm service from 4.x has been removed, and replaced with a HASingletonDeploymentScanner that integrates with the ProfileService.

JBoss 5 is stricter when it comes to verifying/deploying JavaEE artifacts. EJB3 deployments that run in AS 4.2 may fail in AS5. We have tried to keep the validation messages as accurate as possible in order to help you modify your deployment descriptors/annotations to be in-line with the JavaEE 5 requirements.

A new jboss.server.log.threshold system property can be used to control the log/server.log threshold. It defaults to DEBUG.

The default conf/jboss-log4j.xml configuration now includes the thread name for entries in log/server.log (JBAS-5274).

The transaction manager configuration has moved from conf/jboss-service.xml to deploy/transaction-service.xml.

All the security related configuration files are now grouped under the deploy/security directory (JBAS-5318). The security configuration changes are further described in SecurityInJBoss5 wiki.

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/)

You must have adequate disk space to install JDK and JBoss Application Server while also allowing enough space for your applications. Before installing JBoss Application Server you must have a working installation of Java. Since JBoss is 100% pure Java you can have it working on any Operating System / Platform that supports Java.

You must have a working installation of JDK 1.5 or JDK 1.6 before you install JBoss Application Server. You can install the 32-bit or 64-bit JVM as per your requirements. In this guide we will show you how to install a 32-bit Sun JDK 5.0 on a Linux Platform and Microsoft Windows Platform. But before we do that let's take a look at some of the benefits of using a 64-bit JVM.

Installing and Configuring 32-bit Sun JDK 5.0 or JDK 6.0 on Linux

  • Download the Sun JDK 5.0 or JDK 6 (Java 2 Development Kit) from Sun's website: http://java.sun.com/javase/downloads/index_jdk5.jsp for JDK 5.0 or http://java.sun.com/javase/downloads/ for JDK 6.0. Select the JDK Update <x>" (where x is the latest update number) for download and then select "RPM in self-extracting" file for Linux[1]. Read the instructions on Sun's website for installing the JDK.

  • If you do not want to use SysV service scripts you can install the "self-extracting file" for Linux instead of choosing the "RPM in self-extracting" file. In that case you can skip the next step mentioned here. But it is recommended to use the SysV service scripts for production servers.

  • Download and install the appropriate -compat RPM from JPackage here. Please ensure you choose a matching version of the -compat package to the JDK you installed.

  • Create an environment variable that points to the JDK installation directory and call it JAVA_HOME. Add $JAVA_HOME/bin to the system path to be able to run java from the command line. You can do this by adding the following lines to the .bashrc file in your home directory.

    #In this example /usr/java/jdk1.6.0_07 is the JDK installation directory.
                                    export JAVA_HOME=/usr/java/jdk1.6.0_07
                                    export PATH=$PATH:$JAVA_HOME/bin

    Set this variable for the user account doing the installation and also for the user account that will run the server.

  • If you have more than one version of JVM installed in your machine, make sure you are using the JDK1.5 or JDK1.6 installation as the default source for the java and javac executables. You can do this using the alternatives system. The alternatives system allows different versions of Java, from different sources to co-exist on your system.

    Select alternatives for java, javac and java_sdk_1.<x>

    • As root, type the following command at the shell prompt and you should see something like this:

      [root@vsr ~]$ /usr/sbin/alternatives --config java
      There are 2 programs which provide 'java'.
      Selection    Command
      1           /usr/lib/jvm/jre-1.4.2-gcj/bin/java
      *+ 2           /usr/lib/jvm/jre-1.5.0-sun/bin/java
      Enter to keep the current selection[+], or type selection number:

      Make sure the Sun version [jre-1.5.0-sun in this case] is selected (marked with a '+' in the output), or select it by entering its number as prompted.

    • Repeat the same for javac and java_sdk_1.<x>

      [root@vsr ~]$ /usr/sbin/alternatives --config javac
      There are 1 programs which provide 'javac'.
      Selection   Command
      *+ 1           /usr/lib/jvm/java-1.5.0-sun/bin/javac
      Enter to keep the current selection[+], or type selection number:

      [root@vsr ~]$ /usr/sbin/alternatives --config java_sdk_1.5.0
      There are 1 programs which provide 'java_sdk_1.5.0'.
      Selection   Command
      *+ 1           /usr/lib/jvm/java-1.5.0-sun
      Enter to keep the current selection[+], or type selection number:

      You should verify that java, javac and java_sdk_1.<x> all point to the same manufacturer and version.


    You can always override this step by setting the JAVA_HOME environment variable as explained in the previous step.

  • Make sure that the java executable is in your path and that you are using an appropriate version. To verify your Java environment, type java -version at the shell prompt and you should see something like this:

                                    [root@vsr ~]$ java -version
                                    java version "1.5.0_14"
                                    Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)
                                    Java HotSpot(TM) Client VM (build 1.5.0_14-b03, mixed mode, sharing)

Installing and Configuring 32-bit Sun JDK 5.0 or JDK 6.0 on Microsoft Windows

  • Download the Sun JDK 5.0 (Java 2 Development Kit) from Sun's website: http://java.sun.com/javase/downloads/index_jdk5.jsp for JDK 5.0 or http://java.sun.com/javase/downloads/ for JDK 6.0. Choose the JDK Update <x>" (where x is the latest update number) for download and then select your Windows Platform options to perform the installation.

  • Create an environment variable called JAVA_HOME that points to the JDK installation directory, for example: C:\Program Files\Java\jdk1.5.0_14\. In order to run java from the command line add the jre\bin directory to your path, for example: C:\Program Files\Java\jdk1.5.0_14\jre\bin. To do this, open the Control Panel from the Start Menu, switch to Classic View if necessary, open the System Control Panel applet, select the Advanced Tab, and click on the Environment Variables button.

[1] Make sure you choose the appropriate file for your platform.

You can install the JBoss Application Server in one of these two modes:

Three types of server configurations will be included in your installation - minimal, default, and all.

You can download the Binary zip files from http://labs.jboss.com/jbossas/downloads/.

There are two binary distributions available:

In this form of installation, simply unzip the downloaded zip file to the directory of your choice on any operating system that supports the zip format.

  • Unzip jboss-<release>.zip to extract the archive contents into the location of your choice. You can do this using the JDK jar tool (or any other ZIP extraction tool). In the example below we are assuming you downloaded the zip file to the /jboss directory.

                                [usr]$ cd /jboss
                                [usr]$ jar -xvf jboss-<release>.zip

  • You should now have a directory called jboss-<release>. Next you need to set your JBOSS_HOME environment variables. This is discussed in Chapter 6, Setting the JBOSS_HOME variable.

You can download the zip source file from http://labs.jboss.com/jbossas/downloads/.

  • Uncompress jboss-<release>-src.tar.gz to extract the archive contents into the location of your choice. You can do this using the tar archiving utility in Linux (or any other compatible extraction tool). In this example we are assuming your source files were copied in the /jboss folder.

    [user@localhost]$ cd /jboss
                                [user@localhost]$ tar -xvf jboss-<release>-src.tar.gz

  • You should now have a directory called jboss-<release>-src.tar.gz. The next step is to build your source files. In this example we are using Apache ANT. This is discussed in the following section.

Apache Ant is a Java-based build tool. Instead of using an extended model using shell-based commands, Ant is extended using Java classes that use XML-based configuration files. The configuration files call out a target tree that executes various tasks. Each task is run by an object that implements a particular Task interface. This gives you the ability to perform cross platform builds. Please also note that if needed, Ant provides an <exec> task that allows commands to be executed based on the Operating System it is executing on. For more information on Apache ANT please click here.

You will need to build your JBoss Application Server source files before you can run the application server. Apache Ant is shipped with the JBoss Application Server source files and can be executed from the <source_directory>/tools/bin directory.

The source files can also be built using Apache Maven which is also shipped with the JBoss Application Server source files under <source_directory>/tools/maven directory. For more information about Apache Maven, please refer to http://maven.apache.org/.

Like Java, you also need to set the environment variables for Apache ANT and/or Apache Maven. The following example illustrates a desirable configuration for the .bashrc file. In the example the file is edited using the gnome text editor (gedit).

[user@localhost ~]$ gedit .bashrc
                # Source global definitions
                if [ -f /etc/bashrc ]; then
                # User specific aliases and functions
                # The following are the environment variables for Java , ANT and Maven
                export JAVA_HOME=/usr/java/jdk1.6.0_07/
                export PATH=$PATH:$JAVA_HOME/bin
                export ANT_HOME=/home/downloads/jboss-<source_directory>/tools/
                export PATH=$PATH:$ANT_HOME/bin
                export MAVEN_HOME=/home/downloads/jboss-<source_directory>/tools/maven
                export PATH=$PATH:$MAVEN_HOME/bin

To implement the changes you've made to the .bashrc file, type the following on a terminal.

[user@localhost ~]$ source .bashrc
                [user@localhost ~]$

If any errors are displayed, please check your .bashrc file for errors and ensure that all directory paths are correct.

To build the JBoss Application Server source files with Apache ANT, from a terminal change directory to where the unzipped source files are. In the following example we are assuming that the source files were copied and unzipped in the logged in user's downloads folder.

[user@localhost]$ cd /home/user/downloads/jboss-<release>-src/build
[504][valkyrie: jboss-5.0.0.GA-src]$ ls
aspects	          hibernate-int  security
bootstrap         iiop           server
build			  j2se           spring-int
client			  jbossas        system
cluster			  jmx            system-jmx
component-matrix  jmx-remoting   testsuite
connector         main           thirdparty
console           management     tomcat
deployment        mbeans         tools
docbook-support   messaging      varia
ejb3              pom.xml        webservices
embedded          profileservice

From the contents of the build directory above, you can see the build.xml file which is used by Apache ANT as a configuration file when building your source files. The next step is to perform the build using Apache ANT as illustrated below.

[571][valkyrie: build]$ ant
Buildfile: build.xml

Trying to override old definition of task property

[copy] Copying 1 file to /Users/svn/Releases/jboss-5.0.0.GA-src/build


[echo] groups:  default
[echo] modules: bootstrap,main,j2se,mbeans,jmx,system,system-jmx,security,server,deployment,jbossas/remoting,jmx-remoting,jbossas/jmx-remoting,messaging,cluster,varia,iiop,aspects,profileservice,connector,management,ejb3,tomcat,webservices,hibernate-int,console,spring-int


[echo] Calling mvn command located in /Users/svn/Releases/jboss-5.0.0.GA-src/build/../tools/maven


Total time: 21 minutes 34 seconds

A successful build will have the above message. The first time you build the tree it will download a large number of thirdparty files from maven repositories. After that, these will be used from the local repository and the build will be much faster. Typical initial build times can be 30 minutes with subsequent build times 3 minutes. If your build fails, please check the error log and ensure that your configuration files and environment variables are correctly set. The JBoss Application Server files are built under the build/output/jboss-<release> directory as indicated below.

[578][valkyrie: build]$ ls
VersionRelease.java	build.sh		local.properties
build-distr.xml		build.xml		output
build-release.xml	docs			pom.xml
build.bat		eclipse.psf
build.log		etc
[579][valkyrie: build]$ ls output/
[580][valkyrie: build]$

The jboss-<release> directory contains your successful JBoss Application Server files. You can copy this folder to a different location or run the server from this folder after setting the JBOSS_HOME environment variable in your .bashrc file. Next you need to set your JBOSS_HOME environment variables. This is discussed in Chapter 6, Setting the JBOSS_HOME variable.

After you have installed the JBoss Application Server, it is wise to perform a simple startup test to validate that there are no major problems with your Java VM/operating system combination. To test your installation, open the JBOSS_DIST/jboss-<release>/bin directory and execute the run.bat (for Windows) or run.sh (for Linux) script, as appropriate for your operating system.

Your output should look similar to the following (accounting for installation directory differences) and contain no error or exception messages:

        [samson@dhcp-1-150 bin]$ sh run.sh 
        JBoss Bootstrap Environment
        JBOSS_HOME: /home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.GA
        JAVA: /Library/Java/Home/bin/java
        JAVA_OPTS: -Dprogram.name=run.sh -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000
        CLASSPATH: /home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.GA/bin/run.jar
        21:47:23,874 INFO  [ServerImpl] Starting JBoss (Microcontainer)...
        21:47:23,875 INFO  [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.GA (build: SVNTag=JBoss_5_0_0_GA date=200812011226)
        ...output truncated
        21:47:46,090 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-
        21:47:46,112 INFO  [ServerImpl] JBoss (Microcontainer) [5.0.0.GA (build: SVNTag=JBoss_5_0_0_GA date=200812011226)] Started in 22s:227ms

Now open http://localhost:8080 in your web browser. (Make sure you dont have anything else already on your machine using that port).[2] The contents of your page should look similar to the following: Figure 8.1, “Test your Installation”.

You are now ready to use the JBoss Application Server.

[2] Note that on some machines, the name localhost may not resolve properly and you may need to use the local loopback address instead.

Fundamentally, the JBoss architecture consists of the microcontainer, bootstrap beans loaded into the micrcontainer, a collection of deployers for loading various deployment types, and various mcbean(-jboss-beans.xml) and legacy mbean(jboss-service.xml) deployments. This makes it easy to assemble different configurations and gives you the flexibility to tailor them to meet your requirements.

You don’t have to run a large, monolithic server all the time; you can remove the components you don’t need (which can also reduce the server startup time considerably) and you can also integrate additional services into JBoss by writing your own MBeans. You certainly do not need to do this to be able to run standard Java EE 5 applications though.

You don’t need a detailed understanding of the microcontainer to use JBoss, but it’s worth keeping a picture of this basic architecture in mind as it is central to the way JBoss works.

The JBoss Application Server ships with three different server configurations. Within the <JBoss_Home>/server directory, you will find five subdirectories: minimal, default, standard, all and web - one for each server configuration. Each of these configurations provide a different set of services. The default configuration is the one used if you don’t specify another one when starting up the server.

If you want to know which services are configured in each of these instances, the primary differences will be in the <JBoss_Home>/server/<instance-name>/deployers/ directory and also the services deployments in the <JBoss_Home>/server/<instance-name>/deploy directory. For example, the default profile deployers and deploy directory contents are:

[usr@localhost <JBoss_Home>]$ls server/default/deployers 
alias-deployers-jboss-beans.xml		jboss-aop-jboss5.deployer
bsh.deployer				jboss-jca.deployer
clustering-deployer-jboss-beans.xml		jbossweb.deployer
dependency-deployers-jboss-beans.xml	jbossws.deployer
directory-deployer-jboss-beans.xml	j	sr77-deployers-jboss-beans.xml
ear-deployer-jboss-beans.xml		metadata-deployer-jboss-beans.xml
ejb-deployer-jboss-beans.xml		seam.deployer
ejb3.deployer				security-deployer-jboss-beans.xml
[usr@localhost <JBoss_Home>]$ls server/default/deploy 
ROOT.war				jsr88-service.xml
cache-invalidation-service.xml	legacy-invokers-service.xml
ejb2-container-jboss-beans.xml	mail-ra.rar
ejb2-timer-service.xml		mail-service.xml
ejb3-connectors-jboss-beans.xml	management
ejb3-container-jboss-beans.xml	messaging
ejb3-interceptors-aop.xml		monitoring-service.xml
ejb3-timer-service.xml		profileservice-jboss-beans.xml
hdscanner-jboss-beans.xml		properties-service.xml
hsqldb-ds.xml			quartz-ra.rar
http-invoker.sar			remoting-jboss-beans.xml
jboss-local-jdbc.rar		schedule-manager-service.xml
jboss-xa-jdbc.rar			scheduler-service.xml
jbossweb.sar			security
jbossws.sar			sqlexception-service.xml
jca-jboss-beans.xml		transaction-jboss-beans.xml
jms-ra.rar			transaction-service.xml
jmx-console.war			uuid-key-generator.sar
jmx-invoker-service.xml		vfs-jboss-beans.xml

while the web profile deployers and deploy directory contents are:

[usr@localhost <JBoss_Home>]$ls server/web/deployers 
alias-deployers-jboss-beans.xml	jbossweb.deployer
ejb3.deployer			metadata-deployer-jboss-beans.xml
jboss-aop-jboss5.deployer		security-deployer-jboss-beans.xml
[usr@localhost <JBoss_Home>]$ls server/web/deployers 
ROOT.war				jbossweb.sar
ejb3-container-jboss-beans.xml	jca-jboss-beans.xml
hdscanner-jboss-beans.xml		jmx-console.war
hsqldb-ds.xml			jmx-invoker-service.xml
http-invoker.sar			security
jboss-local-jdbc.rar		transaction-jboss-beans.xml

The directory server configuration you’re using, is effectively the server root while JBoss is running. It contains all the code and configuration information for the services provided by the particular server configuration. It’s where the log output goes, and it’s where you deploy your applications. Table 9.1, “Server Configuration Directory Structure” shows the directories inside the server configuration directory (<JBoss_Home>/server/<instance-name>) and their functions.

Table 9.1. Server Configuration Directory Structure

Directory Description
conf The conf directory contains the bootstrap.xml bootstrap descriptor file for a given server configuration. This defines the core microcontainer beans that are fixed for the lifetime of the server.
data The data directory is available for use by services that want to store content in the file system. It holds persistent data for services intended to survive a server restart. Serveral JBoss services, such as the embedded Hypersonic database instance, store data here.
deploy The deploy directory contains the hot-deployable services (those which can be added to or removed from the running server). It also contains applications for the current server configuration. You deploy your application code by placing application packages (JAR, WAR and EAR files) in the deploy directory. The directory is constantly scanned for updates, and any modified components will be re-deployed automatically.
lib This directory contains JAR files (Java libraries that should not be hot deployed) needed by this server configuration. You can add required library files here for JDBC drivers etc. All JARs in this directory are loaded into the shared classpath at startup. Note that this directory only contains those jars unique to the server configuration. Jars common across the server configurations are now located in <JBoss_Home>/common/lib.
log This is where the log files are written. JBoss uses the Jakarta log4j package for logging and you can also use it directly in your own applications from within the server. This may be overridden through the conf/jboss-log4j.xml configuration file.
tmp The tmp directory is used for temporary storage by JBoss services. The deployer, for example, expands application archives in this directory.
work This directory is used by Tomcat for compilation of JSPs.

The "default" server configuration file set is located in the <JBoss_Home>/server/default directory. The following example illustrates a truncated directory structure of the jboss-as-<release> server configuration files:

[user@localhost <JBoss_Home>]$ tree
|-- bin
|-- client
|-- common
|   |-- lib
|   |   |-- antlr.jar
|   |   |-- ... many more jars
|-- docs
|   |-- dtd
|   |-- examples
|   |   |-- binding-manager
|   |   |   `-- sample-bindings.xml
|   |   |-- jca
|   |   |-- jms
|   |   |-- jmx
|   |   |-- netboot
|   |   |   `-- netboot.war
|   |   `-- varia
|   |       |-- deployment-service
|   |       |-- derby-plugin.jar
|   |       |-- entity-resolver-manager
|   |       |   `-- xmlresolver-service.xml
|   |       `-- jboss-bindings.xml
|   `-- schema
|-- lib
|   |-- commons-codec.jar
|   |-- commons-httpclient.jar
|   |-- commons-logging.jar
|   |-- concurrent.jar
|   |-- endorsed
|   |   |-- serializer.jar
|   |   |-- xalan.jar
|   |   `-- xercesImpl.jar
|   |-- getopt.jar
|   |-- jboss-common.jar
|   |-- jboss-jmx.jar
|   |-- jboss-system.jar
|   |-- jboss-xml-binding.jar
|   `-- log4j-boot.jar
`-- server
|-- all
|   |-- conf
|   |   |-- bootstrap/
|   |   |   |-- aop.xml
|   |   |   |-- bindings.xml
|   |   |   |-- aop.xml
|   |   |   |-- classloader.xml
|   |   |   |-- deployers.xml
|   |   |   |-- jmx.xml
|   |   |   |-- profile-repository.xml
|   |   |   |-- profile.xml
|   |   |   |-- vfs.xml
|   |   |-- bootstrap.xml
|   |   |-- bootstrap-norepo.xml
|   |   |-- jacorb.properties
|   |   |-- java.policy
|   |   |-- jax-ws-catalog.xml
|   |   |-- jboss-log4j.xml
|   |   |-- jboss-service.xml
|   |   |-- jbossjta-properties.xml
|   |   |-- jndi.properties
|   |   |-- login-config.xml
|   |   |-- props
|   |   |   |-- jbossws-roles.properties
|   |   |   |-- jbossws-users.properties
|   |   |   |-- jmx-console-roles.properties
|   |   |   `-- jmx-console-users.properties
|   |   |-- standardjboss.xml
|   |   |-- standardjbosscmp-jdbc.xml
|   |   `-- xmdesc
|   |-- deploy
|   |-- deploy-hasingleton
|   |   `-- jms
|   |-- deployers
|   `-- lib
|-- default
|   |-- conf
|   |   |-- bootstrap/
|   |   |   |-- aop.xml
|   |   |   |-- bindings.xml
|   |   |   |-- aop.xml
|   |   |   |-- classloader.xml
|   |   |   |-- deployers.xml
|   |   |   |-- jmx.xml
|   |   |   |-- profile-repository.xml
|   |   |   |-- profile.xml
|   |   |   |-- vfs.xml
|   |   |-- bootstrap.xml
|   |   |-- bootstrap-norepo.xml
|   |   |-- jacorb.properties
|   |   |-- java.policy
|   |   |-- jax-ws-catalog.xml
|   |   |-- jboss-log4j.xml
|   |   |-- jboss-service.xml
|   |   |-- jbossjta-properties.xml
|   |   |-- jndi.properties
|   |   |-- login-config.xml
|   |   |-- props
|   |   |   |-- jbossws-roles.properties
|   |   |   |-- jbossws-users.properties
|   |   |   |-- jmx-console-roles.properties
|   |   |   `-- jmx-console-users.properties
|   |   |-- standardjboss.xml
|   |   |-- standardjbosscmp-jdbc.xml
|   |   `-- xmdesc
|   |       |-- AttributePersistenceService-xmbean.xml
|   |       |-- ClientUserTransaction-xmbean.xml
|   |       |-- JNDIView-xmbean.xml
|   |       |-- Log4jService-xmbean.xml
|   |       |-- NamingBean-xmbean.xml
|   |       |-- NamingService-xmbean.xml
|   |       |-- TransactionManagerService-xmbean.xml
|   |       |-- org.jboss.deployment.JARDeployer-xmbean.xml
|   |       |-- org.jboss.deployment.MainDeployer-xmbean.xml
|   |       `-- org.jboss.deployment.SARDeployer-xmbean.xml
|   |-- data
|   |   |-- hypersonic
|   |   |-- jboss.identity
|   |   |-- tx-object-store
|   |   `-- xmbean-attrs
|   |-- deploy
|   |-- lib
|   |-- log
|   |   |-- boot.log
|   |   |-- server.log
|   |   `-- server.log.2008-08-09
|   |-- tmp
|   `-- work
|       `-- jboss.web
|           `-- localhost
`-- minimal
|-- conf
|   |-- bootstrap/
|   |-- bootstrap/aop.xml
|   |-- bootstrap/classloader.xml
|   |-- bootstrap/deployers.xml
|   |-- bootstrap/jmx.xml
|   |-- bootstrap/profile.xml
|   |-- bootstrap.xml
|   |-- jboss-log4j.xml
|   |-- jboss-service.xml
|   |-- jndi.properties
|   `-- xmdesc
|       |-- NamingBean-xmbean.xml
|       `-- NamingService-xmbean.xml
|-- deploy/
|-- deploy/hdscanner-jboss-beans.xml
|-- deployers/
`-- lib
|-- jboss-minimal.jar
|-- jnpserver.jar
`-- log4j.jar

The files in the conf directory are explained in the following table.

Table 9.2. Contents of "conf" directory

File Description
bootstrap.xml This is the bootstrap.xml file that defines which additional microcontainer deployments will be loaded as part of the bootstrap phase.
bootstrap/* This directory contains the microcontainer bootstrap descriptors that are referenced from the bootstrap.xml file.
jboss-service.xml jboss-service.xml legacy core mbeans that have yet to be ported to either bootstrap deployments, or deploy services. This file will go away in the near future.
jbossjta-properties.xml jbossjta-properties.xml specifies the JBossTS transaction manager default properties.
jndi.properties The jndi.properties file specifies the JNDI InitialContext properties that are used within the JBoss server when an InitialContext is created using the no-arg constructor.
java.policy A placeholder java security policy file that simply grants all permissions.
jboss-log4j.xml This file configures the Apache log4j framework category priorities and appenders used by the JBoss server code.
login-config.xml This file contains sample server side authentication configurations that are applicable when using JAAS based security.
props/* The props directory contains the users and roles property files for the jmx-console.
standardjboss.xml This file provides the default container configurations.
standardjbosscmp-jdbc.xml This file provides a default configuration file for the JBoss CMP engine.
xmdesc/*-mbean.xml The xmdesc directory contains XMBean descriptors for several services configured in the jboss-service.xml file.

The files in the deployers directory are explained in the following table.

Table 9.3. Contents of "deployers" directory

File Description
alias-deployers-jboss-beans.xml Deployers that know how to handle The know how to handle <alias> in <deployment> as true controller context. Meaning they will only get active/installed when their original is installed.
bsh.deployer This file configures the bean shell deployer, which deploys bean shell scripts as JBoss mbean services.
clustering-deployer-jboss-beans.xml Clustering-related deployers which add dependencies on needed clustering services to clustered EJB3, EJB2 beans and to distributable web applications.
dependency-deployers-jboss-beans.xml Deployers for aliases.txt, jboss-dependency.xml jboss-depedency.xml adds generic dependency on whatever. aliases.txt adds human-readable name for deployments, e.g. vfszip://home/blah/.../jboss-5.0.0.GA/server/default/deploy/some-long-name.ear aliased to ales-app.ear.
directory-deployer-jboss-beans.xml Adds legacy behavior for directories, handling its children as possible deployments. e.g. .sar's lib directory to treat its .jar files as deployments
ear-deployer-jboss-beans.xml JavaEE 5 enterprise application related deployers
ejb-deployer-jboss-beans.xml Legacy JavaEE 1.4 ejb jar related deployers
ejb3.deployer This is a deployer that supports JavaEE 5 ejb3, JPA, and application client deployments, .
hibernate-deployer-jboss-beans.xml Deployers for Hibernate -hibernate.xml descriptors, which are similar to Hibernate's .cfg.xml files.
jboss-aop-jboss5.deployer JBossAspectLibrary and base aspects. Why is this in deployers, dependencies?
jboss-jca.deployer jboss-jca.deployer description
jbossweb.deployer The JavaEE 5 servlet, JSF, JSP deployers.
jbossws.deployer The JavaEE 5 webservices endpoint deployers.
jsr77-deployers-jboss-beans.xml Deployers for creating the JSR77 MBeans from the JavaEE components.
metadata-deployer-jboss-beans.xml Deployers for processing the JavaEE metadata from xml, annotations.
seam.deployer Deployer providing integration support for JBoss Seam applications.
security-deployer-jboss-beans.xml Deployers for configuration the security layers of the JavaEE components.

The files in the deploy directory are explained in the following table.

Table 9.4. Contents of "deploy" directory

File Description
ROOT.war ROOT.war establishes the '/' root web application.
cache-invalidation-service.xml This is a service that allows for custom invalidation of the EJB caches via JMS notifications. It is disabled by default.
ejb2-container-jboss-beans.xml ejb2-container-jboss-beans.xml UserTransaction integration bean for the EJB2 containers.
ejb2-timer-service.xml ejb2-timer-service.xml contains the ejb timer service beans.
ejb3-connectors-jboss-beans.xml ejb3-connectors-jboss-beans.xml EJB3 remoting transport beans.
ejb3-container-jboss-beans.xml ejb3-container-jboss-beans.xml UserTransaction integration bean for the EJB3 containers.
ejb3-interceptors-aop.xml ejb3-interceptors-aop.xml defines the EJB3 container aspects.
ejb3-timer-service.xml ejb3-timer-service.xml an alternate quartz based timer service
hdscanner-jboss-beans.xml hdscanner-jboss-beans.xml the deploy directory hot deployment scanning bean
hsqldb-ds.xmlconfigures the Hypersonic embedded database service configuration file. It sets up the embedded database and related connection factories.
http-invoker.sarcontains the detached invoker that supports RMI over HTTP. It also contains the proxy bindings for accessing JNDI over HTTP.
jboss-local-jdbc.raris a JCA resource adaptor that implements the JCA ManagedConnectionFactory interface for JDBC drivers that support the DataSource interface but not JCA.
jboss-xa-jdbc.rarJCA resource adaptors for XA DataSources
jbossweb.sar an mbean service supporting TomcatDeployer with web application deployment service management.
jbossws.sarprovides JEE web services support.
jca-jboss-beans.xml jca-jboss-beans.xml is the application server implementation of the JCA specification. It provides the connection management facilities for integrating resource adaptors into the JBoss server.
jms-ra.rar jms-ra.rar JBoss JMS Resource Adapter
messaging/connection-factories-service.xml configures the DLQ, ExpiryQueue JMS connection factory
messaging/destinations-service.xml The message persistence store service
messaging/destinations-service.xml configures the DLQ, ExpiryQueue JMS destinations.
messaging/jms-ds.xml jms-ds.xml configures the JMSProviderLoader and JmsXA inflow resource adaptor connection factory binding.
messaging/legacy-service.xml legacy-service.xml configures the JMSProviderLoader and JmsXA inflow resource adaptor connection factory binding.
messaging/messaging-jboss-beans.xml The messaging-jboss-beans.xml file configures JMS security and management beans.
messaging/messaging-service.xml The messaging-service.xml file configures the core JBoss Messaging service.
messaging/remoting-bisocket-service.xml The remoting-bisocket-service.xml configures the JMS remoting service layer.
jmx-console.war The jmx-console.war directory provides the JMX Console. The JMX Console provides a simple web interface for managing the MBean server.
jmx-invoker-service.xml jmx-invoker-service.xml is an MBean service archive that exposes a subset of the JMX MBeanServer interface methods as an RMI interface to enable remote access to the JMX core functionality.
jmx-remoting.sar jmx-remoting.sar is a javax.management.remote implementation providing access to the JMX server.
legacy-invokers-service.xml legacy-invokers-service.xml the legacy detached jmx invoker remoting services.
jsr-88-service.xml jsr-88-service.xml provides the JSR 88 remote deployment service.
mail-ra.rar mail-ra.rar is a resource adaptor that provides a JavaMail connector.
mail-service.xml The mail-service.xml file is an MBean service descriptor that provides JavaMail sessions for use inside the JBoss server.
monitoring-service.xml The monitoring-service.xml file configures alert monitors like the console listener and email listener used by JMX notifications.
profileservice-jboss-beans.xml profileservice-jboss-beans.xml description
properties-service.xml The properties-service.xml file is an MBean service descriptor that allows for customization of the JavaBeans PropertyEditors as well as the definition of system properties.
quartz-ra.rar quartz-ra.rar is a resource adaptor for inflow of Quartz events
remoting-jboss-beans.xml remoting-jboss-beans.xml contains the unified invokers based on JBoss Remoting.
scheduler-service.xml The scheduler-service.xml and schedule-manager-service.xml files are MBean service descriptors that provide a scheduling type of service.
security/security-jboss-beans.xml security-jboss-beans.xml security domain related beans.
security/security-policies-jboss-beans.xml security-policies-jboss-beans.xml security authorization related beans for ejb and web authorization.
sqlexception-service.xml The sqlexception-service.xml file is an MBean service descriptor for the handling of vendor specific SQLExceptions.
transaction-jboss-beans.xml transaction-jboss-beans.xml JTA transaction manager related beans.
transaction-service.xml transaction-service.xml ClientUserTransaction proxy service configuration.
uuid-key-generator.sar The uuid-key-generator.sar service provides a UUID-based key generation facility.

Move to JBOSS_DIST/jboss-as/bin directory and execute the run.bat (for Windows) or run.sh (for Linux) script, as appropriate for your operating system.

For more information including setting up multiple JBoss server instances on one machine and hosting multiple domains with JBoss, please refer to the Administration and Configuration Guide. Some examples on binding are shipped in <JBOSS_HOME>/docs/examples/binding-manager/sample-bindings.xml.

On starting your server, your screen output should look like the following (accounting for installation directory differences) and contain no error or exception messages:

[user@mypc bin]$ ./run.sh 

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/user/jboss-as-version/jboss-as

  JAVA: java

  JAVA_OPTS: -Dprogram.name=run.sh -server -Xms1503m -Xmx1503m -Dsun.rmi.dgc.client.
gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true

  CLASSPATH: /home/user/jboss-as-version/jboss-as/bin/run.jar


More options for the JBoss AS run script are discussed in Section 9.3.2, “Start the Server With Alternate Configuration” below.


Note that there is no "Server Started" message shown at the console when the server is started using the production profile, which is the default profile used when no other is specified. This message may be observed in the server.log file located in the server/production/log subdirectory.

You can configure the server to run as a service under Microsoft Windows, and configure it to start automatically if desired.

Download the JavaService package from http://forge.objectweb.org/projects/javaservice/.

Unzip the package and use the JBossInstall.bat file to install the JBoss service. You must set the JAVA_HOME and JBOSS_HOME environment variables to point to the jdk and jboss-as directories before running JBossInstall.bat. Run JBossInstall.bat with the following syntax:

JBossInstall.bat <depends> [-auto | -manual]

Where <depends> is the name of any service that the JBoss AS server depends on, such as the mysql database service.

Once the service is installed the server can be started by using the command net start JBoss, and stopped with the command net stop JBoss.

Please refer to the documentation included in the JavaService package for further information.

When the JBoss Server is running, you can get a live view of the server by going to the JMX console application at http://localhost:8080/jmx-console. You should see something similar to Figure 9.1, “View of the JMX Management Console Web Application”.

The JMX Console is the JBoss Management Console which provides a raw view of the JMX MBeans which make up the server. They can provide a lot of information about the running server and allow you to modify its configuration, start and stop components and so on.

For example, find the service=JNDIView link and click on it. This particular MBean provides a service to allow you to view the structure of the JNDI namespaces within the server. Now find the operation called list near the bottom of the MBean view page and click the invoke button. The operation returns a view of the current names bound into the JNDI tree, which is very useful when you start deploying your own applications and want to know why you can’t resolve a particular EJB name.

Look at some of the other MBeans and their listed operations; try changing some of the configuration attributes and see what happens. With a very few exceptions, none of the changes made through the console are persistent. The original configuration will be reloaded when you restart JBoss, so you can experiment freely without doing any permanent damage.

Now that we have examined the JBoss server, we will take a look at some of the main configuration files and what they are used for. All paths are relative to the server configuration directory (server/default, for example).

In JBoss log4j is used for logging. If you are not familiar with the log4j package and would like to use it in your applications, you can read more about it at the Jakarta web site (http://jakarta.apache.org/log4j/).

Logging is controlled from a central conf/jboss-log4j.xml file. This file defines a set of appenders specifying the log files, what categories of messages should go there, the message format and the level of filtering. By default, JBoss produces output to both the console and a log file (log/server.log).

There are 6 basic log levels used: TRACE, DEBUG, INFO, WARN, ERROR and FATAL. The logging threshold on the console is INFO, which means that you will see informational messages, warning messages and error messages on the console but not general debug messages. In contrast, there is no threshold set for the server.log file, so all generated logging messages will be logged there.

If things are going wrong and there doesn’t seem to be any useful information in the console, always check the server.log file to see if there are any debug messages which might help you to track down the problem. However, be aware that just because the logging threshold allows debug messages to be displayed, that doesn't mean that all of JBoss will produce detailed debug information for the log file. You will also have to boost the logging limits set for individual categories. Take the following category for example.

<!-- Limit JBoss categories to INFO --> 
<category name="org.jboss"> 
    <priority value="INFO"/> 

This limits the level of logging to INFO for all JBoss classes, apart from those which have more specific overrides provided. If you were to change this to DEBUG, it would produce much more detailed logging output.

As another example, let’s say you wanted to set the output from the container-managed persistence engine to DEBUG level and to redirect it to a separate file, cmp.log, in order to analyze the generated SQL commands. You would add the following code to the conf/jboss-log4j.xml file:

<appender name="CMP" class="org.jboss.logging.appender.RollingFileAppender"> 
    <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> 
    <param name="File" value="${jboss.server.home.dir}/log/cmp.log"/> 
    <param name="Append" value="false"/> 
    <param name="MaxFileSize" value="500KB"/> 
    <param name="MaxBackupIndex" value="1"/> 
    <layout class="org.apache.log4j.PatternLayout"> 
        <param name="ConversionPattern" value="%d %-5p [%c] %m%n"/> 
<category name="org.jboss.ejb.plugins.cmp"> 
    <priority value="DEBUG" /> 
    <appender-ref ref="CMP"/> 

This creates a new file appender and specifies that it should be used by the logger (or category) for the package org.jboss.ejb.plugins.cmp.

The file appender is set up to produce a new log file every day rather than producing a new one every time you restart the server or writing to a single file indefinitely. The current log file is cmp.log. Older files have the date they were written added to their filenames. Please note that the log directory also contains HTTP request logs which are produced by the web container.

The security domain information is stored in the file conf/login-config.xml as a list of named security domains, each of which specifies a number of JAAS [3] login modules which are used for authentication purposes in that domain. When you want to use security in an application, you specify the name of the domain you want to use in the application’s JBoss-specific deployment descriptors, jboss.xml (used in defining jboss specific configurations for an application) and/or jboss-web.xml (used in defining jboss for a Web application. We'll quickly look at how to do this to secure the JMX Console application which ships with JBoss.

Almost every aspect of the JBoss server can be controlled through the JMX Console, so it is important to make sure that, at the very least, the application is password protected. Otherwise, any remote user could completely control your server. To protect it, we will add a security domain to cover the application. This can be done in the jboss-web.xml file for the JMX Console, which can be found in deploy/jmx-console.war/WEB-INF/ directory. Uncomment the security-domain in that file, as shown below.


This links the security domain to the web application, but it doesn't tell the web application what security policy to enforce, what URLs are we trying to protect, and who is allowed to access them. To configure this, go to the web.xml file in the same directory and uncomment the security-constraint that is already there. This security constraint will require a valid user name and password for a user in the JBossAdmin group.

   A security constraint that restricts access to the HTML JMX console
   to users with the role JBossAdmin. Edit the roles to what you want and
   uncomment the WEB-INF/jboss-web.xml/security-domain element to enable
   secured access to the HTML JMX console.
            An example security config that only allows users with the
            role JBossAdmin to access the HTML JMX console web application

That's great, but where do the user names and passwords come from? They come from the jmx-console security domain we linked the application to. We have provided the configuration for this in the conf/login-config.xml.

<application-policy name="jmx-console">
        <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
            <module-option name="usersProperties">
            <module-option name="rolesProperties">

This configuration uses a simple file based security policy. The configuration files are found in the conf/props directory of your server configuration. The usernames and passwords are stored in the conf/props/jmx-console-users.properties file and take the form "username=password". To assign a user to the JBossAdmin group add "username=JBossAdmin" to the jmx-console-roles.properties file (additional roles on that username can be added comma separated). The existing file creates an admin user with the password admin. For security, please either remove the user or change the password to a stronger one.

JBoss will re-deploy the JMX Console whenever you update its web.xml. You can check the server console to verify that JBoss has seen your changes. If you have configured everything correctly and re-deployed the application, the next time you try to access the JMX Console, it will ask you for a name and password. [4]

The JMX Console isn't the only web based management interface to JBoss. There is also the Web Console. Although it's a Java applet, the corresponding web application can be secured in the same way as the JMX Console. The Web Console is in the file deploy/management/console-mgr.sar/web-console.war.. The only difference is that the Web Console is provided as a simple WAR file instead of using the exploded directory structure that the JMX Console did. The only real difference between the two is that editing the files inside the WAR file is a bit more cumbersome.

[3] The Java Authentication and Authorization Service. JBoss uses JAAS to provide pluggable authentication modules. You can use the ones that are provided or write your own if you have more specific requirements.

[4] Since the username and password are session variables in the web browser you may need to restart your browser to use the login dialog window.

We use a simple "TODO" application to show how JSF and EJB3 work together in a web application. The "TODO" application works like this: You can create a new 'todo' task item using the "Create" web form. Each 'todo' item has a 'title' and a 'description'. When you submit the form, the application saves your task to a relational database. Using the application, you can view all 'todo' items, edit/delete an existing 'todo' item and update the task in the database.

The sample application comprises the following components:

  • Entity objects - These objects represent the data model; the properties in the object are mapped to column values in relational database tables.

  • JSF web pages - The web interface used to capture input data and display result data. The data fields on these web pages are mapped to the data model via the JSF Expression Language (EL).

  • EJB3 Session Bean - This is where the functionality is implemented. We make use of a Stateless Session Bean.

In this section we will show you how the web interface is defined using JSF pages. We will also see how the data model is mapped to the web form using JSF EL. Using the #{...} notation to reference Java objects is called JSF EL (JSF Expression Language). Lets take a look at the pages used in our application:

EJB 3.0 is one of the major improvements introduced with Java EE 5.0. It aims at reducing the complexity of older versions of EJB and simplifies Enterprise Java development and deployment. You will notice that to declare a class as a 'Session Bean' you simply have to annotate it. Using annotations eliminates the complexity involved with too many deployment descriptors. Also the only interface an EJB3 Session Bean requires is a business interface that declares all the business methods that must be implemented by the bean.

We will explore the two important source files associated with the Bean implementation in our application: TodoDaoInt.java and TodoDao.java.

We will build the sample application using Ant and explore the configuration and packaging details. Please install Ant if currently not installed on your computer.

Let's look at building the example application and then explore the configuration files in detail.

In Chapter 11, Sample Applications, we looked at the directory structure of the jsfejb3 sample application. At the command line, go to the jsfejb3 directory. There you will see a build.xml file. This is our Ant build script for compiling and packaging the archives. To build the application, you need to first of all edit the build.xml file and edit the value of jboss-dist to reflect the location where the JBoss Application Server is installed. Once you have done this, just type the command ant and your output should look like this:

[user@localhost jsfejb3]$ ant
Buildfile: build.xml

    [mkdir] Created dir: /jboss/gettingstarted/jsfejb3/build/classes
    [javac] Compiling 4 source files to /home/user/Desktop/gettingstarted/jsfejb3/build/classes
    [javac] Note: /jboss/gettingstarted/jsfejb3/src/TodoDao.java uses unchecked or unsafe operations.
    [javac] Note: Recompile with -Xlint:unchecked for details.

    [mkdir] Created dir: /jboss/gettingstarted/jsfejb3/build/jars
      [war] Building war: /jboss/gettingstarted/jsfejb3/build/jars/app.war

      [jar] Building jar: /jboss/gettingstarted/jsfejb3/build/jars/app.jar

      [ear] Building ear: /jboss/gettingstarted/jsfejb3/build/jars/jsfejb3.ear


Total time: 3 seconds

If you get the BUILD SUCCESSFUL message, you will find a newly created build directory with 2 sub-directories in it:

  • classes: containing the compiled class files.

  • jars: containing three archives - app.jar, app.war and jsfejb3.ear.

    • app.jar : EJB code and descriptors.

    • app.war : web application which provides the front end to allow users to interact with the business components (the EJBs). The web source (HTML, images etc.) contained in the jsfejb3/view directory is added unmodified to this archive. The Ant task also adds the WEB-INF directory that contains the files which aren’t meant to be directly accessed by a web browser but are still part of the web application. These include the deployment descriptors (web.xml) and extra jars required by the web application.

    • jsfejb3.ear : The EAR file is the complete application, containing the EJB modules and the web module. It also contains an additional descriptor, application.xml. It is also possible to deploy EJBs and web application modules individually but the EAR provides a convenient single unit.

Now that we have built the application, lets take a closer look at some of the important Configuration files. We have built the final archive ready for deployment - jsfejb3.ear. The contents of your EAR file should look like this:

|+ app.jar   // contains the EJB code
    |+ import.sql
    |+ Todo.class
    |+ TodoDao.class
    |+ TodoDaoInt.class
    |+ META-INF
        |+ persistence.xml
|+ app.war   // contains web UI
    |+ index.html
    |+ index.xhtml
    |+ create.xhtml
    |+ edit.xhtml
    |+ todos.xhtml
    |+ TodoBean.class
    |+ style.css
    |+ META-INF
    |+ WEB-INF
       |+ faces-config.xml
       |+ navigation.xml
       |+ web.xml
|+ META-INF  // contains the descriptors
    |+ application.xml
    |+ jboss-app.xml

Deploying an application in JBoss is simple and easy. You just have to copy the EAR file to the deploy directory in the 'server configuration' directory of your choice. Here, we will deploy it to the 'default' configuration, so we copy the EAR file to the JBOSS_DIST/jboss-as/server/default/deploy directory.

You should see something close to the following output from the server:

15:32:23,997 INFO  [EARDeployer] Init J2EE application: file:/jboss/jboss-as-5.0.0<release>/server/default/deploy/jsfejb3.ear
15:32:24,212 INFO  [JmxKernelAbstraction] creating wrapper delegate for: org.jboss.ejb3.
15:32:24,213 INFO  [JmxKernelAbstraction] installing MBean: persistence.units:ear=
jsfejb3.ear,jar=app.jar,unitName=helloworld with dependencies:
15:32:24,213 INFO  [JmxKernelAbstraction]       jboss.jca:name=DefaultDS,service=
15:32:24,275 INFO  [PersistenceUnitDeployment] Starting persistence unit persistence.
15:32:24,392 INFO  [Ejb3Configuration] found EJB3 Entity bean: Todo
15:32:24,450 WARN  [Ejb3Configuration] Persistence provider caller does not implements 
the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null.
15:32:24,512 INFO  [Configuration] Reading mappings from resource : META-INF/orm.xml
15:32:24,512 INFO  [Ejb3Configuration] [PersistenceUnit: helloworld] no META-INF/orm.xml 
15:32:24,585 INFO  [AnnotationBinder] Binding entity from annotated class: Todo
15:32:24,586 INFO  [EntityBinder] Bind entity Todo on table Todo
15:32:26,311 INFO  [SchemaExport] Running hbm2ddl schema export
15:32:26,312 INFO  [SchemaExport] exporting generated schema to database
15:32:26,314 INFO  [SchemaExport] Executing import script: /import.sql
15:32:26,418 INFO  [SchemaExport] schema export complete
15:32:26,454 INFO  [NamingHelper] JNDI InitialContext properties:{java.naming.factory.
initial=org.jnp.interfaces.NamingContextFactory, java.naming.factory.url.pkgs=org.jboss.
15:32:26,484 INFO  [JmxKernelAbstraction] creating wrapper delegate for: org.jboss.ejb3.
15:32:26,485 INFO  [JmxKernelAbstraction] installing MBean: jboss.j2ee:ear=jsfejb3.ear,
jar=app.jar,name=TodoDao,service=EJB3 with dependencies:
15:32:26,513 INFO  [JmxKernelAbstraction]       persistence.units:ear=jsfejb3.ear,
15:32:26,557 INFO  [EJBContainer] STARTED EJB: TodoDao ejbName: TodoDao
15:32:26,596 INFO  [EJB3Deployer] Deployed: file:/jboss/jboss-as-5.0.0<release>
15:32:26,625 INFO  [TomcatDeployer] deploy, ctxPath=/jsfejb3, warUrl=.../tmp/deploy/
15:32:26,914 INFO  [EARDeployer] Started J2EE application: file:/jboss/jboss-as-5.0.0<release>/server/default/deploy/jsfejb3.ear

If there are any errors or exceptions, make a note of the error message. Check that the EAR is complete and inspect the WAR file and the EJB jar files to make sure they contain all the necessary components (classes, descriptors etc.).

You can safely redeploy the application if it is already deployed. To undeploy it you just have to remove the archive from the deploy directory. There’s no need to restart the server in either case. If everything seems to have gone OK, then point your browser at the application URL.


You will be forwarded to the application main page. Figure 12.5, “Sample TODO” shows the sample application in action.

JBoss Seam is a framework that provides the glue between the new EJB3 and JSF frameworks that are part of the Java EE 5.0 standard. In fact, the name Seam refers to the seamless manner in which it enables developers to use these two frameworks in an integrated manner. Seam automates many of the common tasks, and makes extensive use of annotations to reduce the amount of xml code that needs to be written. The overall effect is to significantly reduce the total amount of coding that needs to be done.

If you are new to Seam, you can find more introductory information from the following url and book:

We have included two versions of the example application, one coded using EJB3 / JSF without using Seam, and one using Seam, to demonstrate clearly the difference in application development using the Seam framework.

Let's start off our examination of the Seam implementation in the same way, by examining how the Data Model is implemented. This is done in the Todo.java file.

public class Todo implements Serializable {

  private long id;
  private String title;
  private String description;

  public Todo () {
    title ="";
    description ="";

  @Id @GeneratedValue
  public long getId() { return id;}
  public void setId(long id) { this.id = id; }

  public String getTitle() { return title; }
  public void setTitle(String title) {this.title = title;}

  public String getDescription() { return description; }
  public void setDescription(String description) {
    this.description = description;


The @Entity annotation defines the class as an EJB3 entity bean, and tells the container to map the Todo class to a relational database table. Each property of the class will become a column in the table. Each instance of the class will become a row in this table. Since we have not used the @Table annotation, Seam's "configuration by exception" default will name the table after the class.

@Entity and @Table are both EJB3 annotations, and are not specific to Seam. It is possible to use Seam completely with POJOs (Plain Old Java Objects) without any EJB3-specific annotations. However, EJB3 brings a lot of advantages to the table, including container managed security, message-driven components, transaction and component level persistence context, and @PersistenceContext injection, which we will encounter a little further on.

The @Name annotation is specific to Seam, and defines the string name for Seam to use to register the Entity Bean. This will be the default name for the relational database table. Each component in a Seam application must have a unique name. In the other components in the Seam framework, such as JSF web pages and session beans, you can reference the managed Todo bean using this name. If no instance of this class exists when it is referenced from another component, then Seam will instantiate one.

The @Id annotation defines a primary key id field for the component. @GeneratedValue specifies that the server will automatically generate this value for the component when it is saved to the database.

Seam provides support for model-based constraints defined using Hibernate Validator, although Hibernate does not have to be the object persister used. The @NotNull annotation is a validation constraint that requires this property to have a value before the component can be persisted into the database. Using this annotation allows the validation to be enforced by the JSF code at the view level, without having to specify the exact validation constraint in the JSF code.

At this point the only apparent difference between the Seam version and the EJB3/JSF version of the app is the inclusion of the validator annotation @NotNull, and the @Name annotation. However, while the EJB3/JSF version of this application requires a further TodoBean class to be manually coded and managed in order to handle the interaction between the Todo class and the web interface, when using Seam the Seam framework takes care of this work for us. We'll see how this is done in practice as we examine the implementation of the user interface.

The index.xhtml file used is the same as in the EJB3/JSF example.

create.xhtml begins to reveal the difference that coding using the Seam framework makes.

<h:form id="create">

<f:facet name="beforeInvalidField">
  <h:graphicImage styleClass="errorImg" value="error.png"/>
<f:facet name="afterInvalidField">
  <s:message styleClass="errorMsg" />
<f:facet name="aroundInvalidField">
  <s:div styleClass="error"/>



        <h:inputText id="title" value="#{todo.title}" size="15"/>

        <h:inputTextarea id="description" value="#{todo.description}"/>



<h:commandButton type="submit" id="create" value="Create"

The first thing that is different here is the Java Server Facelet code at the beginning, which works with the @NotNull validation constraint of our todo class to enforce and indicate invalid input to the user.

Also notice here that rather than requiring the use of a TodoBean class as we did in the EJB3/JSF example we back the form directly with a Todo entity bean. When this page is called, JSF asks Seam to resolve the variable todo due to JSF EL references such as #{todo.title}. Since there is no value already bound to that variable name, Seam will instantiate an entity bean of the todo class and return it to JSF, after storing it in the Seam context. The Seam context replaces the need for an intermediary bean.

The form input values are validated against the Hibernate Validator constraints specified in the todo class. JSF will redisplay the page if the constraints are violated, or it will bind the form input values to the Todo entity bean.

Entity beans shouldn't do database access or transaction management, so we can't use the Todo entity bean as a JSF action listener. Instead, creation of a new todo item in the database is accomplished by calling the persist method of a TodoDao session bean. When JSF requests Seam to resolve the variable todoDao through the JSF EL expression #{todoDao.persist}, Seam will either instantiate an object if one does not already exist, or else pass the existing stateful todoDao object from the Seam context. Seam will intercept the persist method call and inject the todo entity from the session context.

Let's have a look at the TodoDao class (defined in TodoDao.java) to see how this injection capability is implemented.

Let's go through a listing of the code for the TodoDao class.

public class TodoDao implements TodoDaoInt {

  @In (required=false) @Out (required=false)
  private Todo todo;

  @PersistenceContext (type=EXTENDED)
  private EntityManager em;

  // Injected from pages.xml
  Long id;
  public String persist () {
    em.persist (todo);
    return "persisted";

  private List <Todo> todos;

  public void findTodos () {
    todos = em.createQuery("select t from Todo t")

  public void setId (Long id) {
    this.id = id;
    if (id != null) {
      todo = (Todo) em.find(Todo.class, id);
    } else {
      todo = new Todo ();
  public Long getId () {
    return id;

  public String delete () {
    em.remove( todo );
    return "removed";

  public String update () {
    return "updated";

  @Remove @Destroy
  public void destroy() {}


First of all notice that this is a stateful session bean. Seam can use both stateful and stateless session beans, the two most common types of EJB3 beans.

The @In and @Out annotations define an attribute that is injected by Seam. The attribute is injected to this object or from this object to another via a Seam context variable named todo, a reference to the Seam registered name of our Todo class defined in Todo.java.

The @PersistenceContext annotation injects the EJB3 Entity manager, allowing this object to persist objects to the database. Because this is a stateful session bean and the PersistenceContext type is set to EXTENDED, the same Entity Manager instance is used until the Remove method of the session bean is called. The database to be used (a persistence-unit) is defined in the file resources/META-INF/persistence.xml

Note that this session bean has simultaneous access to context associated with web request (the form values of the todo object), and state held in transactional resources (the EntityManager). This is a break from traditional J2EE architectures, but Seam does not force you to work this way. You can use more traditional forms of application layering if you wish.

The @DataModel annotation initializes the todos property, which will be outjected or "exposed" to the view. The @Factory annotated method performs the work of generating the todos list, and is called by Seam if it attempts to access the exposed DataModel property and finds it to be null. Notice the absence of property access methods for the todos property. Seam takes care of this for you automatically.

Let's take a look at the JSF code that we use for displaying and editing the list of todos, to get an idea of how to use these interfaces in practice.

Using the DataModel exposed property of the Session Bean it becomes trivial to produce a list of todos:


<h:dataTable value="#{todos}" var="todo">
    <f:facet name="header">Title</f:facet>
    <f:facet name="header">Description</f:facet>
    <a href="edit.seam?tid=#{todo.id}">Edit</a>

  <h:commandButton action="create"
            value="Create New Todo" type="submit"/>


When the JSF variable resolver encounters {#todos} and requests todos, Seam finds that there is no "todos" component in the current scope, so it calls the @Factory("todos") method to make one. The todos object is then outjected once the factory method is done since it is annotated with the @DataModel annotation.

Constructing the view for the edit page is similarly straight forward:

<h:form id="edit">
<f:facet name="beforeInvalidField">
  <h:graphicImage styleClass="errorImg" value="error.png"/>
<f:facet name="afterInvalidField">
  <s:message styleClass="errorMsg" />
<f:facet name="aroundInvalidField">
  <s:div styleClass="error"/>



        <h:inputText id="title" value="#{todo.title}" size="15"/>

        <h:inputTextarea id="description" value="#{todo.description}"/>



<h:commandButton type="submit" id="update" value="Update"

<h:commandButton type="submit" id="delete" value="Delete"

Here we see the same factors in play. JSF validation code taking advantage of the validation constraints defined in our Entity Bean, and the use of the todoDao Session Bean's update and delete methods to update the database.

The call from todos.xhtml: edit.seam?tid=#{todo.id} causes Seam to create a todoDao and set it's id property to tid. Setting its id property causes the todoDao to retrieve the appropriate record from the database.

The functionality that allows the edit page to be called with a parameter in this way is implemented through pages.xml. Let's have a look at the pages.xml file and how it is used by Seam applications.

In the previous chapters, we’ve been using the JBossAS default datasource in our applications. This datasource is configured to use the embedded Hypersonic database instance shipped by default with the distribution. This datasource is bound to the JNDI name java:/DefaultDS and its descriptor is named hsqldb-ds.xml under the deploy directory

Having a database included with JBossAS is very convenient for running the server and examples out-of-the-box. However, this database is not a production quality database and as such should not be used with enterprise-class deployments. As a consequence of this JBoss Support does not provide any official support for Hypersonic.

In this chapter we will explain in details how to configure and deploy a datasource to connect JBossAS to the most popular database servers available on the market today.

Datasource configuration file names end with the suffix -ds.xml so that they will be recognized correctly by the JCA deployer. The docs/example/jca directory contains sample files for a wide selection of databases and it is a good idea to use one of these as a starting point. For a full description of the configuration format, the best place to look is the DTD file docs/dtd/jboss-ds_1_5.dtd. Additional documentation on the files and the JBoss JCA implementation can also be found in the JBoss Application Server Guide available at http://labs.jboss.com/projects/docs/.

Local transaction datasources are configured using the local-tx-datasource element and XA-compliant ones using xa-tx-datasource. The example file generic-ds.xml shows how to use both types and also some of the other elements that are available for things like connection pool configuration. Examples of both local and XA configurations are available for Oracle, DB2 and Informix.

If you look at the example files firebird-ds.xml, facets-ds.xml and sap3-ds.xml, you’ll notice that they have a completely different format, with the root element being connection-factories rather than datasources. These use an alternative, more generic JCA configuration syntax used with a pre-packaged JCA resource adapter. The syntax is not specific to datasource configuration and is used, for example, in the jms-ds.xml file to configure the JMS resource adapter.

We would also highly recommend consulting the JCA wiki pages at http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossJCA

Next, we’ll work through some step-by-step examples to illustrate what’s involved setting up a datasource for a specific database.

The MySQL® database has become the world's most popular open source database thanks to its consistent fast performance, high reliability and ease of use. This database server is used in millions of installations ranging from large corporations to specialized embedded applications across every continent of the world. . In this section, we'll be using the community version of their database server (GA 5.0.45) and the latest JDBC driver (GA 5.1.5) both available at http://www.mysql.com.

Oracle is one of the main players in the commercial database field and most readers will probably have come across it at some point. You can download it freely for non-commercial purposes from http://www.oracle.com/technology/products/database/xe/index.html

In this section, we'll connect the server to Oracle Database 10g Express Edition using the latest JDBC driver (11g) available at http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/index.html

In this section, we'll connect the server to MS SQL Server 2000 using the latest JDBC driver (v1.2) available at http://msdn2.microsoft.com/en-us/data/aa937724.aspx.

Developers wanting to get familiar with software development and implementation in JBoss Application Server can read: JBoss: A Developer's Notebook. (O'Reilly, 2005. Norman Richards, Sam Griffith).

For more comprehensive JBoss documentation covering advanced JBoss topics, refer to the manuals available online at http://www.jboss.org/jbossas/docs.

For general EJB instruction, with thorough JBoss coverage, see Enterprise JavaBeans, 4th Edition. (O'Reilly, 2004. Richard Monson-Haeful, Bill Burke, Sacha Labourey)

To learn more about Hibernate, see Java Persistence With Hibernate. (Manning, 2007. Christian Bauer, Gavin King)

For complete coverage of the JBoss Seam framework, we recommend JBoss Seam: Simplicity And Power Beyond Java EE. (Prentice Hall, 2007. Michael Yuan, Thomas Heute).