The first chapter has given us the initial groundwork to get started with JBoss AS 7. It is time for us to dive right into the new configuration and see how to shape a standalone instance of the application server. As you will see, the application configuration has also been renewed, moving from a large set of xml files to a single monolithic file.
The new configuration file is made up of a list of subsystems, which include the application server core services and standard Java EE services. By the end of this chapter, we will have covered the following topics:
- Introducing the server configuration file
- Configuring the application server’s Thread Pool
- Configuring the application server’s logging subsystem
Configuring the application server
The structure of the application server is maintained into a single file, which acts as a main reference for all server configurations. This file is not a static file, as it reflects the changes that are made when the server is running, for example, adding a new component, such as a JMS destination, or deploying an application.
The default configuration files are named standalone.xml for standalone servers and domain.xml for an application server domain. An application server domain can be seen as a specialized server configuration, which also includes the Domain and Host controller set-up. We will discuss the application server domain in Chapter 5, Configuring a JBoss AS Domain. However, as far as the core services configuration is concerned, what we learn here will be suitable for the domain configuration as well.
You can define as many configuration files as you need. For example, the AS 7.0.2 release provides a few variants of the standalone.xml, such as standalone-preview.xml (which includes JMS and web services subsystems) and the standalone-ha.xml (which can be used to start a cluster-aware application server). If you want to switch to another configuration file, just issue: standalone.bat –server-config customConfiguration.xml
The standalone.xml file is located under the JBOSS_HOME/standalone/configuration folder. This configuration file consists of a large xml file, which is validated by a set of .xsd files mentioned in the element.
If you want to check the single .xsd files, you can find them in the JBOSS_HOME/docs/schema folder of your server distribution. You can get to know all the available server parameters with a simple inspection of these files or by importing them into your Eclipse environment. Once they are located in your project, right-click your file and choose Generate | XML File.
The application server configuration follows a tree-like structure that contains, at the root element, the server definition.
Subscribe to our youtube channel to get new updates..!
In the following sections, we will show in detail each part of the server configuration. This will be helpful to understand the role of each single component in the application server, although we warn you from manually changing the configuration file, since this can lead to unchecked data modifications that can easily corrupt the file.
The best practice for changing the server configuration is to use the Command Line Interface (CLI) or the web admin console, which are described in Chapter 7, Managing the Application Server.
The application server contains a list of basic modules, called extensions, which are shared by all of its services. Extensions can be seen as a special type of module, which are used to extend the functionalities of the application server. Much like standard modules, they are stored in the JBOSS_HOME/modules folder. Each extension is in turn picked up by the AS classloader at boot time, before any deployment. Here’s an extract from the server configuration:
The application server detects that a module is an extension by scanning into the META_INF/services folder of the library. Modules that are qualified as Extensions contain in the META_INF/services folder a placeholder file named org.jboss.as.controller.Extension. This file simply declares the name of the Extension. For example, for the EJB3 subsystem, it will contain org.jboss.as.ejb3.subsystem.EJB3Extension.
Beneath module extensions, you can find the definition of paths that can be defined as logical names for file system paths. For example, the following bit of configuration defines a path relative to the AS log directory named log.dir, which translates for standalone servers into JBOSS_HOME/standalone/log/mylogdir:
Now, this path can be referenced in other sections of the configuration file, for example, we are using it as a folder for storing the logging rotating file handler:
Please note that the property relative-to is not mandatory. If you don’t include it in your path configuration, the path is meant as an absolute path.
By default, the application server provides a set of system paths that are available for use as relative paths and cannot be overridden by the user: