[
"<p>The batch subsystem is used to configure an environment for running batch applications. WildFly uses <a href=\"https://github.com/jberet/jsr352\" rel=\"nofollow\" target=\"_blank\">JBeret</a> for it's batch implementation. Specific information about JBeret can be found in the <a href=\"http://jberet.gitbooks.io/jberet-user-guide/content/\" rel=\"nofollow\" target=\"_blank\">user guide</a>.</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>WILDFLY_HOME/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 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 WildFly, and the related configuration provided by the EE subsystem.</li>\n</ul>",
"<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",
"<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>WILDFLY_HOME/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>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",
"<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>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>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>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>The Administrator role has unrestricted access to all resources and operations on the server except the audit logging system. The Administrator role has access to sensitive data and operations. This role can also configure the access control system. The Administrator role is only required when handling sensitive data or configuring users and roles.</p>\n<p>Administrators cannot access the audit logging system and cannot change themselves to the Auditor or SuperUser role.</p>",
"<p>The Auditor role has all the permissions of the Monitor role and can also view (but not modify) sensitive data, and has full access to the audit logging system. The Auditor role is the only role other than SuperUser that can access the audit logging system.</p>\n<p>Auditors cannot modify sensitive data or resources. Only read access is permitted.</p>",
"<p>The Deployer role has the same permissions as the Monitor, but can modify configuration and state for deployments and any other resource type enabled as an application resource.</p>",
"<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>The Maintainer role has access to view and modify runtime state and all configuration except sensitive data and operations. The Maintainer role is the general purpose role that doesn't have access to sensitive data and operation. The Maintainer role allows users to be granted almost complete access to administer the server without giving those users access to passwords and other sensitive information.</p>\n<p>Maintainers cannot access sensitive data or operations.</p>",
"<p>Users of the Monitor role have the fewest permissions and can only read the current configuration and state of the server. This role is intended for users who need to track and report on the performance of the server.</p>\n<p>Monitors cannot modify server configuration nor can they access sensitive data or operations.</p>",
"<p>The Operator role extends the Monitor role by adding the ability to modify the runtime state of the server. This means that Operators can reload and shutdown the server as well as pause and resume JMS destinations. The Operator role is ideal for users who are responsible for the physical or virtual hosts of the application server so they can ensure that servers can be shutdown and restarted corrected when needed.</p>\n<p>Operators cannot modify server configuration or access sensitive data or operations.</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>The SuperUser role has no restrictions and has complete access to all resources and operations of the server including the audit logging system. This role is equivalent to the administrator users of earlier versions. If RBAC is disabled, all management users have permissions equivalent to the SuperUser role.</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>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>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 JBoss EAP 6 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>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 JBoss EAP 6 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 JBoss EAP 6 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>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, WildFly 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 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>Provides an aggregated view on the subsystems in the domain. Select a subsystem to see the statistics for all running servers in the domain.</p>\n",
"<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 or timed out</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>Click on a host, server group or server to see additional information or execute operations.</p>"]