On 15 Jul 2011, at 22:29, Bill Shannon wrote:
> 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.
Note, by "use schema" I mean the ability to use multiple schemas in one file e.g.
XXX.xml:
<ejb:...>
<web:...>
<cdi:...>
<jax-rs:...>
I wasn't aware this was supported by Java EE. Maybe just a lot of out of date examples.
>
> > 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.
Unfortunately, I think this is one of the biggest stumbling blocks Java EE faces today for usability - the sheer number of XML files required (still!). Use of schema to allow an "all-in-one" xml file and extensibility to add vendor extensions would largely solve this problem. I think we are missing a big trick in terms of usability and adoption by not investigating this.
>
> 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.
Quite possibly. Extensive use of elements to me always looks very clunky.
>
> Should there be primitives and objects, or should everything be an object?
> Same sort of issue.
Ish, except there are major reasons to use primitives in Java - performance.
>
> 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...
Agreed, this should be part of an overall overhaul.
>
>>> 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...
I think the CDI EG would be happy to explore this, were it to be sanctioned by the EE EG and not just deemed a waste of time from the start.