Please see my comments inline.

On Oct 15, 2012, at 11:45 PM, Brian Stansberry <> wrote:

It would be something analogous to how a profile configuration is done:

<deployment name="foo.war"...>
 <deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">
   <start-policy value="deferred"/>

I think this makes sense and I can see the benefit. One thing to consider:
Will this be self-describing (in terms of :read-resource-description or something similar)?

The use case would be to query the possible options for subsystem specific deployment settings when actually creating a deployment (i.e. through the console)

2) The structure of the resource tree. We already support resources like 


Subsystems register resources like those to expose metrics. The commit 
at [4] uses that same tree. When subsystems could now register child 
resources to the deployment=* resource, they could include both runtime 
stuff and configuration stuff.

I'm not sure that mixing the two is ideal, although it's what we do for 
the regular subsystem resources in the profile. I'm vaguely concerned 
that if someday the configuration that subsystems choose to expose via 
this mechanism gets complex, the mixing of metrics with configuration in 
the same tree will start to break down.

I would prefer if this two concepts could somehow be distinguished. Either a separate resource [1], or a dedicated child [2]:

[1] /deployment=foo.war/subsystem-config=web
[2] /deployment=foo.war/subsystem=web/overlay=config(start-policy=deferred)