[jboss-as7-dev] Detyped API document feedback

Brian Stansberry brian.stansberry at redhat.com
Wed Jan 5 12:15:12 EST 2011


On 1/5/11 7:10 AM, David M. Lloyd wrote:
> On 01/04/2011 11:46 PM, Brian Stansberry wrote:
>> On 1/4/11 11:02 AM, David M. Lloyd wrote:
>>
>>> I'd rather do something more dynamic where you can start with a node and
>>> just build up whatever you want from it:
>>>
>>> node = new ModelNode();
>>> node.get("operation").set("change-bind-port"); // string
>>> node.get("address").add("base, "domain"); // a list
>>> node.get("address").add("profile", "web");
>>> node.get("address").add("subsystem", "web");
>>> node.get("address").add("connector", "ssl");
>>> node.get("bind-port").set(8433); // int
>>> result = connection.execute(node); // goes over remoting
>>> System.out.println("Result is: " + result);
>>> // nicely formatted, JSON-style (but with more possible types)
>>>
>>> I wipped up a demo of this style of API at:
>>> https://github.com/dmlloyd/jboss-dmr
>>>
>>> Notice there's only one public class and one type enum.  (The Validation
>>> class isn't anything, just an experiment.)
>>>
>>
>> The add(String, String) method isn't there; just set(String, ModelNode).
>> That would be ok if there were overloaded ModelNode constructors to
>> match the set() methods, allowing you to create a model node, set it's
>> value and pass it as a method parameter all in one line:
>>
>> node.get("address").add().set("base", new ModelNode("domain"));
>>
>> A whole bunch of overloaded variants (set(String, String), set(String,
>> boolean), set(String, int) etc) would accomplish the same thing.
>
> Yeah I knew you'd notice the missing stuff. :-)  Well it's all fixed
> now.  I rounded it out with a bunch of methods that were missing,
> including setEmptyList/setEmptyObject, plus some formatting improvements
> for toString().
>
>> I played at creating a couple "update plans" (pretty much like the
>> Alpha1 deployment plans) and it was pretty painless, except for the
>> minor nit above.
>
> Maybe try again with the most recent version?
>

Thanks, with that it's pretty straightforward:

// We're going to create a composite update for this plan
ModelNode composite = planA.get("operation");
// First, add previously uploaded content to the domain
ModelNode first = composite.get("operations").add();
first.get("operation").set("addDeployment");
first.get("address").add("base", "domain");
first.get("uniqueName").set("foo.war");
first.get("hash").set(new byte[20]); // pretend the hash came from elsewhere
// Next, include it with a server group's list of deployments
ModelNode second = composite.get("operations").add();
second.get("operation").set("addDeployment");
second.get("address").add("base", "domain");
second.get("address").add("server-group", "groupA");
second.get("uniqueName").set("foo.war");
second.get("start").set(true);
// Third operation is to replace previously existing "bar.ear" across
// the domain with new content previously uploaded
ModelNode third = composite.get("operations").add();
third.get("operation").set("fullyReplaceDeployment");
third.get("address").add("base", "domain");
third.get("uniqueName").set("bar.ear");
third.get("hash").set(new byte[20]);

// Next create lists of lists for how to roll out. Inner lists
// are rolled out concurrently; outer lists are done in series
ModelNode serverGroupPlans = planA.get("serverGroups");
ModelNode groupAPlan = serverGroupPlans.add().add();
groupAPlan.get("server-group").set("groupA");
groupAPlan.get("rollingToServers").set(true);
groupAPlan.get("maxFailurePercentage").set(20);
ModelNode groupBPlan = serverGroupPlans.get(0).add();
groupBPlan.get("server-group").set("groupB");
groupBPlan.get("rollingToServers").set(false);
groupBPlan.get("maxFailedServers").set(1);

ModelNode groupCPlan = serverGroupPlans.add().add();
groupCPlan.get("server-group").set("groupC");
groupBPlan.get("rollbackAcrossServers").set(false);
// We're going to re-use serverGroupPlans, so lock it down
serverGroupPlans.protect();

// If application to groupA, B or C fail, don't rollback the others
planA.get("rollbackAcrossGroups").set(false);


// A simple single update plan
ModelNode planB = new ModelNode();
ModelNode operation = planB.get("operation");
operation.get("operation").set("setCoreThreads");
operation.get("address").add("base", "domain");
operation.get("address").add("profile", "production");
operation.get("address").add("subsystem", "threads");
operation.get("address").add("bounded-queue-thread-pool", "pool1");
operation.get("count").set(0);
operation.get("per-cpu").set(20);
// We'll reuse the server-group rollout plans from above
planB.get("serverGroups").set(serverGroupPlans);


Note that if you skip the last line above:

planB.get("serverGroups").set(serverGroupPlans);

then planB looks just like an operation with no associated plan for how 
to roll it out. Which the server would handle by generating a default plan.

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat



More information about the jboss-as7-dev mailing list