[jsr-314-open] getting behind CDI

[Dan Allen]

Jeremy,

Thanks for your excellent reply. I'm excited because I see a common thread
emerging in our exchange and, with some clarifications on my part, I think
we can arrive at a compatible message. Let me state the message, then get
into the inline responses.

The JSF EG is in the business of creating a UI component model
specification. That's complex enough on it's own. A programming model is
equally complex and better solved by existing solutions. (JSR-299 took 3
years to work it out and Spring has been around twice that long).

If the developer wants to target a native Java EE technology stack, we
should consider recommending platform managed beans
(@javax.annotation.ManagedBean) with CDI services. If the developer's scope
is broader, then we could suggest for them to consider alternative bean
containers such as Spring. It's even possible to recommend the use of
@javax.annotation.ManagedBean with @javax.inject.Inject to have a bean which
is portable to both Java EE and Spring, likely the ideal recommendation for
setting a common ground.

Hopefully we can all agree that it's time to look past the rudimentary JSF
managed bean facility. I don't think we do anyone a service by showing them
the @javax.faces.ManagedBean in examples because it's just not going to
stand up to the long-term challenges the developer is going to face.

I'll now jump inline to provide clarifications of my earlier statements to
help support this neutral position.

On Fri, Dec 18, 2009 at 9:08 PM, Jeremy Grelle <
Jeremy.Grelle at springsource.com> wrote:


> First off, I agree that the ultimate goal of pointing users away from the
> JSF-managed bean model is a good thing.


Great!


> That said, we (myself and Keith along with the rest of the Spring team whom
> we represent) have our reservations about CDI.  So while I agree that the
> ultimate goal is a good one, I just want to be clear that I am slightly wary
> of this getting turned around and becoming a public statement of, "The JSF
> EG thinks you should use CDI."  If some of the members of the EG want to
> individually make that push, that's their right, just as it is ours to say
> we don't see a great benefit to choosing CDI over Spring. What I would
> really like to see is us figuring out the most possible common ground
> between CDI and Spring when showing examples that are alternative to the JSF
> managed bean facility.
>

Absolutely. I think if the goal is to demonstrate a common ground solution,
then a @javax.annotation.ManagedBean with @javax.inject.Inject is the way to
go. If the presentation or demonstration has either a more Java EE-centric
theme or a more Spring-centric theme, then naturally the recommendation can
swing to the respective side.


>
> I really want to make it clear that we don't see it as an "us vs. them"
> thing when talking about Spring and Java EE on the whole.


Great! And neither do I. I think that we all work hard to offer developers
good strong choices and I want to continue to learn from each other. The
representatives from the various JSF component libraries set a nice example
for how collaboration, rather than contests, strengthen the whole ecosystem.


> Spring has always provided first-class integration with a wide range of the
> individual parts of EE, and we continue to do so with EE 6 beyond just JSF 2
> as evidenced by our support of specs like JSR-330, JPA 2, Bean Validation,
> javax.annotation.ManagedBean, etc. in the recently finalized Spring 3.0.


What's important here is it respects the developer's time spent learning
this programming model and we can leverage that common thread in the case
when we want to show compatible programming model in a JSF 2 example.


> The major difference being that we enable the use of these pieces in a
> completely modular and portable way that is just as powerful in a
> lightweight servlet container like Tomcat as it is in a full-blown
> commercial app server like WebSphere or WebLogic.  The benefits are
> evidenced by the fact that you can easily use many of these EE 6 pieces
> *today* with Spring 3.0 even in a container like WebSphere 6.1 that is still
> quite widely deployed and is only J2EE 1.4 compliant.
>

The point you make here is one of the driving forces for Weld to provide the
CDI environment for a Servlet Container. We also recognize that you
sometimes have to cater to what is out there, and to provide lightweight
solutions. My hope is that Java EE will continue to become more modular, but
the Web Profile is certainly a step in that direction.


> I'm getting off-topic, but I just want to make the point that we are not
> anti-EE 6.
>

Great! And I can share with you personally that when I recommend Java EE 6,
it's because I see the potential in that platform, not because I'm
anti-Spring.


>
> > When JSF was created, no other facility was available for defining
> contextual managed beans. As of Java EE 6, there is now a platform-wide
> definition of a managed bean.
>
> I assume you mean javax.annotation.ManagedBean, right?  As I mentioned, we
> do support this in Spring 3.0.  I believe this, as well as the other shared
> annotations such as @Resource, @PersistenceContext, @Inject, etc. could be
> our best common ground to use when showing JSF 2 examples.
>

Yes, @javax.annotation.ManagedBean. Excellent. I'm excited we've been able
to find this common groud.


>
> > With the services of CDI, there is a way to discover, produce, scope,
> inject, name and override beans. All of a sudden, the injection facility,
> and limited number of services in the JSF managed bean facility looks
> rudimentary in comparison. And the reality is, before CDI, most developers
> likely used an alternative bean container anyway (probably Spring) to define
> managed beans. So the JSF managed bean facility has been falling out of
> favor for a long time.
>
> Right, but are you saying we should all tell developers to use CDI instead
> of Spring now even if they are already happily using Spring?


Not at all. I didn't mean to imply that developers should drop a solution
they are happy with. As I said, many JSF 2 developers probably already have
Spring in there.

What I'm advocating is for JSF to step away from solving the managed bean
problem, and for us to downplay the existing facility. JSF once had a
responsbility to provide a managed bean container or else it wouldn't have
worked in the Java EE platform. It needed to provide something so that it
could be shipped with Java EE. Now, the managed bean spec and the CDI
services is present to close that gap, relieving JSF of this responsibility.

So, when the context of a tutorial is the native Java EE platform, it's
appropriate to show @javax.annotation.ManagedBean (with CDI) over the JSF
managed bean facility. If the tutorial has a broader scope, then any backend
container (Spring included) is certainly appropriate to
demonstrate/recommend.


> I just don't see CDI being a clearly better alternative to Spring (in fact,
> I see the opposite, but I freely admit to being biased in that regard), and
> I don't know that we should have an opinion either way collectively as an
> EG. Again, individual opinions will vary as to which one to choose, but as a
> group it seems we should generally remain agnostic, especially if our
> overall goal is to get as many people as possible to be successful with JSF
> 2.
>

+1 to not having to establish a collective opinion, other than to say it is
not JSF managed beans.


>
> > But there is a more serious problem with continuing to recommend the use
> of the JSF managed bean facility. The injections do not take the scope of
> the injected bean into consideration. That means, you cannot inject a
> request-scoped bean into a session-scoped bean without causing the
> request-scoped bean to become a session-scoped bean through attachment. This
> is a very typical occurance with having managed beans in a web application.
> CDI not only keeps beans in different scopes loosely coupled, it hides the
> scope at the injection point.
>
> I'd just like to point out again for the sake of contrast that Spring 3.0
> supports the same sort of approach quite well.  We of course supported this
> previously with our "scoped-proxy" feature since back in Spring 2.0, but it
> had to be configured per-bean and was thus only slightly less annoying than
> configuring JSF managed beans.  JSF was a major part of the use case for
> making it work "by default" with annotation-based configuration without
> having to do extra work.
>

Yep, which backs up my statement that the JSF managed bean facility simply
isn't cutting it anymore.


>
> > But I won't be able to use CDI in a Servlet Container, right?
> >
> > Not true. The CDI reference implementation (Weld) provides a single
> extension JAR (weld-servlet.jar) that you drop into your web application
> archive and you get a full CDI environment (you just don't get EJBs, but
> that's to be expected).
>
> And by proxy you also don't get declarative transaction support, correct?
>  To me, that's an immediate show-stopper for any non-trivial application vs.
> what you get with Spring in a servlet container.
>

Touche. I agree that a gap was left behind. The @TransactionAttribute
annotation (in addition to some other EJB features) should have been allowed
on platform managed beans. We plan to support this in Weld as a prototype
for a revision of the platform. I won't deny that there is still work to be
done in making the Java EE programming model truly excellent. But we can all
improve, right?


>
> > Isn't CDI just a Red Hat thing?
> >
> > Of course not. We should all be behind CDI. As the spec lead, Red Hat
> worked very hard to define a set of services for Java EE managed beans that
> would make the development of enterprise applications simpler. That's
> exactly the type of effort we all put in for the JSF 2 specification. (JSF 2
> was forged by all of us collectively. CDI has the same story). So CDI is
> your technology, one that you can use in Java EE 6 or even outside of it.
> There is no reason to back away from it.
>
> With all due respect, I still fail to see why we should *all* be behind
> CDI.
>

Let me clarify the context here. When I used the term *all* here, I was
thinking in the context of folks advocating the native Java EE platform, not
all of the JSF EG, per se. If you are presenting on JSF 2 running in the
context of native Java EE 6, you should be prefering CDI beans over the
@javax.faces.ManagedBean without hesitation. As I said before, if you are
presenting a broader view, then certainly consider any and all available
backends and choose one based on merit.


> > Perhaps a lot of the heated debating over dependency injection turned you
> off, but that heated debate really made the whole platform better because EG
> members, like us, talked and worked things out in the end.
>
> Actually, what turns me off is that what we ended up with seems to only be
> partially worked out and is still a bit of a mess, to be perfectly blunt.
>  I'll elaborate more on that in my discussion of the examples below.
>
> > @ManagedBean
> > @RequestScoped
> > public class BlogEditor {
> >    @ManagedProperty("#{blogDao}") BlogDao blogDao;
> >    // getters and setters required
> > }
>
> First off, I assume these (including @ManagedBean) are all from the
> javax.faces.bean set of annotations.


Yes.


> Agreed, in this particular example, I would not recommend this approach.
>  What about @ViewScoped though?  That's one of the more useful pieces of JSF
> 2 in my opinion.  I don't believe there is an out-of-the-box CDI-equivalent,
> right?  I would assume it's not hard to implement a custom @ViewScoped that
> CDI would recognize?
>

There isn't a CDI equivalent of @ViewScoped in the CDI spec, but Weld/Seam
will be providing a portable extension, hopefully getting weaved back into a
revision of the spec. We shouldn't have to revert to
@javax.faces.ManagedBean just to get this feature.


> > We want to show them:
> >
> > @Named
> > @RequestScoped
> > public class BlogEditor {
> >    @Inject BlogDao blogDao;
> > }
>
> So first of all, I think it would be great if we'd ended up with something
> like the above that would "just work" in both CDI and Spring.  But we
> didn't.  We do actually support the use of @Named as a class-level
> annotation like this in Spring 3.0.  But I'm curious, why in CDI do you
> recommend using @Named vs. javax.annotation.ManagedBean?  It seems to me
> like @ManagedBean has more clearly defined semantics at the class-level.
>

I actually share this view with you, but I didn't have the ability to
influence an alignment. As it turns out, @Named is a synonym for
@ManagedBean, so we could recommend the latter in our common ground
scenario.


>
> Then we're back to the problem of the scopes.  We of course support various
> scope annotations in Spring, and support something equivalent to your above
> example, but don't specifically support the CDI scope annotations.  What
> really has me a bit confused is why the CDI scopes don't use @Scope from
> JSR-330 and instead use the JSR-299-specific @NormalScope.  The JSF scopes
> don't either, for that matter, but I assume that's because 330 was finalized
> well after.  See, this is what I mean by it being a bit of a mess.  We've
> got some JSF-specific scopes, we've got CDI-specific scopes, we've got
> Spring-specific scopes, etc.  Spring can and will ultimately support the
> equivalent of all of the useful ones (including @ConversationScoped in the
> near future...I really wish we could have just relied on JSF or CDI for
> that), but it sadly seems like we ended up with more fragmentation rather
> than less.
>

I'll admit that I don't know the story behind the choice to not align the
scope annotations. And already we are hearing from developers that having
the javax.faces.* stuff in there is adding to the confusion. That's why, to
start, we need to get that stuff deprecated. Then, I think, we should figure
out how to get the number of duplicate scopes down to one. I encourage you
guys to pursue this goal over on the JSR-299 EG. The only way this is going
to get resolved is if communication happens. We can't really solve that
problem here.


>
> So in the above example, we at least have @Named and @Inject as commonly
> supported things.  I really wish there were one common, complete and
> portable set of scope annotations we could support in Spring, but there
> isn't.
>

The one consolation is that the semantics are exactly the same. A scope is a
scope and it's defined on the bean class. So we have to fudge this around
for now, but again, as long as we are staying away from @javax.faces we are
heading in the right direction.


>
> > I'm asking you to consider my request to get behind CDI.
>
> I'm perfectly fine with a world where CDI and Spring co-exist peacefully.


+1


> Despite my own misgivings about CDI, I acknowledge that it appeals to some.
>  The goal of moving away from the JSF managed bean is a good one.


+1


> But as the collective EG whose goal is to see as much adoption as possible
> of JSF 2, and given the corporate realities of how soon most people are
> going to be using an EE 6 container, I don't see how we can be asked to
> promote it as *the* choice of the EG.
>

This has been a great discussion. I think what we can agree on is what we
don't recommend, the JSF managed bean container. What we can both get behind
is a common set of annotations to hook into stronger bean containers such
platform managed beans + CDI or platform managed bean annotations with
Spring. @javax.annotation.ManagedBean + @javax.inject.Inject and do what you
can to find a common ground for scopes ;)

I'm glad that we can communicate with friendly exchanges and I always look
forward to getting your perspective. Frankly, I think that's what defines
this EG, as Andy so elegantly pointed out in his blog.

-Dan

-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20091219/0c78a9a9/attachment.html