Skip to main content

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

  • From: Jevgeni Kabanov <jevgeni@...>
  • To: "jsr342-experts@..." <jsr342-experts@...>
  • Cc: Mircea Markus <mircea.markus@...>
  • Subject: [javaee-spec users] [jsr342-experts] Re: DD Property Substitution
  • Date: Fri, 20 Apr 2012 12:35:48 +0200
  • List-id: <>

350 sounds very interesting, I'll try to join next time or find someone from our org who would. 

Sent from my iPhone

On 20.04.2012, at 12:25, Pete Muir <pmuir@...> wrote:

Mircea Markus is our rep on 350.

On 20 Apr 2012, at 15:19, Werner Keil wrote:

This would be quite useful. Keep doing that for more than one App Server vendor (all involved here btw<347.gif>) in our current DevOps style project, so having some of those standardized would make our and many other lives a lot easier.

I was the only one in the recent conf call of JSR 350, which aims to leverage State Management of systems like WLS, Seam or Tomcat and standardize it, too. Hope, some of the EG reps from other members including Red Hat may make it to future calls?


On Thu, Apr 19, 2012 at 6:53 PM, Jason T. Greene <jason.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.


Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat

Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead
Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR
Skype werner.keil | Google+

* TUGDK: Apr 26 2012, Copenhagen, Denmark. Werner Keil, JCP EC Member, Java Social Project Lead will talk about "Social Media Extensions for Typo3"

* JustJava: May 18 2012, Sao Paulo, Brazil. Werner Keil, JCP EC Member,  Java Social Project Lead will present "Java Social"

* Dutch Mobile Conference: June 8 2012, Amsterdam, Netherlands. Werner Keil, JCP EC Member, OpenDDR Evangelist will present "OpenDDR"

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

Jason T. Greene 04/19/2012

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

Pete Muir 04/20/2012

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

Werner Keil 04/20/2012

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

Pete Muir 04/20/2012

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

Jevgeni Kabanov 04/20/2012

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

Nitta, Minoru 04/23/2012

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

Andrew Phillips 04/24/2012
Please Confirm