[jboss-as7-dev] Subsystem specific deployer configurations in standalone.xml/domain.xml

Brian Stansberry brian.stansberry at redhat.com
Mon Oct 15 17:45:35 EDT 2012

I've been working $subject in order to help support Thomas Diesler's 
request for AS7-3694[1]. The gist of this request is to add deployment 
unit processing (DUP) configuration as children of the deployment 
resource itself. Thomas' OSGi use case is one place where this would be 
used. I expect HASingleton deployment will be another.

WIP is at [2]. I'm looking for feedback. :)

What I've done is based on what Thomas did at [3]. What I want to do is 
move from the generic key/value pairs in that patch to a more formally 
describable management API. Instead of:

<deployment name="foo.war"...>
   <property name="start.policy" value="DEFERRED"/>

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"/>

The existing Extension API already has the hooks to support this. 
Extensions can register xml parsers for children of the <deployment> 
element and can register management resources to act as children of the 
/deployment=foo.war resource as well. Several subsystems already take 
advantage of the latter. Until now the former has been an unimplemented 
API. The commit at [4] implements it.

A couple things giving me some concern:

1) The above xml:

<deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2">

Nicer would be something like:

   <subsystem xmlns="urn:jboss:domain:osgi:1.2">

I need to figure out if I can do some tricks with the parsing to allow 
that to happen.

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.

Comments are appreciated.

[1] https://issues.jboss.org/browse/AS7-3694
[2] https://github.com/bstansberry/jboss-as/commits/AS7-3694
[3] https://github.com/jbossas/jboss-as/pull/3230
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat

More information about the jboss-as7-dev mailing list