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

[Tomaž Cerar]

Why are introducing yet another configuration mechanism for deployments?

now we have
- jboss-deployment-structure.xml
- jboss-deployment-dependencies.xml
- jboss-all.xml
- jboss-xyz.xml - (too) many of them

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,....)

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...

--
tomaz


On Mon, Oct 15, 2012 at 11:45 PM, Brian Stansberry <
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
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20121016/add3e08d/attachment.html