users@javaee-spec.java.net

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

From: Jevgeni Kabanov <jevgeni_at_zeroturnaround.com>
Date: Fri, 20 Apr 2012 12:35:48 +0200

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_at_bleepbleep.org.uk> 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?

Werner

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

Thoughts?

-- 
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+ gplus.to/wernerkeil
* 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"