1

I have a few questions on the various options and best practices when using JSF with EJB3.1. The mental model I have, given the daunting amount of choices and combinations available, is far from clear so some questions may not make sense.

JSF/Facelets reference backing beans (I am using the term "backing bean" for beans whose properties are written or read from Facelets pages) through EL code that is agnostic as to the actual annotations used in the bean classes (javax.faces.bean.* or javax.enterprise.context.*).

Is it correct to say that one can toggle between JSF and CDI scope annotations just by changing the imports in the bean classes without any changes to the Facelets xhtml code?

Is it an established pattern that JSF/Facelets should be used only for the xhtml markup code with all scope and lifecycle (plus injection) annotations done using CDI?

In a JBoss AS setting, where is the lifecycle management of the JSF backing beans (using either JSF or CDI annotations) taking place? In the web container or in the EJB3 container?

In a typical web application given that the SessionScoped beans can be provided by CDI, is there any need for using EJB3 beans other than those of type @Entity, e.g. for the last typical step in each "flow" when information is to be persisted in the database?

Marcus Junius Brutus
  • 26,087
  • 41
  • 189
  • 331

1 Answers1

3

Is it correct to say that one can toggle between JSF and CDI scope annotations just by changing the imports in the bean classes without any changes to the Facelets xhtml code?

Yes.

Is it an established pattern that JSF/Facelets should be used only for the xhtml markup code with all scope and lifecycle (plus injection) annotations done using CDI?

JSF is moving towards CDI. The new @FlowScoped annotation of the upcoming JSF 2.2 is evidence of this as this extends from the CDI API. The only disadvantage is that CDI doesn't offer a standard annotation for the tremendously useful JSF @ViewScoped annotation. You'd need @ConversationScoped wherein you manually start and end the conversation, or take a look at a CDI extension like MyFaces CODI.

In a JBoss AS setting, where is the lifecycle management of the JSF backing beans (using either JSF or CDI annotations) taking place? In the web container or in the EJB3 container?

The web container (in flavor of a WAR). JSF is built on top of the Servlet API, so it's definitely the web container.

In a typical web application given that the SessionScoped beans can be provided by CDI, is there any need for using EJB3 beans other than those of type @Entity, e.g. for the last typical step in each "flow" when information is to be persisted in the database?

The @Entity is part of JPA, not of EJB. The @Entity is to be used on a model class which is mapped to a database table and usually solely meant to transfer data across the layers. What you're last describing sounds like candidate for a @Stateful EJB. To understand @Stateless vs @Stateful EJBs better, head to this detailed answer: JSF request scoped bean keeps recreating new Stateful session beans on every request?

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Sorry, was beleaguered by the dreaded “Stack Overflow requires external JavaScript from another domain” problem and couldn't promptly accept your answer. – Marcus Junius Brutus Jun 26 '12 at 19:12
  • Your answer is very clear. What I realize is a bit hairy is the relationship between the life-cycle of the EJBs and that of the backing beans. It seems to me that, in principle, EJB beans are a totally different beast and don't have any direct connection to the JSF pages and their backing beans. Yet there seems to be some kind of tenuous dependency and some valid and invalid combos in the life cycles of the respective beans. The article you shared sheds some light but I guess there's no substitute for hands-on experience. – Marcus Junius Brutus Jun 26 '12 at 19:18
  • EJBs should be used as business services. They should not care about any JSF artifacts at all and only deal with model objects (the `@Entity` instances). JSF backing bean (a controller) should in turn have a model object (a `@Entity`) as a property which is been used by the view and also an EJB as a service (injected by `@EJB`). The JSF backing bean should have action methods which will execute the EJB's methods. Those action methods are then bound to command links/buttons/ajaxlisteners in the view. – BalusC Jun 26 '12 at 19:30
  • You may find the kickoff example at the bottom of this answer helpful: http://stackoverflow.com/questions/8626291/jsf-managed-bean-ejb-injection/8627413#8627413 Note that EJBs are supposed to be designed that way that they can be used independently from their own client. E.g. by a JSF webapp, or by a oldschool JSP/Servlet webapp, or by a JAX-RS webservice, etc..etc.. – BalusC Jun 26 '12 at 19:32