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

From: Andrew Phillips <>
Date: Tue, 24 Apr 2012 03:06:47 +0100 (BST)

Logging or some other invocation history certainly seems relevant from a traceability perspective. I think there are some other potential concerns in this area worth considering:

- if system properties are specified on the command line, the will be visible during a process listing, potential exposing sensitive data (although that is presumably addressed by the password proposal and, in any case, one could argue that users able to run process listing probably have elevated permissions already)

- using system properties as the mechanism would seem to require that the person specifying the environment values be able to influence the JVM's command line. Without some sort of "this user can only set system properties of a certain type" restriction this would give the environment customizer quite a high degree of control over the process.

- many current PaaS platforms, especially those supporting multiple languages, have gone one step further down the stack and are passing these kind of values in environment variables. Would it make sense to consider those?

- in what way are system properties considered to be superior to a convention-based lookup of e.g. certain JNDI properties?


Andrew Phillips

> From: "Nitta, Minoru" <>
>To: "" <>
>Sent: Monday, 23 April 2012, 14:13
>Subject: [javaee-spec users] [jsr342-experts] Re: DD Property Substitution
>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 []
>> Sent: Friday, April 20, 2012 1:53 AM
>> To:
>> 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