[jboss-as7-dev] Overriding Deployment Descriptors

[Stuart Douglas]

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 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/20120413/9825faef/attachment.html