Adam Bien's Weblog
EJB 3.1 Killed The Backing Beans Or JSF 2, EJB 3.1, JSR-330 - The Perfect Synergy
A Stateless Session Bean with the JSR-330 @Named annotation:
@Stateless
@Named("helloService")
public class HelloService {
@EJB ClockService clockService;
public String getHello(){
return "Hello from EJB / CDI: " + clockService.currentTime();
}
}
can be directly referenced in the JSF 2:
<h:body>
<h:form>
<h:outputLabel value="#{helloService.hello}"/>
</h:form>
</h:body>
You don't need the Backing Bean anymore - but you can still use it.
The project (JSF2EJB3CDI) was implemented in few minutes with NetBeans 6.8, tested with Glassfish v3 and pushed into: http://kenai.com/projects/javaee-patterns/. The entire WAR (JSF 2.0 , EJB 3.1, CDI) is 8 kB small. The initial deployment took 1.516 ms seconds, and was twice as slow, as in the Java EE 6 observer example:
INFO: Initializing Mojarra 2.0.2 (FCS b10) for context '/JSF2EJB3CDI'
INFO: Loading application JSF2EJB3CDI at /JSF2EJB3CDI
INFO: JSF2EJB3CDI was successfully deployed in 1,516 milliseconds.
Posted at 09:00AM Dec 18, 2009 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[14]
[my tweets] 
Rss My book: Real World Java EE - Rethinking Best Practices
I did not get it - to me it still looks like a backing bean (because it is used by JSF) ... just without the faces-config.xml - but thats part of the JSF 2 spec.
Can you tell us what exactly the "problem" was? To me it sounds dimmish.
Gesendet von mcahornsirup am December 18, 2009 at 12:36 PM CET #
@mcahornsirup
in Java EE 5 there was no problem. Just an additional class - so called Backing Beans was required. In this bean the EJB 3 was injected. With Java EE 6 an EJB 3(1) can be used directly as backing bean.
This examples works with backing beans: http://www.adam-bien.com/roller/abien/entry/simplest_possible_jsf_2_ejb
hope it is clear now, how lightweight Java EE 6 actually is :-),
Gesendet von Adam Bien am December 18, 2009 at 12:51 PM CET #
But the killer is neither EJB 3.1 nor JSR330. CDI takes it all! :-)
Gesendet von Benjamin am December 18, 2009 at 04:30 PM CET #
@Benjamin,
a single EJB 3.1 in the front of CDI is the simplest possible thing. Otherwise you will still have to deal with transactions, monitoring, concurrency etc...
Convention Over Configuration rules!,
thanks!,
adam
Gesendet von Adam Bien am December 18, 2009 at 04:54 PM CET #
IIRC wasn't there a change to allow EJB injection into backing beans (even prior to JSF 2.0)?
I think CDI is the real backing bean killer, everytime you go to use a managed bean annotation, you should be using the CDI equivalent.
Technically, you could just add the named annotation to your stateless bean and skip a whole step.
Either way, it is all still very slick and easy to use. Unfortunately, Netbeans came out with great support for backing beans which are now completely unnecessary.
Gesendet von Andy Gibson am December 18, 2009 at 05:05 PM CET #
@Adam,
Correct me if I'm wrong, but this looks like a very simple example with limited use. Off the top of my head, this would work well for pages that primarily display information.
For anything that would require holding state or form input, one would need either a stateful session bean or a (managed | backing) bean with a stateless session bean for business logic.
Gesendet von John Leed am December 18, 2009 at 05:57 PM CET #
CDI (Weld) is a great thing indeed. Seam's fathers took their ideas to the next level.
Andy said: Unfortunately, Netbeans came out with great support for backing beans which are now completely unnecessary.
I agree, but I think it's an option for those who prefers to use @ManagedBean annotation.
I think the real problem is: there's no support for CDI at all, specially with autocomplete or code assist feature. I've created a bug entry for this here: https://netbeans.org/bugzilla/show_bug.cgi?id=178687 , but nobody replied so far. I hope they have a solution soon, 'cause I like netbeans and I like cdi/weld/seam even more.
Gesendet von Geraldo Luiz am December 18, 2009 at 08:27 PM CET #
@John,
it is the simplest possible example and you are absolutely right. Backing Beans are still needed for the implementation of presentation logic.
In some cases you can bind rich domain objects directly to the UI and use the stateless session bean as a gateway... Then a Backing Bean is not need - it would be degrade to a plain delegate...
thanks!,
adam
Gesendet von Adam Bien am December 18, 2009 at 10:46 PM CET #
In order to get this to work I had to create a beans.xml file under WEB-INF with the content:
<beans></beans>
(as in your example project). NetBeans 6.8 did not create this for me.
I may have missed some documentation somewhere -- it took me a little while to figure out how to make this work for my project.
Thanks for the tips, keep them coming!
Gesendet von Chris Rued am December 22, 2009 at 05:51 PM CET #
Hi Adam,
How would JSF 2 resolvers behave suppose there is a managed bean with the same bean name as that of the annotated stateless session beans?
JSF 1.2 supported chaining of EL resolvers. I would suggest that stateless session beans with @Name annotations should at least have a namespace to avoid duplicate bean names.
Jerwin
Gesendet von Jerwin Louise Vergara Uy am December 23, 2009 at 04:16 AM CET #
Does this create a new HelloService for each request (debugging it seems to indicate that) ?
Adding @javax.enterprise.context.ApplicationScoped
yields "org.jboss.weld.DefinitionException: Scope interface javax.enterprise.context.ApplicationScoped is not allowed on stateless enterprise beans for class de.diron.vaude.model.facade.LanguageFacade. Only @Dependent is allowed on stateless enterprise beans"
Gesendet von Sven Peters am December 23, 2009 at 02:19 PM CET #
@Sven,
either it creates a new @Stateless session bean each request (I would prefer that), or reuses one from the pool. I would prefer the creation of a new instance every request. This depends mainly on your application server...
thanks for your comment and debugging efforts!,
adam
Gesendet von Adam Bien am December 23, 2009 at 05:39 PM CET #
I recently came accross your blog and have been reading along. I thought I would leave my first
comment. I dont know what to say except that I have enjoyed reading. Nice blog. I will keep
visiting this blog very often.so you also can read my website,if you like
<a href="http://www.uggprovide.com/">ugg boots</a> or want to buy
<a href="http://www.purchaseuggboots.com/">ugg boots</a>,welcome to my website:
http://www.uggprovide.com/ or http://www.purchaseuggboots.com/
Gesendet von ugg boots am December 25, 2009 at 10:15 AM CET #
Cool example. However, one question (although maybe I should post this on a glassfish forum).
Following your example works great when the project is deployed as WAR to glassfish. However, when the WAR is included in an EAR file an exception is raised by javassist: Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: nl/chriswesdorp/calculator/ejb/ClientProcessor
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:169)
When I remove the beans.xml from the WEB-INF the deploy succeeds but dependency injection in the JSF fails.
Thanks (also for all the other useful information)
Chris
Gesendet von Chris Wesdorp am February 25, 2010 at 12:20 AM CET #