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

[Stuart Douglas]

Tomaž Cerar wrote:
> Why are introducing yet another configuration mechanism for deployments?
>
> now we have
> - jboss-deployment-structure.xml
> - jboss-deployment-dependencies.xml

This is just part of jboss-all, it is not a separate file.

> - jboss-all.xml
> - jboss-xyz.xml - (too) many of them

This is the problem that jboss-all.xml is supposed to solve, in that it 
can contain any of these files, so you only need a single Jboss specific 
descriptor in the deployment.

The big problem is though that because we do not have any fine grained 
overlays, using jboss-all with overlays is a bit problematic, as you 
have to overlay the whole file, even if you just want to modify a single 
line.

 From an administrator point of view I don't think this is to big a 
deal, an admin that does hit this problem should know how to use diff 
and patch to re-generate the overlay automatically (and this problem can 
occur with other descriptors as well, e.g. if you want to change one 
line of jboss-ejb3.xml).

One thing I have been thinking a bit about is fine grained deployment 
descriptors, so deployment descriptors basically translate to a list of 
operations (similar to management operations). You could then have a 
mechanism for removing / adding / changing a single operation).

>
> that in combination with overlays this could provide same capability.
> 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,....)

It is a replacement for them, but we can't just remove the existing ones 
for compatibility reasons.

>
> and overlays just add this extra capability of exposing/manipulating
> this trough management.
> This new approach has only one extra capability that is to enable
> subsystem itself to push/write/change some configuration that is
> deployment-wise.
>  >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.
>
> Maybe I am not seeing some use-case but in general I don't like this
> approach...

I think with Thomas' OSGI use case the OSGI subsystem can decide to 
change these properties. e.g. If it is deployed with 
start.policy=DEFERRED, but then it is actually activated, this deferred 
policy is not longer relevant and should be removed (as I understand it).

Stuart


>
> --
> tomaz
>
>
> On Mon, Oct 15, 2012 at 11:45 PM, Brian Stansberry
> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
>
>     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"...>
>     <properties>
>     <property name="start.policy" value="DEFERRED"/>
>     <property>
>     </deployment>
>
>     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>
>
>     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:
>
>     <deployers>
>     <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
>     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.
>
>     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
>     [4]
>     https://github.com/bstansberry/jboss-as/commit/6326003a104ac4ac825e8dda4c557cfefe9cdcfd
>     --
>     Brian Stansberry
>     Principal Software Engineer
>     JBoss by Red Hat
>     _______________________________________________
>     jboss-as7-dev mailing list
>     jboss-as7-dev at lists.jboss.org <mailto:jboss-as7-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev