I know EE 7 is time driven and we can't put all the features into it.
Configuration is an important topic, but as you say Bill, not as easy as it
seems because it has to fit with the existing EE deployment descriptor. Why
not follow the Bean Validation 1.0 spec ? In Apendix C of the spec, the EG
decided to make a proposal for method-level validation. It even starts with
the following sentences :
"This proposition has not been integrated into the core specification and is
not part of it. It remains here for archaeological
purposes and will be seriously considered for a future revision of this
specification."
Why not follow this example ? The EE 7 EG could start talking about it,
write a proposal, either we have time and it goes into the spec, or we don't
and it stays in the Apendix. The nice thing with that, it that we put into
writing what we discussed. This way, if configuration has to wait EE 8, at
least we will have something to start with.
This being said, I think configuration is a more important topic that
PAAS/SAAS (which I find a bit too young, but I've already said that) and
should make its way into EE 7.
Antonio
On Fri, Jul 15, 2011 at 23:29, Bill Shannon <bill.shannon_at_oracle.com> 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.
>
>
> > 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...
>
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org> |
Twitter<http://twitter.com/agoncal>|
Blog <http://feeds.feedburner.com/AntonioGoncalves> |
LinkedIn<http://www.linkedin.com/in/agoncal>| Paris
JUG <http://www.parisjug.org>