Brian Stansberry [
https://community.jboss.org/people/brian.stansberry] modified the
document:
"Detyped Description of the AS 7 Management Model"
To view the document, visit:
https://community.jboss.org/docs/DOC-16317
--------------------------------------------------------------
h3. Deprecated, instead see
https://docs.jboss.org/author/display/AS71/Description+of+the+Management+... for 7.1 or,
for 7.2,
https://docs.jboss.org/author/display/AS72/Description+of+the+Management+....
AS 7's management API will naturally include the ability for clients to query the
management system to discover meta-information about the management model; i.e. what
resources are available and what attributes and operations they expose. These details will
be returned in a detyped form, either using the
https://github.com/jbossas/jboss-dmr
jboss-dmr library or JSON. (A JMX interface based on open mbeans will also be provided;
most concepts in this article map naturally to JMX.) The purpose of this article is to
describe the detyped representation of the API.
Readers are encouraged to look at the example detyped descriptions of parts of the
management API at the bottom before reading the details.
Before getting into the details of the meta-information, first a couple quick examples on
how to access it.
h5. Reading Management Model Descriptions via the raw Management API
The client must have maven artifact org.jboss.as:jboss-as-controller-client and its
dependencies on the classpath.
1) Create a management client that can connect to your target process's native
management socket (which can be an individual standalone mode server, or, in a domain mode
environment, the Domain Controller or any Host Controller:
ModelControllerClient client =
ModelControllerClient.Factory.create(InetAddress.getByName("localhost"), 9999);
The address and port are what is configured in the target process'
<management-apis><native-api.../> element.
2) Create an operation request object using the org.jboss.dmr.ModelNode class:
ModelNode op = new ModelNode();
op.get("operation").set("read-resource-description");
op.get("recursive").set(true);
op.get("operations").set(true);
ModelNode address = op.get("address");
address.add("subsystem", "web");
address.add("connector", "http");
See
https://community.jboss.org/docs/DOC-16336 http://community.jboss.org/docs/DOC-16336
for basic background on the format of an operation request. The key thing here is we are
executing the "read-resource-description" operation. That operation can be
targetted at any address in the management model; here we are targetting it at the
resource for the web subsystem's http connector.
The request includes two optional parameters:
* recursive -- true means you want the description of child resources under this resource.
Default is false
* operations -- true means you want the description of operations exposed by the resource
to be included. Default is false.
3) Execute the operation and manipulate the result:
ModelNode returnVal = client.execute(op);
System.out.println(returnVal.get("result").toString());
See
https://community.jboss.org/docs/DOC-16354 http://community.jboss.org/docs/DOC-16354
for general details on the structure of the "returnVal" ModelNode.
h5. Reading Management Model Descriptions via the CLI
See
https://community.jboss.org/docs/DOC-16581 http://community.jboss.org/docs/DOC-16581
for basics on using the CLI.
Once you've launched the CLI the syntax for the command shown above would be:
[localhost:9999 /]
/subsystem=web/connector=http:read-resource-description(recursive=true,operations=true)
h3.
h3. Description of addressable portions of the management model
All portions of the management model exposed by AS 7 are addressable via an ordered list
of key/value pairs. For each addressable portion of the model, the following descriptive
information will be available:
* description -- String -- text description of this portion of the model
* head-comment-allowed -- boolean -- indicates whether this portion of the model can store
an XML comment that would be written in the persistent form of the model (e.g. domain.xml)
before the start of the XML element that represents this portion of the model. This item
is optional, and if not present defaults to true. +*(Note: storing XML comments in the
in-memory model is not currently supported and likely will not be supported in AS 7.1.
This description key is for future use.)*+
* tail-comment-allowed -- boolean -- similar to head-comment-allowed, but indicates
whether a comment just before the close of the XML element is supported. A tail comment
can only be supported if the element has child elements, in which case a comment can be
inserted between the final child element and the element's closing tag. This item is
optional, and if not present defaults to true. +*(Note: storing XML comments in the
in-memory model is not currently supported and likely will not be supported in AS 7.1.
This description key is for future use.)*+
* attributes -- Map of String (the attribute name) to complex structure -- the
configuration attributes available in this portion of the model. See below for the
representation of each attribute.
* operations -- Map of String (the operation name) to complex structure -- the operations
that can be targetted at this address. See below for the representation of each
operation.
* children -- Map of String (the type of child) to complex structure -- the relationship
of this portion of the model to other addressable portions of the model. See below for the
representation of each child relationship.
{
"description => "A managable resource",
"tail-comment-allowed" => false,
"attributes" => {
"foo" => {
.... details of attribute foo
}
},
"operations" => {
"start" => {
.... details of the start operation
}
},
"children" => {
"bar" => {
.... details of the relationship with children of type "bar"
}
}
}
h4. Description of an Attribute
An attribute is a portion of the management model that is not directly addressable.
Instead, it is conceptually a property of an addressable part of the model. For each
attribute portion of the model, the following descriptive information will be available:
* description -- String -- text description of the attribute
* type -- org.jboss.dmr.ModelType -- the type of the attribute value. One of the enum
values BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LIST, LONG, OBJECT,
PROPERTY, STRING. Most of these are self-explanatory. An OBJECT will be represented in the
detyped model as a map of string keys to values of some other legal type, conceptually
similar to a javax.management.openmbean.CompositeData. A PROPERTY is a single key/value
pair, where the key is a string, and the value is of some other legal type.
* value-type -- ModelType or complex structure -- Only present if type is LIST or OBJECT.
If type is LIST or all the values of the OBJECT type are of the same type, this will be
one of the ModelType enums BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LONG,
STRING. Otherwise, value-type will detail the structure of the attribute value,
enumerating the value's fields and the type of their value.
* expressions-allowed -- boolean -- indicates whether the value of the attribute may be of
type ModelType.EXPRESSION, instead of its standard type (see type and value-type above for
discussion of an attribute's standard type.) A value of ModelType.EXPRESSION contains
a system-property substitution expression that the server will resolve against the
+server-side+ system property map before using the value. For example, an attribute named
max-threads may have an expression value of ${example.pool.max-threads:10} instead of just
10. Default value if not present is false.
* required -- boolean -- true if the attribute will always exist in a representation of
its portion of the model; false if it may not (implying a null value.) If not present,
true is the default.
* storage -- String -- Either "configuration" or "runtime". If
"configuration" it means the attribute's value is stored as part of the
persistent configuration (e.g. in domain.xml, host.xml or standalone.xml.) If
"runtime" the attribute's value is not stored in the persistent
configuration; the value only exists as long as the resource is running.
* access-type -- String -- One of "read-only", "read-write" or
"metric". Whether an attribute value can be written, or can only read. A
"metric" is a read-only attribute whose value is not stored in the persistent
configuration, and whose value may change due to activity on the server. If an attribute
is "read-write", the resource will expose an operation named
"write-attribute" whose "name" parameter will accept this
attribute's name and whose "value" parameter will accept a valid value for
this attribute. That operation will be the standard means of updating this attribute's
value.
* restart-required -- String -- One of "no-services", "all-services",
"resource-services" or "jvm". Only relevant to attributes whose
access-type is read-write. Indicates whether execution of a write-attribute operation
whose name parameter specifies this attribute requires a restart of services (or an entire
JVM) in order for the change to take effect in the runtime . See discussion of
"Applying Updates to Runtime Services" below. Default value is
"no-services".
* alternatives -- List of string -- Indicates an exclusive relationship between
attributes. If this attribute is defined, the other attributes listed in this
descriptor's value should be undefined (even if their required descriptor says true;
i.e. the presence of this attribute satisfies the requirement.) Default is undefined; i.e.
this does not apply to most attributes.
* requires -- List of string -- Indicates that if this attribute has a value (other than
undefined), the other attributes listed in this descriptor's value must also have a
value, even if their required descriptor says false. This would typically be used in
conjunction with alternatives. For example, attributes "a" and "b" are
required, but are alternatives to each other; "c" and "d" are
optional. But "b" requires "c" and "d", so if "b"
is used, "c" and "d" must also be defined. Default is undefined; i.e.
this does not apply to most attributes.
* head-comment-allowed -- boolean -- indicates whether the model can store an XML comment
that would be written in the persistent form of the model (e.g. domain.xml) before the
start of the XML element that represents this attribute. This item is optional, and if not
present defaults to *false*. (This is a different default from is used for an addressable
portion of the model, since model attributes often map to XML attributes, which don't
allow comments.) +*(Note: storing XML comments in the in-memory model is not currently
supported and likely will not be supported in AS 7.1. This description key is for future
use.)*+
* tail-comment-allowed -- boolean -- similar to head-comment-allowed, but indicates
whether a comment just before the close of the XML element is supported. A tail comment
can only be supported if the element has child elements, in which case a comment can be
inserted between the final child element and the element's closing tag. This item is
optional, and if not present defaults to *false*. (This is a different default from is
used for an addressable portion of the model, since model attributes often map to XML
attributes, which don't allow comments.) +*(Note: storing XML comments in the
in-memory model is not currently supported and likely will not be supported in AS 7.1.
This description key is for future use.)*+
* arbitrary key/value pairs that further describe the attribute value, e.g.
"max" => 2. See "Arbitrary Descriptors" below.
"foo" => {
"description" => "The foo",
"type" => INT,
"max" => 2
}
"bar" => {
"description" => "The bar",
"type" => OBJECT,
"value-type" => {
"size" => INT,
"color" => STRING
}
}
h3. Description of an Operation
An addressable portion of the model may have operations associated with it. The
description of an operation will include the following information:
* operation-name -- String -- the name of the operation
* description -- String -- text description of the operation
* request-properties -- Map of String to complex structure -- description of the
parameters of the operation. Keys are the names of the parameters, values are descriptions
of the parameter value types. See below for details on the description of parameter value
types.
* reply-properties -- complex structure, or empty -- description of the return value of
the operation, with an empty node meaning void.
* restart-required -- String -- One of "no-services", "all-services",
"resource-services" or "jvm". Indicates whether the operation makes a
configuration change that requires a restart of services (or an entire JVM) in order for
the change to take effect in the runtime. See discussion of "Applying Updates to
Runtime Services" below. Default value is "no-services".
h4. Description of an Operation Parameter or Return Value
* description -- String -- text description of the parameter or return value
* type -- org.jboss.dmr.ModelType -- the type of the parameter or return value. One of the
enum values BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LIST, LONG, OBJECT,
PROPERTY, STRING.
* value-type -- ModelType or complex structure -- Only present if type is LIST or OBJECT.
If type is LIST or all the values of the OBJECT type are of the same type, this will be
one of the ModelType enums BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LIST,
LONG, PROPERTY, STRING. Otherwise, value-type will detail the structure of the attribute
value, enumerating the value's fields and the type of their value.
* value-type -- ModelType or complex structure -- Only present if type is LIST or OBJECT.
If type is LIST or all the values of the OBJECT type are of the same type, this will be
one of the ModelType enums BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LONG,
STRING. Otherwise, value-type will detail the structure of the attribute value,
enumerating the value's fields and the type of their value.
* expressions-allowed -- boolean -- indicates whether the value of the the parameter or
return value may be of type ModelType.EXPRESSION, instead its standard type (see type and
value-type above for discussion of the standard type.) A value of ModelType.EXPRESSION
contains a system-property substitution expression that the server will resolve against
the +server-side+ system property map before using the value. For example, a parameter
named max-threads may have an expression value of ${example.pool.max-threads:10} instead
of just 10. Default value if not present is false.
* required -- boolean -- Only relevant to parameters. true if the parameter must be
present in the request object used to invoke the operation; false if it can omitted. If
not present, true is the default.
* nillable -- boolean -- true if null is a valid value. If not present, false is the
default.
* restart-required -- String -- One of "no-services", "all-services",
"resource-services" or "jvm". Only relevant to attributes whose
access-type is read-write. Indicates whether execution of a write-attribute operation
whose name parameter specifies this attribute requires a restart of services (or an entire
JVM) in order for the change to take effect in the runtime . See discussion of
"Applying Updates to Runtime Services" below. Default value is
"no-services".
* alternatives -- List of string -- Indicates an exclusive relationship between
parameters. If this attribute is defined, the other parameters listed in this
descriptor's value should be undefined (even if their required descriptor says true;
i.e. the presence of this parameter satisfies the requirement.) Default is undefined; i.e.
this does not apply to most parameters.
* requires -- List of string -- Indicates that if this parameter has a value (other than
undefined), the other parameters listed in this descriptor's value must also have a
value, even if their required descriptor says false. This would typically be used in
conjunction with alternatives. For example, parameters "a" and "b" are
required, but are alternatives to each other; "c" and "d" are
optional. But "b" requires "c" and "d", so if "b"
is used, "c" and "d" must also be defined. Default is undefined; i.e.
this does not apply to most parameters.
* arbitrary key/value pairs that further describe the attribute value, e.g.
"max" =>2. See "Arbitrary Descriptors" below.
{
"operation-name" => "incrementFoo",
"description" => "Increase the value of the 'foo' attribute
by the given amount",
"request-properties" => {
"increment" => {
"type" => INT,
"description" => "The amount to increment",
"required" => true
}},
"reply-properties" => {
"type" => INT,
"description" => "The new value",
}
}
{
"operation-name" => "start",
"description" => "Starts the thing",
"request-properties" => {},
"reply-properties" => {}
}
h2. Arbitrary Descriptors
The description of an attribute, operation parameter or operation return value type can
include arbitrary key/value pairs that provide extra information. Whether a particular
key/value pair is present depends on the context, e.g. a pair with key "max"
would probably only occur as part of the description of some numeric type.
Following are standard keys and their expected value type. If descriptor authors want to
add an arbitrary key/value pair to some descriptor and the semantic matches the meaning of
one of the following items, the standard key/value type must be used.
* min -- int -- the minimum value of some numeric type. The absence of this item implies
there is no minimum value.
* max -- int -- the maximum value of some numeric type. The absence of this item implies
there is no maximum value.
* min-length -- int -- the minimum length of some string, list or byte[] type. The absence
of this item implies a minimum length of zero.
* max-length -- int -- the maximum length of some string, list or byte[]. The absence of
this item implies there is no maximum value.
* nillable -- boolean -- whether null is a legal value. The absence of this item implies
false; i.e. null is not a legal value.
* allowed -- List -- a list of legal values. The type of the elements in the list should
match the type of the attribute.
* default -- the default value for the attribute if not present in the model
* unit - The unit of the value - e.g. ns, ms, s, m, h, KB, MB, TB. See *Measurement Units*
below.
h4. Measurement Units
Wherever possible, the description of an attribute, operation parameter or operation
return value should include the unit arbitrary descriptor. Valid values for this
descriptor are:
// Simple Unit Types
NONE
PERCENTAGE
// Absolute Sizes in Bytes (utilization)
BYTES
KILOBYTES
MEGABYTES
GIGABYTES
TERABYTES
PETABYTES
// Absolute Sizes in Bits (throughput)
BITS
KILOBITS
MEGABITS
GIGABITS
TERABITS
PETABITS
// Absolute Time - no display, only hints to the UI how to display
EPOCH_MILLISECONDS
EPOCH_SECONDS
// Relative Time
JIFFYS
NANOSECONDS
MICROSECONDS
MILLISECONDS
SECONDS
MINUTES
HOURS
DAYS
// Rate
PER_JIFFY
PER_NANOSECOND
PER_MICROSECOND
PER_MILLISECOND
PER_SECOND
PER_MINUTE
PER_HOUR
PER_DAY
// Temperature
CELSIUS
KELVIN
FAHRENHEIGHT
Legal values are listed in the
https://github.com/jbossas/jboss-as/blob/master/controller-client/src/mai...
MeasurementUnit enum. This enum is in the controller-client package, and is thus usable by
java-based management clients.
h2. Description of Parent/Child Relationships
The address used to target an addressable portion of the model must be an ordered list of
key value pairs. The effect of this requirement is the addressable portions of the model
naturally form a tree structure, with parent nodes in the tree defining what the valid
keys are and the children defining what the valid values are. The parent node also defines
the cardinality of the relationship. The description of the parent node includes a
children element that describes these relationships:
{
....
"children" => {
"connector" => {
.... description of the relationship with children of type
"connector"
},
"virtual-host" => {
.... description of the relationship with children of type
"virtual-host"
}
}
The description of each relationship will include the following elements:
* description -- String -- text description of the relationship
* min-occurs -- int, either 0 or 1 -- Minimum number of children of this type that must
exist in a valid model. If not present, the default value is 0.
* max-occurs -- int -- Maximum number of children of this type that may exist in a valid
model. If not present, the default value is Integer.MAX_VALUE, i.e. there is no limit.
* allowed -- List of strings -- legal values for children names. If not present, there is
no restriction on children names.
* model-description -- either "undefined" or a complex structure -- This is the
full description of the child resource (its text description, attributes, operations,
children) as detailed above. This may also be "undefined", i.e. a null value, if
the query that asked for the parent node's description did not include the
"recursive" param set to true.
Example with if the recursive flag was set to true:
{
"description" => "The connectors used to handle client
connections",
"min-occurs" > 1,
"model-description" => {
"description" => "Handles client connections",
"attributes => {
... details of children as documented above
},
"operations" => {
.... details of operations as documented above
},
"children" => {
.... details of the children's children
}
}
}
If the recursive flag was false:
{
"description" => "The connectors used to handle client
connections",
"min-occurs" > 1,
"model-description" => undefined
}
h2. Applying Updates to Runtime Services
An attribute or operation description may include a "restart-required"
descriptor; this section is an explanation of the meaning of that descriptor.
An operation that changes a management resource's persistent configuration usually can
also also affect a runtime service associated with the resource. For example, there is a
runtime service associated with any host.xml or standalone.xml <interface> element;
other services in the runtime depend on that service to provide the InetAddress associated
with the interface. In many cases, an update to a resource's persistent configuration
can be immediately applied to the associated runtime service. The runtime service's
state is updated to reflect the new value(s).
However, in many cases the runtime service's state cannot be updated without
restarting the service. Restarting a service can have broad effects. A restart of a
service A will trigger a restart of other services B, C and D that depend A, triggering a
restart of services that depend on B, C and D, etc. Those service restarts may very well
disrupt handling of end-user requests.
Because restarting a service can be disruptive to end-user request handling, the handlers
for management operations will not restart any service without some form of explicit
instruction from the end user indicating a service restart is desired. In a few cases,
simply executing the operation is an indication the user wants services to restart (e.g. a
/host=master/server-config=server-one:restart operation in a managed domain, or a /:reload
operation on a standalone server.) For al other cases, if an operation (or attribute
write) cannot be performed without restarting a service, the metadata describing the
operation or attribute will include a "restart-required" descriptor whose value
indicates what is necessary for the operation to affect the runtime:
* no-services -- Applying the operation to the runtime does not require the restart of any
services. This value is the default if the restart-required descriptor is not present.
* all-services -- The operation can only immediately update the persistent configuration;
applying the operation to the runtime will require a subsequent restart of all services in
the affected VM. Executing the operation will put the server into a
"reload-required" state. Until a restart of all services is performed the
response to this operation and to any subsequent operation will include a response header
"process-state" => "reload-required". For a standalone server, a
restart of all services can be accomplished by executing the /:reload CLI command. For a
server in a managed domain, restarting all services currently requires a full restart of
the affected server VM (e.g. /host=master/server-config=server-one:restart).
* jvm --The operation can only immediately update the persistent configuration; applying
the operation to the runtime will require a full process restart (i.e. stop the JVM and
launch a new JVM). Executing the operation will put the server into a
"restart-required" state. Until a restart is performed the response to this
operation and to any subsequent operation will include a response header
"process-state" => "restart-required". For a standalone server, a
full process restart requires first stopping the server via OS-level operations (Ctrl-C,
kill) or via the /:shutdown CLI command, and then starting the server again from the
command line. For a server in a managed domain, restarting a server requires executing the
/host=<host>/server-config=<server>:restart operation.
* resource-services -- The operation can only immediately update the persistent
configuration; applying the operation to the runtime will require a subsequent restart of
some services associated with the resource. If the operation includes the request header
"allow-resource-service-restart" => true, the handler for the operation will
go ahead and restart the runtime service. Otherwise executing the operation will put the
server into a "reload-required" state. (See the discussion of
"all-services" above for more on the "reload-required" state.)
h2. Example Representation of a Portion of the Domain Controller API
{
"description" => "The root node of the domain-level management
model.",
"attributes" => {
"namespaces" => {
"type" => OBJECT,
"value-type" => STRING,
"description" => "Map of namespaces used in the
configuration XML document, where keys are namespace prefixes and values are schema
URIs.",
"required" => false
},
"schema-locations" => {
"type" => OBJECT,
"value-type" => STRING,
"description" => "Map of locations of XML schemas used in
the configuration XML document, where keys are schema URIs and values are locations where
the schema can be found.",
"required" => false
}
},
"operations" => "TODO",
"children" => {
"extension" => {
"description" => "A list of extension modules.",
"model-description" => "TODO"
},
"path" => {
"description" => "A list of named filesystem paths. The
paths may or may not be fully specified (i.e. include the actual paths.)",
"model-description" => {
"description" => "A named filesystem path, but without a
requirement to specify the actual path. If no actual path is specified, acts 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.)",
"tail-comment-allowed" => false,
"attributes" => {
"name" => {
"type" => STRING,
"description" => "The name of the path. Cannot
be one of the standard fixed paths provided by the system: <ul><li>jboss.home
- the root directory of the JBoss AS distribution</li><li>user.home -
user's home directory</li><li>user.dir - user's current working
directory</li><li>java.home - java installation
directory</li><li>jboss.server.base.dir - root directory for an individual
server instance</li></ul> 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.",
"required" => true
},
"path" => {
"type" => STRING,
"description" => "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. <p>If treated as an
absolute path, the actual runtime pathname specified by the value of this attribute will
be determined as follows: </p>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.",
"required" => false,
"min-length" => 1
},
"relative-to" => {
"type" => STRING,
"description" => "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:<ul><li>jboss.home - the root directory of the JBoss AS
distribution</li><li>user.home - user's home
directory</li><li>user.dir - user's current working
directory</li><li>java.home - java installation
directory</li><li>jboss.server.base.dir - root directory for an individual
server instance</li><li>jboss.server.data.dir - directory the server will use
for persistent data file storage</li><li>jboss.server.log.dir - directory the
server will use for log file storage</li><li>jboss.server.tmp.dir - directory
the server will use for temporary file
storage</li><li>jboss.domain.servers.dir - directory under which a host
controller will create the working area for individual server
instances</li></ul>",
"required" => false
}
},
"operations" => {
"add" => {
"operation-name" => "add",
"description" => "Add a new 'path'
child",
"request-properties" => {
"name" => {
"type" => STRING,
"description" => "The value of the
path's 'name' attribute",
"required" => true,
"min-length" => 1,
"nillable" => false
},
"path" => {
"type" => STRING,
"description" => "The value of the
path's 'path' attribute",
"required" => false,
"min-length" => 1,
"nillable" => true
},
"relative-to" => {
"type" => STRING,
"description" => "The value of the
path's 'relative-to' attribute",
"required" => false,
"min-length" => 1,
"nillable" => true
}
},
"reply-properties" => {}
},
"remove" => {
"operation-name" => "remove",
"description" => "Remove a 'path'
child",
"request-properties" => {"name" => {
"type" => STRING,
"description" => "The value of the
path's 'name' attribute",
"required" => true,
"min-length" => 1,
"nillable" => false
}},
"reply-properties" => {}
},
"setPath" => {
"operation-name" => "setPath",
"description" => "Set the value of the
'path' attribute",
"request-properties" => {"path" => {
"type" => STRING,
"description" => "The new value of the
'path' attribute",
"required" => true,
"min-length" => 1,
"nillable" => true
}},
"reply-properties" => {}
},
"setRelativeTo" => {
"operation-name" => "setRelativeTo",
"description" => "Set the value of the
'relative-to' attribute",
"request-properties" => {"relative-to"
=> {
"type" => STRING,
"description" => "The new value of the
'relative-to' attribute",
"required" => true,
"nillable" => true
}},
"reply-properties" => {}
}
}
}
},
"profile" => {
"description" => "A list of profiles available for use in
the domain",
"min-occurs" => 1,
"model-description" => {
"description" => "A named set of subsystem
configurations.",
"attributes" => {"name" => {
"type" => STRING,
"description" => "The name of the
profile",
"required" => true,
"min-length" => 1
}},
"operations" => {},
"children" => {
"subsystem" => {
"description" => "The subsystems that make up
the profile.",
"min-occurs" => 1,
"model-description" => {}
},
"include" => {"model-description" => {
"description" => "Specifies that a contents
of a named profile are to be included in the profile whose definition includes this
item.",
"head-comment-allowed" => true,
"tail-comment-allowed" => false,
"attributes" => {"profile" => {
"type" => LIST,
"description" => "The name of the
included profile",
"required" => true,
"value-type" => STRING
}},
"operations" => "TODO"
}}
}
}
},
"interface" => {
"description" => "A list of named network interfaces
available for use in the domain. The interfaces may or may not be fully specified (i.e.
include criteria on how to determine their IP address.",
"min-occurs" => 0,
"model-description" => "TODO"
},
"socket-binding-group" => {
"description" => "A list of socket binding groups available
for use in the domain",
"min-occurs" => 0,
"model-description" => "TODO"
},
"system-property" => {
"description" => "A list of system properties to set on all
servers in the domain.",
"min-occurs" => 0,
"model-description" => "TODO"
},
"deployment" => {
"description" => "A list of deployments available for use in
the domain",
"min-occurs" => 0,
"model-description" => "TODO"
},
"server-group" => {
"description" => "A list of server groups available for use
in the domain",
"min-occurs" => 0,
"model-description" => "TODO"
},
"host" => {
"description" => "Host controllers currently running in the
domain",
"min-occurs" => 0,
"model-description" => "TODO"
}
}
}
h2. Example Representation of a Portion of the Host Controller API
{
"description" => "The root node of the host-level management
model.",
"attributes" => {
"namespaces" => {
"type" => OBJECT,
"value-type" => STRING,
"description" => "Map of namespaces used in the
configuration XML document, where keys are namespace prefixes and values are schema
URIs.",
"required" => false
},
"schema-locations" => {
"type" => OBJECT,
"value-type" => STRING,
"description" => "Map of locations of XML schemas used in
the configuration XML document, where keys are schema URIs and values are locations where
the schema can be found.",
"required" => false
},
"management" => {
"description" => "Configuration of the host's management
system.",
"type" => OBJECT,
"value-type" => {
"interface" => {
"type" => STRING,
"description" => "Interface on which the host's
socket for intra-domain management communication should be opened.",
"required" => false
},
"port" => {
"type" => STRING,
"description" => "Port on which the host's
socket for intra-domain management communication should be opened.",
"required" => false
}
},
"required" => true,
"head-comment-allowed" => true
},
"domain-controller" => {
"description" => "Configuration of how the host should
interact with the Domain Controller",
"type" => OBJECT,
"value-type" => "TODO",
"required" => true,
"head-comment-allowed" => true,
"tail-comment-allowed" => true
}
},
"operations" => {
"start-server" => {
"operation-name" => "start-server",
"description" => "Start a server.",
"request-properties" => {"server" => {
"type" => STRING,
"description" => "The name of the server.",
"required" => true,
"min-length" => 1
}},
"reply-properties" => {
"type" => STRING,
"description" => "The status of the server following
execution of this operation."
}
},
"restart-server" => {
"operation-name" => "restart-server",
"description" => "Restart a currently running
server.",
"request-properties" => {"server" => {
"type" => STRING,
"description" => "The name of the server.",
"required" => true,
"min-length" => 1
}},
"reply-properties" => {
"type" => STRING,
"description" => "The status of the server following
execution of this operation."
}
},
"stop-server" => {
"operation-name" => "stop-server",
"description" => "Stop a currently running server.",
"request-properties" => {"server" => {
"type" => STRING,
"description" => "The name of the server.",
"required" => true,
"min-length" => 1
}},
"reply-properties" => {
"type" => STRING,
"description" => "The status of the server following
execution of this operation."
}
}
},
"children" => {
"extension" => {
"description" => "A list of extension modules.",
"min-occurs" => 0,
"model-description" => "TODO"
},
"path" => {
"description" => "A list of named filesystem paths.",
"min-occurs" => 0,
"model-description" => {
"description" => "A named filesystem path, but without a
requirement to specify the actual path. If no actual path is specified, acts 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.)",
"tail-comment-allowed" => false,
"attributes" => {
"name" => {
"type" => STRING,
"description" => "The name of the path. Cannot
be one of the standard fixed paths provided by the system: <ul><li>jboss.home
- the root directory of the JBoss AS distribution</li><li>user.home -
user's home directory</li><li>user.dir - user's current working
directory</li><li>java.home - java installation
directory</li><li>jboss.server.base.dir - root directory for an individual
server instance</li></ul> 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.",
"required" => true
},
"path" => {
"type" => STRING,
"description" => "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. <p>If treated as an
absolute path, the actual runtime pathname specified by the value of this attribute will
be determined as follows: </p>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.",
"required" => true,
"min-length" => 1
},
"relative-to" => {
"type" => STRING,
"description" => "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:<ul><li>jboss.home - the root directory of the JBoss AS
distribution</li><li>user.home - user's home
directory</li><li>user.dir - user's current working
directory</li><li>java.home - java installation
directory</li><li>jboss.server.base.dir - root directory for an individual
server instance</li><li>jboss.server.data.dir - directory the server will use
for persistent data file storage</li><li>jboss.server.log.dir - directory the
server will use for log file storage</li><li>jboss.server.tmp.dir - directory
the server will use for temporary file
storage</li><li>jboss.domain.servers.dir - directory under which a host
controller will create the working area for individual server
instances</li></ul>",
"required" => false
}
},
"operations" => {
"add" => {
"operation-name" => "add",
"description" => "Add a new 'path'
child",
"request-properties" => {
"name" => {
"type" => STRING,
"description" => "The value of the
path's 'name' attribute",
"required" => true,
"min-length" => 1
},
"path" => {
"type" => STRING,
"description" => "The value of the
path's 'path' attribute",
"required" => true,
"min-length" => 1
},
"relative-to" => {
"type" => STRING,
"description" => "The value of the
path's 'relative-to' attribute",
"required" => false,
"min-length" => 1,
"nillable" => true
}
},
"reply-properties" => {}
},
"remove" => {
"operation-name" => "remove",
"description" => "Remove a 'path'
child",
"request-properties" => {"name" => {
"type" => STRING,
"description" => "The value of the
path's 'name' attribute",
"required" => true,
"min-length" => 1
}},
"reply-properties" => {}
},
"setPath" => {
"operation-name" => "setPath",
"description" => "Set the value of the
'path' attribute",
"request-properties" => {"path" => {
"type" => STRING,
"description" => "The new value of the
'path' attribute",
"required" => true,
"min-length" => 1
}},
"reply-properties" => {}
},
"setRelativeTo" => {
"operation-name" => "setRelativeTo",
"description" => "Set the value of the
'relative-to' attribute",
"request-properties" => {"relative-to"
=> {
"type" => STRING,
"description" => "The new value of the
'relative-to' attribute",
"required" => true,
"nillable" => true
}},
"reply-properties" => {}
}
}
}
},
"system-property" => {
"description" => "A list of system properties to set on all
servers on the host.",
"min-occurs" => 0
"model-description" => "TODO"
},
"interface" => {
"description" => "A list of fully specified named network
interfaces available for use on the host.",
"min-occurs" => 0
"model-description" => "TODO"
},
"jvm" => {
"description" => "A list of Java Virtual Machine
configurations that can be applied ot servers on the host.",
"min-occurs" => 0
"model-description" => "TODO"
},
"server-config" => {
"description" => "Host-level configurations for the servers
that can run on this host.",
"min-occurs" => 0
"model-description" => {}
},
"server" => {
"description" => "Servers currently running on the
host",
"min-occurs" => 0
"model-description" => "TODO"
}
}
}
--------------------------------------------------------------
Comment by going to Community
[
https://community.jboss.org/docs/DOC-16317]
Create a new document in JBoss AS 7 Development at Community
[
https://community.jboss.org/choose-container!input.jspa?contentType=102&a...]