Skip to main content

[jsr342-experts] Re: Across the board DD property substitution

  • From: "Jason T. Greene" <jason.greene@...>
  • To: jsr342-experts@...
  • Cc: Bill Shannon <bill.shannon@...>
  • Subject: [jsr342-experts] Re: Across the board DD property substitution
  • Date: Thu, 19 Apr 2012 13:49:30 -0500

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
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
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

[jsr342-experts] Across the board DD property substitution

Jason T. Greene 04/19/2012

[jsr342-experts] Re: Across the board DD property substitution

Bill Shannon 04/19/2012

[jsr342-experts] Re: Across the board DD property substitution

Jason T. Greene 04/19/2012
Please Confirm