[
"<p>The batch subsystem is used to configure an environment for running batch applications.</p>\n<p>${build.fullName} uses\n    <a href=\"https://github.com/jberet/jsr352\" rel=\"nofollow\" target=\"_blank\">JBeret</a> for its batch implementation. Specific information about JBeret can be found in the\n    <a href=\"http://jberet.gitbooks.io/jberet-user-guide/content/\" rel=\"nofollow\" target=\"_blank\">user guide</a>.</p>\n",
"<p>Bean Validation is a Java specification which</p>\n<ul>\n    <li>lets you express constraints on object models via annotations</li>\n    <li>lets you write custom constraints in an extensible way</li>\n    <li>provides the APIs to validate objects and object graphs</li>\n    <li>provides the APIs to validate parameters and return values of methods and constructors</li>\n    <li>reports the set of violations (localized)</li>\n    <li>runs in Java SE but is integrated in Java EE (6 and 7; Bean Validation 2.0 is planned to be part of Java EE 8)</li>\n</ul>\n<p>${build.fullName} uses <a href=\"http://hibernate.org/validator/\" rel=\"nofollow\" target=\"_blank\">Hibernate Validator</a> for its batch implementation.</p>\n",
"<p>The two general types of resources are referred to as datasources and XA datasources.</p>\n<ul>\n    <li><strong>Non-XA datasources</strong> are used for applications which do not use transactions, or applications which use transactions with a single database.</li>\n    <li><strong>XA datasources</strong> are used by applications whose transactions are distributed across multiple databases. XA datasources introduce additional overhead.</li>\n</ul>\n",
"<p>The datasource subsystem allows you to create and configure datasources and manage JDBC database drivers.</p>\n<h2>Datasources</h2>\n<p>The two general types of resources are referred to as datasources and XA datasources.</p>\n<ul>\n    <li><strong>Non-XA datasources</strong> are used for applications which do not use transactions, or applications which use transactions with a single database.</li>\n    <li><strong>XA datasources</strong> are used by applications whose transactions are distributed across multiple databases. XA datasources introduce additional overhead.</li>\n</ul>\n<h2>JDBC Drivers</h2>\n<p>Before your application can connect to a datasource, your datasource vendor's JDBC drivers need to be installed. You can choose between two different ways to install JDBC drivers:</p>\n<dl>\n    <dt>Modules</dt>\n    <dd><p>To install a JDBC driver as a module you need to create a file path structure under the\n        <code>${build.installDir}/modules</code>, copy the JDBC driver JAR into the\n        <code>main/</code> subdirectory and create a <code>module.xml</code> file.</p>\n        <p>Once the JDBC driver is available as a module you can use this section to add and remove driver configurations.</p>\n    </dd>\n\n    <dt>Deployments</dt>\n    <dd>\n        <p>You can deploy JDBC drivers just like any other deployment. This means that you can deploy them across multiple servers in a server group, if you use a managed domain. Any JDBC 4-compliant driver will automatically be recognized and installed into the system by name and version.</p>\n        <p>In domain mode drivers deployed as applications will only show up in this section if there are running servers which match the selected profile.</p>\n    </dd>\n</dl>\n",
"<p>The deployment scanner is only used in standalone mode. Its job is to monitor a directory for new files and to deploy those files.</p>\n<p>You can define more deployment-scanner entries to scan for deployments from more locations. </p>\n",
"<p>The distributable-web subsystem manages a set of session management profiles that encapsulate the configuration of a distributable session manager. One of these profiles will be designated as the default profile (via the \"default-session-management\" attribute) and thus defines the default behavior of a distributable web application.</p>\n<p>The default session management stores web session data within an Infinispan cache.</p>\n",
"<p>The overall system configuration. Gives access to the main configuration profiles that can be applied to server groups.</p>\n\n<p>View and modify the configuration for each available <strong>subsystem</strong>. For example, add a datasource, configure a messaging provider, or set up application security.</p>\n\n<p>Related Links</p>\n<ul>\n    <li><a href=\"#runtime\">Domain Runtime</a></li>\n</ul>",
"<p>The EE subsystem provides common functionality in the Java EE platform, such as the EE Concurrency Utilities (JSR 236) and <code>@Resource</code> injection. The subsystem is also responsible for managing the lifecycle of Java EE application's deployments, that is, .ear files.</p>\n<p>The EE subsystem configuration may be used to:</p>\n<ul>\n    <li>Allows the customisation of the deployment behaviour for Java EE Applications.</li>\n    <li>Manage Global modules: a set of JBoss Modules that will be added as dependencies to the JBoss Module of every Java EE deployment. Such dependencies allows Java EE deployments to see the classes exported by the global modules.</li>\n    <li>Manage EE Concurrency Utilities (JSR 236): It was introduced with Java EE 7, to ease the task of writing multithreaded Java EE applications. Instances of these utilities are managed by ${build.fullName}, and the related configuration provided by the EE subsystem.</li>\n</ul>",
"<p>Enterprise beans are server-side application components as defined in the Enterprise JavaBeans (EJB) 3.1 specification, JSR-318. Enterprise beans are designed for the implementation of application business logic in a decoupled manner to encourage reuse.\n    Enterprise beans are written as Java classes and annotated with the appropriate EJB annotations. They can be deployed to the application server in their own archive (a JAR file) or be deployed as part of a Java EE application. The application server manages the lifecycle of each enterprise bean and provides services to them such as security, transactions, and concurrency management.\n    An enterprise bean can also define any number of business interfaces. Business interfaces provide greater control over which of the bean's methods are available to clients and can also allow access to clients running in remote JVMs.\n    There are three types of Enterprise Bean: Session beans, Message-driven beans and Entity beans.</p>\n\n<h2>Session Beans</h2>\n<p>Session Beans are Enterprise Beans that encapsulate a set of related business processes or tasks and are injected into the classes that request them. There are three types of session bean: stateless, stateful, and singleton.</p>\n\n<h2>Message-Driven Beans</h2>\n<p>Message-driven Beans (MDBs) provide an event driven model for application development. The methods of MDBs are not injected into or invoked from client code but are triggered by the receipt of messages from a messaging service such as a Java Messaging Service (JMS) server. The Java EE 6 specification requires that JMS is supported but other messaging systems can be supported as well.</p>\n\n<h2>Entity Beans</h2>\n<p>Entity beans are now deprecated in EJB 3.1 and it's recommended the use of JPA entities instead. Entity beans should only be used for backwards compatibility with legacy systems.</p>",
"<h2>Factories</h2>\n<p>An authentication factory is an authentication policy used for specific authentication mechanisms. Authenticaion factories are specifically based on the authentication mechanism, for example http-authentication-factory and sasl-authentication-factory and kerberos-security-factory.</p>\n<h2>Principal Transformers</h2>\n<p>A principal transformer can be used in multiple locations within the elytron subsystem. A principal transformer can transform or map a name to another name.</p>\n",
"<h2>Role Mappers</h2>\n<p>A role mapper applies a role modification to an identity. This can range from normalizing the format of the roles to adding or removing specific roles. A role mapper can be associated with both security realms as well as security domains.</p>\n<h2>Permission Mappers</h2>\n<p>A permission mapper is associated with a security domain and assigns a set of permissions to a SecurityIdentity.</p>\n<h2>Principal Decoders</h2>\n<p>A principal decoder can be used in multiple locations within the elytron subsystem. A principal decoder converts an identity from a Principal to a string representation of the name. For example, the X500PrincipalDecoder allows you to convert an X500Principal from a certificate’s distinguished name to a string representation.</p>\n<h2>Role Decoders</h2>\n<p>A role decoder is associated with a security domain and is used to decode the current user’s roles. The role decoder takes the raw AuthorizationIdentity returned from the security realm and converts its attributes into roles. </p>\n\n",
"<p>This section comprises several resources as explained below:</p>\n<h2>Authentication Configuration</h2>\n<p>An individual authentication configuration definition, which is used by clients deployed to ${build.fullName} and other resources for authenticating when making a remote connection.</p>\n<h2>Authentication Context</h2>\n<p>An individual authentication context definition, which is used to supply an ssl-context and authentication-configuration when clients deployed to ${build.shortName} and other resources make a remoting connection. </p>\n<h2>Stores</h2>\n<p>Key Store: is the definition of a keystore or truststore including the type of keystore, its location, and credential for accessing it. Credential store to keep alias for sensitive information such as passwords for external services. </p>\n<h2>SSL</h2>\n<p>Configure the client and server side of SSL connections. A key manager definition for creating the key manager list as used to create an SSL context. Other resources available: Security property, Provider loader, Aggregate providers.</p>\n<h2>Security Domains</h2>\n<p>A security domain is the representation of a security policy which is backed by one or more security realms and a set of resources that perform transformations.</p>\n<h2>Logs</h2>\n<p>Audit loggers that persists on files and syslog.</p>\n",
"<h2>Security Realms</h2>\n<p>Security realms provide access to an identity store and are used to obtain credentials. These credentials allow authentication mechanisms to obtain the raw AuthorizationIdentity for performing authentication.</p>\n<h2>Realm Mappers</h2>\n<p>A realm mapper is associated with a security domain and is used in cases where a security domain has multiple security realms configured. The realm mapper uses the name provided during authentication to choose a security realm for authentication.</p>\n",
"<p>Common Object Request Broker Architecture (CORBA) is a standard that enables applications and services to work together even when they are written in multiple, otherwise-incompatible, languages or hosted on separate platforms. CORBA requests are brokered by a server-side component called an Object Request Broker (ORB). ${build.shortName} provides an ORB instance, by means of the Open JDK ORB component.</p>\n",
"<p>Infinispan is a Java data grid platform. It provides a\n    <a href=\"http://www.jcp.org/en/jsr/detail?id=107\">JSR-107</a> compatible cache interface for managing cached data.\n</p>\n<p>The following Infinispan cache containers are used in ${build.fullName}:</p>\n<ul>\n    <li><code>web</code> for Web Session Clustering</li>\n    <li><code>ejb</code> for Stateful Session Bean Clustering</li>\n    <li><code>hibernate</code> for Entity Caching</li>\n    <li><code>singleton</code> for Singleton Caching</li>\n</ul>\n<p>Each cache container defines a \"repl\" and a \"dist\" cache. These caches should not be used directly by user applications.</p>\n\n<p>For more information about Infinispan functionality and configuration options see the\n    <a href=\"http://infinispan.org/docs/5.3.x/index.html\">Infinispan Documentation</a>.</p>\n\n<h2>Clustering Modes</h2>\n<p>Clustering can be configured in two different ways in ${build.shortName} using Infinispan. The correct method for your application will depend on your requirements. There is a trade off between availability, consistency, reliability and scalability with each mode. Before choosing a clustering mode, you must identify what are the most important features of your network for you, and balance those requirements.</p>\n\n<h3>Replication Mode</h3>\n<p>Replicated Mode automatically detects and adds new instances on the cluster. Changes made to these instances will be replicated to all nodes on the cluster. Replicated mode typically works best in small clusters because of the amount of information that has to be replicated over the network. Infinispan can be configured to use UDP multicast, which alleviates network traffic congestion to a degree.</p>\n\n<h3>Distribution Mode</h3>\n<p>Distribution mode allows Infinispan to scale the cluster linearly. Distribution mode uses a consistent hash algorithm to determine where in a cluster a new node should be placed. The number of copies of information to be kept is configurable. There is a trade off between the number of copies kept, durability of the data and performance: the more copies that are kept, the more impact on performance, but the less likely you are to lose data in a server failure. The hash algorithm also works to reduce network traffic by locating entries without multicasting or storing metadata.\n</p>\n<p>One should consider using Distribution (dist) mode as a caching strategy when the cluster size exceeds 6-8 nodes. With Distribution mode, data is distributed to only a subset of nodes within the cluster, as opposed to all nodes (default Replicated mode).\n</p>\n\n<h3>Synchronous and Asynchronous Replication</h3>\n<p>Replication can be performed either in synchronous or asynchronous mode, and the mode chosen depends on your requirements and your application. With synchronous replication, the thread that handles the user request is blocked until replication has been successful. Only when the replication is successful, a response is sent back to the client and the thread is released. Synchronous replication has an impact on network traffic because it requires a response from each node in the cluster. It has the advantage, however, of ensuring that all modifications have been made to all nodes in the cluster.</p>\n<p>Asynchronous replication is carried out in the background. Infinispan implements a replication queue, which is used by a background thread to carry out replication. Replication is triggered either on a time basis, or on the queue size. A replication queue allows increased performance because there is no conversation being carried out between the cluster nodes. The trade off with asynchronous replication is that it is not quite so accurate. Failed replication attempts are written to a log, not notified in real time.</p>\n\n<h2>Cache Container</h2>\n<p>A cache container is repository for the caches used by a subsystem. For Infinispan default cache containers are defined in the configuration xml files. One cache is defined as the default cache, which is the cache that will be used for clustering.</p>\n",
"<p>A logical name for a network interface / IP address / host name to which sockets can be bound. The <code>domain.xml</code>, <code>host.xml</code> and <code>standalone.xml</code> configurations all include a section where interfaces can be declared. Other sections of the configuration can then reference those interfaces by their logical name, rather than having to include the full details of the interface (which may vary on different machines).</p>\n\n<p>An interface configuration includes the logical name of the interface as well as information specifying the criteria to use for resolving the actual physical address to use.</p>",
"<p>The IO subsystem defines the XNIO workers and buffer pools used by other subsystems, such as Undertow and Remoting.</p>\n<h2>Worker</h2>\n<p>Workers are XNIO worker instances. An XNIO worker instance is an abstraction layer for the Java NIO APIs, which provide functionality such as management of IO and worker threads as well as SSL support. By default, ${build.shortName} provides single worker called\n    <code>default</code>, but more can be defined.</p>\n<h2>Buffer Pool</h2>\n<p>Buffer Pools are pooled NIO buffer instances.</p>\n<p><strong>Important:</strong><br/>\n    Changing the buffer size has a big impact on application performance. For most servers, the ideal size is usually 16k.\n</p>",
"<p>The JAX-RS subsystem is used to enable the deployment and functionality of JAX-RS applications.</p>\n<p>${build.fullName} uses\n    <a href=\"http://resteasy.jboss.org/\" rel=\"nofollow\" target=\"_blank\">RESTEasy</a> for its JAX-RS implementation.</p>",
"<p>The Java EE Connector Architecture (JCA) defines a standard architecture for Java EE systems to external heterogeneous Enterprise Information Systems (EIS). Examples of EISs include Enterprise Resource Planning (ERP) systems, mainframe transaction processing (TP), databases, and messaging systems. A resource adapter is a component that implements the Java EE Connector API architecture.</p>\n<p>JCA 1.7 provides features for managing:</p>\n<ul>\n    <li>connections</li>\n    <li>transactions</li>\n    <li>security</li>\n    <li>life-cycle</li>\n    <li>work instances</li>\n    <li>transaction inflow</li>\n    <li>message inflow</li>\n</ul>\n<p>JCA 1.7 was developed under the Java Community Process as\n    <a href=\"https://www.jcp.org/en/jsr/detail?id=322\" rel=\"nofollow\" target=\"_blank\">JSR-322</a>.</p>\n\n<h2>Resource Adapters</h2>\n<p>A resource adapter is a deployable Java EE component that provides communication between a Java EE application and an Enterprise Information System (EIS) using the Java Connector Architecture (JCA) specification. A resource adapter is often provided by EIS vendors to allow easy integration of their products with Java EE applications.</p>\n<p>An Enterprise Information System can be any other software system within an organization. Examples include Enterprise Resource Planning (ERP) systems, database systems, e-mail servers and proprietary messaging systems.</p>\n<p>A resource adapter is packaged in a Resource Adapter Archive (RAR) file which can be deployed to ${build.shortName}. A RAR file may also be included in an Enterprise Archive (EAR) deployment.</p>\n",
"<p>Before your application can connect to a datasource, your datasource vendor's JDBC drivers need to be installed. You can choose between two different ways to install JDBC drivers:</p>\n<dl>\n    <dt>Modules</dt>\n    <dd><p>To install a JDBC driver as a module you need to create a file path structure under the\n        <code>${build.installDir}/modules</code>, copy the JDBC driver JAR into the\n        <code>main/</code> subdirectory and create a <code>module.xml</code> file.</p>\n        <p>Once the JDBC driver is available as a module you can use this section to add, modify and remove driver configurations.</p>\n    </dd>\n\n    <dt>Deployments</dt>\n    <dd>\n        <p>You can deploy JDBC drivers just like any other deployment. This means that you can deploy them across multiple servers in a server group, if you use a managed domain. Any JDBC 4-compliant driver will automatically be recognized and installed into the system by name and version.</p>\n        <p>In domain mode drivers deployed as applications will only show up in this section if there are running servers which match the selected profile.</p>\n    </dd>\n</dl>\n",
"<p>Enable the gathering of diagnostic data to aid in troubleshooting. ${build.shortName} subscribers can provide this information to Red Hat when requesting support.</p>",
"<p>JGroups is a toolkit for reliable messaging and can be used to create clusters whose nodes can send messages to each other.</p>\n<p>The\n    <code>jgroups</code> subsystem provides group communication support for high availability services in ${build.shortName}. It allows you to configure named channels and protocol stacks as well as view runtime statistics for channels. The\n    <code>jgroups</code> subsystem is available when using a configuration that provides high availability capabilities, such as the\n    <i>ha</i> or <i>full-ha</i> profile in a managed domain, or the <code>standalone-ha.xml</code> or\n    <code>standalone-full-ha.xml</code> configuration file for a standalone server.</p>\n<p>${build.shortName} is preconfigured with two JGroups stacks:</p>\n<dl>\n    <dt>udp</dt>\n    <dd>The nodes in the cluster use User Datagram Protocol (UDP) multicasting to communicate with each other. This is the default stack.</dd>\n    <dt>tcp</dt>\n    <dd>The nodes in the cluster use Transmission Control Protocol (TCP) to communicate with each other.</dd>\n</dl>\n<p>You can use the preconfigured stacks or define your own to suit your system’s specific requirements.</p>\n<p><strong>Note:</strong><br/>\n    TCP has more overhead and is often considered slower than UDP since it handles error checking, packet ordering, and congestion control itself. JGroups handles these features for UDP, whereas TCP guarantees them itself. TCP is a good choice when using JGroups on unreliable or high congestion networks, or when multicast is not available.\n</p>\n",
"<p>Configure remote Java Management Extensions (JMX) access.</p>\n<p>The JMX subsystem registers a service with the Remoting endpoint so that remote access to JMX can be obtained over the exposed Remoting connector.</p>\n<p>This is switched on by default in standalone mode and accessible over port 9990 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 ${build.fullName} instance to be monitored.</p>\n",
"<p>Manages the Java Persistence API (JPA) 2.1 container-managed requirements and allows you to deploy persistent unit definitions, annotations, and descriptors.</p>\n<p>The Java Persistence API (JPA) is a Java specification for accessing, persisting, and managing data between Java objects or classes and a relational database. The JPA specification recognizes the interest and the success of the transparent object or relational mapping paradigm. It standardizes the basic APIs and the metadata needed for any object or relational persistence mechanism.</p>",
"<p>Manage JavaServer Faces (JSF) implementations.</p>",
"<p>Provide Java EE management capabilities defined by the\n    <a href=\"https://jcp.org/en/jsr/detail?id=77\" rel=\"nofollow\" target=\"_blank\">JSR-77</a> specification.</p>",
"<p>The logging subsystem provides highly configurable logging facilities for both its own internal use and for use by deployed applications. It's based on JBoss LogManager and it supports several third party application logging frameworks in addition to JBoss Logging.</p>\n\n<p>The logging subsystem is configured using a system of log categories and log handlers. Log categories define what messages to capture, and log handlers define how to deal with those messages (write to disk, send to console etc).</p>\n\n<p>Logging Profiles allow uniquely named sets of logging configuration to be created and assigned to applications independent of any other logging configuration. The configuration of logging profiles is almost identical to the main logging subsystem.</p>",
"<p>The logging subsystem is configured using a system of log categories and log handlers. Log categories define what messages to capture, and log handlers define how to deal with those messages (write to disk, send to console etc).</p>\n",
"<p>Logging Profiles allow uniquely named sets of logging configuration to be created and assigned to applications independent of any other logging configuration. The configuration of logging profiles is almost identical to the main logging subsystem.</p>",
"<p>The Mail subsystem allows you to configure separate mail settings, that is named mail-session. A mail session can have only three types of servers: IMAP, POP, SMTP.</p>\n<p>Each service references an existing outbound socket binding <code>outbound-socket-binding</code> (see <a href=\"#configuration;path=configuration%255C2socket-bindings\">Socket Binding Groups</a>).</p>\n",
"<h2>Apache ActiveMQ Artemis</h2>\n<p>Apache ActiveMQ Artemis is an open source project for an asynchronous messaging system. It is high performance, embeddable, clustered and supports multiple protocols. ${build.shortName} uses Apache ActiveMQ Artemis as its JMS broker and is configured using the messaging-activemq subsystem. This fully replaces the HornetQ broker but retains protocol compatibility with previous versions.</p>\n\nThe core ActiveMQ Artemis is JMS-agnostic and provides a non-JMS API, which is referred to as the core API. ActiveMQ Artemis also provides a JMS client API which uses a facade layer to implement the JMS semantics on top of the core API. Essentially, JMS interactions are translated into core API operations on the client side using the JMS client API. From there, all operations are sent using the core client API and Apache ActiveMQ Artemis wire format. The server itself only uses the core API. For more details on the core API and its concepts, refer to the\n<a target=\"_blank\" href=http://activemq.apache.org/artemis/docs/1.1.0/using-core.html\">ActiveMQ Artemis documentation</a>.\n",
"<p>${build.shortName} messaging clusters allow groups of ${build.shortName} messaging servers to be grouped together in order to share message processing load. Each active node in the cluster is an active ${build.shortName} messaging server which manages its own messages and handles its own connections.</p>\n\n<p>The cluster is formed by each node declaring cluster connections to other nodes in the ${build.shortName} configuration file. When a node forms a cluster connection to another node, it internally creates a core api connection between itself and the other node. This is done transparently behind the scenes; you do not have to declare an explicit api for each node. These cluster connections allow messages to flow between the nodes of the cluster to balance the load.</p>\n\n<p>For a complete documentation about clustering, see\n    <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/paged/configuring-messaging/chapter-28-clusters-overview\">Clusters Overview</a>.\n</p>\n\n<p>This section contains the configuration for the following topics:</p>\n<ul>\n    <li>Broadcast Groups</li>\n    <li>Discovery Groups</li>\n    <li>Cluster Connections</li>\n    <li>Grouping Handlers</li>\n    <li>Core Bridges</li>\n</ul>\n\n<h2>Broadcast Groups</h2>\n<p>A broadcast group is the means by which a server broadcasts connectors over the network. A connector defines a way in which a client, or other server, can make connections to the server.</p>\n\n<p>The broadcast group takes a set of connectors and broadcasts them on the network. Depending on which broadcasting technique you configure the cluster, it uses either UDP or JGroups to broadcast connector pairs information.</p>\n\n<p>Broadcast groups are defined in the messaging-activemq subsystem of the server configuration. There can be many broadcast groups per ${build.shortName} messaging server.</p>\n\n<h2>Discovery Groups</h2>\n<p>While the broadcast group defines how connector information is broadcasted from a server, a discovery group defines how connector information is received from a broadcast endpoint, for example, a UDP multicast address or JGroup channel.</p>\n\n<p>A discovery group maintains a list of connectors, one for each broadcast by a different server. As it receives broadcasts on the broadcast endpoint from a particular server, it updates its entry in the list for that server. If it has not received a broadcast from a particular server for a length of time it will remove that server’s entry from its list.</p>\n\n<h2>Cluster Connections</h2>\n<p>Cluster connections group servers into clusters so that messages can be load balanced between the nodes of the cluster. Cluster connections are defined in the ${build.shortName} server configuration using the\n    <code>cluster-connection</code> element. There can be zero or more cluster connections defined per ${build.shortName} messaging server.\n</p>\n\n<h2>Grouping Handlers</h2>\n<p>In a cluster, message groups with specific group ids can arrive on any of the nodes. It is important for a node to determine which group ids are bound to which consumer on which node. Each node is responsible for routing message groups correctly to the node which has the consumer processing those group ids, irrespective of where the message groups arrive by default. Once messages with a given group id are sent to a specific consumer connected to the given node in the cluster, then those messages are never sent to another node even if the consumer is disconnected.</p>\n\n<p>This situation is addressed by a grouping handler. Each node has a grouping handler and this grouping handler (along with other handlers) is responsible for routing the message groups to the correct node.</p>\n\n<h2>Core Bridges</h2>\n<p>The function of a api is to consume messages from one destination and forward them to another one, typically on a different ${build.shortName} messaging server.</p>\n\n<p>The source and target servers do not have to be in the same cluster which makes bridging suitable for reliably sending messages from one cluster to another, for instance across a WAN, or internet and where the connection may be unreliable.</p>\n\n<p>The api has built-in resilience to failure so if the target server connection is lost, for example, due to network failure, the api will retry connecting to the target until it comes back online. When it comes back online it will resume operation as normal.</p>\n\n<p>Bridges are a way to reliably connect two separate ${build.shortName} messaging servers together. With a core api both source and target servers must be ${build.shortName} messaging servers.</p>\n",
"<p>Contains the configuration for the following topics:</p>\n<ul>\n    <li>Acceptors & Connectors</li>\n    <li>Connector Services</li>\n    <li>(Pooled) Connection Factories</li>\n</ul>\n\n<h2>Acceptors & Connectors</h2>\n<p>An acceptor defines which types of connection are accepted by the ${build.shortName} embedded messaging server. You can define any number of acceptors per server.</p>\n\n<p>A connector defines how to connect to an embedded ${build.shortName} messaging server, and is used by a client to make connections.</p>\n\n<p>For more information about acceptors and connectors, see the\n    <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/paged/configuring-messaging/chapter-8-configuring-the-messaging-transports\">Acceptors and Connectors section</a>.\n</p>\n\n<h2>Connector Services</h2>\n<p>A connector service allows to integrate external components with Apache ActiveMQ Artemis to send and receive messages.</p>\n\n<h2>Connection Factories</h2>\n<p>By default, the ${build.shortName} messaging subsystem provides the <code>InVmConnectionFactory</code> and\n    <code>RemoteConnectionFactory</code> connection factories, as well as the\n    <code>activemq-ra</code> pooled connection factory.</p>\n\n<p><code>InVmConnectionFactory</code> references an\n    <code>in-vm-connector</code> and can be used to send and receive messages when both the client and server are running in the same JVM.\n    <code>RemoteConnectionFactory</code> references an\n    <code>http-connector</code> and can be used to send and receive messages over HTTP when the client and server are running in different JVMs.\n</p>\n\n<p>Pooled connection factories allow you to configure the inbound and outbound connectors of the integrated ActiveMQ Artemis resource adapter. For more information on configuring a pooled-connection-factory to connect to a remote ActiveMQ Artemis server, see\n    <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html/configuring_messaging/resource_adapters#use_provided_amq_adapter\">Using the Integrated Resource Adapter for Remote Connections</a>.\n</p>\n",
"<p>Contains the configuration for the following topics:</p>\n<ul>\n    <li>Core Queues</li>\n    <li>JMS Destinations</li>\n    <li>Security Settings</li>\n    <li>Address Settings</li>\n    <li>Diverts</li>\n</ul>\n\n<h2>Core Queues</h2>\n<p>Apache ActiveMQ Artemis core is JMS-agnostic. It does not have any concept of a JMS topic. A JMS topic is implemented in core as an address (the topic name) with zero or more queues bound to it. Each queue bound to that address represents a topic subscription. Likewise, a JMS queue is implemented as an address (the JMS queue name) with one single queue bound to it which represents the JMS queue.</p>\n\n<p>By convention, all JMS queues map to core queues where the core queue name has the string \"jms.queue.\" prepended to it. E.g. the JMS queue with the name \"orders.europe\" would map to the core queue with the name \"jms.queue.orders.europe\". The address at which the core queue is bound is also given by the core queue name.</p>\n\n<p>For JMS topics the address at which the queues that represent the subscriptions are bound is given by prepending the string \"jms.topic.\" to the name of the JMS topic. E.g. the JMS topic with name \"news.europe\" would map to the core address \"jms.topic.news.europe\"</p>\n\n<h2>JMS Destinations</h2>\n<p>JMS destinations, along with JMS connection factories, are JMS administrative objects. Destinations are used by JMS clients for both producing and consuming messages. The destination allows the JMS client to specify the target when it produces messages and the source of messages when consuming messages. When using a publish-subscribe pattern, destinations are referred to as topics. When using a point-to-point pattern, destinations are referred to as queues.</p>\n\n<p>Applications may use many different JMS destinations which are configured on the server side and usually accessed via JNDI.</p>\n\n<h2>Security Settings</h2>\n<p>Security settings are used to configure security around specific destinations. This is done by adding a security constraint using the security-setting configuration element. ${build.shortName} messaging comes with a\n    <code>security-setting</code> configured by default.</p>\n\n<p>The security-setting option makes use of wildcards to handle which destinations to apply the security constraint. The value of a single\n    <code>#</code> patterm will match any address. For more information on using wildcards in security constraints, see\n    <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/paged/configuring-messaging/chapter-7-configuring-security#role_based_security_for_address\">Role Based Security for Addresses</a>.\n</p>\n\n<h2>Address Settings</h2>\n<p>The messaging-activemq subsystem has several configurable options which control aspects of how and when a message is delivered, how many attempts should be made, and when the message expires. These configuration options all exist within the\n    <code>&lt;address-setting&gt;</code> configuration element. You can have ${build.shortName} apply a single\n    <code>&lt;address-setting&gt;</code> to multiple destinations by using a wildcard syntax.</p>\n\n<p>For more information on using wildcards in address settings, see\n    <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/paged/configuring-messaging/chapter-6-address-settings\">Wildcard Syntax</a>.\n</p>\n\n<h2>Diverts</h2>\n<p>Diverts are objects configured in ${build.shortName} messaging that help in diverting messages from one address to another. Diverts can be classified into the following types:\n\n<dl>\n    <dt>Exclusive</dt>\n    <dd>A message is only diverted to a new address and never sent to the old address.</dd>\n    <dt>Non-exclusive</dt>\n    <dd>A message is sent the old address, and a copy of it is also sent to the new address. Non-exclusive diverts can be used for splitting the flow of messages.</dd>\n</dl>\n\n<p>A divert will only divert a message to an address on the same server. If you want to divert to an address on a different server, a common pattern would be to divert to a local store-and-forward queue, then set up a api that consumes from that queue and forwards to an address on a different server.</p>",
"<p>High availability is the ability for the system to continue functioning after failure of one or more of the servers.</p>\n\n<p>A part of high availability is failover which is the ability for client connections to migrate from one server to another in event of server failure so client applications can continue to operate.</p>\n\n<p><strong>Note</strong><br/> Only persistent message data will survive failover. Any non persistent message data will not be available after failover.</p>\n\n<h2>Live / Backup Pairs</h2>\n<p>${build.shortName} messaging allows servers to be linked together as live - backup pairs where each live server has a backup. Live servers receive messages from clients, while a backup server is not operational until failover occurs. A backup server can be owned by only one live server, and it will remain in passive mode, waiting to take over the live server’s work.</p>\n\n<p>When a live server crashes or is brought down in the correct mode, the backup server currently in passive mode will become the new live server. If the new live server is configured to allow automatic failback, it will detect the old live server coming back up and automatically stop, allowing the old live server to start receiving messages again.</p>\n\n<p><strong>Note</strong><br/> If you deploy just one pair of live / backup servers, you cannot effectively use a load balancer in front of the pair because the backup instance is not actively processing messages. Moreover, services such as JNDI and the Undertow web server are not active on the backup server either. For these reasons, deploying JEE applications to an instance of ${build.shortName} being used as a backup messaging server is not supported.</p>\n\n<h2>HA Policies</h2>\n<p>${build.shortName} messaging supports two different strategies for backing up a server: <em>replication</em> and <em>shared store</em>. Each strategy can take the role of a master or slave. Remember that only one HA policy option can be configured per messaging server.</p>\n\n<p>For more information about high availability and the different strategies and policies, see <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/paged/configuring-messaging/chapter-29-high-availability\">High Availability</a>.</p>\n",
"<p>${build.shortName} messaging includes a fully functional JMS message api. The function of a JMS api is to consume messages from a source queue or topic and send them to a target queue or topic, typically on a different server.</p>\n\n<p>The source and target servers do not have to be in the same cluster, which makes bridging suitable for reliably sending messages from one cluster to another, for instance across a WAN, and where the connection may be unreliable.</p>\n\n<p>\n    <strong>Note</strong><br/>Do not confuse a JMS bridge with a core bridge. A JMS bridge can be used to bridge any two JMS 1.1 compliant JMS providers and uses the JMS API. A core bridge is used to bridge any two ${build.shortName} messaging instances and uses the core API. It is preferable to use a core bridge instead of a JMS bridge whenever possible.\n</p>",
"<p>Contains the configuration for discover groups, connector, connection factory, queues and topics to a remote ActiveMQ Artemis server:</p>\n\n<h2>Connectors</h2>\n<p>A connector defines how to connect to a remote ActiveMQ Artemis server.</p>\n\n<p>For more information about connectors, see the\n    <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.1/html/configuring_messaging/acceptors_and_connectors\">Connectors documentation</a>.\n</p>\n\n<h2>Discovery Groups</h2>\n<p>A discovery group defines how connector information is received from a broadcast endpoint, for example, a UDP multicast address or JGroup channel.</p>\n<p>A discovery group maintains a list of connectors, one for each broadcast by a different server. As it receives broadcasts on the broadcast endpoint from a particular server, it updates its entry in the list for that server. If it has not received a broadcast from a particular server for a length of time it will remove that server’s entry from its list.</p>\n\n\n<h2>Connection Factories</h2>\n<p>By default, the ${build.shortName} messaging subsystem provides the <code>InVmConnectionFactory</code> and\n    <code>RemoteConnectionFactory</code> connection factories, as well as the\n    <code>activemq-ra</code> pooled connection factory.\n</p>\n\n<p>Pooled connection factories allow you to configure the inbound and outbound connectors of the remote ActiveMQ Artemis resource adapter. For more information on configuring a pooled-connection-factory to connect to a remote ActiveMQ Artemis server, see\n    <a target=\"_blank\" href=\"https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.1/html/configuring_messaging/resource_adapters#use_provided_amq_adapter\">Using the Integrated Resource Adapter for Remote Connections</a>.\n</p>\n\n<h2>External Queue / Topic</h2>\n<p>The queues and topics that exists in the remote ActiveMQ Artemis server.</p>\n",
"<p>An Apache ActiveMQ Artemis server. Each Apache ActiveMQ Artemis server has its own ultra high performance persistent journal, which it uses for message and other persistence.</p>\n\n<p>Using a high performance journal allows outrageous persistence message performance, something not achievable when using a relational database for persistence.</p>\n\n<p>Apache ActiveMQ Artemis clients, potentially on different physical machines interact with the Apache ActiveMQ Artemis server. Apache ActiveMQ Artemis currently provides two APIs for messaging at the client side:</p>\n\n<ol>\n    <li>Core client API. This is a simple intuitive Java API that allows the full set of messaging functionality without some of the complexities of JMS.</li>\n    <li>JMS client API. The standard JMS API is available at the client side.</li>\n</ol>\n\n<p>Apache ActiveMQ Artemis also provides different protocol implementations on the server so you can use respective clients for these protocols:</p>\n\n<ol>\n    <li>Stomp</li>\n    <li>OpenWire</li>\n    <li>AMQP</li>\n</ol>\n\n<p>JMS semantics are implemented by a JMS facade layer on the client side.</p>\n\n<p>The Apache ActiveMQ Artemis server does not speak JMS and in fact does not know anything about JMS, it is a protocol agnostic messaging server designed to be used with multiple different protocols.</p>\n\n<p>When a user uses the JMS API on the client side, all JMS interactions are translated into operations on the Apache ActiveMQ Artemis core client API before being transferred over the wire using the Apache ActiveMQ Artemis wire format.</p>\n\n<p>The server always just deals with core API interactions.</p>",
"<p>Support Eclipse MicroProfile Config for applications deployed in WildFly. The integration uses the\n    <a href=\"https://github.com/smallrye/smallrye-config/\">SmallRye</a> component to provide the MicroProfile Config implementation.\n</p>\n",
"<!--\n  ~ Copyright 2015-2016 Red Hat, Inc, and individual contributors.\n  ~\n  ~ Licensed under the Apache License, Version 2.0 (the \"License\");\n  ~ you may not use this file except in compliance with the License.\n  ~ You may obtain a copy of the License at\n  ~\n  ~ https://www.apache.org/licenses/LICENSE-2.0\n  ~\n  ~ Unless required by applicable law or agreed to in writing, software\n  ~ distributed under the License is distributed on an \"AS IS\" BASIS,\n  ~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\n  ~ See the License for the specific language governing permissions and\n  ~ limitations under the License.\n  -->\n<p>Support Eclipse MicroProfile Metrics in WildFly. The integration uses the\n    <a href=\"https://github.com/smallrye/smallrye-metrics/\">SmallRye</a> component to provide the MicroProfile Metrics implementation.\n</p>\n",
"<p>mod_cluster is an httpd-based load balancer. Like mod_jk and mod_proxy, mod_cluster uses a communication channel to forward requests from httpd to one of a set of application server nodes. Unlike mod_jk and mod_proxy, mod_cluster leverages an additional connection between the application server nodes and httpd.</p>\n\n<p>The application server nodes use this connection to transmit server-side load balance factors and lifecycle events back to httpd via a custom set of HTTP methods, affectionately called the Mod-Cluster Management Protocol (MCMP). This additional feedback channel allows mod_cluster to offer a level of intelligence and granularity not found in other load balancing solutions.</p>",
"<p>Bind entries into global JNDI namespaces and configure the remote JNDI interface.</p>",
"<p>A logical name for a filesystem path. The <code>domain.xml</code>, <code>host.xml</code> and <code>standalone.xml</code> configurations all include a section where paths can be declared. Other sections of the configuration can then reference those paths by their logical name, rather than having to include the full details of the path (which may vary on different machines).</p>\n\n<p>For example, the logging subsystem configuration includes a reference to the <code>jboss.server.log.dir</code> path that points to the server&#39;s <code>log</code> directory.</p>",
"<p>Enable deployment of applications containing JBoss Microcontainer services, as supported by previous versions of ${build.shortName}.</p>",
"<p>A profile is named set of subsystems along with each subsystem’s configurations. A subsystem is an additional set of capabilities added to the core server by an extension. Subsystems provide capabilities like servlet handling capabilities, an EJB container, JTA, etc.</p>\n\n<p>Different profiles can be defined to address the specific needs of different server groups.</p>\n\n<img class=\"preview\" src=\"previews/profiles.png\"/>",
"<p>JBoss Remoting has three top-level configurable elements: the worker thread pool, one or more connectors, and a series of local and remote connection URIs.</p>\n<p>Most people will not need to configure the Remoting subsystem at all, unless they use custom connectors for their own applications. Applications which act as Remoting clients, such as EJBs, need separate configuration to connect to a specific connector.</p>",
"<p>${build.shortName} can be suspended or shut down gracefully. This allows active requests to complete normally, without accepting any new requests. A timeout value specifies how long that the suspend or shut down operation will wait for active requests to complete. While the server is suspended, management requests are still processed.</p>\n<p>Graceful shutdown is coordinated at a server-wide level, mostly focused on the entry points at which a request enters the server. The following subsystems support graceful shutdown:</p>\n<dl>\n    <dt>Undertow</dt>\n    <dd>The <code>undertow</code> subsystem will wait for all requests to finish.</dd>\n    <dt>Modcluster</dt>\n    <dd>The <code>modcluster</code> subsystem will notify the load balancer that the server is suspending in the\n        <code>PRE_SUSPEND</code> phase.\n    </dd>\n    <dt>EJB</dt>\n    <dd>The\n        <code>ejb3</code> subsystem will wait for all remote EJB requests and MDB message deliveries to finish. Delivery to MDBs is stopped in the\n        <code>PRE_SUSPEND</code> phase. EJB timers are suspended, and missed timers will be activated when the server is resumed.\n    </dd>\n    <dt>EE Concurrency</dt>\n    <dd>The server will wait for all active jobs to finish. All queued jobs will be skipped. Currently, since EE Concurrency does not have persistence, those queued jobs that were skipped will be lost.<br/>While the server is in a suspended state, scheduled tasks will continue to execute at their scheduled times but will throw a\n        <code>java.lang.IllegalStateException</code>. Once the server is resumed, scheduled tasks will continue to execute normally and in most cases, tasks will not need to be rescheduled.\n    </dd>\n    <dt>Batch</dt>\n    <dd>The server will stop all running jobs within the timeout period and defer all scheduled jobs.<br/>Graceful shutdown currently will not reject inbound remote distributed transactions or new inbound JMS messages. EE batch jobs and EE concurrency tasks scheduled by inflight activity are currently allowed to proceed. However, EE concurrency tasks submitted that pass the timeout window currently error when executed.\n    </dd>\n</dl>\n<p>Requests are tracked by the request-controller subsystem. Without this subsystem, suspend and resume capabilities are limited and the server will not wait for requests to complete before suspending or shutting down. However, if you do not need this capability, the request-controller subsystem can be removed for a small performance improvement.</p>",
"<p>A resource adapter is a deployable Java EE component that provides communication between a Java EE application and an Enterprise Information System (EIS) using the Java Connector Architecture (JCA) specification. A resource adapter is often provided by EIS vendors to allow easy integration of their products with Java EE applications.</p>\n<p>An Enterprise Information System can be any other software system within an organization. Examples include Enterprise Resource Planning (ERP) systems, database systems, e-mail servers and proprietary messaging systems.</p>\n<p>A resource adapter is packaged in a Resource Adapter Archive (RAR) file which can be deployed to the server. A RAR file may also be included in an Enterprise Archive (EAR) deployment.</p>",
"<p>Enable deployment of SAR archives containing MBean services, as supported by previous versions of ${build.shortName}.</p>",
"<p>A security domain consists of configurations for authentication, authorization, security mapping, and auditing. It implements Java Authentication and Authorization Service (JAAS) declarative security.</p>\n<p>Authentication refers to verifying the identity of a user. In security terminology, this user is referred to as a principal. Although authentication and authorization are different, many of the included authentication modules also handle authorization.\n</p>\n<p>Authorization is a process by which the server determines if an authenticated user has permission or privileges to access specific resources in the system or operation.</p>\n<p>Security mapping refers to the ability to add, modify, or delete information from a principal, role, or attribute before passing the information to your application.</p>\n<p>The auditing manager allows you to configure provider modules to control the way that security events are reported.\nIf you use security domains, you can remove all specific security configuration from your application itself. This allows you to change security parameters centrally. One common scenario that benefits from this type of configuration structure is the process of moving applications between testing and production environments.</p>",
"<p>The elytron subsystem is new in ${build.fullName}. It is based on the WildFly Elytron project, which is a security framework used to unify security across the entire application server. The elytron subsystem enables a single point of configuration for securing both applications and the management interfaces. WildFly Elytron also provides a set of APIs and SPIs for providing custom implementations of functionality and integrating with the subsystem.</p>\n<p>In addition, there are several other important features of Elytron:</p>\n<ul>\n    <li>Stronger authentication mechanisms for HTTP and SASL authentication.</li>\n    <li>Improved architecture that allows for SecurityIdentities to be propagated across security domains. This ensures transparent transformation that is ready to be used for authorization. This transformation takes place using configurable role decoders, role mappers, and permission mappers.</li>\n    <li>Centralized point for SSL/TLS configuration including cipher suites and protocols.</li>\n    <li>SSL/TLS optimizations such as eager SecureIdentity construction and closely tying authorization to establishing an SSL/TLS connection. Eager SecureIdentity construction eliminates the need for a SecureIdentity to be constructed on a per-request basis. Closely tying authentication to establishing an SSL/TLS connection enables permission checks to happen BEFORE the first request is received.</li>\n    <li>A secure credential store that replaces the previous vault implementation. The new secure credential store can store multiple other encrypted credential types in addition to encrypted strings.</li>\n</ul>\n<p>The new elytron subsystem exists in parallel to the legacy security subsystem and legacy core management authentication. Both the legacy and Elytron methods may be used for securing the management interfaces as well as providing security for applications.</p>",
"<p>Configure Java security policies to be used by the Java Security Manager.</p>\n<p>The Java Security Manager is a class that manages the external boundary of the Java Virtual Machine (JVM) sandbox, controlling how code executing within the JVM can interact with resources outside the JVM. When the Java Security Manager is activated, the Java API checks with the security manager for approval before executing a wide range of potentially unsafe operations. The Java Security Manager uses a security policy to determine whether a given action will be allowed or denied.</p>",
"<p>Define singleton policies to configure the behavior of singleton deployments or to create singleton MSC services.</p>\n<p>A clustered singleton service, also known as a high-availability (HA) singleton, is a service deployed on multiple nodes in a cluster. The service is provided on only one of the nodes. The node running the singleton service is usually called the master node.</p>\n<p>When the master node either fails or shuts down, another master is selected from the remaining nodes and the service is restarted on the new master. Other than a brief interval when one master has stopped and another has yet to take over, the service is provided by one, but only one, node.</p>",
"<p>A socket binding is a named configuration for a socket. The <code>domain.xml</code> and <code>standalone.xml</code> configurations both include a section where named socket configurations can be declared. Other sections of the configuration can then reference those sockets by their logical name, rather than having to include the full details of the socket configuration (which may vary on different machines).</p>",
"<p>Configure subsystems and global resources such as interfaces, socket bindings, paths and system properties.</p>\n\n<p>View and modify the configuration for each available <strong>subsystem</strong>. For example, add a datasource, configure a messaging provider, or set up application security.</p>\n\n<p>Related Links</p>\n<ul>\n    <li><a href=\"#runtime\">Server Runtime</a></li>\n</ul>",
"<p>A set of subsystem configurations. A subsystem is an added set of capabilities added to the core server by an extension. As such a subsystem provides servlet handling capabilities, an EJB container, JTA support, etc.</p>",
"<p>System property values can be set in a number of places in <code>domain.xml</code>, <code>host.xml</code> and <code>standalone.xml</code>. The values in <code>standalone.xml</code> are set as part of the server boot process. Values in <code>domain.xml</code> and <code>host.xml</code> are applied to servers when they are launched.</p>",
"<p>Configure transaction manager options, such as timeout values, transaction logging, and whether to use Java Transaction Service (JTS).</p>",
"<p>The Undertow subsystem allows you to configure the web server and servlet container settings. It implements the\n    <a href=\"https://jcp.org/en/jsr/detail?id=340\" target=\"_blank\">Java Servlet 3.1 Specification</a> as well as websockets and supports HTTP Upgrade and using high performance non-blocking handlers in servlet deployments. The Undertow subsystem also has the ability to act as a high performance reverse proxy which supports mod_cluster.\n</p>\n\n<p>Within the Undertow subsystem, there are six main components to configure:</p>\n<ol>\n    <li>Global Settings</li>\n    <li>Buffer Caches</li>\n    <li>Server</li>\n    <li>Servlet Container</li>\n    <li>Filters</li>\n    <li>Handlers</li>\n</ol>\n\n<p><strong>Important</strong><br/>\n    The Undertow subsystem also relies on the IO subsystem to provide XNIO workers and buffer pools. The IO subsystem is configured separately and provides a default configuration which should give optimal performance in most cases.\n</p>\n",
"<p>A Mapping from a security domain references in a deployed application and Single Sign-on settings.</p>\n",
"<p>The buffer cache is used to cache static resources. ${build.shortName} enables multiple caches to be configured and referenced by deployments, allowing different deployments to use different cache sizes. Buffers are allocated in regions and are a fixed size. The total amount of space used can be calculated by multiplying the buffer size by the number of buffers per region by the maximum number of regions. The default size of a buffer cache is 10MB.</p>",
"<p>A byte buffer pool used for IO operations, this provides the same capabilities as the buffer pool from the IO subsystem, so they can be used interchangeably and must have a unique name. This buffer pool allows for more precise configuration of the total amount of retained memory than the IO subsystem.</p>",
"<p>A filter enables some aspect of a request to be modified and can use predicates to control when a filter executes. Some common use cases for filters include setting headers or doing GZIP compression.</p>\n\n<p>The following types of filters can be defined:</p>\n<ol>\n    <li>Custom Filter</li>\n    <li>Error Page</li>\n    <li>Expression Filter</li>\n    <li>GZip</li>\n    <li>Mod Cluster</li>\n    <li>Request Limit</li>\n    <li>Response Header</li>\n    <li>Rewrite</li>\n</ol>\n\n<p><strong>Note</strong><br/>\n    A filter is functionally equivalent to a global valve used in previous versions of ${build.shortName}.</p>\n",
"<p>Undertow allows for two types of handlers to be configured:</p>\n<ol>\n    <li>File Handlers</li>\n    <li>Reverse-Proxy Handlers</li>\n</ol>\n<p>File handlers serve static files. Each file handler must be attached to a location in a virtual host. Reverse-proxy handlers allow ${build.shortName} to server as a high performance reverse-proxy. It can handle AJP, HTTP, and HTTP.2 backends and supports mod_cluster.</p>\n\n",
"<p>A server represents an instance of Undertow and consists of several elements:</p>\n<ol>\n    <li>Host</li>\n    <li>HTTP Listener</li>\n    <li>HTTPS Listener</li>\n    <li>AJP Listener</li>\n</ol>\n\n<p>The host element provides a virtual host configuration while the three listeners provide connections of that type to the Undertow instance.</p>\n\n<p><strong>Note</strong><br/>\n    Multiple servers may be configured, which allow deployments and servers to be completely isolated. This may be useful in certain scenarios such as multi-tenant environments.\n</p>",
"<p>A servlet container provides all servlet, JSP and websocket-related configuration, including session-related configuration. While most servers will only need a single servlet container, it is possible to configure multiple servlet containers by adding an additional servlet-container element. Having multiple servlet containers enables behavior such as allowing multiple deployments to be deployed to the same context path on different virtual hosts.</p>\n\n<p><strong>Note</strong><br/>\n    Much of the configuration provided in by servlet container can be individually overridden by deployed applications using their <code>web.xml</code> file.</p>",
"<p>JBossWS components are provided to the application server through the webservices subsystem. JBossWS components handle the processing of WS endpoints. The subsystem supports the configuration of published endpoint addresses, and endpoint handler chains. A default webservice subsystem is provided in the server's domain and standalone configuration files.</p>\n\n<h2>Additional Resources</h2>\n<p>The web service subsystem is provided by the JBossWS project. For a detailed description of the available configuration properties, please consult the project documentation.</p>\n<ul>\n    <li>JBossWS homepage: <a href=\"https://www.jboss.org/jbossws\" target=\"_blank\">https://www.jboss.org/jbossws</a></li>\n    <li>Project Documentation:\n        <a href=\"https://docs.jboss.org/author/display/JBWS\" target=\"_blank\">https://docs.jboss.org/author/display/JBWS</a>\n    </li>\n</ul>",
"<p>Configure Contexts and Dependency Injection (CDI) functionality for ${build.shortName}.</p>",
"<p>Core management configures the following features:</p>\n<ul>\n    <li>Configurationm changes: Enable or disable the in-memory recording of any configuration change to this profile. The configuration changes for the profile section may be viewed in the runtime section of the server associated to this profile.</li>\n    <li>Process State Listener: Add custom class listen for any change on the server's process state.</li>\n</ul>\n",
"<p>The content repository holds all content uploaded to the domain controller. After being uploaded the content can be assigned to a server group.</p>\n\n<p id=\"drag-and-drop-deployment\">You can use <strong>drag and drop</strong> to add new content or replace existing content. Simply drag one or several files onto the content column. If there's already a content with the same name, the content will be replaced, otherwise the content will be added.</p>\n\n<p>You can also add unmanaged deployments. An unmanaged deployment points to a folder on the server's local file system. Compared to managed deployments, unmanaged deployments won't be copied (i.e. uploaded) to the server's deployment repository before they're deployed. The deployment content will remain at and be deployed directly from its original location.</p>\n\n<p>If a content is no longer assigned to a server group, you can remove the content again.</p>",
"<p>A <strong>deployment</strong> is any resource, such a WAR or EAR application, that can be deployed to a server.</p>\n\n<p>In a managed domain, deployments are assigned to server groups. All server instances within a server group will have the same deployment content.</p>\n\n<img class=\"preview\" src=\"previews/deployments.png\"/>",
"<p>Manage the deployments of a server group</p>\n<p id=\"drag-and-drop-deployment\">You can use\n    <strong>drag and drop</strong> to add new deployments to the selected server group. Simply drag one or several files onto the deployment column. The deployments added by drag and drop will be disabled by default.\n</p>\n<p>Select one or several items from the content repository and deploy it to the selected server group.</p>\n<p>Add unmanaged deployments. An unmanaged deployment points to a folder on the server's local file system. Compared to managed deployments, unmanaged deployments won't be copied (i.e. uploaded) to the server's deployment repository before they're deployed. The deployment content will remain at and be deployed directly from its original location.</p>\n",
"<p>A server group is a collection of server instances that are managed and configured as one. In a managed domain, every application server instance belongs to a server group, even if it is the only member. The server instances in a group share the same profile configuration and deployed content.</p>\n\n<p>Use this column to manage deployments that have been assigned to one or more server groups. Upload new deployments, deploy content from the content repository or create an unmanaged deployments.</p>\n",
"<p>A deployment represents anything that can be deployed (e.g. an application such as EJB-JAR, WAR, EAR, any kind of standard archive such as RAR or JBoss-specific deployment) into a server.</p>\n<p id=\"drag-and-drop-deployment\">You can use\n    <strong>drag and drop</strong> to add new content or replace existing deployments. Simply drag one or several files onto the deployment column. If there's already a deployment with the same name, the deployment will be replaced, otherwise the deployment will be added. The deployments added by drag and drop will be enabled by default.\n</p>",
"<p>Extensions are a way to add new features to the management console. They are written in JavaScript and should use the\n    <a href=\"https://github.com/hal/hal.next/wiki/JavaScript-API\">JavaScript API</a> to interact with the console and the management interface. If you want to develop an extension, see\n    <a href=\"https://github.com/hal/hal.next/wiki/Extensions\">https://github.com/hal/hal.next/wiki/Extensions</a> for more information.\n</p>\n\n<div class=\"alert alert-warning\">\n    <span class=\"pficon pficon-warning-triangle-o\"></span>Extensions are written in <strong>JavaScript</strong> and are\n    <strong>injected</strong> into the browser. Please install only extensions that you trust!\n</div>\n\n<h2>Extension Points</h2>\n<p>The console provides four different extension points which can be used by extensions:</p>\n<ol>\n    <li>Header: Adds a menu item to the \"Extensions\" dropdown in the header</li>\n    <li>Finder Item: Adds a new item to a specific finder column</li>\n    <li>Footer: Adds a menu item to the \"Extensions\" dropdown in the footer</li>\n    <li>Custom: It's up to the extension how to add itself to the console</li>\n</ol>\n\n<h2>Installation</h2>\n<p>Extensions can be added to the console using two different ways:</p>\n\n<dl>\n    <dt>Bundled Extensions</dt>\n    <dd>\n        <p>Bundled extensions are part of the ${build.fullName} installation and installed as modules. They have to be installed outside of the console. WildFly and the console have to be restarted / reloaded after adding or removing bundled extensions.</p>\n    </dd>\n\n    <dt>Standalone Extensions</dt>\n    <dd>\n        <p>Standalone extensions are hosted by a public available endpoint. This endpoint must serve a JSON file which contains metadata for the extension. You can add and remove standalone extensions using the management console. They're stored in the browser's local storage. As such they're scoped to the browser and URL which runs the management console.</p>\n    </dd>\n</dl>\n",
"<p>Configure settings related to the management interface, review the last configuration changes and manage extensions to the management console.</p>\n\n<h2>Management Interface</h2>\n<p>View and modify settings for the http and native management interfaces such as a list of allowed origins, security realm, SSL context.</p>\n\n<h2>Extensions</h2>\n<p>View and manage extensions to the management console. Extensions are a way to add new features to the management console. They're written in JavaScript and fall into two categories:</p>\n<ul>\n    <li>Bundled Extensions: Part of the ${build.fullName} installation provided by modules</li>\n    <li>Standalone Extensions: 3rd party extensions hosted by a public server</li>\n</ul>\n",
"<p>The method of applying a patch to ${build.shortName} depends on your installation method. If you installed ${build.shortName} using the ZIP or installer methods, you must use the ZIP-based patch management system. If you used RPMs to install ${build.shortName} on Red Hat Enterprise Linux, you must use RPM patches.\nImportant.</p>\n\n<p>Before applying or rolling back a patch, you should back up your ${build.shortName} server, including all deployments and configuration files.</p>\n\n<p>Cumulative patches for a ZIP or Installer installation of ${build.shortName} are available to download from the Red Hat Customer Portal.</p>\n\n<p>For multiple ${build.shortName} hosts in a managed domain environment, individual hosts can be patched from your ${build.shortName} domain controller.</p>\n\n<p>In addition to applying a patch, you can also roll back the application of a patch.</p>\n\n<h3>Important Notes on ZIP/Installer Installation Patching</h3>\n\n<ul>\n    <li>If you apply a patch that updates a module, the new patched JARs that are used at runtime are stored in <code>${build.installDir}/modules/system/layers/base/.overlays/PATCH_ID/MODULE</code>. The original unpatched files are left in <code>${build.installDir}/modules/system/layers/base/MODULE</code>, but these JARs are not used at runtime.</li>\n    <li>In order to significantly decrease the size of cumulative patch releases for ${build.shortName}, you now cannot perform a partial roll back of a cumulative patch. For a patch that has been applied, you will only be able to roll back the whole patch.</li>\n    <li>For example, if you apply CP03 to ${build.shortName}, you will not be able to roll back to CP01 or CP02. If you would like the ability to roll back to each cumulative patch release, each cumulative patch must be applied separately in the order they were released.</li>\n</ul>",
"<p>Users authenticated using either the <code>mgmt-users.properties</code> file or an LDAP server, can be members of user groups. A user group is an arbitrary label that can be assigned to one or more users.</p>\n<p>The RBAC system can be configured to automatically assign roles to users depending on what user groups they are members of. It can also exclude users from roles based on group membership.</p>\n<p>When using the <code>mgmt-users.properties</code> file, group information is stored in the <code>mgmt-groups.properties</code> file. When using LDAP the group information is stored in the LDAP sever and maintained by those responsible for the LDAP server.</p>",
"<p>Role-Based Access Control (RBAC) is a mechanism for specifying a set of permissions for management users. It allows multiple users to share responsibility for managing servers without each of them requiring unrestricted access. By providing \"separation of duties\" for management users, it's easy to spread responsibility between individuals or groups without granting unnecessary privileges. This ensures the maximum possible security of your servers and data while still providing flexibility for configuration, deployment, and management.</p>\n<p>Role-Based Access Control works through a combination of role permissions and constraints. Seven predefined roles are provided that each have different fixed permissions. The predefined roles are: Monitor, Operator, Maintainer, Deployer, Auditor, Administrator, and SuperUser (select a role to get more details about its permissions). Each management user is assigned one or more roles, which specify what the user is permitted to do when managing the server.</p>\n<p><strong>Important:</strong> Before changing the provider to <code>rbac</code>, be sure your configuration has a user who will be mapped to one of the RBAC roles, preferably with at least one in the Administrator or SuperUser role. Otherwise your installation will not be manageable unless it is shut down and the XML configuration is edited.</p>",
"<h2>Standard Roles</h2>\n<p>There are seven predefined user roles:</p>\n<ul>\n    <li>Monitor</li>\n    <li>Operator</li>\n    <li>Maintainer</li>\n    <li>Deployer</li>\n    <li>Auditor</li>\n    <li>Administrator</li>\n    <li>SuperUser</li>\n</ul>\n<p>Each of these roles has a different set of permissions and is designed for specific use cases. The Monitor, Operator, Maintainer, Administrator, and SuperUser role each build upon each other, with each having more permissions than the previous. The Auditor and Deployer roles are similar to the Monitor and Maintainer roles respectively but have some additional special permissions and restrictions.</p>\n\n<h2>Scoped Roles</h2>\n<p>Scoped Roles are user-defined roles that grant the permissions of one of the standard roles but only for one or more specified server groups or hosts. Scoped roles allow for management users to be granted permissions that are limited to only those server groups or hosts that are required.</p>\n<p>They are defined by five characteristics:</p>\n<ol>\n    <li>A unique name.</li>\n    <li>Which of the standard roles it is based on.</li>\n    <li>If it applies to Server Groups or Hosts</li>\n    <li>The list of server groups or hosts that it is restricted to.</li>\n    <li>If all users are automatically include. This defaults to false.</li>\n</ol>\n<p>Once created a scoped role can be assigned to users and groups the same way that the standard roles are.</p>\n<p>Creating a scoped role does not let you define new permissions. Scoped roles can only be used to apply the permissions of an existing role in a limited scope. For example, you could create a scoped role based on the Deployer role which is restricted to a single server group.</p>\n<p>There are only two scopes that roles can be limited to, host and server group.</p>\n<dl>\n    <dt>Host-scoped roles</dt>\n    <dd>A role that is host-scoped restricts the permissions of that role to one or more hosts. This means access is provided to the relevant /host=*/ resource trees but resources that are specific to other hosts are hidden.</dd>\n    <dt>Server-Group-scoped roles</dt>\n    <dd>A role that is server-group-scoped restricts the permissions of that role to one or more server groups. Additionally the role permissions will also apply to the profile, socket binding group, server config and server resources that are associated with the specified server-groups. Any sub-resources within any of those that are not logically related to the server-group will not be visible to the user.</dd>\n</dl>",
"<p>There are seven predefined user roles:</p>\n<ul>\n    <li>Monitor</li>\n    <li>Operator</li>\n    <li>Maintainer</li>\n    <li>Deployer</li>\n    <li>Auditor</li>\n    <li>Administrator</li>\n    <li>SuperUser</li>\n</ul>\n<p>Each of these roles has a different set of permissions and is designed for specific use cases. The Monitor, Operator, Maintainer, Administrator, and SuperUser role each build upon each other, with each having more permissions than the previous. The Auditor and Deployer roles are similar to the Monitor and Maintainer roles respectively but have some additional special permissions and restrictions.</p>",
"<p>What a management user is permitted to do is determined by the roles to which the user is assigned. A system of includes and excludes based on the user membership determines to which role a user belongs.</p>\n<p>A user is considered to be assigned to a role if:</p>\n<ol>\n    <li>The user is:</li>\n    <ul>\n        <li>listed as a user to be included in the role, or</li>\n        <li>a member of a group that is listed to be included in the role.</li>\n    </ul>\n    <li>The user is not:</li>\n    <ul>\n        <li>listed as a user to exclude from the role, or</li>\n        <li>a member of a group that is listed to be excluded from the role.</li>\n    </ul>\n</ol>\n<p>Exclusions take priority over inclusions.</p>",
"<p>Displays the application security domain configuration and its associated deployments.</p>\n",
"<p>Provides access to runtime operations such as 'Test Connection' and flush operations.</p>\n<p>In order to view datasource and JDBC statistics, please make sure to enable them in the configuration section.</p>",
"<p>Displays runtime metrics for servlets and websockets as contained in deployments.</p>\n",
"<p>A domain consists of one domain controller, one or more host controller(s), and zero or more server groups per host.</p>\n<img class=\"preview\" src=\"previews/domain.png\"/>\n<p>A domain controller is the central point from which the domain is controlled. It ensures that each server is configured according to the management policy of the domain. The domain controller is also a host controller.</p>\n<p>A host controller is a physical or virtual host on which the domain.sh or domain.bat script is run. Host controllers are configured to delegate domain management tasks to the domain controller. The host controller on each host interacts with the domain controller to control the lifecycle of the application server instances running on its host and to assist the domain controller to manage them. Each host can contain multiple server groups.</p>\n<p>A server group is a set of server instances which have ${build.shortName} installed on them and are managed and configured as one. The domain controller manages the configuration of and applications deployed onto server groups. Consequently, each server in a server group shares the same configuration and deployments.</p>\n",
"<p>Provides a set of runtime operations for the following resources of elytron subsystem:</p>\n<ul>\n    <li><strong>Certificate Authority Account</strong>: Create, deactivate and update an account and change the account key.</li>\n    <li><strong>Key Manager</strong>: Reinitialize key manager.</li>\n    <li><strong>Security Domain</strong>: Read an identity.</li>\n    <li><strong>Trust Manager</strong>: Reload the certificate revocation list.</li>\n</ul>",
"<p>Provides a set of runtime operations for the following resources of elytron subsystem:</p>\n<ul>\n    <li><strong>Caching Realm</strong>: Removes all entries from the cache.</li>\n    <li><strong>Custom Modifiable Realm</strong>: Add, read and remove identities. Also sets a password for an identity.</li>\n    <li><strong>Filesystem Realm</strong>: Add, read and remove identities. Also sets a password for an identity.</li>\n    <li><strong>LDAP Realm</strong>: Add, read and remove identities. Also sets a password for an identity.</li>\n    <li><strong>Properties Realm</strong>: Reload the properties files from the file system.</li>\n</ul>",
"<p>Provides a set of runtime operations for the following resources of elytron subsystem:</p>\n<ul>\n    <li><strong>Credential Store</strong>: Add, read and remove aliases, sets a password for an alias. Also, reloads the credential store.</li>\n    <li><strong>Filtering Key Store</strong>: Read and remove aliases.</li>\n    <li><strong>Key Store</strong>: Read, change and remove aliases. Import and export a certificate. Generate a key pair. Generate a certificate signing request. Load and store the Key Store.</li>\n    <li><strong>LDAP Key Store</strong>: Read and remove aliases.</li>\n</ul>",
"<p>A host controller is launched when the <code>domain.sh</code> or <code>domain.bat</code> script is run on a host.</p>\n\n<p>The primary responsibility of a host controller is server management. It delegates domain management tasks and is responsible for starting and stopping the individual application server processes that run on its host.</p>\n\n<p>It interacts with the domain controller to help manage the communication between the servers and the domain controller. Multiple host controllers of a domain can interact with only a single domain controller. Hence, all the host controllers and server instances running on a single domain mode have a single domain controller and must belong to the same domain.</p>\n\n<p>By default each host controller reads its configuration from the\n    <code>domain/configuration/host.xml</code> file located in the unzipped ${build.shortName} installation file on its host's filesystem. The\n    <code>host.xml</code> file contains the following configuration information that is specific to the particular host:\n</p>\n\n<ul>\n    <li>The names of the ${build.shortName} instances meant to run from this installation.</li>\n    <li>Any of the following configurations:</li>\n    <ul>\n        <li>How the host controller contacts the domain controller to register itself and access the domain configuration.</li>\n        <li>How to find and contact a remote domain controller.</li>\n        <li> That the host controller is to act as the domain controller</li>\n    </ul>\n    <li>Configurations specific to the local physical installation. For example, named interface definitions declared in\n        <code>domain.xml</code> can be mapped to an actual machine-specific IP address in\n        <code>host.xml</code>. And abstract path names in domain.xml can be mapped to actual filesystem paths in\n        <code>host.xml</code>.\n    </li>\n</ul>",
"<p>Lists the deployed REST resources</p>",
"<p>Provides an overview of the local JNDI namespace. The Java EE platform specification defines the following JNDI contexts:</p>\n<ul>\n    <li><code>java:comp</code> - The namespace is scoped to the current component (i.e. EJB)</li>\n    <li><code>java:module</code> - Scoped to the current module</li>\n    <li><code>java:app</code> - Scoped to the current application</li>\n    <li><code>java:global</code> - Scoped to the application server</li>\n</ul>\n<p>In addition to the standard namespaces, ${build.shortName} also provides the following two global namespaces:</p>\n<ul>\n    <li><code>java:jboss</code></li>\n    <li><code>java:/</code></li>\n</ul>\n<p>Please note that only entries within the java:jboss/exported context are accessible over remote JNDI. For web deployments <code>java:comp</code> is aliased to <code>java:module</code>, so EJB's deployed in a war do not have their own comp namespace.</p>",
"<p>Shows statistics for persistence units which are part of active deployments of the selected server.</p>\n<p>In order to view statistics, please make sure to enable them by adding\n    <code>&lt;property name=\"hibernate.generate_statistics\" value=\"true\"/&gt;</code> to your persistence.xml.\n</p>",
"<p>View server and application logs in order to help diagnose errors, performance problems, and other issues. For a log to be viewable, it must be located in the server's\n    <code>jboss.server.log.dir</code> directory. The console also respects user RBAC role assignments, so a user can only view logs that they are authorized to access.\n</p>\n\n<p>By default the console displays the last 2000 lines of a log file. If you want to view the log file as a whole, please choose 'Download'. To view or follow the log file in a separate browser window choose 'Open in external window'.</p>",
"<p>A management operation is an operation that is performed on the ${build.shortName} and is related to administration scope. The HTTP handling related to application usage (ejb, rest, jms, etc) are not registered as a management operation.</p>\n<p>Adding a deployment, changing of datasource's password, increasing thread-pools are examples of management operations.</p>\n<p>There are management operations that needs exclusive locks to write to resources, if this exlcusive lock is held more than 15s, it is considered a non progressing operation and it will be reported in this view.</p>\n<p>The management operations view, allows the administrator to list all running management operations of a standalone server or all hosts and servers of the domain. It also allows to cancel any active management operation or cancel all the non progressing operations.</p>\n\n",
"<p>Displays runtime metrics for balancers, nodes and contexts.</p>\n",
"<p>The elytron subsystem is new in ${build.fullName}. It is based on the WildFly Elytron project, which is a security framework used to unify security across the entire application server. The elytron subsystem enables a single point of configuration for securing both applications and the management interfaces. WildFly Elytron also provides a set of APIs and SPIs for providing custom implementations of functionality and integrating with the subsystem.</p>\n<p>This runtime view provides dynamic information about the various stores, security realms and ssl resources that are configured for this server.</p>",
"<p>A server group is a collection of server instances that are managed and configured as one. In a managed domain, every application server instance belongs to a server group, even if it is the only member. The server instances in a group share the same profile configuration and deployed content.</p>\n\n<p>A domain controller and a host controller enforce the standard configuration on all server instances of every server group in its domain.</p>\n\n<p>A domain can consist of multiple server groups. Different server groups can be configured with different profiles and deployments. A domain can be configured with different server tiers providing different services, for example.</p>\n\n<p>Different server groups can also have the same profile and deployments. This can, for example, allow for rolling application upgrades where the application is upgraded on one server group and then updated on a second server group, avoiding a complete service outage.</p>\n",
"<p>View and monitor runtime services, like log files, JVM metrics and subsystem specific runtime data.</p>",
"<p class=\"topology\">An overview of the hosts, server groups and servers defined in your domain with the server groups as columns and the hosts as rows. The servers are displayed according to their status:\n    <span class=\"status error\">error</span>,\n    <span class=\"status warning\">needs reload / restart</span>,\n    <span class=\"status suspended\">suspended</span>,\n    <span class=\"status ok\">up and running</span> and\n    <span class=\"status inactive\">stopped or disabled</span>.</p>\n<p>Select a host, server group or server to see additional information or execute operations.</p>",
"<p>Displays runtime metrics of connectors registered as ajp-listener, http-listener and https-connectors of a specific server.</p>",
"<p>The webserver (Undertow) contains many runtime metrics, split in the following sections:</p>\n<ul>\n    <li><strong>Application Security Domain</strong>: Displays the application security domain configuration and its associated deployments.</li>\n    <li><strong>Server</strong>: Displays runtime metrics of connectors registered as ajp-listener, http-listener and https-connectors of a specific server.</li>\n    <li><strong>Modcluster</strong>: Displays runtime metrics for balancers, nodes and contexts.</li>\n    <li><strong>Deployment</strong>: Displays runtime metrics for servlets and websockets as contained in deployments.</li>\n</ul>",
"<p>Workers are XNIO worker instances. An XNIO worker instance is an abstraction layer for the Java NIO APIs, which provide functionality such as management of IO and worker threads as well as SSL support. By default, ${build.shortName} provides single worker called <code>default</code>, but more can be defined.</p>"]