jar \-uf jdbc-driver.jar META-INF/services/java.sql.Driver
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:
-
Change to, or create, an empty temporary directory.
-
Create a META-INF subdirectory.
-
Create a META-INF/services subdirectory.
-
Create a META-INF/services/java.sql.Driver file which contains one line - the fully-qualified class name of the JDBC driver.
-
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:
<subsystem xmlns="urn:jboss:domain:datasources:1.0">
<datasources>
<datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS">
<connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
<driver>h2</driver>
<pool>
<min-pool-size>10</min-pool-size>
<max-pool-size>20</max-pool-size>
<prefill>true</prefill>
</pool>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</datasource>
<xa-datasource jndi-name="java:jboss/datasources/ExampleXADS" pool-name="ExampleXADS">
<driver>h2</driver>
<xa-datasource-property name="URL">jdbc:h2:mem:test</xa-datasource-property>
<xa-pool>
<min-pool-size>10</min-pool-size>
<max-pool-size>20</max-pool-size>
<prefill>true</prefill>
</xa-pool>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</xa-datasource>
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
</drivers>
</datasources>
</subsystem>
(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:
[standalone@localhost:9999 /] /subsystem=datasources:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"data-source" => {"java:/H2DS" => {
"connection-url" => "jdbc:h2:mem:test;DB_CLOSE_DELAY=-1",
"jndi-name" => "java:/H2DS",
"driver-name" => "h2",
"pool-name" => "H2DS",
"use-java-context" => true,
"enabled" => true,
"jta" => true,
"pool-prefill" => true,
"pool-use-strict-min" => false,
"user-name" => "sa",
"password" => "sa",
"flush-strategy" => "FailingConnectionOnly",
"background-validation" => false,
"use-fast-fail" => false,
"validate-on-match" => false,
"use-ccm" => true
}},
"xa-data-source" => undefined,
"jdbc-driver" => {"h2" => {
"driver-name" => "h2",
"driver-module-name" => "com.h2database.h2",
"driver-xa-datasource-class-name" => "org.h2.jdbcx.JdbcDataSource"
}}
}
}
[standalone@localhost:9999 /] /subsystem=datasources:installed-drivers-list
{
"outcome" => "success",
"result" => [{
"driver-name" => "h2",
"deployment-name" => undefined,
"driver-module-name" => "com.h2database.h2",
"module-slot" => "main",
"driver-xa-datasource-class-name" => "org.h2.jdbcx.JdbcDataSource",
"driver-class-name" => "org.h2.Driver",
"driver-major-version" => 1,
"driver-minor-version" => 2,
"jdbc-compliant" => true
}]
}
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:
[standalone@localhost:9999 /] help Supported commands: [...] data-source - allows to add new, modify and remove existing data sources xa-data-source - allows add new, modify and remove existing XA data sources For a more detailed description of a specific command, execute the command with '--help' as the argument.
Using security domains
Information can be found at https://community.jboss.org/wiki/JBossAS7SecurityDomainModel
Deployment of -ds.xml files
Starting with JBoss Application Server 7.1.0.Final you have the ability to deploy a -ds.xml file following the schema:
http://docs.jboss.org/ironjacamar/schema/datasources_1_1.xsd
It is mandatory to use a reference to an already deployed / defined <driver> entry.
This feature is primarily intended for development, and thus has a few limitations to be aware of. It can not be altered in any of the management interfaces (consle, CLI, etc). Only limited runtime information is available. Also, password vaults and security domains are not deployable, so these can not be bundled with a datasource deployment.
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.
-
IronJacamar homepage: http://www.jboss.org/ironjacamar
-
Project Documentation: http://www.jboss.org/ironjacamar/docs
-
Schema description: http://docs.jboss.org/ironjacamar/userguide/1.0/en-US/html/deployment.html#deployingds_descriptor
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
There are two kinds of basic JMS connection-factory:
-
In-VM connection factories can be used by a local client (i.e. one running in the same JVM as the server)
-
Netty connections factories can be used by a remote client.
There is also a pooled-connection-factory which is special in that it leverages the outbound adapter of the HornetQ JCA Resource Adapter. It is also special because:
-
It is only available to local clients, although it can be configured to point to a remote server.
-
As the name suggests, it is pooled and therefore provides superior performance to the clients which are able to use it. The pool size can be configured via the max-pool-size and min-pool-size attributes.
-
It should only be used to send (i.e. produce) messages.
-
It can be configured to use specific security credentials via the user and password attributes. This is useful if the remote server to which it is pointing is secured.
-
Resources acquired from it will be automatically enlisted any on-going JTA transaction. If you want to send a message from an EJB using CMT then this is likely the connection factory you want to use so the send operation will be atomically committed along with the rest of the EJB's transaction operations.
To be clear, the inbound adapter of the HornetQ JCA RA (which is for consuming messages) is only used by MDBs and other JCA-based components. It is not available to traditional clients.
Both a connection-factory a pooled-connection-factory reference a connector declaration.
A netty-connector is associated with a socket-binding which tells the client using the connection-factory where to connect.
-
A connection-factory referencing a netty-connector is suitable to be used by a remote client to send messages to or receive messages from the server (assuming the connection-factory has an appropriately exported entry).
-
A pooled-connection-factory referencing a netty-connector is suitable to be used by a local client to send messages to a remote server granted the socket-binding references an outboud-socket-binding pointing to the remote server in question.
An in-vm-connector is associated with a server-id which tells the client using the connection-factory where to connect (since multiple HornetQ servers can run in a single JVM).
-
A connection-factory referencing an in-vm-connector is suitable to be used by a local client to either send messages to or receive messages from a local server.
-
A pooled-connection-factory referencing an in-vm-connector is suitable to be used by a local client only to send messages to a local server.
The entry declaration of a connection-factory or a pooled-connection-factory specifies the JNDI name under which the factory will be exposed. Only JNDI names bound in the "java:jboss/exported" namespace are available to remote clients. If a connection-factory has an entry bound in the "java:jboss/exported" namespace a remote client would look-up the connection-factory using the text after "java:jboss/exported". For example, the "RemoteConnectionFactory" is bound by default to "java:jboss/exported/jms/RemoteConnectionFactory" which means a remote client would look-up this connection-factory using "jms/RemoteConnectionFactory". A pooled-connection-factory should not have any entry bound in the "java:jboss/exported" namespace because a pooled-connection-factory is not suitable for remote clients.
<subsystem xmlns="urn:jboss:domain:messaging:1.0">
[...]
<connectors>
<netty-connector name="netty" socket-binding="messaging"/>
<netty-connector name="netty-throughput" socket-binding="messaging-throughput">
<param key="batch-delay" value="50"/>
</netty-connector>
<in-vm-connector name="in-vm" server-id="0"/>
</connectors>
[...]
<jms-connection-factories>
<connection-factory name="InVmConnectionFactory">
<connectors>
<connector-ref connector-name="in-vm"/>
</connectors>
<entries>
<entry name="java:/ConnectionFactory"/>
</entries>
</connection-factory>
<connection-factory name="RemoteConnectionFactory">
<connectors>
<connector-ref connector-name="netty"/>
</connectors>
<entries>
<entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
</entries>
</connection-factory>
<pooled-connection-factory name="hornetq-ra">
<transaction mode="xa"/>
<connectors>
<connector-ref connector-name="in-vm"/>
</connectors>
<entries>
<entry name="java:/JmsXA"/>
</entries>
</pooled-connection-factory>
</jms-connection-factories>
[...]
</subsystem>
(See standalone/configuration/standalone-full.xml)
JMS Queues and Topics
JMS queues and topics are sub resources of the messaging subsystem. They are defined in the jms-destinations section. One can define either a jms-queue or jms-topic. Each destination must be given a name and contain at least one entry element.
Each entry refers to a JNDI name of the queue or topic. Keep in mind that any jms-queue or jms-topic which needs to be accessed by a remote client needs to have an entry in the "java:jboss/exported" namespace. As with connection factories, if a jms-queue or jms-topic has an entry bound in the "java:jboss/exported" namespace a remote client would look it up using the text after "java:jboss/exported". For example, the following jms-queue "testQueue" is bound to "java:jboss/exported/jms/queue/test" which means a remote client would look-up this jms-queue using "jms/queue/test". A local client could look it up using "java:jboss/exported/jms/queue/test", "java:jms/queue/test", or more simply "jms/queue/test":
<subsystem xmlns="urn:jboss:domain:messaging:1.0">
[...]
<jms-destinations>
<jms-queue name="testQueue">
<entry name="jms/queue/test"/>
<entry name="java:jboss/exported/jms/queue/test"/>
</jms-queue>
<jms-topic name="testTopic">
<entry name="jms/topic/test"/>
<entry name="java:jboss/exported/jms/topic/test"/>
</jms-topic>
</jms-destinations>
</subsystem>
(See standalone/configuration/standalone-full.xml)
JMS endpoints can easily be created through the CLI:
[standalone@localhost:9999 /] jms-queue add --queue-address=myQueue --entries=queue/myQueue
[standalone@localhost:9999 /] /subsystem=messaging/hornetq-server=default/jms-queue=myQueue:read-resource
{
"outcome" => "success",
"result" => {
"durable" => true,
"entries" => ["queue/myQueue"],
"selector" => undefined
}
}
A number of additional commands to maintain the JMS subsystem are available as well:
[standalone@localhost:9999 /] jms-queue --help --commands add ... remove To read the description of a specific command execute 'jms-queue command_name --help'.
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:
<subsystem xmlns="urn:jboss:domain:messaging:1.0">
[...]
<address-settings>
<address-setting match="#">
<dead-letter-address>jms.queue.DLQ</dead-letter-address>
<expiry-address>jms.queue.ExpiryQueue</expiry-address>
<redelivery-delay>0</redelivery-delay>
[...]
</address-setting>
</address-settings>
[...]
</subsystem>
(See standalone/configuration/standalone-full.xml)
Security Settings for HornetQ addresses and JMS destinations
Security constraints are matched against an address wildcard, similar to the DLQ and redelivery settings. Note: Multiple roles are separated by spaces.
<subsystem xmlns="urn:jboss:domain:messaging:1.0">
[...]
<security-settings>
<security-setting match="#">
<permission type="send" roles="guest"/>
<permission type="consume" roles="guest"/>
<permission type="createNonDurableQueue" roles="role1"/>
<permission type="deleteNonDurableQueue" roles="role1 role2"/>
</security-setting>
</security-settings>
[...]
</subsystem>
(See standalone/configuration/standalone-full.xml)
Security Domain for Users
By default, HornetQ will use the "other" JAAS security domain. This domain is used to authenticate users making connections to HornetQ and then they are authorized to perform specific functions based on their role(s) and the security-settings described above. This domain can be changed by using security-domain, e.g.:
<subsystem xmlns="urn:jboss:domain:messaging:1.0"> [...] <security-domain>mySecurityDomain</security-domain> [...] </subsystem>
Deployment of -jms.xml files
Starting with JBoss Application Server 7.1.0.Final you have the ability to deploy a -jms.xml file defining JMS destinations, e.g.:
<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-deployment:1.0">
<hornetq-server>
<jms-destinations>
<jms-queue name="sample">
<entry name="jms/queue/sample"/>
<entry name="java:jboss/exported/jms/queue/sample"/>
</jms-queue>
</jms-destinations>
</hornetq-server>
</messaging-deployment>
|
|
This feature is primarily intended for development as destinations deployed this way can not be managed with any of the provided management tools (e.g. console, CLI, etc). |
JMS Bridge
The function of a JMS bridge is to consume messages from a source JMS destination, and send them to a target JMS destination. Typically either the source or the target destinations are on different servers.
The bridge can also be used to bridge messages from other non HornetQ JMS servers, as long as they are JMS 1.1 compliant.
The JMS Bridge is provided by the HornetQ project. Fo a detailed description of the available configuration properties, please consult the project documentation.
Modules for other messaging brokers
Source and target JMS resources (destination and connection factories) are looked up using JNDI.
If either the source or the target resources are managed by another messaging server than AS7, the required client classes must be bundled in a module. The name of the module must then be declared when the JMS Bridge is configured.
The use of a JMS bridges with any messaging provider will require to create a module containing the jar of this provider.
Let's suppose we want to use an hypothetical messaging provider named AcmeMQ. We want to bridge messages coming from a source AcmeMQ destination to a target destination on the local AS7 messaging server. To lookup AcmeMQ resources from JNDI, 2 jars are required, acmemq-1.2.3.jar, mylogapi-0.0.1.jar (please note these jars do not exist, this is just for the example purpose). We must not include a JMS jar since it will be provided by a AS7 module directly.
To use these resources in a JMS bridge, we must bundle them in a JBoss module:
in $JBOSS_HOME/modules, we create the layout:
modules/
`-- org
`-- acmemq
`-- main
|-- acmemq-1.2.3.jar
|-- mylogapi-0.0.1.jar
`-- module.xml
We define the module in module.xml:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.acmemq">
<properties>
<property name="jboss.api" value="private"/>
</properties>
<resources>
<!-- insert resources required to connect to the source or target -->
<!-- messaging brokers if it not another AS7 instance -->
<resource-root path="acmemq-1.2.3.jar" />
<resource-root path="mylogapi-0.0.1.jar" />
</resources>
<dependencies>
<!-- add the dependencies required by JMS Bridge code -->
<module name="javax.api" />
<module name="javax.jms.api" />
<module name="javax.transaction.api"/>
<module name="org.jboss.remote-naming"/>
<!-- we depend on org.hornetq module since we will send messages to -->
<!-- the HornetQ server embedded in the local AS7 instance -->
<module name="org.hornetq" />
</dependencies>
</module>
Configuration
A JMS bridge is defined inside a jms-bridge section of the `messaging` subsystem in the XML configuration files.
<subsystem xmlns="urn:jboss:domain:messaging:1.3">
<jms-bridge name="myBridge" module="org.acmemq">
<source>
<connection-factory name="ConnectionFactory"/>
<destination name="sourceQ"/>
<user>user1</user>
<password>pwd1</password>
<context>
<property key="java.naming.factory.initial" value="org.acmemq.jndi.AcmeMQInitialContextFactory"/>
<property key="java.naming.provider.url" value="tcp://127.0.0.1:9292"/>
</context>
</source>
<target>
<connection-factory name="/jms/invmTargetCF"/>
<destination name="/jms/targetQ"/>
</target>
<quality-of-service>AT_MOST_ONCE</quality-of-service>
<failure-retry-interval>500</failure-retry-interval>
<max-retries>1</max-retries>
<max-batch-size>500</max-batch-size>
<max-batch-time>500</max-batch-time>
<add-messageID-in-header>true</add-messageID-in-header>
</jms-bridge>
</subsystem>
The source and target sections contain the name of the JMS resource (connection-factory and destination) that will be looked up in JNDI.
It optionally defines the user and password credentials. If they are set, they will be passed as arguments when creating the JMS connection from the looked up ConnectionFactory.
It is also possible to define JNDI context properties in the context section. If the context section is absent, the JMS resources will be looked up in the local AS7 instance (as it is the case in the target section in the example above).
Management commands
A JMS Bridge can also be managed using the JBoss command line interface:
[standalone@localhost:9999 /] /subsystem=messaging/jms-bridge=myBridge/:add(module="org.acmemq", \
source-destination="sourceQ", \
source-connection-factory="ConnectionFactory", \
source-user="user1", \
source-password="pwd1", \
source-context={"java.naming.factory.initial" => "org.acmemq.jndi.AcmeMQInitialContextFactory", \
"java.naming.provider.url" => "tcp://127.0.0.1:9292"}, \
target-destination="/jms/targetQ", \
target-connection-factory="/jms/invmTargetCF", \
quality-of-service=AT_MOST_ONCE, \
failure-retry-interval=500, \
max-retries=1, \
max-batch-size=500, \
max-batch-time=500, \
add-messageID-in-header=true)
{"outcome" => "success"}
You can also see the complete JMS Bridge resource description from the CLI:
[standalone@localhost:9999 /] /subsystem=messaging/jms-bridge=*/:read-resource-description
{
"outcome" => "success",
"result" => [{
"address" => [
("subsystem" => "messaging"),
("jms-bridge" => "*")
],
"outcome" => "success",
"result" => {
"description" => "A JMS bridge instance.",
"attributes" => {
...
}
}]
}
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.
-
HornetQ homepage: http://www.jboss.org/hornetq
-
Project Documentation: http://www.jboss.org/hornetq/docs
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:
<extension module="org.jboss.as.web" />
Basic subsystem configuration example:
<subsystem xmlns="urn:jboss:domain:web:1.0" default-virtual-server="default-host"> <connector name="http" scheme="http" protocol="HTTP/1.1" socket-binding="http"/> <virtual-server name="default-host" enable-welcome-root="true"> <alias name="localhost" /> <alias name="example.com" /> </virtual-server> </subsystem>
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").
[standalone@localhost:9999 /] /subsystem=web:read-resource
{
"outcome" => "success",
"result" => {
"configuration" => {
"static-resources" => {
"sendfile" => 49152,
"max-depth" => 3,
"read-only" => true,
"webdav" => false,
"listings" => false,
"disabled" => false
},
"jsp-configuration" => {
"development" => false,
"keep-generated" => true,
"recompile-on-fail" => false,
"check-interval" => 0,
"modification-test-interval" => 4,
"display-source-fragment" => true,
"error-on-use-bean-invalid-class-attribute" => false,
"java-encoding" => "UTF8",
"tag-pooling" => true,
"generate-strings-as-char-arrays" => false,
"target-vm" => "1.5",
"dump-smap" => false,
"mapped-file" => true,
"disabled" => false,
"source-vm" => "1.5",
"trim-spaces" => false,
"smap" => true
}
},
"connector" => {"http" => undefined},
"virtual-server" => {"localhost" => undefined}
}
}
(See standalone/configuration/standalone.xml)
Connector configuration
The connectors are child resources of the subsystem web. Each connector does reference a particular socket binding:
[standalone@localhost:9999 /] /subsystem=web:read-children-names(child-type=connector)
{
"outcome" => "success",
"result" => ["http"]
}
[standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"protocol" => "HTTP/1.1",
"scheme" => "http",
"socket-binding" => "http",
"ssl" => undefined,
"virtual-server" => undefined
}
}
Creating a new connector requires you to declare a new socket binding first:
[standalone@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=custom:add(port=8181)
The newly created, unused socket binding can then be used to create a new connector configuration:
[standalone@localhost:9999 /] /subsystem=web/connector=test-connector:add(
socket-binding=custom, scheme=http, protocol="HTTP/1.1", enabled=true
)
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:
[standalone@localhost:9999 /] /subsystem=web/connector=http:read-attribute(name=bytesSent, name=requestCount)
{
"outcome" => "success",
"result" => "3"
}
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:
[standalone@localhost:9999 /] /subsystem=web:read-children-names(child-type=connector)
{
"outcome" => "success",
"result" => [
"ajp",
"http",
"https"
]
}
[standalone@localhost:9999 /] /subsystem=web/connector=https:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"protocol" => "HTTP/1.1",
"scheme" => "https",
"secure" => true,
"socket-binding" => "https",
"ssl" => {},
"virtual-server" => undefined
}
}
Creating a new connector may require you to declare a new socket binding first:
[standalone@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=https:add(port=8443)
The newly created, unused socket binding can then be used to create a new connector configuration:
[standalone@localhost:9999 /] /subsystem=web/connector=test-connector:add(socket-binding=https, scheme=https, protocol="HTTP/1.1", enabled=true, ssl = {})
The default for SSL is to use Alias "tomcat" and password "changeit". It is possible to create the corresponding keystore using keytool:
keytool -genkey -alias tomcat -keyalg RSA
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:
[standalone@localhost:9999 /] /subsystem=web:read-children-names(child-type=connector)
{
"outcome" => "success",
"result" => [
"ajp",
"http"
]
}
[standalone@localhost:9999 /] /subsystem=web/connector=ajp:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"protocol" => "AJP/1.3",
"scheme" => "http",
"socket-binding" => "ajp",
"ssl" => undefined,
"virtual-server" => undefined
}
}
Creating a new connector requires you to declare a new socket binding first:
[standalone@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=ajp:add(port=8009)
The newly created, unused socket binding can then be used to create a new connector configuration:
[standalone@localhost:9999 /] /subsystem=web/connector=ajp:add(
socket-binding=ajpm, protocol="AJP/1.3", enabled=true
)
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.
[standalone@localhost:9999 /] /subsystem=web/connector=https:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"protocol" => "HTTP/1.1",
"scheme" => "https",
"secure" => true,
"socket-binding" => "https",
"ssl" => {
"certificate-file" => "/home/jfclere/CERTS/SERVER/newcert.pem",
"certificate-key-file" => "/home/jfclere/CERTS/SERVER/newkey.pem",
"password" => "xxxxxxx"
},
"virtual-server" => undefined
}
}
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.
[standalone@localhost:9999 /] /subsystem=web:read-children-names(child-type=virtual-server)
{
"outcome" => "success",
"result" => ["localhost"]
}
[standalone@localhost:9999 /] /subsystem=web/virtual-server=default-host:read-resource
{
"outcome" => "success",
"result" => {
"access-log" => undefined,
"alias" => ["example.com"],
"default-web-module" => undefined,
"enable-welcome-root" => true,
"rewrite" => undefined
}
}
Adding a virtual server declaration is can be done through the default :add() operation
[standalone@localhost:9999 /] /subsystem=web/virtual-server=example.com:add [standalone@localhost:9999 /] /subsystem=web/virtual-server=example.com:remove
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.
-
JBoss Web Configuration Reference: http://docs.jboss.org/jbossweb/7.0.x/config/index.html
-
JBossWeb homepage: http://www.jboss.org/jbossweb
-
Project Documentation: http://docs.jboss.org/jbossweb/7.0.x/
Web services
Domain management
The webservices subsystem is the subsystem that brings the services provided through JBossWS components and which deal with deployment of WS endpoints on the application server.
Structure of the webservices subsystem
Published endpoint address
JBossWS supports rewriting the of the <soap:address> element in endpoint published WSDL contracts. That's useful for controlling the server address that is advertised to clients for each endpoint.
The following elements are available and can be modified (all are optional and require server restart upon modification):
|
Name |
Type |
Description |
|
modify-wsdl-address |
boolean |
If the content of <soap:address> is a valid URL, JBossWS will not rewrite it unless modify-soap-address is true. |
|
wsdl-host |
string |
The hostname / IP address to be used for rewriting <soap:address>. |
|
wsdl-port |
int |
Set this property to explicitly define the HTTP port that will be used for rewriting the SOAP address. |
|
wsdl-secure-port |
int |
Set this property to explicitly define the HTTPS port that will be used for rewriting the SOAP address. |
Predefined endpoint configurations
JBossWS allows for defining endpoint configurations to be referenced by endpoint implementations. This allows for instance for adding a given handler to any WS endpoint that is marked with a given endpoint configuration (through @org.jboss.ws.api.annotation.EndpointConfig).
JBoss Application Server comes with a default Standard-Endpoint-Config as well as with an example of custom endpoint configuration (Recording-Endpoint-Config) including a recording handler (please reference the JBossWS documentation for details on that).
[standalone@localhost:9999 /] /subsystem=webservices:read-resource
{
"outcome" => "success",
"result" => {
"endpoint" => {},
"modify-wsdl-address" => true,
"wsdl-host" => expression "${jboss.bind.address:127.0.0.1}",
"endpoint-config" => {
"Standard-Endpoint-Config" => undefined,
"Recording-Endpoint-Config" => undefined
}
}
}
The Standard-Endpoint-Config is a special endpoint configuration that is automatically used for any endpoint which no other configuration is associated to.
Endpoint configs
Endpoint configs are defined using endpoint-config element; each endpoint config may include properties and handlers set to the endpoints associated to the config.
[standalone@localhost:9999 /] /subsystem=webservices/endpoint-config=Recording-Endpoint-Config:read-resource
{
"outcome" => "success",
"result" => {
"post-handler-chain" => undefined,
"property" => undefined,
"pre-handler-chain" => {"recording-handlers" => undefined}
}
}
A new endpoint config can be added as follows:
[standalone@localhost:9999 /] /subsystem=webservices/endpoint-config=My-Endpoint-Config:add
{
"outcome" => "success",
"response-headers" => {
"operation-requires-restart" => true,
"process-state" => "restart-required"
}
}
Handler chains
Each endpoint config may be associated both to PRE and POST handler chains. Each handler chain may include JAXWS handlers. For outbound messages, PRE handler chain handlers are meant to be executed before any handler attached to the endpoints using standard JAXWS means (e.g. using @HandlerChain), while POST handler chain handlers are executed after usual endpoint handlers. For inbound messages, the opposite applies.
* Server inbound messages Client --> ... --> POST HANDLER --> ENDPOINT HANDLERS --> PRE HANDLERS --> Endpoint * Server outbound messages Endpoint --> PRE HANDLER --> ENDPOINT HANDLERS --> POST HANDLERS --> ... --> Client
protocol-binding attribute can be used to set the protocols which the chain needs to be triggered for.
[standalone@localhost:9999 /] /subsystem=webservices/endpoint-config=Recording-Endpoint-Config/pre-handler-chain=recording-handlers:read-resource
{
"outcome" => "success",
"result" => {
"protocol-bindings" => "##SOAP11_HTTP ##SOAP11_HTTP_MTOM ##SOAP12_HTTP ##SOAP12_HTTP_MTOM",
"handler" => {"RecordingHandler" => undefined}
},
"response-headers" => {"process-state" => "restart-required"}
}
A new handler chain can be added as follows:
[standalone@localhost:9999 /] /subsystem=webservices/endpoint-config=My-Endpoint-Config/post-handler-chain=my-handlers:add(protocol-bindings="##SOAP11_HTTP")
{
"outcome" => "success",
"response-headers" => {
"operation-requires-restart" => true,
"process-state" => "restart-required"
}
}
[standalone@localhost:9999 /] /subsystem=webservices/endpoint-config=My-Endpoint-Config/post-handler-chain=my-handlers:read-resource
{
"outcome" => "success",
"result" => {
"handler" => undefined,
"protocol-bindings" => "##SOAP11_HTTP"
},
"response-headers" => {"process-state" => "restart-required"}
}
Handlers
JAXWS handler can be added in handler chains:
[standalone@localhost:9999 /] /subsystem=webservices/endpoint-config=Recording-Endpoint-Config/pre-handler-chain=recording-handlers/handler=RecordingHandler:read-resource
{
"outcome" => "success",
"result" => {"class" => "org.jboss.ws.common.invocation.RecordingServerHandler"},
"response-headers" => {"process-state" => "restart-required"}
}
[standalone@localhost:9999 /] /subsystem=webservices/endpoint-config=My-Endpoint-Config/post-handler-chain=my-handlers/handler=foo-handler:add(class="org.jboss.ws.common.invocation.RecordingServerHandler")
{
"outcome" => "success",
"response-headers" => {
"operation-requires-restart" => true,
"process-state" => "restart-required"
}
}
Endpoint-config handler classloading
The class attribute is to be used for providing the full class name of the handler. At deploy time, an instance of that class is created for each referencing deployment; for that to succeed, either the deployment classloader or the classloader for module org.jboss.as.webservices.server.integration need to be able to load the handler class.
Runtime information
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:
[standalone@localhost:9999 /] /deployment="*"/subsystem=webservices/endpoint="*":read-resource
{
"outcome" => "success",
"result" => [{
"address" => [
("deployment" => "jaxws-samples-handlerchain.war"),
("subsystem" => "webservices"),
("endpoint" => "jaxws-samples-handlerchain:TestService")
],
"outcome" => "success",
"result" => {
"class" => "org.jboss.test.ws.jaxws.samples.handlerchain.EndpointImpl",
"context" => "jaxws-samples-handlerchain",
"name" => "TestService",
"type" => "JAXWS_JSE",
"wsdl-url" => "http://localhost:8080/jaxws-samples-handlerchain?wsdl"
}
}]
}
Component Reference
The web service subsystem is provided by the JBossWS project. For a detailed description of the available configuration properties, please consult the project documentation.
-
JBossWS homepage: http://www.jboss.org/jbossws
-
Project Documentation: https://docs.jboss.org/author/display/JBWS
Logging
Overview
The overall server logging configuration is represented by the logging subsystem. It consists of four notable parts: handler configurations, logger, the root logger declarations (aka log categories) and logging profiles. Each logger does reference a handler (or set of handlers). Each handler declares the log format and output:
<subsystem xmlns="urn:jboss:domain:logging:1.0">
<console-handler name="CONSOLE" autoflush="true">
<level name="DEBUG"/>
<formatter>
<pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
</formatter>
</console-handler>
<periodic-rotating-file-handler name="FILE" autoflush="true">
<formatter>
<pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
</formatter>
<file relative-to="jboss.server.log.dir" path="server.log"/>
<suffix value=".yyyy-MM-dd"/>
</periodic-rotating-file-handler>
<logger category="com.arjuna">
<level name="WARN"/>
</logger>
[...]
<root-logger>
<level name="DEBUG"/>
<handlers>
<handler name="CONSOLE"/>
<handler name="FILE"/>
</handlers>
</root-logger>
</subsystem>
deployment Logging
Per-deployment logging allows you to add a logging configuration file to your deployment and have the logging for that deployment configured according to the configuration file. In an EAR the configuration should be in the META-INF directory. In a WAR or JAR deployment the configuration file can be in either the META-INF or WEB-INF/classes directories.
The following configuration files are allowed:
-
logging.properties
-
jboss-logging.properties
-
log4j.properties
-
log4j.xml
-
jboss-log4j.xml
You can also disable this functionality system wide by adding the -Dorg.jboss.as.logging.per-deployment=false system property.
Logging Profiles
Logging profiles are like additional logging subsystems. Each logging profile constists of three of the four notable parts listed above: handler configurations, logger and the root logger declarations.
You can assign a logging profile to a deployment via the deployments manifest. Add a Logging-Profile entry to the MANIFEST.MF file with a value of the logging profile id. For example a logging profile defined on /subsystem=logging/logging-profile=ejbs the MANIFEST.MF would look like:
Manifest-Version: 1.0 Logging-Profile: ejbs
A logging profile can be assigned to any number of deployments. Using a logging profile also allows for runtime changes to the configuration. This is an advantage over the per-deployment logging configuration as the redeploy is not required for logging changes to take affect.
Why is there a logging.properties file?
You may have noticed that there is a logging.properties file in the configuration directory. This is logging configuration is used when the server boots up until the logging subsystem kicks in. If the logging subsystem is not included in your configuration, then this would act as the logging configuration for the entire server.
In the future this file may go away or be automatically generated from the logging subsystem. For most users this file should not be modified.
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 |
Filter Expressions
|
Filter Type |
Expression |
Description |
Parameter(s) |
Examples |
|
accept |
accept |
Accepts all log messages. |
None |
accept |
|
deny |
deny |
enies all log messages. |
None |
deny |
|
not |
not(filterExpression) |
Accepts a filter as an argument and inverts the returned value. |
The expression takes a single filter for it's argument. |
not(match("JBAS")) |
|
all |
all(filterExpressions) |
A filter consisting of several filters in a chain. If any filter find the log message to be unloggable, the message will not be logged and subsequent filters will not be checked. |
The expression takes a comma delimited list of filters for it's argument. |
all(match("JBAS"), match("WELD")) |
|
any |
any(filterExpressions) |
A filter consisting of several filters in a chain. If any filter fins the log message to be loggable, the message will be logged and the subsequent filters will not be checked. |
The expression takes a comma delimited list of filters for it's argument. |
any(match("JBAS"), match("WELD")) |
|
levelChange |
levelChange(level) |
A filter which modifies the log record with a new level. |
The expression takes a single string based level for it's argument. |
levelChange(WARN) |
|
levels |
levels(levels) |
A filter which includes log messages with a level that is listed in the list of levels. |
The expression takes a comma delimited list of string based levels for it's argument. |
levels(DEBUG, INFO, WARN, ERROR) |
|
levelRange |
levelRange([minLevel,maxLevel]) |
A filter which logs records that are within the level range. |
The filter expression uses a "[" to indicate a minimum inclusive level and a "]" to indicate a maximum inclusive level. Otherwise use "(" or ")" respectively indicate exclusive. The first argument for the expression is the minimum level allowed, the second argument is the maximum level allowed. |
|
|
match |
match("pattern") |
A regular-expression based filter. The raw unformatted message is used against the pattern. |
The expression takes a regular expression for it's argument. match("JBAS\d+") |
|
|
substitute |
substitute("pattern", "replacement value") |
A filter which replaces the first match to the pattern with the replacement value. |
The first argument for the expression is the pattern the second argument is the replacement text. |
substitute("JBAS", "EAP") |
|
substituteAll |
substituteAll("pattern", "replacement value") |
A filter which replaces all matches of the pattern with the replacement value. |
The first argument for the expression is the pattern the second argument is the replacement text. |
substituteAll("JBAS", "EAP") |
Logging Subsystem Descriptions
async-handler
Defines a handler which writes to the sub-handlers in an asynchronous thread. Used for handlers which introduce a substantial amount of lag.
|
Attribute |
Description |
Type |
Allow Null |
Expression Allowed |
Access Type |
Restart Required |
Default Value |
Allowed Values |
|
enabled |
If set to true the handler is enabled and functioning as normal, if set to false the handler is ignored when processing log messages. |
BOOLEAN |
true |
true |
read-write |
no-services |
true |
Any |
|
overflow-action |
Specify what action to take when the overflowing. The valid options are 'block' and 'discard' |
STRING |
false |
true |
read-write |
no-services |
BLOCK |
|
|
formatter |
Defines a pattern for the formatter. |
STRING |
true |
true |
read-write |
no-services |
%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n |
Any |
|
filter-spec |
A filter expression value to define a filter. Example for a filter that does not match a pattern: not(match("JBAS.*")) |
STRING |
true |
true |
read-write |
no-services |
null |
|
|
level |
The log level specifying which message levels will be logged by this logger. Message levels lower than this value will be discarded. |
STRING |
true |
true |
read-write |
no-services |
ALL |
|
|
queue-length |
The queue length to use before flushing writing |
INT |
false |
true |
read-write |
resource-services |
null |
Any |
|
subhandlers |
The Handlers associated with this async handler. |
LIST |
true |
false |
read-write |
no-services |
null |
Any |
|
name |
The handler's name. |
STRING |
true |
false |
read-only |
|
null |
Any |
|
encoding |
The character encoding used by this Handler. |
STRING |
true |
true |
read-write |
no-services |
null |
Any |
console-handler
Defines a handler which writes to the console.
|
Attribute |
Description |
Type |
Allow Null |
Expression Allowed |
Access Type |
Restart Required |
Default Value |
Allowed Values |
|
formatter |
Defines a pattern for the formatter. |
STRING |
true |
true |
read-write |
no-services |
%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n |
Any |
|
enabled |
If set to true the handler is enabled and functioning as normal, if set to false the handler is ignored when processing log messages. |
BOOLEAN |
true |
true |
read-write |
no-services |
true |
Any |
|
filter-spec |
A filter expression value to define a filter. Example for a filter that does not match a pattern: not(match("JBAS.*")) |
STRING |
true |
true |
read-write |
no-services |
null |
|
|
level |
The log level specifying which message levels will be logged by this logger. Message levels lower than this value will be discarded. |
STRING |
true |
true |
read-write |
no-services |
ALL |
|
|
autoflush |
Automatically flush after each write. |
BOOLEAN |
true |
true |
read-write |
no-services |
true |
Any |
|
name |
The handler's name. |
STRING |
true |
false |
read-only |
|
null |
Any |
|
encoding |
The character encoding used by this Handler. |
STRING |
true |
true |
read-write |
no-services |
null |
Any |
|
target |
Defines the target of the console handler. The value can either be SYSTEM_OUT or SYSTEM_ERR. |
STRING |
true |
true |
read-write |
no-services |
System.out |
|
custom-handler
Defines a custom logging handler. The custom handler must extend java.util.logging.Handler.
|
Attribute |
Description |
Type |
Allow Null |
Expression Allowed |
Access Type |
Restart Required |
Default Value |
Allowed Values |
|
enabled |
If set to true the handler is enabled and functioning as normal, if set to false the handler is ignored when processing log messages. |
BOOLEAN |
true |
true |
read-write |
no-services |
true |
Any |
|
module |
The module that the logging handler depends on. |
STRING |
false |
false |
read-only |
|
null |
Any |
|
class |
The logging handler class to be used. |
STRING |
false |
false |
read-only |
|
null |
Any |
|
properties |
Defines the properties used for the logging handler. All properties must be accessible via a setter method. |
OBJECT |
true |
true |
read-write |
no-services |
null |
Any |
|
formatter |
Defines a pattern for the formatter. |
STRING |
true |
true |
read-write |
no-services |
%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n |
Any |
|
filter-spec |
A filter expression value to define a filter. Example for a filter that does not match a pattern: not(match("JBAS.*")) |
STRING |
true |
true |
read-write |
no-services |
null |
|
|
level |
The log level specifying which message levels will be logged by this logger. Message levels lower than this value will be discarded. |
STRING |
true |
true |
read-write |
no-services |
ALL |
|
|
name |
The handler's name. |
STRING |
true |
false |
read-only |
|
null |
Any |
|
encoding |
The character encoding used by this Handler. |
STRING |
true |
true |
read-write |
no-services |
null |
Any |
file-handler
Defines a handler which writes to a file.
|
Attribute |
Description |
Type |
Allow Null |
Expression Allowed |
Access Type |
Restart Required |
Default Value |
Allowed Values |
|
enabled |
If set to true the handler is enabled and functioning as normal, if set to false the handler is ignored when processing log messages. |
BOOLEAN |
true |
true |
read-write |
no-services |
true |
Any |
|
append |
Specify whether to append to the target file. |
BOOLEAN |
true |
true |
read-write |
resource-services |
true |
Any |
|
autoflush |
Automatically flush after each write. |
BOOLEAN |
true |
true |
read-write |
no-services |
true |
Any |
|
formatter |
Defines a pattern for the formatter. |
STRING |
true |
true |
read-write |
no-services |
%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n |
Any |
|
filter-spec |
A filter expression value to define a filter. Example for a filter that does not match a pattern: not(match("JBAS.*")) |
STRING |
true |
true |
read-write |
no-services |
null |
|
|
level |
The log level specifying which message levels will be logged by this logger. Message levels lower than this value will be discarded. |
STRING |
true |
true |
read-write |
no-services |
ALL |
|
|
file |
The file description consisting of the path and optional relative to path. |
OBJECT |
true |
false |
read-write |
no-services |
null |
Any |
|
name |
The handler's name. |
STRING |
true |
false |
read-only |
|
null |
Any |
|
encoding |
The character encoding used by this Handler. |
STRING |
true |
true |
read-write |
no-services |
null |
Any |
logger
Defines a logger category.
|
Attribute |
Description |
Type |
Allow Null |
Expression Allowed |
Access Type |
Restart Required |
Default Value |
Allowed Values |
|
filter-spec |
A filter expression value to define a filter. Example for a filter that does not match a pattern: not(match("JBAS.*")) |
STRING |
true |
true |
read-write |
no-services |
null |
|
|
level |
The log level specifying which message levels will be logged by this logger. Message levels lower than this value will be discarded. |
STRING |
true |
true |
read-write |
no-services |
ALL |
|
|
use-parent-handlers |
Specifies whether or not this logger should send its output to it's parent Logger. |
BOOLEAN |
true |
true |
read-write |
no-services |
true |
Any |
|
category |
Specifies the category for the logger. |
STRING |
true |
false |
read-only |
|
null |
Any |
|
handlers |
The Handlers associated with this Logger. |
LIST |
true |
false |
read-write |
no-services |
null |
Any |
periodic-rotating-file-handler
Defines a handler which writes to a file, rotating the log after a time period derived from the given suffix string, which should be in a format understood by java.text.SimpleDateFormat.
|
Attribute |
Description |
Type |
Allow Null |
Expression Allowed |
Access Type |
Restart Required |
Default Value |
Allowed Values |
|
enabled |
If set to true the handler is enabled and functioning as normal, if set to false the handler is ignored when processing log messages. |
BOOLEAN |
true |
true |
read-write |
no-services |
true |
Any |
|
append |
Specify whether to append to the target file. |
BOOLEAN |
true |
true |
read-write |
resource-services |
true |
Any |
|
autoflush |
Automatically flush after each write. |
BOOLEAN |
true |
true |
read-write |
no-services |
true |
Any |
|
suffix |
Set the suffix string. The string is in a format which can be understood by java.text.SimpleDateFormat. The period of the rotation is automatically calculated based on the suffix. |
STRING |
false |
true |
read-write |
no-services |
null |
Any |
|
formatter |
Defines a pattern for the formatter. |
STRING |
true |
true |
read-write |
no-services |
%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n |
Any |
|
filter-spec |
A filter expression value to define a filter. Example for a filter that does not match a pattern: not(match("JBAS.*")) |
STRING |
true |
true |
read-write |
no-services |
null |
|
|
level |
The log level specifying which message levels will be logged by this logger. Message levels lower than this value will be discarded. |
STRING |
true |
true |
read-write |
no-services |
ALL |
|
|
file |
The file description consisting of the path and optional relative to path. |
OBJECT |
true |
false |
read-write |
no-services |
null |
Any |
|
name |
The handler's name. |
STRING |
true |
false |
read-only |
|
null |
Any |
|
encoding |
The character encoding used by this Handler. |
STRING |
true |
true |
read-write |
no-services |
null |
Any |
root-logger
Defines the root logger for this log context.
|
Attribute |
Description |
Type |
Allow Null |
Expression Allowed |
Access Type |
Restart Required |
Default Value |
Allowed Values |
|
filter-spec |
A filter expression value to define a filter. Example for a filter that does not match a pattern: not(match("JBAS.*")) |
STRING |
true |
true |
read-write |
no-services |
null |
|
|
level |
The log level specifying which message levels will be logged by this logger. Message levels lower than this value will be discarded. |
STRING |
true |
true |
read-write |
no-services |
ALL |
|
|
handlers |
The Handlers associated with this Logger. |
LIST |
true |
false |
read-write |
no-services |
null |
Any |
size-rotating-file-handler
Defines a handler which writes to a file, rotating the log after a the size of the file grows beyond a certain point and keeping a fixed number of backups.
|
Attribute |
Description |
Type |
Allow Null |
Expression Allowed |
Access Type |
Restart Required |
Default Value |
Allowed Values |
|
enabled |
If set to true the handler is enabled and functioning as normal, if set to false the handler is ignored when processing log messages. |
BOOLEAN |
true |
true |
read-write |
no-services |
true |
Any |
|
append |
Specify whether to append to the target file. |
BOOLEAN |
true |
true |
read-write |
resource-services |
true |
Any |
|
autoflush |
Automatically flush after each write. |
BOOLEAN |
true |
true |
read-write |
no-services |
true |
Any |
|
rotate-size |
The size at which to rotate the log file. |
STRING |
false |
true |
read-write |
no-services |
2m |
Any |
|
formatter |
Defines a pattern for the formatter. |
STRING |
true |
true |
read-write |
no-services |
%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n |
Any |
|
filter-spec |
A filter expression value to define a filter. Example for a filter that does not match a pattern: not(match("JBAS.*")) |
STRING |
true |
true |
read-write |
no-services |
null |
|
|
level |
The log level specifying which message levels will be logged by this logger. Message levels lower than this value will be discarded. |
STRING |
true |
true |
read-write |
no-services |
ALL |
|
|
max-backup-index |
The maximum number of backups to keep. |
INT |
true |
true |
read-write |
no-services |
1 |
Any |
|
file |
The file description consisting of the path and optional relative to path. |
OBJECT |
true |
false |
read-write |
no-services |
null |
Any |
|
name |
The handler's name. |
STRING |
true |
false |
read-only |
|
null |
Any |
|
encoding |
The character encoding used by this Handler. |
STRING |
true |
true |
read-write |
no-services |
null |
Any |
syslog-handler
Defines a syslog handler.
|
Attribute |
Description |
Type |
Allow Null |
Expression Allowed |
Access Type |
Restart Required |
Default Value |
Allowed Values |
|
port |
The port the syslog server is listening on. |
INT |
true |
true |
read-write |
no-services |
514 |
Any |
|
app-name |
The app name used when formatting the message in RFC5424 format. By default the app name is "java". |
STRING |
true |
true |
read-write |
no-services |
null |
Any |
|
enabled |
If set to true the handler is enabled and functioning as normal, if set to false the handler is ignored when processing log messages. |
BOOLEAN |
true |
true |
read-write |
no-services |
true |
Any |
|
level |
The log level specifying which message levels will be logged by this logger. Message levels lower than this value will be discarded. |
STRING |
true |
true |
read-write |
no-services |
ALL |
|
|
facility |
STRING |
true |
true |
read-write |
no-services |
user-level |
|
|
|
server-address |
The address of the syslog server. |
STRING |
true |
true |
read-write |
no-services |
localhost |
Any |
|
hostname |
The name of the host the messages are being sent from. For example the name of the host the application server is running on. |
STRING |
true |
true |
read-write |
no-services |
null |
Any |
|
syslog-format |
Formats the log message according to the RFC specification. |
STRING |
true |
true |
read-write |
no-services |
RFC5424 |
|
|
name |
The handler's name |
STRING |
true |
false |
read-only |
|
null |
Any |
JMX
The JMX subsystem registers a service with the Remoting endpoint so that remote access to JMX can be obtained over the exposed Remoting connector.
This is switched on by default in standalone mode and accessible over port 9999 but in domain mode is switched off so needs to be enabled - in domain mode the port will be the port of the Remoting connector for the AS instance to be monitored.
To use the connector you can access it in the standard way using a service:jmx URL:
import javax.management.MBeanServerConnection;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;
public class JMXExample {
public static void main(String[] args) throws Exception {
//Get a connection to the JBoss AS MBean server on localhost
String host = "localhost";
int port = 9999; // management-native port
String urlString =
System.getProperty("jmx.service.url","service:jmx:remoting-jmx://" + host + ":" + port);
JMXServiceURL serviceURL = new JMXServiceURL(urlString);
JMXConnector jmxConnector = JMXConnectorFactory.connect(serviceURL, null);
MBeanServerConnection connection = jmxConnector.getMBeanServerConnection();
//Invoke on the JBoss AS MBean server
int count = connection.getMBeanCount();
System.out.println(count);
jmxConnector.close();
}
}
You also need to set your classpath when running the above example. The following script covers Linux. If your environment is much different, paste your script when you have it working.
!/bin/bash
# specify your AS7 folder
export YOUR_AS7_HOME=~/as7
java -classpath $YOUR_AS7_HOME/bin/client/jboss-client.jar:./ JMXExample
You can also connect using jconsole.
If using jconsole use the jconsole.sh and jconsole.bat scripts included in the bin folder of the AS distribution as these set the classpath as required to connect over Remoting.
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
OSGi functionality in JBoss AS 7 is provided through the OSGi subsystem.
The documentation of this functionality can be found at the JBoss OSGi documentation pages.
Integration with AS 7 and reference the the OSGi subsystem in the AS 7 XML configuration file can be found in the Application Server Integration section.
More information on the OSGi component in JBoss AS 7 can be found on the JBoss OSGi project pages.
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:
<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.0">
<deployment-scanner scan-interval="5000"
relative-to="jboss.server.base.dir" path="deployments" />
</subsystem>
You can define more deployment-scanner entries 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:
[standalone@localhost:9999 /] /subsystem=deployment-scanner:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {"scanner" => {"default" => {
"auto-deploy-exploded" => false,
"auto-deploy-zipped" => true,
"deployment-timeout" => 60L,
"name" => "default",
"path" => "deployments",
"relative-to" => "jboss.server.base.dir",
"scan-enabled" => true,
"scan-interval" => 5000
}}}
}
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
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=new:add(scan-interval=10000,relative-to="jboss.server.base.dir",path="other-deployments")
{"outcome" => "success"}
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=new:remove
{"outcome" => "success"}
You can also change the attributes at runtime, so for example to turn off scanning you can do
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:write-attribute(name="scan-enabled",value=false)
{"outcome" => "success"}
[standalone@localhost:9999 /] /subsystem=deployment-scanner:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {"scanner" => {"default" => {
"auto-deploy-exploded" => false,
"auto-deploy-zipped" => true,
"deployment-timeout" => 60L,
"name" => "default",
"path" => "deployments",
"relative-to" => "jboss.server.base.dir",
"scan-enabled" => false,
"scan-interval" => 5000
}}}
}
Simple configuration subsystems
The following subsystems currently have no configuration beyond its root element in the configuration
<subsystem xmlns="urn:jboss:domain:ee:1.0"/> <subsystem xmlns="urn:jboss:domain:ejb3:1.0"/> <subsystem xmlns="urn:jboss:domain:jaxrs:1.0"/> <subsystem xmlns="urn:jboss:domain:remoting:1.0"/> <subsystem xmlns="urn:jboss:domain:sar:1.0"/> <subsystem xmlns="urn:jboss:domain:threads:1.0"/> <subsystem xmlns="urn:jboss:domain:weld:1.0"/>
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 |