I have done up a quick and dirty prototype of my #2 approach at 

https://github.com/stuartwdouglas/jboss-as/compare/AS7-4296

The basic usage can be seen in ContentOverrideTestCase: 

https://github.com/stuartwdouglas/jboss-as/blob/01e2cdb24e34a898643682da7b284d8b4885bf98/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/deployment/contentoverride/ContentOverrideTestCase.java

(it does not work in domain mode, and basically is the bare minimum required to get it functional)

This approach actually works with any content, not just deployment descriptors, so for example you could use it to replace an image or a web page as well.

Stuart 




On 06/04/2012, at 1:45 AM, Jason T. Greene wrote:

On 4/5/12 3:52 AM, Chris Kriel wrote:
Are you sure that this truly reflects what most users want? Are you not just
adding a lot of complexity to cater for the whim of a small group of users?
From what I can gather from this thread, the motivation for these overrides
are rather thin. It is based on some users having a "policy" to not
break-open deployment artefacts. How overriding is better or safer that
"breaking open" escapes me at the moment.

Very much part of the EJB specification is the definition of roles and
responsibilities. As you know, it describes a definite role for composing
(and by implication "breaking-open" to recompose) artefacts. If your
configuration is too dynamic for this approach then it is a matter of
application design to pick this up from elsewhere (DB or properties file).

I certainly see where you are coming from. In fact I do agree that this
feature could be used as a crutch over better ways to solve the problem.

There are, however, legitimate reasons / use-cases for an override. Here
is a few in no particular order:

1. Third-party application - Some third party applications need
customizations for either the environment (ip addresses, etc), or in
some cases running on JBoss AS (the case app was primarily tailored to
another app server). If you followed Stuarts proposal #2 of deploying
the override first, then updating a newer thirdparty app is a bit
simpler, you just deploy the new version, and the same overrides take effect

2. Staging / Dev / Prod deltas - A good example is @Alternative in CDI,
you specify which set of beans you get in beans.xml Another example is
that applications can now specify environmental values in annotations
(e.g.in EE6 you can now specify @DataSourceDefinition with a URL and a
user/pass). Having the ability to provide a per-environment DD lets you
override those values. (Another thing we are looking at doing is
supporting sys props in deployment descriptors as a vendor extension,
which offers another way to skin this cat).

3. Geographic/Region deltas - Very similar to 2 You might want to add
certain values like "distinct-name" (used by EJB remote invocation to
differentiate connections)

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev