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"/>
</deployment>
</deployment>
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
this:
/deployment=foo.war/subsystem=web
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)