Brian Stansberry [
http://community.jboss.org/people/bstansberry%40jboss.com] modified the
document:
"Format of a Detyped Operation Request"
To view the document, visit:
http://community.jboss.org/docs/DOC-16336
--------------------------------------------------------------
The basic method a user of the AS 7 programmatic managment API would use it very simple:
ModelNode execute(ModelNode operation) throws CancellationException, IOException;
where the return value is the detyped representation of the response, and operation is the
detyped representation of the operating being invoked.
The purpose of this article is to document the structure of operation.
h3. Simple Operations
A text representation of simple operation would look like this:
{
"op" => "setCoreThreads",
"op-addr" => [
("base" => "domain"),
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
}
Java code to produce that output would be:
ModelNode op = new ModelNode();
op.get("op").set("setCoreThreads");
ModelNode addr = opB.get("op-addr");
addr.add("base", "domain");
addr.add("profile", "production");
addr.add("subsystem", "threads");
addr.add("bounded-queue-thread-pool", "pool1");
op.get("count").set(0);
op.get("per-cpu").set(20);
System.out.println(op);
The order in which the items appear in the request is not relevant. The required elements
are:
* op -- String -- The name of the operation being invoked.
* op-addr -- the address of the managed resource against which the request should be
executed.
The other key/value pairs are parameter names and their values. The names and values
should match what is specified in the operation's
http://community.jboss.org/docs/DOC-16317 description.
Parameters may have any name, except for op, op-addr and rollout-plan.
h3. Composite Operations
The root resource managed by a (Domain|Host|Server)Controller will expose an operation
named "composite". This operation executes a list of other operations as a
(semi-)atomic unit. The structure of the request for the "composite" operations
has the same fundamental structure as a simple operation (operation name, address, params
as key value pairs.
{
"op" => "composite",
"op-addr" => [],
"steps" => [
{
"op" => "write-core-threads",
"op-addr" => [
("base" => "domain"),
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
},
{
"op" => "write-core-threads",
"op-addr" => [
("base" => "domain"),
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool2")
],
"count" => 5,
"per-cpu" => 10
}
],
"rollback-on-runtime-failure" => false
}
The "composite" operation takes two parameters:
* steps -- a list, where each item in the list has the same structure as a simple
operation request. In the example above each of the two steps is modifying the thread pool
configuration for a different pool. There need not be any particular relationship between
the steps.
* rollback-on-runtime-failure -- boolean, optional, defaults to true. Whether steps that
successfully execute should be reverted if other steps fail at runtime. Note that if any
steps modify the persistent configuration, and any of those steps fail, all steps will be
reverted. Partial/incomplete changes to the persistent configuration are not allowed. So,
this flag only deals with what happens if there is a problem applying an operation to the
running state of a server (e.g. actually increasing the size of a runtime thread pool.)
h3. Operations with a Rollout Plan
Operations targetted at domain or host level resources can potentially impact multiple
servers. Such operations can include a "rollout plan" detailing the sequence in
which the operation should be applied to servers as well as policies for detailing whether
the operation should be reverted if it fails to execute successfully on some servers.
If the operation includes a rollout plan, the structure is as follows:
{
"op" => "setCoreThreads",
"op-addr" => [
("base" => "domain"),
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
"rollout-plan" => "TODO"
}
+TODO -- flesh out the structure of the rollout plan. Deployment plans in Alpha1 had a
structure that could apply very easily, but it's not particularly intuitive. It was
hidden from users by the DeploymentPlanBuilder API. So I want to tweak it a bit to make it
more understandable to the end user.
+
As you can see, the rollout plan is simply another structure at the same level as op,
op-addr and the operation parameters.+
+
--------------------------------------------------------------
Comment by going to Community
[
http://community.jboss.org/docs/DOC-16336]
Create a new document in JBoss AS7 Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=102&am...]