Bill,
* 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.
- That is certainly our goal (with the additional benefit of modernizing
the syntax overall for the "POJO" era). I definitely think we should try
to get developer feedback (provided that it is well informed feedback
from actual/potential Java EE developers). Vendors (today or in years
past) might have wanted something that really isn't quite reflective of
actual developer needs...
- Just to be absolutely clear, I'm not necessarily advocating the "one
big XML DD" model - I think flexibility is more important. I still
should be able to have separate application.xml, web.xml,
persistence.xml, beans.xml files or I might choose to consolidate the
ones that make sense for my application -- for example defining
beans.xml content in web.xml. I do think the capability of providing
vendor extensions in XML DD is important -- Resin users have been doing
that for ages in resin-web.xml and do that today with resin-beans.xml.
Cheers,
Reza
On 7/18/2011 5:55 PM, 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.
>
>>> 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.
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1390 / Virus Database: 1516/3773 - Release Date: 07/18/11
>
>