Skip to end of metadata
Go to start of metadata

The following chapters will focus on the high level management use cases that are available through the CLI and the web interface. For a detailed description of each subsystem configuration property, please consult the respective component reference.

Schema Location
The configuration schema can found in $JBOSS_HOME/docs/schema.

Data sources

Datasources are configured through the datasource subsystem. Declaring a new datasource consists of two separate steps: You would need to provide a JDBC driver and define a datasource that references the driver you installed. 

JDBC Driver Installation

The recommended way to install a JDBC driver into the application server is to simply deploy it as a regular JAR deployment.  The reason for this is that when you run your application server in domain mode, deployments are automatically propagated to all servers to which the deployment applies; thus distribution of the driver JAR is one less thing for you to worry about!

Any JDBC 4-compliant driver will automatically be recognized and installed into the system by name and version. A JDBC JAR is identified using the Java service provider mechanism. Such JARs will contain a text a file named META-INF/services/java.sql.Driver, which contains the name of the class(es) of the Drivers which exist in that JAR. If your JDBC driver JAR is not JDBC 4-compliant, it can be made deployable in one of a few ways.

Modify the JAR

The most straightforward solution is to simply modify the JAR and add the missing file. You can do this from your command shell by:

  1. Change to, or create, an empty temporary directory.
  2. Create a META-INF subdirectory.
  3. Create a META-INF/services subdirectory.
  4. Create a META-INF/services/java.sql.Driver file which contains one line - the fully-qualified class name of the JDBC driver.
  5. Use the jar command-line tool to update the JAR like this:

For a detailed explanation how to deploy JDBC 4 compliant driver jar, please refer to the chapter "Application Deployment".

Datasource Definitions

The datasource itself is defined within the subsystem datasources:

(See standalone/configuration/standalone.xml)

As you can see the datasource references a driver by it's logical name.

You can easily query the same information through the CLI:

Using the web console or the CLI greatly simplifies the deployment of JDBC drivers and the creation of datasources.

The CLI offers a set of commands to create and modify datasources:

Component Reference

The datasource subsystem is provided by the IronJacamar project. For a detailed description of the available configuration properties, please consult the project documentation.

Messaging

The JMS server configuration is done through the messaging subsystem. In this chapter we are going outline the frequently used configuration options. For a more detailed explanation please consult the HornetQ user guide (See "Component Reference"). 

Connection Factories

The JMS connection factories can be split into two kinds: In-VM connections and connections factories that can be used by remote clients. Each connection factory does reference a connector declaration, that is associated with a socket binding. The connection factory entry declaration specifies the JNDI name under which the factory will be exposed.

(See standalone/configuration/standalone.xml)

Queues and Topics

Queues and topics are sub resources of the messaging subsystem.
Each entry refers to a JNDI name of the queue or topic:

(See standalone/configuration/standalone.xml)

JMS endpoints can easily be created through the CLI:

A number of additional commands to maintain the JMS subsystem are available as well:

Dead Letter & Redelivery

Some of the settings are applied against an address wild card instead of a specific messaging destination. The dead letter queue and redelivery settings belong into this group:

(See standalone/configuration/standalone.xml)

Security Settings

Security constraints are matched against an address wildcard, similar to the DLQ and redelivery settings.

(See standalone/configuration/standalone.xml)

Component Reference

The messaging subsystem is provided by the HornetQ project. Fo a detailed description of the available configuration properties, please consult the project documentation.

Web

The web subsystem configuration basically consists of three parts: The JSP Configuration, connectors and virtual servers. Advanced topics like load balancing and failover are covered on the "High Availability Guide". The default configuration does is suitable for most use cases and provides reasonable performance settings.

Required extension:

Basic subsystem configuration example:

Dependencies on other subsystems:

None

Container configuration
JSP Configuration

The "configuration" subresource covers all aspects that relate to the configuration of the servlet engine itself. For a detailed explanation of each configuration attribute, please consult the JBossWeb documentation (See "Component Reference").

(See standalone/configuration/standalone.xml)

Connector configuration

The connectors are child resources of the subsystem web. Each connector does reference a particular socket binding:

Creating a new connector requires you to declare a new socket binding first:

The newly created, unused socket binding can then be used to create a new connector configuration:

Statistic information can be displayed from the connectors:

The following attributes can be queried:

value
description
bytesSent Number of byte sent by the connector
bytesReceived Number of byte received by the connector (POST data).
processingTime Processing time used by the connector. Im milli-seconds.
errorCount Number of error that occurs when processing requests by the connector.
maxTime Max time spent to process a request.
requestCount Number of requests processed by the connector.

For example:

There are 3 different connectors available:

HTTP Connectors

This one is the default connector, it runs usually on port 8080. See above how to configure it.

HTTPS Connectors

The HTTPS connectors are child resources of the subsystem web. By default they use JSSE. Each connector does reference a particular socket binding:

Creating a new connector may require you to declare a new socket binding first:

The newly created, unused socket binding can then be used to create a new connector configuration:

The default for SSL is to use Alias "tomcat" and password "changeit". It is possible to create the corresponding keystore using keytool:

Of course specify a password value of "changeit".

AJP Connectors

The AJP connectors are child resources of the subsystem web. They are used with mod_jk, mod_proxy and mod_cluster of the Apache httpd front-end. Each connector does reference a particular socket binding:

Creating a new connector requires you to declare a new socket binding first:

The newly created, unused socket binding can then be used to create a new connector configuration:

Native Connectors

Native connectors are high performance connectors based on Tomcat native. They are used if the native modules are installed, a lot of distributions have it included, in case you don't have it try JBoss Web Native.

At a configuration level only the SSL part needs to be configured differently because it use OpenSSL.

Virtual-Server configuration

Similar to the connectors, the virtual server declarations are child resources of the web subsystem. They will be referenced by alias names and can optionally refer to a default web application that acts serves the root web context.

Adding a virtual server declaration is can be done through the default :add() operation

add/remove operations exists on any node in the configuration tree.
Component Reference

The web subsystem is provided by the JBossWeb project. Fo a detailed description of the available configuration properties, please consult the JBossWeb documentation.

Web services

Web service endpoint are exposed through the deployments that provide endpoint implementation. Thus they can be queried as deployment resources. For further information please consult the chapter "Application Deployment". Each web service endpoint specifies a web context and a WSDL Url:

Component Reference

The web service subsystem is provided by the JBossWS project. Fo a detailed description of the available configuration properties, please consult the project documentation.

Logging

The overall server logging configuration is represented by the logging subsystem. It consists of three notable parts: handler configurations, logger and the root logger declarations (aka log categories). Each logger does reference a handler (or set of handlers). Each handler declares the log format and output:

Default Log File Locations

Managed Domain

In a managed domain two types of log files do exist: Controller and server logs. The controller components govern the domain as whole. It's their responsibility to start/stop server instances and execute managed operations throughout the domain. Server logs contain the logging information for a particular server instance. They are co-located with the host the server is running on.

For the sake of simplicity we look at the default setup for managed domain. In this case, both the domain controller components and the servers are located on the same host:

Process Log File
Host Controller ./domain/log/host-controller/boot.log
Process Controller ./domain/log/process-controller/boot.log
"Server One" ./domain/servers/server-one/log/boot.log
"Server One" ./domain/servers/server-one/log/server.log
"Server Three" ./domain/servers/server-three/log/boot.log
"Server Three" ./domain/servers/server-three/log/server.log


The server logs as you know it from previous JBoss AS versions are located in the servers subdirectory: I.e. ./domain/servers/server-three/log/server.log


Standalone Server 

The default log files for a standalone server can be found in the log subdirectory of the distribution:

Process Log File
Server ./standalone/log/boot.log
Server ./standalone/log/server.log

JMX

The JMX subsystem sets up a JMX connector so that invocations can be done on the JMX MBean server from outside the JVM

To use the connector you can access it in the standard way:

You can also connect using jconsole. In addition to the standard JVM MBeans, the JBoss AS 7 MBean server contains the following MBeans:

JMX ObjectName Description
jboss.msc:type=container,name=jboss-as Exposes management operations on the JBoss Modular Service Container, which is the dependency injection framework at the heart of JBoss AS 7. It is useful for debugging dependency problems, for example if you are integrating your own subsystems, as it exposes operations to dump all services and their current states
jboss.naming:type=JNDIView Shows what is bound in JNDI
jboss.modules:type=ModuleLoader,name=* This collection of MBeans exposes management operations on JBoss Modules classloading layer. It is useful for debugging dependency problems arising from missing module dependencies

OSGi

Old Documentation
This documentation applies to AS 7.0 only and has been superceded by documentation that can be found
in the JBoss OSGi Documentation Pages.

OSGi functionality in JBoss AS 7 is provided through the OSGi subsystem.

More information on the OSGi component in JBoss AS 7 can be found on the JBoss OSGi project pages.

The OSGi subsystem can be configured in its section in the JBoss AS 7 configuration XML file.

The following items can be configured:

Subsystem Attributes

Attribute Description
activation When set to lazy the OSGi subsystem will not get activated until the first OSGi bundle deployment. When set to eager the OSGi subsystem will be activated at startup of the Application Server.

Configuration Admin

The OSGi Configuration Admin Service (CAS) is a standard service aimed at configuring OSGi-based applications. Many OSGi applications use the CAS to configure themselves.

The OSGi subsystem configuration allows for the specification of CAS configuration information, to configure bundles written for this specification (chapter 104 in the OSGi 4.2 Compendium Specification)

To add CAS configuration information, add <configuration> tags to the OSGi subsystem configuration. For example, the following is used to configure the context root where the Felix Web Console appears:

Configuration information consists of a <configuration> tag specifying a PID (Persistent Identifier) attribute which identifies the system to be configured. The configuration tag can contain any number of embedded <property> tags which hold the configuration information for this PID.

Framework Properties

OSGi Framework properties are specified as embedded <property> elements in the <properties> tag.

The following properties are specified:

Property Description
org.jboss.osgi.system.modules A comma-separated list of module identifiers. Each system module is added as a dependency to the OSGi framework module. The packages from these system modules can be made visible as framework system packages by adding them to the org.osgi.framework.system.packages.extra property.
org.osgi.framework.system.packages.extra Extra packages which the system bundle must export from the current execution environment.
org.osgi.framework.startlevel.beginning The beginning start level of the OSGi Framework. This also influences which modules are pre-loaded. See the modules section.

Additional OSGi Framework properties can be specified. For more information on OSGi Framework properties see the OSGi 4.2 Core Specification.

Modules

JBoss AS 7 comes with a repository of modules and OSGi bundles that can be automatically loaded at startup. JBoss-Modules compliant modules can be found in the modules/ directory and OSGi bundles can be found in the bundles/ directory. In the <modules> section of the XML configuration both JBoss-Modules as well as OSGi Bundles can be specified.

OSGi Bundles can also be started automatically at startup. This is specified with the startlevel attribute. The default start level of the OSGi Framework is 1. To enable additional functionality in the OSGi Framework, increase the org.osgi.framework.startlevel.beginning framework property.

Note that these modules don't trigger the activation of the OSGi subsystem. Once the subsystem is activated as described above, these modules and bundles will be automatically loaded and optionally started.

The following modules and bundles are listed in the default configuration.

Module Identifier Description
javaee.api Provides JavaEE APIs.
org.apache.aries.jmx Provides JMX support to OSGi as described in chapter 124 of the OSGi 4.2 Enterprise Specification. For more information see Using JMX below.
org.apache.aries.util Needed by the Aries JMX bundle.
org.apache.felix.configadmin An implementation of the OSGi Configuration Admin specificaton. Chapter 104 in the OSGi 4.2 Compendium Specification.
org.apache.felix.eventadmin An implementation of the OSGi Event Admin specification. Chapter 113 in the OSGi 4.2 Compendium Specification.
org.apache.felix.log An implementation of the OSGi Log Service specification. Chapter 101 in the OSGi 4.2 Compendium Specification.
org.apache.felix.metatype An implementation of the OSGi Metatype Service specification. Chapter 105 in the OSGi 4.2 Compendium Specification.
org.apache.felix.webconsole The Felix Web Console. For more information see Using the Felix Web Console below.
org.jboss.as.osgi.configadmin Component providing the OSGi Configuration Admin Service with information from the OSGi subsystem configuration.
org.jboss.logging The JBoss Logging Framework.
org.jboss.osgi.blueprint An implementation of the OSGi Blueprint Specification. Blueprint is a component model and IoC specification for OSGi which significantly simplifies the use of OSGi services. It can be found in chapter 121 in the OSGi 4.2 Enterprise Specification.
org.jboss.osgi.http An implementation of the OSGi Http Service. Chapter 102 in the OSGi 4.2 Compendium Specification. The port used by this implementation is set by default to <socket-binding name="osgi-http" port="8090"/> in the socket-binding-group.
org.jboss.osgi.jmx Enhanced JMX API, the MBeans can be found under jboss.osgi.
org.jboss.osgi.logging Sends log messages sent to the OSGi Log Service to JBoss Logging.
org.jboss.osgi.webapp OSGi Support for Web Apps, as described in chapter 128 in the OSGi 4.2 Compendium Specification.
org.jboss.osgi.webconsole Customizations of the Felix Web Console.
org.jboss.osgi.xerces An implementation of the OSGi XML Parser specification. Chapter 702 in the OSGi 4.2 Compendium Specification.
org.osgi.compendium A bundle providing the APIs defined by the OSGi Compendium Specification.

Using the Felix Web Console

For fine-grained management of the OSGi Framework, the Apache Felix Web Console can be used. This web console is shipped as part of JBoss AS 7 and is specifically aimed at fine-grained control of the OSGi Framework.

The Web Console is not enabled by default. The relevant modules are marked as having startlevel=2, so to enable the web console set the initial framework start level to 2 or higher:

By default the console appears on http://localhost:8090/jboss-osgi with as username and password admin/admin. This can be configured through the OSGi Configuration Admin Service configuration.

Start JBoss AS 7 and make sure the OSGi Framework is active; the framework can be activated by deploying an OSGi bundle into JBoss AS 7 or by setting its activation mode to eager.

Then open a web browser and access: http://localhost:8090/jboss-osgi. A log-in dialog appears. Enter the password configured or the default username and password: admin/admin and the web console will appear:

Using JMX

The OSGi Framework exposes a number of JMX MBeans that enable remote control of the framework. Both the MBeans that are defined in chapter 124 of the OSGi 4.2 Enterprise Specification as well as JBoss-extended MBeans are available.

The JMX support is not enabled by default. The relevant modules are marked as having startlevel=2, so to enable JMX set the initial framework start level to 2 or higher:

Start JBoss AS 7 and make sure the OSGi Framework is active; the framework can be activated by deploying an OSGi bundle into JBoss AS 7 or by setting its activation mode to eager.

The JMX functionality can now be accessed through a JMX console, for instance jconsole which ships with the JDK:

Connect using the Remote Process URL service:jmx:rmi:///jndi/rmi://127.0.0.1:1090/jmxrmi. (You can also connect directly to the Local Process, the one that starts with jboss-modules.jar -mp ...)

When the connection is established navigate to the MBeans tab to interact with the OSGi MBeans.

Deployment Scanner

The deployment scanner is only used in standalone mode. Its job is to monitor a directory for new files and to deploy those files. It can be found in standalone.xml:

The subsystem can be removed complete from the standalone configuration, e.g. for security reasons. In this case all deployments are only possible via CLI or Console as in the domain mode.
You can define more deployment-scanner entries, by using different name identifier, to scan for deployments from more locations. The configuration showed will scan the $JBOSS_HOME/standalone/deployments directory every five seconds. The runtime model is shown below, and uses default values for attributes not specified in the xml:

The attributes are

Name Type Description
name STRING The name of the scanner. default is used if not specified
path STRING The actual filesystem path to be scanned. Treated as an absolute path, unless the 'relative-to' attribute is specified, in which case the value is treated as relative to that path.
relative-to STRING Reference to a filesystem path defined in the "paths" section of the server configuration, or one of the system properties specified on startup. In the example above jboss.server.base.dir resolves to {{$JBOSS_HOME/standalone
scan-enabled BOOLEAN If true scanning is enabled
scan-interval INT Periodic interval, in milliseconds, at which the repository should be scanned for changes. A value of less than 1 indicates the repository should only be scanned at initial startup.
auto-deploy-zipped BOOLEAN Controls whether zipped deployment content should be automatically deployed by the scanner without requiring the user to add a .dodeploy marker file.
auto-deploy-exploded BOOLEAN Controls whether exploded deployment content should be automatically deployed by the scanner without requiring the user to add a .dodeploy marker file. Setting this to 'true' is not recommended for anything but basic development scenarios, as there is no way to ensure that deployment will not occur in the middle of changes to the content.
deployment-timeout LONG Timeout, in seconds, a deployment is allows to execute before being canceled. The default is 60 seconds.

Deployment scanners can be added by modifying standalone.xml before starting up the server or they can be added and removed at runtime using the CLI

You can also change the attributes at runtime, so for example to turn off scanning you can do

Simple configuration subsystems

The following subsystems currently have no configuration beyond its root element in the configuration

The presence of each of these turns on a piece of functionality:

Name Description
EE Enables the deployment of .EAR archives.
EJB3 Enables the deployment and functionality of EJB 3.1 applications.
JAXRS Enables the deployment and functionality of JAX-RS applications. This is implemented by the RestEasy project
Remoting Turns on the remoting subsystem, which is used for the management communication and will be what underlies remote JNDI lookups and remote EJB calls in a future release.
Sar Enables the deployment of .SAR archives containing MBean services, as supported by previous versions of JBoss Application Server
Threads This subsystem is being deprecated and will not be part of the next release
Weld Enables the deployment and functionality of CDI applications
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.