JSF, CDI and EJB containers : which combination of them should be used?

Question

I was reading this post and it makes me have some confusions: In that post it is mentionned which annotation to use with each specific container : JSF, CDI or EJB containers.

As a beginner, i learned the JSF framework and was used to its @ManagedBean annotation and its optional name parameter for referencing the bean from JSF pages and didn't know much about CDI and i was using EJB for its powerful features instead (and even after reading this post i still think that EJBs are more powerful and more featured than CDI).

So.. both JSF and CDI containers have their own annotations and ways for referencing beans on the web page but EJBs just have the @Stateless (or @Stateful) and therefore can't be referenced on web pages which means that the JSF container must always be annexed with EJBs (because i assume that mixing EJB and CDI containers is absurd as they are almost similar but for this point i wish someone to tell me if i'm wrong ).

The problem with JSF container is that it's

"still not complete and mature container"

as said on that post and the worst i knew about it was a warning message in Netbeans next to the @ManagedBean:

"Annotations from the package javax.faces.bean will be deprected in the next JSF version. CDI ones are recommanded instead."

(well, here there is another alternative package for that annotation : javax.annotation.ManagedBean but i don't know either if i can use it nor if it has a parameter for referencing the bean on the web page and which one it is)

So now i started to wonder about the future also about which combination of containers should i use. Is CDI + EJB the future ?

Cheers for all.

Answer 1

Java EE 7 is becoming more CDI aligned. So, EJB will be just a very special case of CDI + powerful services (asynchronus, message consumer, schedule tasks...). With this in mind, @ManagedBean becomes redundant because @Named lets you expose a bean to JSF pages.

As the technology matures you will end with the CDI container everywhere (even for stand alone apps).

Some points to keep in mind:

• The service layer is not only for @Stateless or @Stateful. Now, every class could be @Named and be injected (and use the services that this implies as interceptos, life cycle management, resource injection).
• Presentation is not only for @ManagedBean. Every @Named could be behind the web page with a related scope (session, view...)
• Not just the EJBs are transactional, now every @Named with @Transactional (Java EE 7) could write to the database.

The architecture gets simplified, the patterns are the same (MVC, Boundary-Control-Entity), just change the annotations and a little bit your implementation.

There is currently a mature project called Apache DeltaSpike with some relevant CDI extensions that are portable and in most cases will simplify your life (even if your are using Java EE 6!).

Note: Could be easier to use full CDI in Java EE 7 rather than Java EE 6, because 6 has not @Transactional, so you will need to create a transactional interceptor by your own.

DeltaSpike says:

Transactional support for non-EJB beans: The Transactional Interceptor in DeltaSpike paved the way for @Transactional in Java EE 7.

Answer 2

First of all, I want to make the distinction between EJB and JSF Managed Beans. EJBs are persistent objects and as a general rule, you cannot use them directly as JSF managed objects, since the JSF object management subsystem doesn't allow for the needs of databases. Most importantly, of swapping in and out instances of an object with different keys. All your database operations require application code because JSF cannot help you. It's not designed to do that.

For traditional management versus CDI: Unless Oracle does a "Microsoft" and abandons the traditional long-term support for deprecated items, it should be safer to use the old-style ManagedBean annotations. And, in fact, depending on what version of what Enterprise Java container you are targeting, CDI may not yet be functional.

If you are sure that you will always have CDI support, it's probably better to code to CDI, since it's the one designated for longer term support.