10:23 a.m.
I'm going to venture out onto a limb here in hopes of leveraging the
influence of your professional recommendations. I ask that you read through
this message with an open, forward-looking mind.
I feel strongly that, as a group, we should provide a consistent
recommendation regarding the programming model of JSF by getting behind CDI.
Now, I realize there are Spring developers and supporters on this EG. So,
before going any further, I want to clarify that the point I am making
relates specifically to the native Java EE 6 technology stack. Spring has
always been a strong alternative to the native Java EE programming model and
continues to be a great companion of JSF. The common rival that we want to
downplay is JSF managed beans.
I made the following analogy in my JSF 2 talk at JSF Summit that sets the
stage for my advice:
Facelets replaces JSP as CDI replaces JSF managed beans
(Keep in mind CDI is not a programming model, but adds additional discovery
of a platform-defined managed beans)
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. 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.
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. Therefore this discrepency of JSF managed
beans alone could be enough to question their viability. (If you are a
type-safety advocate, CDI has that going for it over JSF managed beans as
well. And with @ManagedBean, you still can't scope a stateful EJB, which
could cut out an unnecessary middle layer).
Having stated my advice for recommending CDI over JSF managed beans, let me
address some common misconceptions that may be stopping you from embracing
CDI.
*
Isn't CDI heavyweight?*
No. CDI is extremely efficient. All bean definitions and injection points
are calculated at startup. The scanning process is localized to archives
that contain a beans.xml file, so the number of classes to scan is
reasonable. The scanner is pluggable, so it can leverage the scanning that
may already be taking place in the application server. I would estimate that
it doesn't take any longer than looking for @ManagedBean annotations on
classes. Also, proxies are used to manage scoped injections, meaning the
overhead of interceptors is not present.
*Doesn't CDI require extra setup?*
CDI is present in any Java EE 6 application server (full or web profile), so
you can depend on it being there. JSF 2 is part of the Java EE 6 platform,
which is one of it's greatest differentiators over competing web frameworks.
(Of course, other web frameworks could use CDI too, but that is a separate
point).
*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).
*What about older Java EE containers?*
The Weld servlet extension JAR could be added to an application deployed to
a pre-Java EE container and likely work just fine. Let the Weld team know
what doesn't work: https://jira.jboss.org/jira/browse/WELDX
*Isn't it easier just to get started with JSF 2 along?*
Use these Maven 2 archetypes to get started with JSF 2.0 + CDI 1.0 in a
jiffy: http://tinyurl.com/weld-archetypes (soon to be available in the Maven
Central Repository)
*But we worked hard to be able to define JSF managed beans with annotations*
Yes, when we did that Java EE 6 was not around and it was a good step
forward at the time. But 6 months has gone by and Java EE 6 is here, along
with CDI. It's time to embrace the improvements.
*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.
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. I really want you
guys to view CDI as just as much part of our collective stack as the EL,
JSF, JPA and other successful technologies.
Showing users how to use @ManagedBean on a class and inject other managed
beans with @ManagedProperty or an EJB with @EJB is showing developers only a
portion of the value of this platform's programming model. We want to put
our best foot forward. That's why we show composite components in
presentations and not how to create a components in Java. We show Facelets,
not JSP. We want to make it seem as easy as it can be.
Rather than recommending:
@ManagedBean
@RequestScoped
public class BlogEditor {
@ManagedProperty("#{blogDao}") BlogDao blogDao;
// getters and setters required
}
We want to show them:
@Named
@RequestScoped
public class BlogEditor {
@Inject BlogDao blogDao;
}
or even simpler, we can use the built-in @Model stereotype that combines
@Named and @RequestScoped
@Model
public class BlogEditor {
@Inject BlogDao blogDao;
}
The only consolation is that they have to add an empty beans.xml to WEB-INF.
I'm asking you to consider my request to get behind CDI. We aren't talking
about a big change here. But the consistency of the message, and the power
that they get with CDI, will make a huge impact. I encourage you to read the
Weld reference guide as it very clearly explains what CDI is all about (if
it doesn't, tell us). http://tinyurl.com/weldrefguide
(I'll conclude by saying that if this were a Spring + JSF 2 talk, I won't
start by recommending @ManagedBean as a first step).
I welcome your feedback. I'll be glad to answer questions as well.
-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
10:39 a.m.
*Isn't it easier just to get started with JSF 2 along?*
^ alone
--
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
5:44 p.m.
I'm all +1 for this.
CDI is incredibly powerful, as Gavin says "it changes everything". It seems
to me that loose coupling with strong typing, implemented with producers,
events, interceptors, decorators and stereotypes, is the next logical step
in the evolution of object-oriented development.
And we get conversation scope to boot. :)
david
2009/12/17 Dan Allen <dan.j.allen(a)gmail.com>
I'm going to venture out onto a limb here in hopes of leveraging
the
influence of your professional recommendations. I ask that you read through
this message with an open, forward-looking mind.
I feel strongly that, as a group, we should provide a consistent
recommendation regarding the programming model of JSF by getting behind CDI.
Now, I realize there are Spring developers and supporters on this EG. So,
before going any further, I want to clarify that the point I am making
relates specifically to the native Java EE 6 technology stack. Spring has
always been a strong alternative to the native Java EE programming model and
continues to be a great companion of JSF. The common rival that we want to
downplay is JSF managed beans.
I made the following analogy in my JSF 2 talk at JSF Summit that sets the
stage for my advice:
Facelets replaces JSP as CDI replaces JSF managed beans
(Keep in mind CDI is not a programming model, but adds additional discovery
of a platform-defined managed beans)
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. 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.
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. Therefore this discrepency of JSF managed
beans alone could be enough to question their viability. (If you are a
type-safety advocate, CDI has that going for it over JSF managed beans as
well. And with @ManagedBean, you still can't scope a stateful EJB, which
could cut out an unnecessary middle layer).
Having stated my advice for recommending CDI over JSF managed beans, let me
address some common misconceptions that may be stopping you from embracing
CDI.
*
Isn't CDI heavyweight?*
No. CDI is extremely efficient. All bean definitions and injection points
are calculated at startup. The scanning process is localized to archives
that contain a beans.xml file, so the number of classes to scan is
reasonable. The scanner is pluggable, so it can leverage the scanning that
may already be taking place in the application server. I would estimate that
it doesn't take any longer than looking for @ManagedBean annotations on
classes. Also, proxies are used to manage scoped injections, meaning the
overhead of interceptors is not present.
*Doesn't CDI require extra setup?*
CDI is present in any Java EE 6 application server (full or web profile),
so you can depend on it being there. JSF 2 is part of the Java EE 6
platform, which is one of it's greatest differentiators over competing web
frameworks. (Of course, other web frameworks could use CDI too, but that is
a separate point).
*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).
*What about older Java EE containers?*
The Weld servlet extension JAR could be added to an application deployed to
a pre-Java EE container and likely work just fine. Let the Weld team know
what doesn't work: https://jira.jboss.org/jira/browse/WELDX
*Isn't it easier just to get started with JSF 2 along?*
Use these Maven 2 archetypes to get started with JSF 2.0 + CDI 1.0 in a
jiffy: http://tinyurl.com/weld-archetypes (soon to be available in the
Maven Central Repository)
*But we worked hard to be able to define JSF managed beans with
annotations*
Yes, when we did that Java EE 6 was not around and it was a good step
forward at the time. But 6 months has gone by and Java EE 6 is here, along
with CDI. It's time to embrace the improvements.
*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.
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. I really want you
guys to view CDI as just as much part of our collective stack as the EL,
JSF, JPA and other successful technologies.
Showing users how to use @ManagedBean on a class and inject other managed
beans with @ManagedProperty or an EJB with @EJB is showing developers only a
portion of the value of this platform's programming model. We want to put
our best foot forward. That's why we show composite components in
presentations and not how to create a components in Java. We show Facelets,
not JSP. We want to make it seem as easy as it can be.
Rather than recommending:
@ManagedBean
@RequestScoped
public class BlogEditor {
@ManagedProperty("#{blogDao}") BlogDao blogDao;
// getters and setters required
}
We want to show them:
@Named
@RequestScoped
public class BlogEditor {
@Inject BlogDao blogDao;
}
or even simpler, we can use the built-in @Model stereotype that combines
@Named and @RequestScoped
@Model
public class BlogEditor {
@Inject BlogDao blogDao;
}
The only consolation is that they have to add an empty beans.xml to
WEB-INF.
I'm asking you to consider my request to get behind CDI. We aren't talking
about a big change here. But the consistency of the message, and the power
that they get with CDI, will make a huge impact. I encourage you to read the
Weld reference guide as it very clearly explains what CDI is all about (if
it doesn't, tell us). http://tinyurl.com/weldrefguide
(I'll conclude by saying that if this were a Spring + JSF 2 talk, I won't
start by recommending @ManagedBean as a first step).
I welcome your feedback. I'll be glad to answer questions as well.
-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
5:50 p.m.
On Thu, Dec 17, 2009 at 6:44 PM, David Geary <clarity.training(a)gmail.com>wrote:
I'm all +1 for this.
CDI is incredibly powerful, as Gavin says "it changes everything". It seems
to me that loose coupling with strong typing, implemented with producers,
events, interceptors, decorators and stereotypes, is the next logical step
in the evolution of object-oriented development.
And we get conversation scope to boot. :)
Yep. Adam Bien provided a nice taste of the kind of out-of-the-box
functionality you can get in a recent blog entry:
http://www.adam-bien.com/roller/abien/entry/java_ee_6_observer_with
-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
8:08 p.m.
Dan, I totally respect your desire to push CDI as an integral part of the "native
Java EE" or rather the "Java EE 6 Web Profile Container" programming model,
but I would like to offer a slightly contrasting point of view. See my further points
inline below.
On Dec 17, 2009, at 8:23 AM, Dan Allen wrote:
I feel strongly that, as a group, we should provide a consistent
recommendation regarding the programming model of JSF by getting behind CDI. Now, I
realize there are Spring developers and supporters on this EG. So, before going any
further, I want to clarify that the point I am making relates specifically to the native
Java EE 6 technology stack. Spring has always been a strong alternative to the native Java
EE programming model and continues to be a great companion of JSF. The common rival that
we want to downplay is JSF managed beans.
First off, I agree that the ultimate goal of pointing users away from the JSF-managed bean
model is a good thing. 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.
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. 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.annotationManagedBean, etc. in the recently finalized Spring
3.0. 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.
I'm getting off-topic, but I just want to make the point that we are not anti-EE 6.
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.
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? 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.
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.
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.
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.
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. 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?
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.
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.
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.
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. 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. 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.
Cheers,
Jeremy
10:25 a.m.
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(a)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
2:22 p.m.
Dan,
Indeed, I believe we are arriving at a nice common ground. Thank you for the
clarifications. I'm glad that you are accepting of our stance and see this as a very
positive discussion. I have just a few more points to add...
On Dec 19, 2009, at 8:25 AM, Dan Allen wrote:
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.
Perhaps one of the first things we should do is update the "Get Started" on
www.javaserverfaces.org<http://www.javaserverfaces.org> to show both options. This
would require both a Weld archetype (which I think you've been working on?) and one
for Spring 3 (I could work on providing one).
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.
Right, and we can provide a similar extension in Spring, but I'm wondering if we can
find some sort of shared approach...
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.
To be fair, we aren't yet providing any out-of-the-box implementations of
JSR-330's @Scope other than the @Singleton that is required by by the spec. Maybe
this is an opportunity for further collaboration, outside of the scope of the EG. It
would be really cool if we could establish a single common and complete set of scope
annotations as portable extensions usable in both Seam and Spring...I'm not entirely
certain yet how technically feasible this would be...just something to think about.
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.
+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 ;)
+1
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.
Indeed, it is quite refreshing to be able to have such discussions without things
degenerating into TSS-style bickering. As can seen by taking a look at some of the
arguments on the JSR-330 list, for example, EG's are not by rule free of such
nonsense. I am thankful for your open-ness and for Ed and everyone else's roles in
fostering such an environment, and look forward to seeing it continue.
Cheers,
Jeremy
6:53 p.m.
Jeremy,
Perhaps one of the first things we should do is update the "Get Started" on
To be fair, we aren't yet providing any out-of-the-box
implementations of
> JSR-330's @Scope other than the @Singleton that is required by by the spec.
> Maybe this is an opportunity for further collaboration, outside of the
> scope of the EG. It would be really cool if we could establish a single
> common and complete set of scope annotations as portable extensions usable
> in both Seam and Spring...I'm not entirely certain yet how technically
> feasible this would be...just something to think about.
Sounds like an action item for collaboration in 2010!
> 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.
> Indeed, it is quite refreshing
to be able to have such discussions without
> things degenerating into TSS-style bickering. As can seen by taking a look
> at some of the arguments on the JSR-330 list, for example, EG's are not by
> rule free of such nonsense. I am thankful for your open-ness and for Ed and
> everyone else's roles in fostering such an environment, and look forward to
> seeing it continue.
+1
On that note, Happy Holidays and New Year. I'm looking forward to 2010!
-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
www.javaserverfaces.org to show both options. This would require
both a
Weld archetype (which I think you've been working on?) and one for Spring 3
(I could work on providing one).
We must have been on the same wavelength because that's exactly what I was
working on while you were writing back. I've split the page into three
parts, explaining that there are three "packages" so to speak. I've left
the
Spring section open. If you want to fill that in with an archetype of your
choice, that would be great. I've granted you edit access. (You have to
tolerate the painfully slow Google Sites editor. It takes some patience to
tame the bullets).
We can clean up some of the text throughout the page, I was just throwing
down some structure quickly.
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.
Right, and we can provide a similar extension in Spring, but I'm wondering
if we can find some sort of shared approach...
..
9:39 a.m.
Googlers sites is fast for me with ff3 on Ubuntu or even windoze. :)
Lincoln Baxter III
http://ocpsoft.com
http://scrumshark.com
Keep it simple.
On Dec 19, 2009 7:53 PM, "Dan Allen" <dan.j.allen(a)gmail.com> wrote:
Jeremy,
Perhaps one of the first things we should do is update the "Get
Started"
on www.javaserverfaces.or...
We must have been on the same wavelength because that's exactly what I was
working on while you were writing back. I've split the page into three
parts, explaining that there are three "packages" so to speak. I've left
the
Spring section open. If you want to fill that in with an archetype of your
choice, that would be great. I've granted you edit access. (You have to
tolerate the painfully slow Google Sites editor. It takes some patience to
tame the bullets).
We can clean up some of the text throughout the page, I was just throwing
down some structure quickly.
> >>> Agreed, in this particular example, I would not
recommend this
approach. What about @ViewS...
...
> To be fair, we aren't yet providing any out-of-the-box implementations
of
JSR-330's @Scope other...
Sounds like an action item for collaboration in 2010!
> >> I'm glad that we can communicate with friendly
exchanges and I always
look forward to getting...
+1
On that note, Happy Holidays and New Year. I'm looking forward to 2010!
-Dan
-- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #2...
4:16 p.m.
Now I'm convinced it's time to upgrade my laptop to Ubuntu. I've been away
too long. It will be my xmas present to myself ;) Downloading an image now.
- Dan Allen
Sent from my Android-powered phone:
An open platform for carriers, consumers
and developers.
On Dec 20, 2009 10:39 AM, "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com>
wrote:
Googlers sites is fast for me with ff3 on Ubuntu or even windoze. :)
Lincoln Baxter III http://ocpsoft.com http://scrumshark.com Keep it simple.
> On Dec 19, 2009 7:53 PM, "Dan Allen"
<dan.j.allen(a)gmail.com> wrote: > >
Jeremy, >
Perhaps one of the first things we should do is update the "Get
Started"
on www.javaserverfaces.or...
> > We must have been on the same wavelength because that's
exactly what I
was working on while y...
> >>> Agreed, in this particular example, I would not
recommend this
approach. What about @ViewS...
...
> To be fair, we aren't yet providing any out-of-the-box implementations
of
JSR-330's @Scope other...
> > Sounds like an action item for collaboration in 2010! >
> >> I'm glad that we can communicate with friendly
exchanges and I always
look forward to getting...
> > +1 > > On that note, Happy Holidays and New Year.
I'm looking forward
to 2010! > > -Dan
-- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #2...
6:33 p.m.
I've found this a fascinating thread. I didn't know that Spring 3.0 had many
of the same features as CDI.
So I can intelligently recommend either Spring 3 or CDI, I'd like to know
what are the advantages and disadvantages of each. I read the comments on
TSS (<http://www.theserverside.com/news/thread.tss?thread_id=58858#330454>),
and from that thread I surmised that Spring 3.0 and CDI were similar, but I
don't understand the differences. I appreciate, btw, the much more cordial
discussion Dan and Jeremy have had on this list.
Dan and Jeremy, it'd be great if you guys could let us know what the pros
and cons of each are.
Thanks,
david
2009/12/19 Dan Allen <dan.j.allen(a)gmail.com>
Jeremy,
Perhaps one of the first things we should do is update the "Get Started" on
> www.javaserverfaces.org to show both options. This would require both a
> Weld archetype (which I think you've been working on?) and one for Spring 3
> (I could work on providing one).
>
We must have been on the same wavelength because that's exactly what I was
working on while you were writing back. I've split the page into three
parts, explaining that there are three "packages" so to speak. I've left
the
Spring section open. If you want to fill that in with an archetype of your
choice, that would be great. I've granted you edit access. (You have to
tolerate the painfully slow Google Sites editor. It takes some patience to
tame the bullets).
We can clean up some of the text throughout the page, I was just throwing
down some structure quickly.
>
> 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.
>
>
> Right, and we can provide a similar extension in Spring, but I'm wondering
> if we can find some sort of shared approach...
>
...
>
To be fair, we aren't yet providing any out-of-the-box implementations of
> JSR-330's @Scope other than the @Singleton that is required by by the spec.
> Maybe this is an opportunity for further collaboration, outside of the
> scope of the EG. It would be really cool if we could establish a single
> common and complete set of scope annotations as portable extensions usable
> in both Seam and Spring...I'm not entirely certain yet how technically
> feasible this would be...just something to think about.
>
Sounds like an action item for collaboration in 2010!
>
> 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.
>
>
> Indeed, it is quite refreshing to be able to have such discussions without
> things degenerating into TSS-style bickering. As can seen by taking a look
> at some of the arguments on the JSR-330 list, for example, EG's are not by
> rule free of such nonsense. I am thankful for your open-ness and for Ed and
> everyone else's roles in fostering such an environment, and look forward to
> seeing it continue.
>
+1
On that note, Happy Holidays and New Year. I'm looking forward to 2010!
-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
2:24 a.m.
The most essential and basic feature I miss is the conversation scope which
is covered by weldx. Spring is only making a promise for 3.1 here.
Conversation delimiters are set programmatically in weldx which I consider not
ideal. I'd wish having annotation/XML based navigation rules that cover
conversations and contained beans. Maybe we can cover this feature in the future?
Best regards,
Ganesh
David Geary schrieb:
I've found this a fascinating thread. I didn't know that
Spring 3.0 had
many of the same features as CDI.
So I can intelligently recommend either Spring 3 or CDI, I'd like to
know what are the advantages and disadvantages of each. I read the
comments on TSS
(<http://www.theserverside.com/news/thread.tss?thread_id=58858#330454>),
and from that thread I surmised that Spring 3.0 and CDI were similar,
but I don't understand the differences. I appreciate, btw, the much more
cordial discussion Dan and Jeremy have had on this list.
Dan and Jeremy, it'd be great if you guys could let us know what the
pros and cons of each are.
Thanks,
david
2009/12/19 Dan Allen <dan.j.allen(a)gmail.com <mailto:dan.j.allen@gmail.com>>
Jeremy,
Perhaps one of the first things we should do is update the "Get
Started" on www.javaserverfaces.org
<http://www.javaserverfaces.org> to show both options. This
would require both a Weld archetype (which I think you've been
working on?) and one for Spring 3 (I could work on providing one).
We must have been on the same wavelength because that's exactly what
I was working on while you were writing back. I've split the page
into three parts, explaining that there are three "packages" so to
speak. I've left the Spring section open. If you want to fill that
in with an archetype of your choice, that would be great. I've
granted you edit access. (You have to tolerate the painfully slow
Google Sites editor. It takes some patience to tame the bullets).
We can clean up some of the text throughout the page, I was just
throwing down some structure quickly.
> 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.
Right, and we can provide a similar extension in Spring, but I'm
wondering if we can find some sort of shared approach...
...
To be fair, we aren't yet providing any out-of-the-box
implementations of JSR-330's @Scope other than the @Singleton
that is required by by the spec. Maybe this is an opportunity
for further collaboration, outside of the scope of the EG. It
would be really cool if we could establish a single common and
complete set of scope annotations as portable extensions usable
in both Seam and Spring...I'm not entirely certain yet how
technically feasible this would be...just something to think about.
Sounds like an action item for collaboration in 2010!
> 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.
Indeed, it is quite refreshing to be able to have such
discussions without things degenerating into TSS-style
bickering. As can seen by taking a look at some of the
arguments on the JSR-330 list, for example, EG's are not by rule
free of such nonsense. I am thankful for your open-ness and for
Ed and everyone else's roles in fostering such an environment,
and look forward to seeing it continue.
+1
On that note, Happy Holidays and New Year. I'm looking forward to 2010!
-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
3:17 a.m.
On Mon, Dec 21, 2009 at 9:24 AM, Ganesh <ganesh(a)j4fry.org> wrote:
The most essential and basic feature I miss is the conversation scope
which
is covered by weldx. Spring is only making a promise for 3.1 here.
Myfaces has Orchestra which delivers it for Spring, I don´t think it is
really
bound to MyFaces at all since the JSF specific part is very small and
probably does not touch anything MyFaces internal.
Orchestra has been there almost for 2 years now, and it is overlooked by
many who think this is a MyFaces only thing.
(In fact to my knowledge it works even outside of JSF on plain servlet
level)
So conversation support for Spring is there and has been very reliable for
ages now (Kudos to Mario Ivankovitch and Simon Kitching for pulling it off),
but not inside Spring itself which as Ganesh has pointed out will come in
3.1!
Werner
Conversation delimiters are set programmatically in weldx which I consider
not
ideal. I'd wish having annotation/XML based navigation rules that cover
conversations and contained beans. Maybe we can cover this feature in the
future?
Best regards,
Ganesh
David Geary schrieb:
> I've found this a fascinating thread. I didn't know that Spring 3.0 had
> many of the same features as CDI.
>
> So I can intelligently recommend either Spring 3 or CDI, I'd like to know
> what are the advantages and disadvantages of each. I read the comments on
> TSS (<http://www.theserverside.com/news/thread.tss?thread_id=58858#330454>),
> and from that thread I surmised that Spring 3.0 and CDI were similar, but I
> don't understand the differences. I appreciate, btw, the much more cordial
> discussion Dan and Jeremy have had on this list.
>
> Dan and Jeremy, it'd be great if you guys could let us know what the pros
> and cons of each are.
>
> Thanks,
>
>
> david
>
> 2009/12/19 Dan Allen <dan.j.allen(a)gmail.com <mailto:dan.j.allen@gmail.com
> >>
>
>
> Jeremy,
>
> Perhaps one of the first things we should do is update the "Get
> Started" on www.javaserverfaces.org
> <http://www.javaserverfaces.org> to show both options. This
>
> would require both a Weld archetype (which I think you've been
> working on?) and one for Spring 3 (I could work on providing one).
>
>
> We must have been on the same wavelength because that's exactly what
> I was working on while you were writing back. I've split the page
> into three parts, explaining that there are three "packages" so to
> speak. I've left the Spring section open. If you want to fill that
> in with an archetype of your choice, that would be great. I've
> granted you edit access. (You have to tolerate the painfully slow
> Google Sites editor. It takes some patience to tame the bullets).
>
> We can clean up some of the text throughout the page, I was just
> throwing down some structure quickly.
>
>
> 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.
>>
>
> Right, and we can provide a similar extension in Spring, but I'm
> wondering if we can find some sort of shared approach...
>
> ...
>
> To be fair, we aren't yet providing any out-of-the-box
> implementations of JSR-330's @Scope other than the @Singleton
> that is required by by the spec. Maybe this is an opportunity
> for further collaboration, outside of the scope of the EG. It
> would be really cool if we could establish a single common and
> complete set of scope annotations as portable extensions usable
> in both Seam and Spring...I'm not entirely certain yet how
> technically feasible this would be...just something to think about.
>
>
> Sounds like an action item for collaboration in 2010!
>
>
> 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.
>>
>
> Indeed, it is quite refreshing to be able to have such
> discussions without things degenerating into TSS-style
> bickering. As can seen by taking a look at some of the
> arguments on the JSR-330 list, for example, EG's are not by rule
> free of such nonsense. I am thankful for your open-ness and for
> Ed and everyone else's roles in fostering such an environment,
> and look forward to seeing it continue.
>
>
> +1
>
> On that note, Happy Holidays and New Year. I'm looking forward to 2010!
>
> -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
>
>
>
11:43 a.m.
Spring also has Spring WebFlow and SpringFaces, which provide conversation
scope.
david
2009/12/21 Werner Punz <werner.punz(a)gmail.com>
On Mon, Dec 21, 2009 at 9:24 AM, Ganesh <ganesh(a)j4fry.org> wrote:
> The most essential and basic feature I miss is the conversation scope
> which
> is covered by weldx. Spring is only making a promise for 3.1 here.
>
> Myfaces has Orchestra which delivers it for Spring, I don´t think it is
really bound to MyFaces at all since the JSF specific part is very small and
probably does not touch anything MyFaces internal.
Orchestra has been there almost for 2 years now, and it is overlooked by
many who think this is a MyFaces only thing.
(In fact to my knowledge it works even outside of JSF on plain servlet
level)
So conversation support for Spring is there and has been very reliable for
ages now (Kudos to Mario Ivankovitch and Simon Kitching for pulling it off),
but not inside Spring itself which as Ganesh has pointed out will come in
3.1!
Werner
Conversation delimiters are set programmatically in weldx which I consider
> not
> ideal. I'd wish having annotation/XML based navigation rules that cover
> conversations and contained beans. Maybe we can cover this feature in the
> future?
>
> Best regards,
> Ganesh
> David Geary schrieb:
>
>> I've found this a fascinating thread. I didn't know that Spring 3.0 had
>> many of the same features as CDI.
>>
>> So I can intelligently recommend either Spring 3 or CDI, I'd like to know
>> what are the advantages and disadvantages of each. I read the comments on
>> TSS (<
>> http://www.theserverside.com/news/thread.tss?thread_id=58858#330454>),
>> and from that thread I surmised that Spring 3.0 and CDI were similar, but I
>> don't understand the differences. I appreciate, btw, the much more cordial
>> discussion Dan and Jeremy have had on this list.
>>
>> Dan and Jeremy, it'd be great if you guys could let us know what the pros
>> and cons of each are.
>>
>> Thanks,
>>
>>
>> david
>>
>> 2009/12/19 Dan Allen <dan.j.allen(a)gmail.com <mailto:
>> dan.j.allen(a)gmail.com>>
>>
>>
>> Jeremy,
>>
>> Perhaps one of the first things we should do is update the "Get
>> Started" on www.javaserverfaces.org
>> <http://www.javaserverfaces.org> to show both options. This
>>
>> would require both a Weld archetype (which I think you've been
>> working on?) and one for Spring 3 (I could work on providing one).
>>
>>
>> We must have been on the same wavelength because that's exactly what
>> I was working on while you were writing back. I've split the page
>> into three parts, explaining that there are three "packages" so to
>> speak. I've left the Spring section open. If you want to fill that
>> in with an archetype of your choice, that would be great. I've
>> granted you edit access. (You have to tolerate the painfully slow
>> Google Sites editor. It takes some patience to tame the bullets).
>>
>> We can clean up some of the text throughout the page, I was just
>> throwing down some structure quickly.
>>
>>
>> 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.
>>>
>>
>> Right, and we can provide a similar extension in Spring, but I'm
>> wondering if we can find some sort of shared approach...
>>
>> ...
>>
>> To be fair, we aren't yet providing any out-of-the-box
>> implementations of JSR-330's @Scope other than the @Singleton
>> that is required by by the spec. Maybe this is an opportunity
>> for further collaboration, outside of the scope of the EG. It
>> would be really cool if we could establish a single common and
>> complete set of scope annotations as portable extensions usable
>> in both Seam and Spring...I'm not entirely certain yet how
>> technically feasible this would be...just something to think
>> about.
>>
>>
>> Sounds like an action item for collaboration in 2010!
>>
>>
>> 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.
>>>
>>
>> Indeed, it is quite refreshing to be able to have such
>> discussions without things degenerating into TSS-style
>> bickering. As can seen by taking a look at some of the
>> arguments on the JSR-330 list, for example, EG's are not by rule
>> free of such nonsense. I am thankful for your open-ness and for
>> Ed and everyone else's roles in fostering such an environment,
>> and look forward to seeing it continue.
>>
>>
>> +1
>>
>> On that note, Happy Holidays and New Year. I'm looking forward to
>> 2010!
>>
>> -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
>>
>>
>>
4 p.m.
FWIW, Micha Kiener, the lead for the coversation scope in Spring 3.1,
gave a great talk about it at the JSF Summit. I'm sure he'd be happy
to share his slides if anyone is interested (conference attendees can
download it from the site).
Orchestra is really nice, too.
Sent from my iPhone
http://www.jsfcentral.com
http://www.Virtua.com
On Dec 21, 2009, at 12:43 PM, David Geary <clarity.training(a)gmail.com>
wrote:
Spring also has Spring WebFlow and SpringFaces, which provide
conversation scope.
david
2009/12/21 Werner Punz <werner.punz(a)gmail.com>
On Mon, Dec 21, 2009 at 9:24 AM, Ganesh <ganesh(a)j4fry.org> wrote:
The most essential and basic feature I miss is the conversation
scope which
is covered by weldx. Spring is only making a promise for 3.1 here.
Myfaces has Orchestra which delivers it for Spring, I don´t think it
is really bound to MyFaces at all since the JSF specific part is ve
ry small and probably does not touch anything MyFaces internal.
Orchestra has been there almost for 2 years now, and it is
overlooked by many who think this is a MyFaces only thing.
(In fact to my knowledge it works even outside of JSF on plain
servlet level)
So conversation support for Spring is there and has been very
reliable for ages now (Kudos to Mario Ivankovitch and Simon Kitching
for pulling it off), but not inside Spring itself which as Ganesh
has pointed out will come in 3.1!
Werner
Conversation delimiters are set programmatically in weldx which I
consider not
ideal. I'd wish having annotation/XML based navigation rules that
cover
conversations and contained beans. Maybe we can cover this feature
in the future?
Best regards,
Ganesh
David Geary schrieb:
I've found this a fascinating thread. I didn't know that Spring 3.0
had many of the same features as CDI.
So I can intelligently recommend either Spring 3 or CDI, I'd like to
know what are the advantages and disadvantages of each. I read the
comments on TSS (<http://www.theserverside.com/news/thread.tss?thread_id=58858#330454
>), and from that thread I surmised that Spring 3.0 and CDI were
similar, but I don't understand the differences. I appreciate, btw,
the much more cordial discussion Dan and Jeremy have had on this list.
Dan and Jeremy, it'd be great if you guys could let us know what the
pros and cons of each are.
Thanks,
david
2009/12/19 Dan Allen <dan.j.allen(a)gmail.com <mailto:dan.j.allen@gmail.com
>>
Jeremy,
Perhaps one of the first things we should do is update the "Get
Started" on www.javaserverfaces.org
<http://www.javaserverfaces.org> to show both options. This
would require both a Weld archetype (which I think you've been
working on?) and one for Spring 3 (I could work on providing
one).
We must have been on the same wavelength because that's exactly
what
I was working on while you were writing back. I've split the page
into three parts, explaining that there are three "packages" so to
speak. I've left the Spring section open. If you want to fill that
in with an archetype of your choice, that would be great. I've
granted you edit access. (You have to tolerate the painfully slow
Google Sites editor. It takes some patience to tame the bullets).
We can clean up some of the text throughout the page, I was just
throwing down some structure quickly.
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.
Right, and we can provide a similar extension in Spring, but
I'm
wondering if we can find some sort of shared approach...
...
To be fair, we aren't yet providing any out-of-the-box
implementations of JSR-330's @Scope other than the @Singleton
that is required by by the spec. Maybe this is an opportunity
for further collaboration, outside of the scope of the EG. It
would be really cool if we could establish a single common and
complete set of scope annotations as portable extensions usable
in both Seam and Spring...I'm not entirely certain yet how
technically feasible this would be...just something to think
about.
Sounds like an action item for collaboration in 2010!
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.
Indeed, it is quite refreshing to be able to have such
discussions without things degenerating into TSS-style
bickering. As can seen by taking a look at some of the
arguments on the JSR-330 list, for example, EG's are not by
rule
free of such nonsense. I am thankful for your open-ness and
for
Ed and everyone else's roles in fostering such an environment,
and look forward to seeing it continue.
+1
On that note, Happy Holidays and New Year. I'm looking forward to
2010!
-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
1:06 p.m.
On Mon, Dec 21, 2009 at 3:24 AM, Ganesh <ganesh(a)j4fry.org> wrote:
The most essential and basic feature I miss is the conversation scope
which
is covered by weldx. Spring is only making a promise for 3.1 here.
Actually, the conversation context is defined in the CDI specification,
making it a standard scope that's available with any CDI implementation.
It's not specific to Weld. However, Weld does add some features missing from
the standard conversation (admittedly, some pretty important features).
Conversation delimiters are set programmatically in weldx which I consider
not
ideal. I'd wish having annotation/XML based navigation rules that cover
conversations and contained beans. Maybe we can cover this feature in the
future?
I recognize that it was a bit of a let down that JSF 2 didn't define a
conversation scope. But in the long run it was right to wait. The problem is
that Java EE has never had a way to define new scopes. You could layer a
framework over Java EE that did scoping, but the scope itself would never be
standard. We didn't want JSF taking on the responsibility, especially since
this feature was coming in CDI. But, the timing of the JSF 2 release made it
impossible to have conversation scope defined at the time.
Now, there is a way in the platform to define new scopes. CDI went ahead and
introduced the conversation scope, but stated explicitly that it is designed
for use with JSF. In the future, I forsee scopes being defined by the specs
in which they are used. So the conversation scope could be defined in the
JSF specification, or, at the very least, there should be controls defined
that manipulate the conversation scope. This integration would be along the
lines of the JSF - Bean Validation integration. The JSF spec could define
component tags / view metadata tags that control the boundaries of the
conversation, just like in Seam (and other such frameworks).
In summary, this is a developing story. Things will improve and mature. We
needed the scoping mechanism in CDI in order to define new scopes in the
platform (which frameworks like Spring are free to emulate). Then we can go
back and add controls in JSF to manipulate these scopes. And, tying into
what Jeremy and I were discussing, it's really important that we standardize
the scope annotations so that we can ensure maximum portability of beans
(even between the platform and frameworks like Spring that utilize these
declarations).
-Dan
p.s. Currently, you can control the CDI conversation using the standard Java
API or via an EL expression (if you name the built-in conversation bean).
--
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
12:08 a.m.
David,
I'm going to disappoint you slightly because I don't think this list is the
appropriate place to compare Spring 3.0 and CDI. I would like to avoid an
unbounded thread, which these things inevitably turn into. My best advice
for you is to simply evaluate the two reference guides and post your
conclusions.
What I will say is that the relevance (I'm avoiding the term "benefit") of
CDI is that it's bundled in the Java EE 6 platform, giving the platform a
bean container for the first time. Well, okay, there was a half-hearted
attempt at a bean container prior to that. Really, it was just a specialized
bean container that only supported one type of bean (EJBs) and a fixed set
of platform-bound resource injections (@PersistenceContext, @Resource, etc).
Granted, there are still some bumbs to be worked out across the platform.
But the steps that were taken in Java EE 6, most notably that it now has a
bean container, are pretty damn monumental.
What's more, for the first time ever, it's possible to extend Java EE using
the CDI extension SPI. That means you can add/modify/remove beans,
interceptors, decorators, qualifiers, etc. at startup time, get information
about the runtime, and other sorts of tweaking. You could call it Tweak EE
(playing off of Tweak UI).
So if something isn't working out for you, it's certainly possible that an
extension will be able to fill in the void. I'd go so far as to say that a
framework like Spring could leverage the extension SPI heavily to integrate
itself into Java EE if the developer was looking for that type of bridge.
(Experience will tell us if that is true). There are certainly places in
Spring today that it has to go searching for information that now the CDI
extension SPI could provide for it for free.
That's my brief sketch of CDI. The advantage that Spring has is that it's
incredibly well-known and, well, it's at version 3.0. It wouldn't really be
a balanced equation to compare Spring with CDI anyway, since Spring is so
much more than just a bean container. If you did a head-to-head comparison,
it would have to be with Spring core (and the Java EE integration). But I
don't want to partake in that comparison on this list, as I mentioned
before. Besides, it's the holiday and we don't want to create a long thread
to distract folks from their presents (and family).
-Dan
On Sun, Dec 20, 2009 at 7:33 PM, David Geary <clarity.training(a)gmail.com>wrote:
I've found this a fascinating thread. I didn't know that
Spring 3.0 had
many of the same features as CDI.
So I can intelligently recommend either Spring 3 or CDI, I'd like to know
what are the advantages and disadvantages of each. I read the comments on
TSS (<http://www.theserverside.com/news/thread.tss?thread_id=58858#330454>),
and from that thread I surmised that Spring 3.0 and CDI were similar, but I
don't understand the differences. I appreciate, btw, the much more cordial
discussion Dan and Jeremy have had on this list.
Dan and Jeremy, it'd be great if you guys could let us know what the pros
and cons of each are.
Thanks,
david
--
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
1 a.m.
On Wed, Dec 23, 2009 at 1:08 AM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
What's more, for the first time ever, it's possible to extend
Java EE using
the CDI extension SPI. That means you can add/modify/remove beans,
interceptors, decorators, qualifiers, etc. at startup time, get information
about the runtime, and other sorts of tweaking. You could call it Tweak EE
(playing off of Tweak UI).
Pete explains this point better than I do. See this interview:
http://java.dzone.com/articles/coming-java-ee-extensions-jsr
It's really about exposing information, making Java EE is a good citizen to
the frameworks that are trying to plug into it.
-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
2:01 p.m.
But I don't want to partake in that comparison on this list, as I
mentioned before. Besides, it's the holiday and we don't want to create a
long thread to distract folks from their presents (and family).
Besides, there is already a nice long thread on this topic here:
http://www.theserverside.com/news/thread.tss?thread_id=58985 (Not that I
agree or sanction the comments, I'm just saying, if you enjoy the
entertainment of a TSS frame war, you've got one already).
-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
3:59 p.m.
On Dec 22, 2009, at 10:08 PM, Dan Allen wrote:
I'm going to disappoint you slightly because I don't think
this list
is the appropriate place to compare Spring 3.0 and CDI. I would like
to avoid an unbounded thread, which these things inevitably turn
into. My best advice for you is to simply evaluate the two reference
guides and post your conclusions.
Agreed. And thanks, Dan, I suspect you've just saved me a whole lot
of typing. We are both passionate about our chosen frameworks and I
don't really think either of us is in the position to give a truly
unbiased comparison. The fact is, they can both help you get your job
done, but they take fundamentally different angles of attack.
So if something isn't working out for you, it's certainly
possible
that an extension will be able to fill in the void. I'd go so far as
to say that a framework like Spring could leverage the extension SPI
heavily to integrate itself into Java EE if the developer was
looking for that type of bridge. (Experience will tell us if that is
true). There are certainly places in Spring today that it has to go
searching for information that now the CDI extension SPI could
provide for it for free.
That is a possibility (at least in theory...the devil is in the
details), and a path we would consider if we had sufficient demand
from the Spring community. To be perfectly honest, it would surprise
me at this point if we did get that level of demand, but I'm always
willing to be surprised.
That's my brief sketch of CDI. The advantage that Spring has is
that
it's incredibly well-known and, well, it's at version 3.0. It
wouldn't really be a balanced equation to compare Spring with CDI
anyway, since Spring is so much more than just a bean container.
Indeed, and it is my duty to continually remind people of that fact
since I mainly work on the "more". ;) One cannot overstate the
leverage we get in Spring's higher-level modules, including the main
framework modules as well as all of the surrounding projects like
Spring Security, Spring Web Flow + Faces, Spring Integration, Grails,
etc. by being able to depend on a very stable, well-documented, yet
always improving core that isn't constrained by the timelines of EE
spec releases. This allows us to bring a continuously expanding set
of functionality with an extremely consistent programming model to our
users across a rather diverse range of problem sets, and that's
obviously something that we've been very successful with. (For anyone
who may still be wondering why we've chosen not to change the core
behavior of Spring in the subtle, yet fundamentally different ways
that would be required to implement CDI, I hope this bigger picture
helps make our reasoning a little more clear.) CDI has the potential
to bring similar benefits on its own to the "native Java EE" crowd,
and for such folks who choose not to use Spring for whatever reason
(as is their right), I'm sure the advance is quite welcome.
Meanwhile, we're happy to continue giving Spring users what they've
come to expect, and let new users to the Java platform make the choice
that best suits their needs. And that's about the extent of
"comparison" you will get out of me for the moment... :)
Besides, it's the holiday and we don't want to create a long
thread
to distract folks from their presents (and family).
+10. Happy holidays, everyone!
Cheers,
Jeremy
9:24 a.m.
On 12/19/2009 08:25 AM, Dan Allen wrote:
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 am sorry to be so dense here, but how does
@javax.annotation.ManagedBean work with JSF 2.0? I just tried out
@javax.annotation.ManagedBean("user")
public class UserBean implements Serializable { ... }
The JSF EL does not pick this up, even in an EE6 container (GlassFish
v3). This isn't really surprising. The JSR316 spec mandates that the
name is turned into a JNDI name, but it specifies no interaction with an
EL.
I tried adding an empty beans.xml to check whether that would trigger a
lookup by the CDI implementation, but it didn't, and reading the JSR 299
spec, I don't think it should. Is there some other straightforward way
of making @javax.annotation.ManagedBean work with the JSF EL?
If not, it would seem to me that we need to use @javax.inject.Named if
we want to avoid @javax.faces.bean.ManagedBean.
Cheers,
Cay
--
Cay S. Horstmann | http://horstmann.com | mailto:cay@horstmann.com
1:38 p.m.
On Wed, Dec 23, 2009 at 10:24 AM, Cay Horstmann <cay(a)horstmann.com> wrote:
On 12/19/2009 08:25 AM, Dan Allen wrote:
> 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 am sorry to be so dense here, but how does @javax.annotation.ManagedBean
work with JSF 2.0? I just tried out
@javax.annotation.ManagedBean("user")
public class UserBean implements Serializable { ... }
The JSF EL does not pick this up, even in an EE6 container (GlassFish v3).
This isn't really surprising. The JSR316 spec mandates that the name is
turned into a JNDI name, but it specifies no interaction with an EL.
I tried adding an empty beans.xml to check whether that would trigger a
lookup by the CDI implementation, but it didn't, and reading the JSR 299
spec, I don't think it should. Is there some other straightforward way of
making @javax.annotation.ManagedBean work with the JSF EL?
If not, it would seem to me that we need to use @javax.inject.Named if we
want to avoid @javax.faces.bean.ManagedBean.
Shoot, I made the false assumption that the name in
@javax.annotation.ManagedBean was the EL name. On the one hand it makes some
sense that it is the JNDI name to make it consistent with how the container
treats EJBs. But on the other hand, what developers expect in all but a few
cases is that it would the EL name.
It's possible to put together an EL resolver the bridge the gap. Below is a
hacked together EL resolver that finds @javax.annotation.ManagedBean
references in the same module as the web app.
public class ManagedBeanELResolver extends ELResolver {
public Object getValue(ELContext context, Object base, Object property) {
if (property == null) {
return null;
}
String propertyAsString = property.toString();
if (base == null) {
try {
InitialContext ic = new InitialContext();
// we assume the managed bean is in the war
Object result = ic.lookup("java:module/" + propertyAsString);
context.setPropertyResolved(true);
return result;
} catch (NamingException ex) {
}
}
// delegate up the chain
return null;
}
public Class<?> getType(ELContext context, Object base, Object property)
{
return null;
}
public void setValue(ELContext context, Object base, Object property,
Object value) {
}
public boolean isReadOnly(ELContext context, Object base, Object
property) {
return false;
}
public Iterator<FeatureDescriptor> getFeatureDescriptors(ELContext
context, Object base) {
return null;
}
public Class<?> getCommonPropertyType(ELContext context, Object base) {
return null;
}
}
Register in faces-config.xml
<application>
<el-resolver>com.acme.ManagedBeanELResolver</el-resolver>
</application>
I guess the question is, does Spring intend on use the
@javax.annotation.ManagedBean name as an EL name? If that is the case, then
it's inconsistent between Spring and the platform. If Spring doesn't,
perhaps they would consider using @javax.inject.Named (the most logical
choice at this point) and we can align on that annotation.
So, as Cay points out, we are back to @javax.inject.Named as the
recommendation (unless you want to use that hacked up EL resolver).
-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
2:13 p.m.
Ahh, I see...I made the mistake of assuming that CDI was already exposing such beans via
EL. Indeed, having to resolve the bean from JNDI isn't too pleasant. Looking at the
spec, I see now that @Named is necessary to give a bean an EL name.
WRT @javax.annotation.ManagedBean, Spring just uses the value as the bean id, rather than
registering anything with JNDI, thus it becomes resolvable via EL as long as you register
the provided SpringBeanELResolver.
Agreed, then, since we do support the use of @Named at the class level in Spring, it makes
sense to settle on it for the sake of more consistent examples.
Cheers,
Jeremy
On Dec 23, 2009, at 11:38 AM, Dan Allen wrote:
On Wed, Dec 23, 2009 at 10:24 AM, Cay Horstmann
<cay@horstmann.com<mailto:cay@horstmann.com>> wrote:
On 12/19/2009 08:25 AM, Dan Allen wrote:
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 am sorry to be so dense here, but how does @javax.annotation.ManagedBean work with JSF
2.0? I just tried out
@javax.annotation.ManagedBean("user")
public class UserBean implements Serializable { ... }
The JSF EL does not pick this up, even in an EE6 container (GlassFish v3). This isn't
really surprising. The JSR316 spec mandates that the name is turned into a JNDI name, but
it specifies no interaction with an EL.
I tried adding an empty beans.xml to check whether that would trigger a lookup by the CDI
implementation, but it didn't, and reading the JSR 299 spec, I don't think it
should. Is there some other straightforward way of making @javax.annotation.ManagedBean
work with the JSF EL?
If not, it would seem to me that we need to use @javax.inject.Named if we want to avoid
@javax.faces.bean.ManagedBean.
Shoot, I made the false assumption that the name in @javax.annotation.ManagedBean was the
EL name. On the one hand it makes some sense that it is the JNDI name to make it
consistent with how the container treats EJBs. But on the other hand, what developers
expect in all but a few cases is that it would the EL name.
It's possible to put together an EL resolver the bridge the gap. Below is a hacked
together EL resolver that finds @javax.annotation.ManagedBean references in the same
module as the web app.
public class ManagedBeanELResolver extends ELResolver {
public Object getValue(ELContext context, Object base, Object property) {
if (property == null) {
return null;
}
String propertyAsString = property.toString();
if (base == null) {
try {
InitialContext ic = new InitialContext();
// we assume the managed bean is in the war
Object result = ic.lookup("java:module/" + propertyAsString);
context.setPropertyResolved(true);
return result;
} catch (NamingException ex) {
}
}
// delegate up the chain
return null;
}
public Class<?> getType(ELContext context, Object base, Object property) {
return null;
}
public void setValue(ELContext context, Object base, Object property, Object value) {
}
public boolean isReadOnly(ELContext context, Object base, Object property) {
return false;
}
public Iterator<FeatureDescriptor> getFeatureDescriptors(ELContext context,
Object base) {
return null;
}
public Class<?> getCommonPropertyType(ELContext context, Object base) {
return null;
}
}
Register in faces-config.xml
<application>
<el-resolver>com.acme.ManagedBeanELResolver</el-resolver>
</application>
I guess the question is, does Spring intend on use the @javax.annotation.ManagedBean name
as an EL name? If that is the case, then it's inconsistent between Spring and the
platform. If Spring doesn't, perhaps they would consider using @javax.inject.Named
(the most logical choice at this point) and we can align on that annotation.
So, as Cay points out, we are back to @javax.inject.Named as the recommendation (unless
you want to use that hacked up EL resolver).
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com<http://mojavelinux.com/>
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
2:20 p.m.
On Wed, Dec 23, 2009 at 3:13 PM, Jeremy Grelle <
Jeremy.Grelle(a)springsource.com> wrote:
Ahh, I see...I made the mistake of assuming that CDI was already
exposing
such beans via EL. Indeed, having to resolve the bean from JNDI isn't too
pleasant. Looking at the spec, I see now that @Named is necessary to give a
bean an EL name.
WRT @javax.annotation.ManagedBean, Spring just uses the value as the bean
id, rather than registering anything with JNDI,
Right, that makes sense, since both are what I would call the "native
internal id representation" of the bean.
thus it becomes resolvable via EL as long as you register the
provided
SpringBeanELResolver.
Got it. So in a sense this is like the ManagedBeanELResolver I proposed,
except that looking up in JNDI is not as straightforward as looking up a
Spring bean id.
Agreed, then, since we do support the use of @Named at the class level in
Spring, it makes sense to settle on it for the sake of more consistent
examples.
Excellent. There you have it, folks ;)
-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
2:27 p.m.
Dan Allen wrote:
Agreed, then, since we do support the use of @Named at the class
level in Spring, it makes sense to settle on it for the sake of
more consistent examples.
Excellent. There you have it, folks ;)
I don't have anything useful to add other than to say that I very much
appreciate seeing the way that you two (Dan and Jeremy) have worked
through this. It is certainly beneficial to the world of JSF to have
support from both the CDI and Spring camps. It is refreshing to see
amicable discussion like this, as opposed to the madness that flares up
on TSS, etc...
Andy
-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
9:56 a.m.
It seems so long ago that we had this discussion :-)
I thought you might find it interesting that the Java EE tutorial does
just what Dan asked for: They use @Named, not @ManagedBean, in their
published examples. Look at
http://java.sun.com/javaee/6/docs/tutorial/doc/gjcxv.html and search for
"managed bean".
Cheers,
Cay
On 12/17/2009 08:23 AM, Dan Allen wrote:
I'm going to venture out onto a limb here in hopes of leveraging
the
influence of your professional recommendations. I ask that you read
through this message with an open, forward-looking mind.
I feel strongly that, as a group, we should provide a consistent
recommendation regarding the programming model of JSF by getting behind
CDI.
..
Showing users how to use @ManagedBean on a class and inject other
managed beans with @ManagedProperty or an EJB with @EJB is showing
developers only a portion of the value of this platform's programming
model. We want to put our best foot forward. That's why we show
composite components in presentations and not how to create a components
in Java. We show Facelets, not JSP. We want to make it seem as easy as
it can be.
Rather than recommending:
@ManagedBean
@RequestScoped
public class BlogEditor {
@ManagedProperty("#{blogDao}") BlogDao blogDao;
// getters and setters required
}
We want to show them:
@Named
@RequestScoped
public class BlogEditor {
@Inject BlogDao blogDao;
}
--
Cay S. Horstmann | http://horstmann.com | mailto:cay@horstmann.com
5897
days inactive
5927
days old
jsr-314-open-mirror@lists.jboss.org
25 comments
9 participants
participants (9)
-
Andy Schwartz -
Cay Horstmann -
Dan Allen -
David Geary -
Ganesh -
Jeremy Grelle -
Kito Mann -
Lincoln Baxter, III -
Werner Punz