On 4/19/12 1:06 PM, Bill Shannon wrote:
> 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".
I also prefer attributes over elements, although you often need to
introduce a virtual element. So we could have something like:
<parsing property-resolution="true" strict-validation="true"..../>
Another challenge I forgot to mention is that XSDs become more difficult
to write. Every value you take has to accept either a property string or
the data type (e.g. integer).
>
> 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.
That's certainly understandable. This was brought up a bit late. Well
ignore that I said EE7, I am interested in what everyone thinks about
this sort of thing for Java EE in some eventual release.
>
> 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.
That's another good point. Assuming it was vender specific, I suppose
the only way to really test this at a decent level would be to provide
an SPI for the TCK that every implementation would have to implement to
validate the test.
I don't think setting properties in the descriptors themselves is all
that useful. Really the whole point of them is to reference external values.
>
> All these problems are solvable, of course, but I'm not sure now is the
> right time to solve them.
I can certainly accept that. Thanks for your feedback.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat