Java continues to be the most widely-used single-programming language today, edged out only by all scripting languages grouped together. Java remains also the language and/or platform of choice for Enterprise and Web application development, especially large-scale application development.
Nevertheless the Java language has changed a lot since its first appearance and will possibly continue to change in the future. Oracle, who has acquired Sun, the home of the Java language, has stated that its high-level Java strategy is to enhance and extend the reach of Java to new and emerging software development paradigms: simplify, optimize, and integrate the Java platform into new deployment architectures; and invest in the Java developer community allowing for increased participation.
At this point, one question arises: are application servers ready to meet these new paradigms? Originally designed as web containers for supporting web applications and, later, as EJB containers for remotely accessible services, application servers have expanded considerably from their simple origins. Today, most application servers provide a comprehensive service layer, which delivers support for distributed transactions, clustering, security, and so on.
In addition, a large number of open source building blocks have been added to the application server and they are heavily used in today's products. However, integrating all these libraries does not come without a price because each library has, in turn, evolved with complexity, following its own unsynchronized evolution path and requiring more and more additional libraries to work.
As most IT experts agree, the challenge for today's application server is to combine a rich set of features requested by the customers along with a lightweight and flexible container configuration.
The 7.0 release of JBoss AS is designed around a brand new kernel, which is now based on two main projects:
Modular Service Container (MSC): This one provides a way to install, uninstall, and manage services used by a container. MSC further enables resources injection into services and dependency management between services.
The following picture depicts the basic architecture of the new application server kernel:
Understanding the details of the new modular kernel may be a little invasive at the beginning of the book, however, we will smoothly introduce some useful concepts within this chapter, just to make sure you get acquainted with the server configuration basics.
For the time being, let's just start installing the core server components and their required dependencies.
The first step in learning about the application server will be installing all the necessary stuff on your machine in order to run it. The application server itself requires just a Java Virtual Machine environment installed.
As far as the hardware requirements are concerned, you should be aware that the server distribution, at the time of writing, requires about 75MB of hard-disk space and allocates a minimum of 64MB and a maximum of 512MB for a standalone server.
In order to get started, this is our checklist:
Install the Java Development Kit where JBoss AS 7 will run.
Install JBoss AS 7.0.
Install Eclipse development environment.
At the end of this chapter, you will have all the instruments to get started with the application server.
At the time of writing, the J2SE 1.7 has been finally released and it's available for download. Although, there are no known issues with this Java release, there are still a few users who have tested it intensively with the new application server.
So, let's move on the Oracle download page, which now hosts all JDK downloads: http://www.oracle.com/technetwork/java/javase/downloads/index.html
Choose to download the latest JDK/JRE which is, at the time of writing, the JDK 1.6 Update 26.
The download will take a few minutes depending how fast your network is. Once the download is complete, run the executable file to start the installation. (The actual name of the installer varies, also if you are on a 32-bit system or 64-bit. However, the steps will be the same, just the name will change).
jdk-6u26-windows-i586.exe # Windows sh jdk-6u26-linux-i586.bin # Linux
If you are installing on a Linux/Unix box, you can safely accept all the defaults given to you by the setup wizard. The Windows users should stay away from the installation paths that include empty spaces, such as
C:\Program Files, as this leads to some issues when you are referencing the core libraries. An installation path such as
C:\Software\Java or simply
C:\Java is a better alternative.
When the installation is complete, we need to update a couple of settings on the computer so it can interact with Java. The most important setting is
JAVA_HOME, which is directly referenced by JBoss startup script.
If you are running Windows XP-2000, follow these steps:
Right-click on My Computer and select Properties from the context menu.
On the Advanced tab, click on the Environment Variables button.
Then, in the System Variables box, click on New.
Name the new variable as
JAVA_HOME, and give a value of the path to your JDK installation; I would recommend something like:
Because of increased security in Windows Vista, standard users must have User Account Control (UAC) turned on to change the environment variables, and the change must be completed via user accounts. In the User Accounts window, under Tasks, select Change my environment variables. Use the New, Edit or Delete buttons to amend environment variables
Now it's time to modify the system's
PATHvariable. Double-click on the
PATHsystem variable. In the box that pops up, navigate to the end of the Variable Value line, add a semicolon to the end, and then add the path to your JDK. This will be something like
Unix/Linux users can add the following commands in the user's profile scripts:
export JAVA_HOME=/installDir/jdk1.6.0_26 export PATH=$JAVA_HOME/bin:$PATH
JBoss application server can be freely downloaded from the community site: http://www.jboss.org/jbossas/downloads/.
As you can see from the above picture, as I'm writing this book, you can choose between the 7.0.2 final release (Arc) and the newer 7.1.0 Beta. If you plan to use JBoss AS 7 in production, we suggest you using the former stable release which provides all the functionalities contained in this book except for one mentioned in Chapter 4 ("Adding a Remote EJB client").
The 7.0.2 release is available in the Web profile certified distribution and in the full distribution, which contains all the available server modules.
On the other hand, if you are on a learning path to the new server, just proceed to the new 7.1.0 Beta release, which is available in the single EE6 server release."
Choose to download the full server distribution. You will be then warned that this download is part of a community release and, as such, it is not yet fully supported. As said before, RedHat maintains the Enterprise releases of JBoss middleware and, hopefully, the AS 7 will be soon part of it.
JBoss AS 7 does not come with an installer; it is simply a matter of extracting the compressed archive.
Windows users can simply use any uncompress utility, such as WinZip, or WinRAR taking care to choose a folder, which doesn't contain empty spaces. Unix /Linux should use the
unzip shell command to explode the archive:
Unix/Linux users should be aware that JBoss AS does not require root privileges as none of the default ports used by JBoss are below the privileged port range of 1024. To reduce the risk of users gaining root privileges through the JBoss AS, install and run JBoss as a non-root user.
After you have installed JBoss, 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, move to the
bin directory of your
and issue the following command:
standalone.bat # Windows users $ standalone.sh # Linux/Unix users
Here's a sample JBoss AS 7 startup console:
The above command starts up a JBoss standalone instance that's equivalent of starting the application server with the
run.bat/run.sh script used by earlier AS releases. You will notice how amazingly fast is starting the new release of the application server; this is due to the new modular architecture, which only starts up necessary parts of the application server container needed by loaded applications.
If you need to customize the startup properties of your application server, then you need to open the
standalone.conf.bat for the Windows users) where the memory requirements of JBoss are declared. Here's the Linux core section of it:
if [ "x$JAVA_OPTS" = "x" ]; then JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 - Dsun.rmi.dgc.server.gcInterval=3600000" fi
So, by default, the application server starts with a minimum memory requirement of 64MB of heap space and a maximum of 512MB. This will be just enough to get started, however, if you need to run a core Java EE application on it, you will likely require at least 1GB of heap space or 2GB or more depending on your application type. Generally speaking, 32-bit machines cannot execute a process whose space exceeds 2GB, however on 64 bit machines, there's essentially no limit to process size.
You can verify that the server is reachable from the network by simply pointing your browser to the application server's welcome page, which is reachable by default at the well-known address:
If you have been using previous releases of the application server you might have heard about the twiddle command-line utility that queried the MBeans installed on the application server. This utility has been replaced by a more sophisticated interface named the Command Line Interface (CLI), which can be found in the
Just launch the
jboss-admin.bat script (or
jboss-admin.sh for Linux users) and you will be able to manage the application server via a shell interface.
We have just started an interactive shell session which is also able to use the command-line completion (by pressing the Tab key) to match partly-typed command names. No more searches for finding the exact syntax of commands!
The command-line interface is discussed in depth in Chapter 7, Managing the Application Server, which is all about the server-management interfaces; We will, however, have an initial taste of its basic functionalities in the following sections to get you accustomed to this powerful tool.
Probably the easiest way to stop JBoss is by sending an interrupt signal with Ctrl+C.
However, if your JBoss process was launched in the background or rather is running on another machine (see next), then you can use the CLI interface to issue an immediate shutdown command:
[disconnected /] connect Connected to localhost:9999 [localhost:9999 /] :shutdown
There is actually one more option to shutdown the application server, which is pretty useful if you need to shut down the server from within a script. This option consists of passing the
--connect option to the admin shell, thereby switching off the interactive mode:
jboss-admin.bat --connect command=:shutdown # Windows jboss-admin.sh --connect command=:shutdown # Unix / Linux
Shutting down the application server, which is running on a remote machine, is just a matter of connecting and providing the server's remote address to the CLI:
[disconnected /] connect 192.168.1.10 Connected to 192.168.1.10:9999 [192.168.1.10:9999 /] :shutdown
When issued on the root node path of the AS server, it is able to reload the services configuration:
[disconnected /] connect Connected to localhost:9999 [localhost:9999 /] :reload
Although the main focus of this book is the administration of the application server, we are also concerned with the application packaging and deploying. For this reason, we will sometimes add examples that require a development environment to be executed.
The development environment used in this book is Eclipse known by Java developers worldwide and contains a huge set of plugins to expand its functionalities. Besides this, Eclipse is the first IDE that is compatible with the new application server.
So, let's move to the downloading page of Eclipse which is located at: http://www.eclipse.org.
From there, download the latest Enterprise Edition (at the time of this writing, it's version 3.7 and is also known as Indigo). The compressed package contains all the Java EE plugins already installed and requires about 210MB of disk space:
Once you have unzipped the previously downloaded file, you will see a folder named
eclipse. In that folder, you will find the eclipse application (a big blue dot). We recommend you create a shortcut on the desktop to simplify the launching of Eclipse. Note that just like JBoss AS, Eclipse does not have an installation process. Once you have unzipped the file, you are done!
The next step will be installing the JBoss AS plugin, which is a part of the suite of plugins named JBoss tools. Installing new plugins in Eclipse is pretty simple; just follow these steps:
From the menu, choose Help | Install New Software.
Then, click on the Add button where you will enter the JBoss tools' download URL (along with a description): http://download.jboss.org/jbosstools/updates/development/indigo/.
As you can see from the previous screenshot, you need to check the JBossAS Tools plugin and move forward to the next options where you will complete the installation process. Once done, restart when prompted.
Now, you should be able to see the JBoss AS 7 enlisted as a server by choosing New | Server from the upper menu and expanding the JBoss Community option:
Completing the server installation into the Eclipse is quite straightforward as it just requires pointing to the folder where your server distribution, hence we will leave this to the reader as a practical exercise.
Once done with the installation of all the necessary tools, we will concentrate on the new application server structure. The first thing you'll notice when you browse through the application server folders is that its file system is basically divided into two core parts: the dichotomy reflects the distinction between standalone servers and domain servers.
The concept of the domain server is not new in the market of application servers, however, it is introduced for the first time in JBoss AS as a way to manage and coordinate a set of instances of the application server. An application server node which is not configured as part of a domain is qualified as standalone server and it resembles in practice to a single instances of the application server you used in earlier releases.
We will discuss the concept of domains in detail in Chapter 5, Configuring a JBoss AS Domain, of this book; for the time being, we will explore the different file system structures for both kinds of servers.
From a bird's eye perspective, we can see the one that the main file system is split in two: one section which is pertinent to domain servers and another which is relative to standalone servers. The following screenshot depicts the new tree of the application server:
In the next section, we will enter into the single folders of the new AS infrastructure, dissecting their content and what they are used for in the application server.
This is where you start your application server instances. You can start a standalone server by launching the
standalone.sh for Linux users). In addition to the startup scripts, you can find the
standalone.bat, which can be used to customize JBoss' bootstrap processIf you are going to use a domain of servers, you will use the
domain.bat script (
domain.sh for Linux users). This shell script starts up a set of application server instances as specified by the domain configuration file.
In addition, this folder contains the web services utility scripts (
wsprovide.sh) used to generate the web services definition language and the corresponding Java interfaces.
In spite of its name, this folder does not contain the server documentation, but two subfolders: the first one named
licenses barely contains the licenses information for the application server and its dependencies. You might use the
licenses.xml file as quick reference for finding out which are the version shipped with the default application server modules or dependencies. For example, JBoss AS 7 ships with the release 4.0.0.CR2 of Hibernate core libraries.
<dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-core</artifactId> <version>4.0.0.CR2</version> <licenses> <license> <name>GNU Lesser General Public License</name> <url>http://www.gnu.org/licenses/lgpl-2.1.html</url> <distribution>repo</distribution> <comments>See discussion at http://hibernate.org/license for more details.</comments> </license> </licenses> </dependency>
The other subfolder named
schema contains the .xsd files which are used by the configuration as schema.
The next folder is the domain folder, which contains the domain structure, split across a set of folders:
configuration folder contains as you might imagine the configuration files. The main configuration file is
domain.xml which contains all services which are used by the nodes of the domain. It also configures the socket-binding interfaces for all services.
Along with it, the other key file is
host.xml which is used to define the management aspects of the domain.
The last file contained in the configuration folder is
logging.properties which are used to define the logging format of the bootstrap process.
lib folder hosts the sub-folder
ext, which is there to support Java SE/EE style "extensions". Some of the application server deployers are able to scan this folder for additional libraries which are picked up by the local class loader; nevertheless this approach is not recommended and maintained only for compliance with the language specifications. The
modules folder should be the one and only path for your libraries.
log folder contains as you might imagine the logging output of the domain. The file, by default, is truncated every time the server is rebooted.
The servers folder holds a set of sub-folders for each server defined in the configuration file. The most useful directory contained beneath each server is the
log folder which is the location where single instances emit their log. The
data folder is used by the application server to store its runtime data, such as the transaction logging The
tmp folder is a temporary location for some resource artifacts which is not a big issue for any of you.
If you are running the application server in standalone mode, this is the part of the AS file system you will be interested in. Its structure is quite similar to the domain folder with the notable exception of a deployment folder. Let's proceed with order. Just below the domain folder, you will find the following set of subdirectories.
The configuration folder contains also the application server configuration files. As a matter of fact the application server ships with a set of different configuration files, each one using a different set of functionalities. Launching the standalone start-up script, by default, the
standalone.xml configuration file will be used.
standalone.xml, this folder contains the
logging.properties file, which is also about the logging of bootstrap process. The other file you will find within it,
mgmt-users.properties, can be used to secure the management interfaces. The security is discussed in detail in Chapter 10, Securing JBoss AS, of this book.
deployments folder is the location in which users can place their deployment content (for example, WAR, EAR, JAR, SAR files) to have it automatically deployed into the server runtime. Users, particularly those running production systems, are encouraged to use the JBoss AS management APIs to upload and deploy deployment content instead of relying on the deployment scanner subsystem that periodically scans this directory. See Chapter 6, Deploying Applications on JBoss AS 7, for more details.
This directory contains the default page which is loaded when you surf on the home of your application server (
http://localhost:8080). In terms of web server configuration, this is the Web root context
modules folder, you will find the application server's set of libraries, which are a part of the server distribution.
Historically, JBoss AS releases used to manage their set of libraries in different ways. Lets recap to make some order. Earlier, Release 4.x was used to define the core server libraries into the
JBOSS_HOME/server libraries. Thereafter, each server definition had its specific library into the
This approach was pretty simple this way; however, it led to a useless proliferation of libraries which were replicated in the
default/all server distribution.
The release 5.x and 6.x had the concept of the
common/lib folder which was the main repository for all modules that were common to all server definitions. Each server distribution still contained a
server/<servername>/lib path for the libraries that were specific to that server definition. Unchanged from the earlier release was the repository for core server modules comprised by
JBoss AS 7 follows a real modular approach deprecating all earlier approaches. The server bootstrap libraries are now located at the root of the application server. There you can find the
jboss-modules.jar archive, which is all you need to bootstrap the new application server kernel, based on the JBoss modules.
The application server modules are now defined beneath the
modules folder, grouped in a set of subfolders each one dedicated to a set of resources. At first sight, this approach might seem less intuitive than previous releases; however, once accustomed to it, you will find it much easier to handle module installation/updates.
The following table resumes the diverse approaches used across different server releases:
5.x â 6.x
Listing all the modules will take up too much space; however, the module repository layout is pretty much the same as the module name. For example, the
org.jboss.as.ejb3 module will be found in
org/jboss/as/ejb3 subfolder of the
modules folder. In the last section of this chapter, we will see how modules are actually loaded by the application server.
Learning more about JBoss module is essential if you want to understand the next chapters that discuss about the server configuration. Basically, each module is a pluggable unit. As depicted by the following picture. JBoss modules can load libraries using two approaches:
Using a static file system
Using direct JAR execution
Using a static file system approach is the simplest way to load a module, and it's used as a default when starting up the application server. It is based on the assumption that the filesystem reflects the name and version of modules used. All you need to provide to the environment is the location where modules are stored. So, for example, you could start a standalone instance of JBoss AS 7 using the following command:
java -jar jboss-modules.jar -mp "%JBOSS_HOME%\modules" org.jboss.as.standalone
The argument module path (
-mp) actually points to the root directory (or directories), which will be searched by the default module loader for module definitions. A module is defined using a simple XML descriptor, like this:
<module xmlns="urn:jboss:module:1.0" name="org.jboss.msc"> <main-class name="org.jboss.msc.Version"/> <resources> <resource-root path="jboss-msc-1.0.0.Beta8.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="org.jboss.logging"/> <module name="org.jboss.modules"/> </dependencies> </module>
Basically, a module definition contains two main elements: the resources
defined in the module (and their path) and the module dependencies
. The previous example is the module definition for the JBoss MSC module which is contained in the
jboss-msc-1.0.0.Beta8.jar file and bears a dependency on
javax.api, org.jboss.logging and
A module which is defined with a
main-class element is said to be executable. In other words, the module name can be listed on the command line, and the standard static
main(String) method in the named module's
main-class will be loaded and executed.
When the module is executed as a JAR file you just need to provide the name of your application module, which is packed in JAR file, and it will be picked up by JBoss modules:
java -jar jboss-modules.jar -jar your-app.jar
Then, in your
application.jar, you might specify a set of module definitions, much the same way you did for flat filesystem modules. These definitions are contained in the
Main-Class: mypackage/MyClass Dependencies: org.jboss.logging
In this chapter, we introduced the new application server, its new features, and the reasons which are behind these changes.
The release 7.0 of the JBoss application server provides the foundation for a new generation of application server, which will deliver the truly modular services.
The outcome of this is a lighter platform based on a tiny modular kernel that is able to load and extend its components from the filesystem and activate them just when they are required by the user.
The physical structure of the application server has been modified to reflect the dichotomy between standalone servers and domain servers, the former being basically a single node instance and the latter a set of managed resources controlled by a Domain Controller and a Host Controller.
In the next chapter we will enter into the details of the application server configuration, focusing our attention on the standalone server configuration file, which holds both core application server configuration and the stack of Enterprise services running on top of it.