Date: Fri, 20 Apr 2012 11:49:14 +0200
This would be quite useful. Keep doing that for more than one App Server
vendor (all involved here btw[?]) 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"
(image/gif attachment: 347.gif)