schema.jboss-as-config_2_1.xsd Maven / Gradle / Ivy
Root element for the master document specifying the core configuration
for the servers in a domain. There should be one such master
document per domain, available to the host controller that
is configured to act as the domain controller.
The name to use for the domain controller. Useful for administrators who need to work with multiple domains.
Root element for a document configuring a host controller and
the group of servers under the control of that host controller.
The standard usage would be for a domain to have one such host controller
on each physical (or virtual) host machine. Emphasis in this
document is on enumerating the servers, configuring items that
are specific to the host environment (e.g. IP addresses), and
on any server-specific configuration settings.
The name to use for this host's host controller. Must be unique across the domain.
If not set, defaults to the runtime value "HOSTNAME" or "COMPUTERNAME" environment variables,
or, if neither environment variable is present, to the value of InetAddress.getLocalHost().getHostName().
If the special value "jboss.domain.uuid" is used, a java.util.UUID will be created
and used, based on the value of InetAddress.getLocalHost().
Root element for a document specifying the configuration
of a single "standalone" server that does not operate
as part of a domain.
Note that this element is distinct from the 'serverType'
specified in this schema. The latter type forms part of the
configuration of a server that operates as part of a domain.
The name to use for this server.
If not set, defaults to the runtime value "HOSTNAME" or "COMPUTERNAME" environment variables,
or, if neither environment variable is present, to the value of InetAddress.getLocalHost().getHostName().
If the special value "jboss.domain.uuid" is used, a java.util.UUID will be created
and used, based on the value of InetAddress.getLocalHost().
Domain-wide default configuration settings for the management of standalone servers and a Host Controller.
The centralized configuration for the management of a Host Controller.
The centralized configuration for the management of standalone server.
The centralized configuration for domain-wide management.
The LDAP connection definition.
The name of this connection.
The URL to connect to ldap.
The distinguished name to use when connecting to LDAP to perform searches.
The credential to use when connecting to perform a search.
A reference to a security realm to obtain an initialised SSLContext to use when establishing a
connection to the LDAP server.
The realm referenced here MUST NOT be a realm that is also configured to use this connection.
The initial context factory to establish the LdapContext.
Defines how referrals should be handled if encountered when using this connection, by default they are
ignored.
If set to FOLLOW then if referrals are encountered using this connection they will automatically be followed. Apart from the alternative
location if set to FOLLOW it is assumed the remainder of settings for this connection can be applied to the connection
for the referral.
Finally if this option is set to THROW an exception is thrown by the connection when referrals are encountered, the security realm will then
use information from the Exception to identify an alternative connection to use.
A space seaparated list of URLs that this connection will handle referrals for.
Note: Only the prototocol, host and port should be specified in the URLs. The LDAP connections are not ordered so a single URL should only
be listed against a single connection, if multpile connections are defined as handling the same URL which connection will be selected is undefined
and subject to change.
A list of URLs.
Configuration of a security realm for securing access to the management interfaces.
The name of this security-realm, each security-realm must be assigned a unique name.
List of modules to be searched for supported security realm plug-ins.
The name of the module.
This type defines which plug in will be used to handle either the loading of the
authentication data or authorization data during the authentication process.
The properties to be made available to the plug-in.
The short name of the plug-in as already dynamically registered by being referenced
in the plug-ins element.
By default plug-ins will be assumed to be used with the DIGEST authentication mechanism,
this attribute can override the plug-in for use with the PLAIN mechanism.
Configuration defining how to load the authorization information for the authenticated user.
After a user has been authenticated additional information such as groups or roles can be loaded and
associated with the user for subsequent authorization checks, this type is used to define
how the roles are loaded.
The membership information loaded is the authenticated identities group membership, commonly there
is a 1:1 mapping between group membership and the applicable roles, this attribute allows for the
mapping to be performed automatically.
Configuration of the identities that represent the server.
Configuration of the secret/password-based identity of this server.
The secret / password - Base64 Encoded
Configuration of the SSL identity of this server.
The protocol to use when creating the SSLContext.
The keystore configuration for the server.
The password to open the keystore.
This is a more complex keystore definition which also allows for an alias
and key password to be specified.
The alias of the entry to use from the keystore, if specified all remaining
entries in the keystore will be ignored.
Note: The use of aliases is only available for JKS based stores, for other store types this will be ignored.
The password to use when loading keys from the keystore.
An extension of keyStoreType used by realms.
The provider for the store, the default is a file based JKS store.
The path of the keystore, this is required if the provider is JKS otherwise it will be ignored.
The name of another previously named path, or of one of the
standard paths provided by the system. If 'relative-to' is
provided, the value of the 'path' attribute is treated as
relative to the path specified by this attribute.
An extension of keyStoreType used by realms.
The provider for the store, the default is a file based JKS store.
The path of the keystore, this is required if the provider is JKS otherwise it will be ignored.
The name of another previously named path, or of one of the
standard paths provided by the system. If 'relative-to' is
provided, the value of the 'path' attribute is treated as
relative to the path specified by this
attribute.
An extension of keyStoreType used for audit logging configuration.
The path of the keystore, this is required if the provider is JKS otherwise it will be ignored.
The name of another previously named path, or of one of the
standard paths provided by the system. If 'relative-to' is
provided, the value of the 'path' attribute is treated as
relative to the path specified by this
attribute.
An audit specific extension of the extended key store type.
The path of the keystore, this is required if the provider is JKS otherwise it will be ignored.
The name of another previously named path, or of one of the
standard paths provided by the system. If 'relative-to' is
provided, the value of the 'path' attribute is treated as
relative to the path specified by this
attribute.
This type definition is used to control the local authentication mechanism.
When using the local mechanism it is optional for the client side to send an
authentication user name - this attribute specifies the user name to be assumed
if the remote client does not send one.
A comma separated list of users that can be specified by the client when connecting
using the local authentication mechanism.
If a default user has been specified then that user is automatically added to the
allowed list. If both default-user and allowed-users are omitted despite the mechanism
being enabled no incoming connection attemps using the mechanism will succeed.
If any user name should be accepted the value should be set to "*".
After authentication has occurred the username of the authenticated user is then passed
to the configured authorization mechanism to load the group membership information for
the authenticated user.
As the local authenitication mechanism is a special case with an artificial identifier
for the authenticated user this can cause problems during group loading where a user
with the same name does not exist.
Setting this attribute to 'false' will disable the loading of groups for the local user.
Configuration of the server side authentication mechanisms.
Optionally one truststore can be defined and one username/password based store can be defined.
Authentication will first attempt to use the truststore and if this is not available will fall back
to the username/password authentication.
If none of these are specified the only available mechanism will be the local mechanism for the
Native interface and the HTTP interface will not be accessible.
Configuration of a keystore to use to create a trust manager to verify clients.
Configuration to enable the local authentication mechanism, if this element
is omitted then local authentication will be disabled.
Definition to use a JAAS based configuration for authentication.
The name identifying the jaas configuration of LoginModules.
The base type used for LDAP authentication and authorization definitions.
The name of the connection to use to connect to LDAP.
Definition to use LDAP as the user repository.
The name of the attribute to search for the user, this filter will then perform
a simple search where the username entered by the user matches the attribute
specified here.
The fully defined filter to be used to search for the user based on their entered
user ID. The filter should contain a variable in the form {0} - this will be
replaced with the username supplied by the user.
The base distinguished name to commence the search for the user.
Should the search be recursive.
The name of the attribute which is the users distinguished name.
This attribute is independent of the filtering configuration, if this attribute is set then after
the users entry in LDAP is identified this attribute will be read to discover the users actual username.
This is optional but could be useful in a few scenarios e.g. authenticate with an e-mail address but be identified by a username,
correcting the case of an entered username or even in the future ensuring consistency after a different
authentication approach.
Note: This value will become the username used for any subsequent group loading.
Should users be allowed to supply an empty password? Some LDAP servers will
allow an anonymous bind
so an empty password could appear as a successful authentication
even though no password was sent to verify.
Base type of common attributes used for
LDAP searches.
The base distinguished name to commence the search.
Should the search be recursive.
Search definition to locate a user from
the supplied username.
The attribute on the user entry which is their distinguished name.
The name of the attribute to search for the user, this filter will then perform a
simple search where the username entered by the user matches the attribute specified here.
The attribute on the user entry which is their distinguished name.
The fully defined filter to be used to search for the user based on their entered user
ID. The filter should contain a variable in
the form {0} - this will be replaced with the username
supplied by the user.
If the username was already converted to a distinguished name during authentication this attribute forces
the search to be repeated
before loading group information.
This would most likely be required if a different LDAP server
was being used to load group information as was used for authentication.
The attribute on the group entry that references the principal.
Group search definition where an attribute on the group references the principal.
Should searching use the simple name or distinguished name of the principal.
Group search definition where an attribute on the principal references the group.
The name of the attribute on the principal that references the group.
After a referral has been followed should the original LDAP connection defined for
group loading be used or should the connection from the last referral be used instead.
By default each attempt to load a group will revert back to the original connection as defined
in the configuration, however setting this attribute to false will cause subsequent searches to
use the connection of the last referral.
Defines the form the name of the group should take, either it's simple name or it's complete
distringuished name.
Should any group searching be iterative, i.e. should additional searches be performed to identify the
groups that the groups are members of.
On the group entry which of it's attributes is it's distingushed name.
On the group entry which of it's attributes is it's simple name.
The type of cache, by-search-time and the entries are evicted based on search time and search order, by-access-time and
the entires are evicted based on the time they were last accessed.
The time until an entry is evicted from the cache in seconds, a time of <=0 means no eviction based
on time.
If items are not going to be evicted based on time then max-cache-size should be set otherwise the cache
could grow without restriction.
Note: The eviction time is handled on a best-efforts basis, during times of many concurrent authentications
there could be small delay before the evictions fire.
Should non IO failures be cached? e.g. should searches for a non-existent user be cached to avoid
repeating the same search.
The maximum number of items to hold in the cache before items are evicted, or <=0 where the size of
the cache is unlimited.
This value should be higher than the anticipated cache size for current users otherwise items
will be continually evicted.
A set of users
A single user.
The users username.
Declaration of a location of a properties file.
The name of another previously named path, or of one of the
standard paths provided by the system. If 'relative-to' is
provided, the value of the 'path' attribute is treated as
relative to the path specified by this attribute.
The path of the properties file.
Declaration of users stored within properties files.
The entries within the properties file are username={credentials} with each user
being specified on it's own line.
Are the credentials within the properties file stored in plain text, if not
the {credential} is expected to be the hex encoded Digest hash
of 'username : realm : password'.
Declaration of management operation audit logging formatters.
Shared configuration for audit log formatters..
The name of the formatter. Must be unique across all types of formatter
(there is only the JSON formatter at present but more are planned for the
future)
Whether or not to include the date in the formatted log record
The date format to use as understood by {@link java.text.SimpleDateFormat}.
Will be ignored if include-date="false".
The separator between the date and the rest of the formatted log message.
Will be ignored if include-date="false".
Configuration of a JSON formatter for the audit log.
If true will format the JSON on one line. There may still be
values containing new lines, so if having the whole record on
one line is important, set escape-new-line or escape-control-characters to true.
If true will escape all new lines with the ascii code in octal,
e.g. #012.
If true will escape all control characters (ascii entries with a decimal
value less than 32) with the ascii code in octal, e.g.'\n\ becomes '#012'.
If this is true, it will override escape-new-line="false"
Declaration of management operation audit logging handlers.
Common configuration of a handler for the audit log.
The name of the handler. The name must be unique across all types of handler.
The name of the formatter to use for the handler.
The number of logging failures before this handler is disabled.
Configuration of a simple file handler for the audit log. This writes to a local file.
The path of the audit log.
The name of another previously named path, or of one of the
standard paths provided by the system. If 'relative-to' is
provided, the value of the 'path' attribute is treated as
relative to the path specified by this attribute.
Configuration of a syslog file handler for the audit log on a server. This writes to syslog server.
The configuration of the protocol to use communication with the syslog server. See your
syslog provider's documentation for configuration options.
The format to use for the syslog messages. See your syslog provider's documentation for what is supported.
Format the syslog data according to the RFC-5424 standard
Format the syslog data according to the RFC-3164 standard
The maximum length in bytes a log message, including the header, is allowed to be. If undefined, it will default to 1024 bytes if the syslog-format is RFC3164, or 2048 bytes if the syslog-format is RFC5424.
Whether or not a message, including the header, should truncate the message if the length in bytes is greater than the maximum length. If set to false messages will be split and sent with the same header values.
The facility to use for syslog logging as defined in section 6.2.1 of RFC-5424, and section 4.1.1 of RFC-3164.
The numerical values in the enumeration entries, is the numerical value as defined in the RFC.
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
The application name to add to the syslog records as defined in section 6.2.5 of RFC-5424. If not specified it will default to the name of the product.
The host of the syslog server.
The port of the syslog server.
Configure udp as the protocol for communicating with the syslog server
Configure tcp as the protocol for communicating with the syslog server
The message transfer setting as described in section 3.4 of RFC-6587. See your syslog provider's
documentation for what is supported
Use the octet counting format for message transfer as described in section 3.4.1 of RFC-6587.
Use the non-transparent-framing format for message transfer as described in section 3.4.1 of RFC-6587.
Configure tls as the protocol for communicating with the syslog server
Configuration of a keystore to use to create a trust manager to verify the server
certificate for encrypted communications. If the server certificate is signed off by a
signing authority, tls can be used without a truststore.
Configuration of a keystore containing a client certificate and a private key, e.g. in
PKCS12 format. This turns on authenticating the clients against the syslog server.
Declaration of management operation audit logging configuration coming from the model controller core.
Whether operations should be logged on boot.
Whether operations that do not modify the configuration or any runtime services should be logged.
Whether audit logging is enabled.
References to audit-log-handlers defined in the audit-log-handlers section
A reference to an audit-log-handler defined in the audit-log-appenders section
The security realm to use for this management interface, the capabilities
of the security realm will be queried to identify the authentication mechanism(s) to
offer.
Configuration of a host's exposed native management interface.
Configuration of the socket used by host or standalone server's exposed management interface.
Network interface on which the host's socket for
management communication should be opened.
Configuration of the socket used by host or standalone server's exposed HTTP management interface.
Port on which the host's socket for native
management communication should be opened.
Configuration of a host's exposed HTTP management interface.
Configuration of the socket used by host or standalone server's exposed HTTP management interface.
Port on which the host's socket for
management communication should be opened.
If not specified the port will not be opened.
Port on which the host's socket for HTTPS
management communication should be opened.
If not specified the port will not be opened.
If specified the security-realm will be required to obtain
the SSL configuration.
Configuration of the socket used by host or standalone server's exposed HTTP management interface.
Configuration of the socket to use for the native management interface is a choice
between a direct configuration of the address and port, or a reference to a socket-binding
configuration in the server's socket-binding-group element. The latter is the recommended
approach as it makes it easier to avoid port conflicts by taking advantage of the
socket-binding-group's port-offset configuration. Direct configuration of the address and
ports is deprecated and is only provided to preserve backward compatibility.
Deprecated. Use 'socket-binding'
Reference to the configuration of the socket to be used by a standalone server's exposed native management interface.
Name of a socket-binding configuration declared in the server's socket-binding-group.
Configuration of a standalone server's exposed HTTP/HTTPS management interface.
Configuration of the socket to use for the HTTP/HTTPS management interface is a choice
between a direct configuration of the address and ports, or a reference to socket-binding
configurations in the server's socket-binding-group element. The latter is the recommended
approach as it makes it easier to avoid port conflicts by taking advantage of the
socket-binding-group's port-offset configuration. Direct configuration of the address and
ports is deprecated and is only provided to preserve backward compatibility.
Deprecated. Use 'socket-binding'
Reference to the configurations of the sockets to be used by a standalone server's exposed HTTP and HTTPS management interface.
Name of a socket-binding configuration declared in the server's socket-binding-group to use for a HTTP socket.
Name of a socket-binding configuration declared in the server's socket-binding-group to use for a HTTPS socket.
Note: When specified the interface must also be configured to reference a security realm with a configured keystore.
Makes the native management interface available via the connectors set up in the remoting subsystem,
using the remoting subsystem's endpoint. This should only be used for a server not for a HC/DC.
The remote domain controller's host name. If not set, a discovery option must be provided,
or the --cached-dc startup option must be used, or the --admin-only startup option must be used
with the 'admin-only-policy' attribute set to a value other than 'fetch-from-master'.
The remote domain controller's port. If not set, a discovery option must be provided,
or the --cached-dc startup option must be used, or the --admin-only startup option must be used
with the 'admin-only-policy' attribute set to a value other than 'fetch-from-master'.
Set to true to instruct the master Host Controller to automatically not forward configuration and
operations for profiles, socket binding groups and server groups which do not affect our servers.
Provides names of direct child resources of the domain root resource requests for which the
Host Controller should ignore. Only relevant on a slave Host Controller. Configuring such
"ignored resources" may help allow a Host Controller from an earlier release to function as a
slave to a master Host Controller running a later release, by letting the slave ignore portions
of the configuration its version of the software cannot understand. This strategy can only be
successful if the servers managed by the slave Host Controller do not reference any of the
ignored configuration.
Supports the following attributes:
type -- the type of resource (e.g. 'profile' or 'socket-binding-group') certain instances of which
should be ignored. The value corresponds to the 'key' portion of the first element in the
resource's address (e.g. 'profile' in the address /profile=ha/subsystem=web)
wildcard -- if 'true', all resources of the given type should be ignored.
Child elements list the names of specific instances of the given type of resource
that should be ignored. Each element in the list corresponds to the 'value' portion of
the first element in the resource's address (e.g. 'ha' in the address /profile=ha/subsystem=web.)
The name of a specific instances of a particular type of resource that should be ignored.
The 'name' attribute corresponds to the 'value' portion of the first element in the resource's address
(e.g. 'ha' in the address /profile=ha/subsystem=web.)
The name for this domain controller discovery option.
The fully qualified class name for the DiscoveryOption implementation.
The module from which the DiscoveryOption implementation should be loaded. If not provided,
the DiscoveryOption implementation must be available from the Host Controller's own module.
The name for this domain controller discovery option.
The remote domain controller's host name.
The remote domain controller's port.
Indicates each server's writable directories should be grouped under the server's name
in the domain/servers directory. This is the default option.
Indicates each server's writable directories should be grouped based on their "type"
(i.e. "data", "log", "tmp") with directories of a given type for all servers appearing
in the domain level directory for that type, e.g. domain/data/servers/server-name.
Contains a list of extension modules.
A module that extends the standard capabilities of a domain
or a standalone server.
The name of the module
The name of the server group
The name of the profile this server is running.
Set to true to have servers belonging to the server group connect back to the host controller using the
endpoint from their remoting subsystem. The subsystem must be preset for this to
work.
Contains a list of deployments that have been mapped to a server-group.
A deployment that has been mapped to a server group.
Whether the deployment deploy automatically when the server starts up.
Unique identifier of the deployment. Must be unique across all deployments.
Name by which the deployment will be known within a running server.of the deployment.
Does not need to be unique across all deployments in the domain, although it must be unique within
an individual server. For example, two different deployments running on different servers in
the domain could both have a 'runtime-name' of 'example.war', with one having a 'name'
of 'example.war_v1' and another with an 'name' of 'example.war_v2'.
Contains a list of deployments that have been mapped to a server.
A deployment that has been mapped to a server.
Whether the deployment deploy automatically when the server starts up.
The checksum of the content
Archived content found on the filesystem
Exploded content found on the filesystem
Contains a list of domain-level deployments
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),
which can be enabled or disabled on a domain level.
The domain controller/server bootstrap configuration
The URI for bootstrapping a domain server
Contains a list of profiles available for use in the domain
Contains a list of subsystems
A profile declaration may include configuration
elements from other namespaces for the subsystems that make up the profile.
Name of the profile
Contains a list of subsystems
A profile declaration may include configuration
elements from other namespaces for the subsystems that make up the profile.
Contains a list of socket binding groups
Contains a list of socket configurations
Name of an interface that should be used as the interface for
any sockets that do not explicitly declare one.
Contains a list of socket configurations
Name of an interface that should be used as the interface for
any sockets that do not explicitly declare one.
Increment to apply to the base port values defined in the
socket group to derive the values to use on this
server.
Configuration information for a socket.
Specifies zero or more client mappings for this socket binding.
A client connecting to this socket should use the destination address
specified in the mapping that matches its desired outbound interface.
This allows for advanced network topologies that use either network
address translation, or have bindings on multiple network interfaces
to function.
Each mapping should be evaluated in declared order, with the first successful
match used to determine the destination.
Name of the interface to which the socket should be bound, or, for multicast
sockets, the interface on which it should listen. This should
be one of the declared interfaces.
Number of the port to which the socket should be bound.
Whether the port value should remain fixed even if numerically offsets
are applied to the other sockets in the socket group..
Multicast address on which the socket should receive multicast
traffic. If unspecified, the socket will not be configured
to receive multicast.
Port on which the socket should receive multicast
traffic. Must be configured if 'multicast-address' is configured.
Type definition for a client mapping on a socket binding. A client
mapping specifies how external clients should connect to this
socket's port, provided that the client's outbound interface
match the specified source network value.
Source network the client connection binds on. This value is in
the form of ip/netmask. A client should match this value against
the desired client host network interface, and if matched the
client should connect to the corresponding destination values.
If omitted this mapping should match any interface.
The destination address that a client should connect to if the
source-network matches. This value can either be a hostname or
an IP address.
The destination port that a client should connect to if the
source-network matches.
If omitted this mapping will reuse the effective socket binding
port.
Configuration information for an outbound socket.
The name of the outbound socket binding
The name of the interface that should be used for setting up the source address of the
outbound socket. This should be one of the declared interfaces.
The port number that will be used for setting the source address of the outbound socket. If the
source-interface attribute has been specified and the source-port attribute equals 0 or is absent,
then the system uses an ephemeral port while binding the socket to a source address.
Whether the source-port value should remain fixed even if the socket binding group specifies
a port offset
The remote server address to which the outbound socket has to be connect.
The address can be either an IP address of the host server of the hostname of the server
The remote port to which the outbound socket has to connect.
The reference to a socket binding that has to be used as the destination for the outbound
socket binding. This socket binding name should belong to the same socket binding group
to which this local destination client socket belongs.
The socket group to use for the server group or server.
Increment to apply to the base port values defined in the
referenced socket group to derive the values to use on this
server.
A list of named network interfaces. The interfaces may or may
not be fully specified (i.e. include criteria on how to determine
their IP address.)
A named network interface, but without any criteria
for determining the IP address to associate with that interface.
Acts as a placeholder in the model (e.g. at the domain level)
until a fully specified interface definition is applied at a
lower level (e.g. at the server level, where available addresses
are known.)
A list of fully specified named network interfaces.
A named network interface, along with required criteria
for determining the IP address to associate with that interface.
A set of criteria that can be used at runtime to determine
what IP address to use for an interface.
Either an IP address in IPv6 or IPv4 dotted decimal notation,
or a hostname that can be resolved to an IP address.
The name of a network interface (e.g. eth0, eth1, lo).
A regular expression against which the names of the network
interfaces available on the machine can be matched to find
an acceptable interface.
A network IP address and the number of bits in the
address' network prefix, written in "slash notation";
e.g. "192.168.0.0/16".
Empty element indicating that part of the selection criteria
for an interface should be whether or not it is a loopback
interface.
A loopback address that may not actually be configured on the machine's loopback interface.
Differs from inet-addressType in that the given value will be used even if no NIC can
be found that has the IP address associated with it.
An IP address in IPv6 or IPv4 dotted decimal notation.
Empty element indicating that part of the selection criteria
for an interface should be whether or not it supports
multicast.
Empty element indicating that part of the selection criteria
for an interface should be whether or not it is a point-to-point
interface.
Empty element indicating that part of the selection criteria
for an interface should be whether or not it is currently up.
Empty element indicating that part of the selection criteria
for an interface should be whether or not it is a virtual
interface.
Empty element indicating that part of the selection criteria
for an interface should be whether or not it has a publicly
routable address.
Empty element indicating that part of the selection criteria
for an interface should be whether or not an address associated
with it is site-local.
Empty element indicating that part of the selection criteria
for an interface should be whether or not an address associated
with it is link-local.
Empty element indicating that sockets using this interface
should be bound to the IPv6 wildcard address (::).
Deprecated. The name of this type implies sockets will be
reachable only via IPv6 addresses and not via IPv4, but this
is not the case. Since using any-addressType provides the same effect,
this any-ipv6-addressType will be removed in a future release.
Empty element indicating that sockets using this interface
should be bound to the IPv4 wildcard address (0.0.0.0).
Deprecated. In the absence of -Djava.net.preferIPv4Stack=true,
the JVM cannot be instructed to bind a socket to all IPv4 addresses,
but only to IPv4 addresses, so the intended semantic cannot be
obtained via this setting alone. Since using any-addressType
and setting -Djava.net.preferIPv4Stack=true provides the same effect,
this any-ipv4-addressType will be removed in a future release.
Empty element indicating that sockets using this interface
should be bound to a wildcard address. The IPv6 wildcard
address (::) will be used unless the java.net.preferIpV4Stack
system property is set to true, in which case the IPv4
wildcard address (0.0.0.0) will be used. If a socket is
bound to an IPv6 anylocal address on a dual-stack machine,
it can accept both IPv6 and IPv4 traffic; if it is bound to
an IPv4 (IPv4-mapped) anylocal address, it can only accept
IPv4 traffic.
Configuration information for a socket.
Name of the interface to which the socket should be bound, or, for multicast
sockets, the interface on which it should listen. This should
be one of the declared interfaces.
Number of the port to which the socket should be bound.
Whether the port value should remain fixed even if numerically offsets
are applied to the other sockets in the socket group..
Multicast address on which the socket should receive multicast
traffic. If unspecified, the socket will not be configured
to receive multicast.
Port on which the socket should receive multicast
traffic. If unspecified, the socket will not be configured
to receive multicast.
A list of named filesystem paths. The paths may or may
not be fully specified (i.e. include the actual paths.)
A named filesystem path, but without a requirement to specify
the actual path. If no actual path is specified, acts as a
as a placeholder in the model (e.g. at the domain level)
until a fully specified path definition is applied at a
lower level (e.g. at the host level, where available addresses
are known.)
The name of the path. Cannot be one of the standard fixed paths
provided by the system:
jboss.home.dir - the root directory of the JBoss AS distribution
user.home - user's home directory
user.dir - user's current working directory
java.home - java installation directory
jboss.server.base.dir - root directory for an individual server
instance
Note that the system provides other standard paths that can be
overridden by declaring them in the configuration file. See
the 'relative-to' attribute documentation for a complete
list of standard paths.
The actual filesystem path. Treated as an absolute path, unless the
'relative-to' attribute is specified, in which case the value
is treated as relative to that path.
If treated as an absolute path, the actual runtime pathname specified
by the value of this attribute will be determined as follows:
If this value is already absolute, then the value is directly
used. Otherwise the runtime pathname is resolved in a
system-dependent way. On UNIX systems, a relative pathname is
made absolute by resolving it against the current user directory.
On Microsoft Windows systems, a relative pathname is made absolute
by resolving it against the current directory of the drive named by the
pathname, if any; if not, it is resolved against the current user
directory.
The name of another previously named path, or of one of the
standard paths provided by the system. If 'relative-to' is
provided, the value of the 'path' attribute is treated as
relative to the path specified by this attribute. The standard
paths provided by the system include:
jboss.home.dir - the root directory of the JBoss AS distribution
user.home - user's home directory
user.dir - user's current working directory
java.home - java installation directory
jboss.server.base.dir - root directory for an individual server
instance
jboss.server.config.dir - directory in which server configuration
files are stored.
jboss.server.data.dir - directory the server will use for persistent
data file storage
jboss.server.log.dir - directory the server will use for
log file storage
jboss.server.temp.dir - directory the server will use for
temporary file storage
jboss.domain.servers.dir - directory under which a host controller
will create the working area for
individual server instances
A list of named filesystem paths.
A named filesystem path.
The name of the path. Cannot be one of the standard fixed paths
provided by the system:
jboss.home.dir - the root directory of the JBoss AS distribution
user.home - user's home directory
user.dir - user's current working directory
java.home - java installation directory
jboss.server.base.dir - root directory for an individual server
instance
Note that the system provides other standard paths that can be
overridden by declaring them in the configuration file. See
the 'relative-to' attribute documentation for a complete
list of standard paths.
The actual filesystem path. Treated as an absolute path, unless the
'relative-to' attribute is specified, in which case the value
is treated as relative to that path.
If treated as an absolute path, the actual runtime pathname specified
by the value of this attribute will be determined as follows:
If this value is already absolute, then the value is directly
used. Otherwise the runtime pathname is resolved in a
system-dependent way. On UNIX systems, a relative pathname is
made absolute by resolving it against the current user directory.
On Microsoft Windows systems, a relative pathname is made absolute
by resolving it against the current directory of the drive named by the
pathname, if any; if not, it is resolved against the current user
directory.
Note relative path declarations have to use '/' as file separator.
The name of another previously named path, or of one of the
standard paths provided by the system. If 'relative-to' is
provided, the value of the 'path' attribute is treated as
relative to the path specified by this attribute. The standard
paths provided by the system include:
jboss.home.dir - the root directory of the JBoss AS distribution
user.home - user's home directory
user.dir - user's current working directory
java.home - java installation directory
jboss.server.base.dir - root directory for an individual server
instance
jboss.server.config.dir - directory in which server configuration
files are stored.
jboss.server.data.dir - directory the server will use for persistent
data file storage
jboss.server.log.dir - directory the server will use for
log file storage
jboss.server.temp.dir - directory the server will use for
temporary file storage
jboss.domain.servers.dir - directory under which a host controller
will create the working area for
individual server instances
Allows the full set of JVM options to be set via the jvm schema elements
Sets a subset of the JVM options via the jvm schema elements
Initial JVM heap size
Maximum JVM heap size
JVM option value
JVM agent lib value
JVM agent path value
JVM javaagent value
Configuration of if a classification's read is sensitive
Configuration of if a classification's write is sensitive
Configuration of if a classification's addressability is sensitive
The name of the constraint, must be unique for each name
'core' or the name of the subsystem defining the constraint
The name of the constraint, must be unique for each name
'core' or the name of the subsystem defining the constraint