On 18 Jul 2011, at 22:55, Bill Shannon wrote:
> 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.
Agreed, and it certainly alleviated the "XML problem" - I think it demonstrates how far we've come that we now see people complaining about this relatively minor problem!
>
>>> 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.
Ok, well the offer stands - let us know if you want to explore a XML syntax for CDI 1.1 :-)