I think this is useful and interesting.
I think we may need some tracking mechanism (logging or something else?)
to know what property values are used at deployment. Vendor specific
descriptors are persistent (it's a file) but property values are easily
changeable after deployment.
> -----Original Message-----
> From: Jason T. Greene [mailto:jason.greene_at_redhat.com]
> Sent: Friday, April 20, 2012 1:53 AM
> To: jsr342-experts_at_javaee-spec.java.net
> Subject: [jsr342-experts] DD Property Substitution
>
> 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