Yes, I think this is also really useful for cloud deployments as you can use it to alter the default config.
On 19 Apr 2012, at 22:23, Jason T. Greene wrote:
> This is somewhat related to the password aliasing discussion awhile back.
>
> One popular feature we have had some support for in many of the JBoss AS vendor descriptors is the ability to reference system properties that get resolved at deployment. This is useful for prod/staging/test differentiation, and also running an application in a cloud environment.
>
> I really think we should consider enabling this in all spec descriptors as well for EE7. The problem with relying on vendor descriptors to do this is that you have to maintain a duplicate structure just to use property replacement which becomes a maintenance burden (especially now that these spec descriptors are less frequently needed due to EE5 and EE6 enhancements). Descriptor overrides are even worse because you have to maintain a duplicate for every distinct environment an application can run on.
>
> Along with various benefits like controlling environmental values (ip addresses etc) this leads to other interesting capabilities, like the power to control the active @Alternative in CDI using a property.
>
> There is of course a compatibility issue to deal with that requires thought. Someone might have used system properties as an actual value string, and resolve it in their code to work around the lack of this feature (the TCK does this for example). One solution could be to introduce a common attribute/element to every descriptor enabling it.
>
> Another consideration is supporting multiple sources (system props, container props, password stores, etc). We could leave this up to the vendor, or define a common set.
>
> Thoughts?
>
> --
> Jason T. Greene
> JBoss AS Lead / EAP Platform Architect
> JBoss, a division of Red Hat