[javaee-spec users] [jsr342-experts] Re: DD Property Substitution
- From: "Nitta, Minoru" <minoru.nitta@...>
- To: "jsr342-experts@..." <jsr342-experts@...>
- Subject: [javaee-spec users] [jsr342-experts] Re: DD Property Substitution
- Date: Mon, 23 Apr 2012 12:13:27 +0000
- Accept-language: ja-JP, en-US
- List-id: <jsr342-experts.javaee-spec.java.net>
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@...]
> Sent: Friday, April 20, 2012 1:53 AM
> To: jsr342-experts@...
> 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
> or define a common set.
> Jason T. Greene
> JBoss AS Lead / EAP Platform Architect
> JBoss, a division of Red Hat