JBoss AS 7 Configuration, Deployment and Administration

5 (1 reviews total)
By Francesco Marchioni
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Installing JBoss AS 7

About this book

As the Java EE standard has evolved and matured, the API has become increasingly rich and complex. The next generation of application servers needs to be modular and configurable to run only specific services or containers. JBoss AS 7 promises to meet those requirements but the configuration of a complex application server is composed of a mix of administrative and management tasks which often overlap, generating confusion.

JBoss AS 7 Configuration, Deployment and Administration will give you an expert's understanding of every component that makes up the JBoss application server, and will show you how to use them, helping you to dramatically cut down the learning curve for this exciting product.

This book will guide you through configuration, management, deployment and advanced administration in a logical order to avoid the common pitfalls of setting up a new AS. The book dives into the new application server structure and shows you how to install it. You will learn how to configure the core AS services, including thread pools, the messaging system, and the transaction service. Finally, you will learn how to deploy and manage your applications and then tune the performance of your AS to achieve an efficient, indispensible application server.

Publication date:
December 2011
Publisher
Packt
Pages
380
ISBN
9781849516785

 

Chapter 1. Installing JBoss AS 7

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:

  • JBoss Modules: This handles class loading of resources in the container. You can think about JBoss Modules as a thin bootstrap wrapper for executing an application in a modular environment.

  • 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.

 

Getting started with the application server


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:

  1. Install the Java Development Kit where JBoss AS 7 will run.

  2. Install JBoss AS 7.0.

  3. Install Eclipse development environment.

At the end of this chapter, you will have all the instruments to get started with the application server.

Installing the Java environment

JBoss AS is a full Java application server and hence it requires a Virtual Machine for the Java Platform to run on.

Note

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.

For this reason, at the moment, we suggest you start with J2SE 1.6 and consider moving to the new Java platform in the near future.

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:

  1. Right-click on My Computer and select Properties from the context menu.

  2. On the Advanced tab, click on the Environment Variables button.

  3. Then, in the System Variables box, click on New.

  4. Name the new variable as JAVA_HOME, and give a value of the path to your JDK installation; I would recommend something like: C:\Java\jdk1.6.0_26.

    Tip

    Windows Vista tip

    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

  5. Now it's time to modify the system's PATH variable. Double-click on the PATH system 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 %JAVA_HOME%\bin.

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

Installing JBoss AS 7

JBoss application server can be freely downloaded from the community site: http://www.jboss.org/jbossas/downloads/.

Note

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.

Note

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:

unzip jboss-as-7.0.2.Final.zip

Tip

Security warning

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.

Starting up JBoss AS

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 JBOSS_HOME directory 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 (or 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: http://localhost:8080.

Connecting to the server with the command line interface

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 JBOSS_HOME/bin folder.

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!

Note

In the previous screenshot, we have just connected to the server using the connect command, which by default uses the loopback server address and plugs into the port 9999.

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.

Stopping JBoss

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

Locating the shutdown script

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

Stopping JBoss on a remote machine

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

Note

Since JBoss AS 7.1.0 Beta1 accessing remotely the CLI requires authentication. Check out Chapter 10 for more information about it.

Restarting JBoss

The command-line Interface contains a lot of useful commands. One of the most interesting options is the ability to reload all or parts of the AS configuration using the reload command.

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

Installing Eclipse environment

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!

Installing JBoss tools

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:

  1. From the menu, choose Help | Install New Software.

  2. 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.

 

Exploring the application server file system


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.

The bin folder

This is where you start your application server instances. You can start a standalone server by launching the standalone.bat (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.

The bin folder also includes another useful script command, named jboss-admin.bat (jboss-admin.sh for Linux users), which starts the new interactive command-line interface.

In addition, this folder contains the web services utility scripts (wsconsume.sh and wsprovide.sh) used to generate the web services definition language and the corresponding Java interfaces.

The docs folder

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 domain folder

The next folder is the domain folder, which contains the domain structure, split across a set of folders:

The 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.

The content folder is used as a repository to store deployed modules.

The 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.

The 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.

The standalone folder

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.

Besides 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.

The data folder is used by the application server to store its runtime data, such as the transaction logging.

The 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.

The lib folder hosts the sub folder ext, which is used to define extensions of the application server. The same considerations for the domain's lib path apply here.

The log folder contains the logs emitted by the standalone instance of the application server. The default log file, named server.log, is truncated every time the server is rebooted.

The tmp folder holds is used by JBoss Virtual File System as a temporary location for resource artifacts.

The welcome-content folder:

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 .

The modules folder

Beneath the 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 server/<servername>/lib folder.

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_HOME/server.

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:

AS Release

Bootstrap libs

Server libs

4.x

JBOSS_HOME/server

JBOSS_HOME/server/<server>/lib

5.x – 6.x

JBOSS_HOME/server

JBOSS_HOME/common/lib

and

JBOSS_HOME/server/<server>/lib

7.x

JBOSS_HOME/jboss-modules.jar

JBOSS_HOME/modules subfolders

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.

Loading application server modules

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 org.jboss.modules module.

Note

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.

The other way to approach the module repository is by using direct JAR execution . This means that the module information, such as its dependencies, is contained in the MANIFEST file.

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 META-INF/MANIFEST.MF file:

Main-Class: mypackage/MyClass
Dependencies: org.jboss.logging
 

Summary


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.

About the Author

  • Francesco Marchioni

    Francesco Marchioni is a Red Hat Certified JBoss Administrator (RHCJA) and Sun Certified Enterprise Architect working at Red Hat in Rome, Italy. He started learning Java in 1997, and since then he has followed the path to the newest Application Program Interfaces released by Sun. In 2000, he joined the JBoss community when the application server was running the 2.X release.

    He has spent years as a software consultant, where he has envisioned many successful software migrations from vendor platforms to open source products, such as JBoss AS, fulfilling the tight budget requirements of current times.

    Over the last 10 years, he has authored many technical articles for OReilly Media and ran an IT portal focused on JBoss products (http://www.mastertheboss.com).

    Browse publications by this author

Latest Reviews

(1 reviews total)
Excellent
Book Title
Access this book, plus 7,500 other titles for FREE
Access now