Installing Eclipse environment - JBoss

Although the main focus of this tutorial 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 tutorial 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:

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.

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 tutorial

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

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.

Frequently asked Jboss Interview Questions

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 coming next tutorial, Securing JBoss AS, of this tutorial.

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 (https://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//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//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:

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.