Pete Muir wrote on 07/15/11 05:26 AM:
>> What I don't understand is how that approach would be used to replace the
>> full range of things you can configure with our existing deployment
>> descriptors. How would I use this to replace application.xml? How would I
>> configure the location of the library directory? How would I list the
>> modules included in the application? (I can imagine answers to these
>> questions, but what I want to know is how *you* think this would work.)
>
> AIUI the reason that XML config got dropped from CDI 1.0 was that it wasn't
> consistent with the rest of the deployment descriptors in EE (it used
> attributes and schema a lot, as opposed to dtd and elements).
EE deployment descriptors have used XML schemas for several releases.
> I personally
> think a simple update to "modern" xml would be a sufficient for these
> deployment descriptors. IOW add in schema support so we can merge files
> easily and make proper use of attributes for configuring elements which just
> have short text bodies.
When we switched from DTDs to schemas (J2EE 1.4, I believe) we first proposed
an approach that would make use of XML schema's extensibility. We were firmly
trounced. Every other Java EE vendor made it quite clear that they did *not*
want deployment descriptors to be extensible; they wanted deployment descriptors
to *only* contain spec-defined elements. We immediately withdrew that proposal.
The choice of elements vs. attributes was made for J2EE 1.2 and carried
forward when we switched to schemas. As far as I can tell, there's no
"science" to this, it's just a matter of personal taste.
Should there be primitives and objects, or should everything be an object?
Same sort of issue.
In my opinion, there's not enough value in *just* changing from an element
to an attribute; better to be consistent with what we've done in the past.
Changing from elements to attributes as part of a larger change to deployment
descriptors could be considered, however, which brings us back to the issue
at hand...
>> In any event, the basic "bean configuration" capability you describe seems
>> like it would fit well with CDI, where it was first proposed. We know
>> that we need a way to specify or override CDI configuration using XML, but
>> unfortunately I don't see that in the CDI 1.1 JSR. Perhaps this is being
>> deferred until CDI 2.0 and/or Java EE 8?
>
> We didn't propose it for CDI 1.1 for these reasons:
>
> * That the primary objection to the XML config in CDI 1.0 came from the Java
> EE EG as the design wasn't consistent with other dd's in Java EE, and that
> this is not something that the CDI EG (1.1) could resolve nor was there any
> mention in the EE7 JSR proposal to do a wholescale review of dd's. It would
> have been a worthless exercise to consider it IOW.
> * That the CDI EG for 1.0
> decided that they would prefer no XML config than a design that was
> consistent with the other dd's in EE 6, and that there has been no change of
> opinion here.
> * That portable extensions fill the gap making it less relevant
> for CDI in isolation. If we could extend this XML approach to other specs as
> well, it suddenly becomes much more interesting again.
I think there's a bit of a disconnect here, and perhaps some confusion at
least on my part.
As I remember it, the full CDI XML config was dropped because it used a style
inconsistent with the other deployment descriptors, and while it was an
interesting approach that we wanted to explore further, there wasn't enough time
to do so for Java EE 6.
Exploring this new approach for Java EE 7 is risky because it touches so many
things. We went in to Java EE 7 preferring to constrain the scope of the
release so that we could get it done quickly, and this seemed like it would
be more work than we could fit in. I'm still worried about that, but it's
still worth having the discussion so that we can better understand what we
might do for Java EE 8.
An open question then is whether, once we all understand this new approach,
we should consider introducing it with CDI 1.1 (but not elsewhere), or
defer it to the CDI release that would go with EE 8. Using this new approach
to control only the things you can already control with CDI might be a
constrained enough problem that you could consider it for CDI 1.1. But
allowing it to also control (e.g.) the Servlet-specific annotations that
the web container processes might push it into the "too much for EE 7"
category. Is the constrained version worth the effort now? I don't know...