My first concern is the compatibility issue. Adding an attribute to
every element to enable this support "works", but seems kind of klunky
and ugly. From time to time we've discussed larger changes to the
descriptor format, and most people would prefer that we use more
attributes and fewer elements. If we went in that direction, this
"orthogonal" use of an attribute to specify how to interpret other
values would become more difficult. A simple per-descriptor value
would be simpler, but introduces other problems as well since its
effect would be more "global".
My second concern is the amount of effort it will take for us to
implement this in the RI, and to test it in the TCK. To be effective,
you would want this to be implemented at a relatively low level in the
processing of descriptors, so that most code accessing descriptor
elements wouldn't need to know about this. (If all code accessing
descriptor elements needs to handle this issue, some cases will be
missed.) But some code will need to see the unexpanded descriptor
element values, so there needs to be a way to support that as well.
Given all the other things the RI team is working on, they may not have
time to design and implement and test this.
My third concern is exactly how we would specify this. I don't think it
would be acceptable to define a property expansion mechanism without also
defining some properties and/or a way to set properties. If properties
can be set in the descriptors themselves, this becomes much more complicated.
If properties are set external to the descriptor, we don't currently have
a good mechanism for doing things like that, at least not in a portable way.
Without a portable solution, testing becomes more difficult.
All these problems are solvable, of course, but I'm not sure now is the
right time to solve them.
Jason T. Greene wrote on 04/19/2012 09:16 AM:
> 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?
>