On 09/11/2010 07:32 PM, glassfish_at_javadesktop.org wrote:
> Take a look at this post where I explain the difference and when to use each one: http://www.germanescobar.net/2010/04/4-areas-of-possible-confusion-in-jee6.html
That is an excellent and very clearly written summary of the points of
conflict and confusion in the Java EE Specification. Anyone from Oracle
reading should be getting in touch to license that as a official
documentation, *right* *now*.
If only that was in an appendix to the tutorial. I'd save people trying
to learn EE 6 about three days of pain and suffering. The CDI-vs-JSF DI
farce is an awfully confusing thing to deal with when learning Java EE,
and the way the various documentation totally fails to deal with it is
seriously annoying.
It took me quite some time to figure out what the relationship between
the JSF managed bean and scope annotations, and the CDI named and scope
annotations, was. The duplication of @ManagedBean in the annotation
package doesn't help any, nor does CDI's completely different use of the
@EJB annotation.
IMO, as someone who suffered through this recently, there is a fairly
urgent need for a Java EE 6.2 that addresses the worst areas of
confusion in the DI-related parts of the specification (created by the
late addition of CDI) by:
- Deprecating JSF injection in favour of CDI, making CDI a mandatory
dependency for JSF implementations
- Requiring JSF implementations to do DI on @FacesConverter objects and
similar JSF "helper" objects instantiated by the container
- Deprecating javax.annotation.ManagedBean or clearly defining its role
in the CDI-driven container
- Deprecating one of javax.inject.Singleton and
javax.enterprise.inject.ApplicationScoped.
- Deprecating @EJB. Except, because Weld has re-purposed it for
a producer method annotation, it might not be possible to cleanly
deprecate it, so this source of confusion may have to remain.
Right now, the spec is a learner's / beginner's nightmare, and will
cause people to give up on Java EE as a whole as an overly complex mess,
rather than persisting until they can see through it and understand
what's going on, how the history lead us to this point, etc.
WTF was going on with the parallel development of JSR-299 and JSR-330
anyway ... it's like they didn't talk to each other, or the JSF2 guys,
at all. The tools and technology are great, but the way it interacts and
duplicates functionality is a train-wreck.
(BTW, your article does need a note somewhere that CDI may have to be
enabled with beans.xml to get CDI-driven DI using the current-standard
implementation Weld.)
--
Craig Ringer