Why are introducing yet another configuration mechanism for deployments?<br><br>now we have <br>- jboss-deployment-structure.xml<br>- jboss-deployment-dependencies.xml<br>- jboss-all.xml<br>- jboss-xyz.xml - (too) many of them<br>
<br>that in combination with overlays this could provide same capability.<br>AFAIR primary idea behind jboss-all.xml was to unify configuration for all subsystems (get rid of all other jboss-cmp.xml, jboss-ejb3.xml, jboss-app.xml,....)<br>
<br>and overlays just add this extra capability of exposing/manipulating this trough management.<br>This new approach has only one extra capability that is to enable subsystem itself to push/write/change some configuration that is deployment-wise.<br>
>From my point of view that is just wrong. Subsystems should not run-time decide and change some deployment parameters that you can than also manipulate trough mgmt.<br><br>Maybe I am not seeing some use-case but in general I don't like this approach...<br>
<br>--<br>tomaz<br><br><br><div class="gmail_quote">On Mon, Oct 15, 2012 at 11:45 PM, Brian Stansberry <span dir="ltr"><<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been working $subject in order to help support Thomas Diesler's<br>
request for AS7-3694[1]. The gist of this request is to add deployment<br>
unit processing (DUP) configuration as children of the deployment<br>
resource itself. Thomas' OSGi use case is one place where this would be<br>
used. I expect HASingleton deployment will be another.<br>
<br>
WIP is at [2]. I'm looking for feedback. :)<br>
<br>
What I've done is based on what Thomas did at [3]. What I want to do is<br>
move from the generic key/value pairs in that patch to a more formally<br>
describable management API. Instead of:<br>
<br>
<deployment name="foo.war"...><br>
<properties><br>
<property name="start.policy" value="DEFERRED"/><br>
<property><br>
</deployment><br>
<br>
It would be something analogous to how a profile configuration is done:<br>
<br>
<deployment name="foo.war"...><br>
<deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2"><br>
<start-policy value="deferred"/><br>
</deployment><br>
</deployment><br>
<br>
The existing Extension API already has the hooks to support this.<br>
Extensions can register xml parsers for children of the <deployment><br>
element and can register management resources to act as children of the<br>
/deployment=foo.war resource as well. Several subsystems already take<br>
advantage of the latter. Until now the former has been an unimplemented<br>
API. The commit at [4] implements it.<br>
<br>
A couple things giving me some concern:<br>
<br>
1) The above xml:<br>
<br>
<deployment-subsystem xmlns="urn:jboss:domain:osgi:1.2"><br>
<br>
Nicer would be something like:<br>
<br>
<deployers><br>
<subsystem xmlns="urn:jboss:domain:osgi:1.2"><br>
<br>
I need to figure out if I can do some tricks with the parsing to allow<br>
that to happen.<br>
<br>
2) The structure of the resource tree. We already support resources like<br>
this:<br>
<br>
/deployment=foo.war/subsystem=web<br>
<br>
Subsystems register resources like those to expose metrics. The commit<br>
at [4] uses that same tree. When subsystems could now register child<br>
resources to the deployment=* resource, they could include both runtime<br>
stuff and configuration stuff.<br>
<br>
I'm not sure that mixing the two is ideal, although it's what we do for<br>
the regular subsystem resources in the profile. I'm vaguely concerned<br>
that if someday the configuration that subsystems choose to expose via<br>
this mechanism gets complex, the mixing of metrics with configuration in<br>
the same tree will start to break down.<br>
<br>
Comments are appreciated.<br>
<br>
<br>
[1] <a href="https://issues.jboss.org/browse/AS7-3694" target="_blank">https://issues.jboss.org/browse/AS7-3694</a><br>
[2] <a href="https://github.com/bstansberry/jboss-as/commits/AS7-3694" target="_blank">https://github.com/bstansberry/jboss-as/commits/AS7-3694</a><br>
[3] <a href="https://github.com/jbossas/jboss-as/pull/3230" target="_blank">https://github.com/jbossas/jboss-as/pull/3230</a><br>
[4]<br>
<a href="https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd" target="_blank">https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd</a><br>
<span class="HOEnZb"><font color="#888888">--<br>
Brian Stansberry<br>
Principal Software Engineer<br>
JBoss by Red Hat<br>
_______________________________________________<br>
jboss-as7-dev mailing list<br>
<a href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a><br>
</font></span></blockquote></div><br>