Pete Muir wrote on 07/18/11 02:49 AM:
>
> 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.
It's not, because all the other Java EE vendors previously told us that
they didn't want it to be allowed.
>>> 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.
That was our position many years ago, but it was rejected.
Instead, we've been working towards reducing the need for XML at all,
which I think has been well received by developers.
>> 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.
I don't think anyone has suggested that it's a waste of time from the start.
But if all you end up with is a different syntax for doing exactly the same
things we can already do, it probably will be a waste of time. It's important
to understand what the larger goal is.
For example, if the larger goal is to consolidate all the deployment descriptors
into a single deployment descriptor that supports vendor-specific extensions,
let's find out if that's what developers want.