Antonio,
* 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.
- Well said and good idea about the appendix. I do agree that it is
important to get Java EE 7 out in a timely fashion.
Cheers,
Reza
On 7/16/2011 3:31 AM, Antonio Goncalves wrote:
> 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
> <mailto: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>
> ------------------------------------------------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 10.0.1390 / Virus Database: 1516/3767 - Release Date: 07/15/11
>