Skip to main content

[jsr342-experts] Re: DD Property Substitution

  • From: "Nitta, Minoru" <minoru.nitta@...>
  • To: "jsr342-experts@..." <jsr342-experts@...>
  • Subject: [jsr342-experts] Re: DD Property Substitution
  • Date: Mon, 23 Apr 2012 12:13:27 +0000
  • Accept-language: ja-JP, en-US

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 
> vendor,
> or define a common set.
> 
> Thoughts?
> 
> --
> Jason T. Greene
> JBoss AS Lead / EAP Platform Architect
> JBoss, a division of Red Hat


[jsr342-experts] DD Property Substitution

Jason T. Greene 04/19/2012

[jsr342-experts] Re: [javaee-spec users] DD Property Substitution

Pete Muir 04/20/2012

[jsr342-experts] Re: DD Property Substitution

Werner Keil 04/20/2012

[jsr342-experts] Re: DD Property Substitution

Pete Muir 04/20/2012

[jsr342-experts] Re: DD Property Substitution

Jevgeni Kabanov 04/20/2012

[jsr342-experts] Re: DD Property Substitution

Nitta, Minoru 04/23/2012
 
 
Close
loading
Please Confirm
Close