Adam Bien's Weblog

CDI With Or Without EJB 3.1

Java EE 6 comes with EJB 3.1 and CDI. You could work exclusively with EJB 3.1 or CDI, but you will not end up with the simplest possible solution. CDI comes with typesafe and scalable (=start easy, but sky is the limit) DI, events, decorators and "glue" logic.

CDI, however, is missing some EJB 3.1 features:

  1. Timers
  2. Asynchronous, transactional execution with Future support
  3. Pooling: important for throttling and prevention of denial of service attacks
  4. Monitoring - all EJBs are exposed via JMX and can be so monitored with JConsole
  5. Declarative, "Convention Over Configuration" transactions. Without EJB 3 you will end up in a considerable bloat

EJB 3.1 and CDI are both part of Java EE 6. The "KISSiest" thing you can do is to deploy a EJB 3.1 boundary and use e.g. CDI behinds behind.

You could also implement all aspects (transactions, jmx, throttling) by your own - but this would introduce additional complexity to your project (and: don't re-invent the wheel).


NEW workshop: Microservices with Java EE 7 and Java 8, January 26th, 2015, Airport Munich

A book about rethinking Java EE Patterns

Comments:

Hello Adam,

With CDI and its integration of the JavaEE Interceptors (via the JavEE6 InterceptorBinding) something like @Transactional, known from the Spring Framework can be created in an esay manner.

A full-blown version of such a Transaction-Interceptor will be part of the MyFAces CDI extension project, called "CODI".

In the meantime, a very simple version of such an artifact is located here:

http://github.com/matzew/hbase-jpa-jsf/blob/master/src/main/java/net/wessendorf/cdi/transactional/TransactionalInterceptor.java

(taken from the Apache OpenWebBeans project's reservation example)

Posted by Matthias Wessendorf on September 14, 2010 at 03:00 PM CEST #

@Matthias,

yes - but why to implement or integrate a custom interceptor, if the transactional aspect is already a part of EJB and both are a part of Java EE 6 / even WebProfile?

Its cool stuff - but why you are doing that?

Btw. (I did it also several time in my leisure, but never for "real world") :-)

thanks!,

adam

Posted by adam-bien.com on September 14, 2010 at 04:11 PM CEST #

That way I do not need to ship EJBlite with Tomcat/Jetty.

Posted by Matthias Wessendorf on September 14, 2010 at 04:38 PM CEST #

@Matthias,

if you just have a CDI container and nothing else - a custom "Transactional" aspect is not only cool, but also useful :-),

thanks!,

adam

Posted by adam-bien.com on September 14, 2010 at 05:57 PM CEST #

The problem with CDI + EJB is the lifecycle mismatch as explained in this post: http://www.germanescobar.net/2010/03/whats-so-wrong-with-ejbs.html.

That's why people are trying to stay away of EJB's. They make the learning curve steeper. I'd go with CDI + POJO's + Interceptors instead.

Posted by German Escobar on September 14, 2010 at 06:20 PM CEST #

Hello Adam, i want to know it will be a second edition of your book
in Real World Java EE Patterns - Rethinking Best Practice where explain the JEE 6 Best Practices ?.

Posted by Eudris Cabrera on September 14, 2010 at 06:42 PM CEST #

@Eudris,

stay tuned :-)

adam

Posted by adam-bien.com on September 14, 2010 at 07:04 PM CEST #

@German,

You can inject a @Stateless into @RequestScope @SessionScoped or @Singleton without any problem. You can even declare a @Stateful beans as @SessionScoped And you can inject CDI beans into EJBs. The integration between EJBs and managed beans is clearly defined.
I didn't had any problems so far in real world (also not in stress tests, synchronization problems etc.).

What problems do you encountered more specifically?

adam

Posted by adam-bien.com on September 14, 2010 at 07:10 PM CEST #

Adam,

I've seen people, for example, declaring @Stateless within a @SessionScoped bean, which is, a lifecycle mismatch. I know this is trivial for JEE experts but this is a problem for newbies, believe me. And it is something that can be avoided. Why do they have to learn two lifecycles and their valid combinations?

What we really want are the features of EJB's without introducing a new lifecycles (let others manage it, in this case, CDI). So, we want to say that a POJO is @Synchronized, @Transactional, etc., which is much more cleaner/clear. What do you think?

German.

Posted by German Escobar on September 15, 2010 at 04:47 AM CEST #

@German,

and I've seen people declaring @Stateless @Singleton or even better: @ConcurrencyManagement(Bean) @Stateful. You just cannot prevent this. If you have problems to understand that a Stateless Bean is not stateful :-), you will also have a hard time to understand qualifiers, stereotypes and especially implement transactional aspects (you have to implement them without EJBs)

What I do in projects: just provide a small working example as a blueprint with short documentation in the wiki. It works really well.

In the future CDI should come with aspects currently available with EJB 3.1. The EJB 3.1 spec could be replaced with few stereotypes then and the EJB "component model" entirely removed.

But now: the easiest possible solution is using an EJB 3.1 as a boundary and inject CDI beans into it. You could also use entirely EJB 3.1 if you prefer (=don't need the sophisticated DI, events and stereotypes).

Agreed?

thanks for your comment - really appreciate it!,

adam

Posted by adam-bien.com on September 15, 2010 at 05:28 PM CEST #

Definitely. That's the easiest way right now ;-)

> In the future CDI should come with aspects currently available with EJB 3.1. The EJB 3.1 spec could be replaced with few stereotypes then and the EJB "component model" entirely removed.

Agree. Maybe not included in the CDI spec but a separate spec would be better; just to leave CDI as simple as it is right now.

Posted by German Escobar on September 15, 2010 at 09:42 PM CEST #

@German,

its a pity - now we have full agreement and the discussion probably ends here :-).

Thanks for your interesting input!,

adam

Posted by adam-bien.com on September 15, 2010 at 10:24 PM CEST #

Pity it doesn't work worth a damn in Glassfish 3.1b19 and later. See, for example, https://glassfish.dev.java.net/issues/show_bug.cgi?id=11888, which is just sitting there, unmaintained, in violation of the Java EE specification. One of many reasons I made sure to rip all vestiges of CDI out of my Java EE application. Can't wait till it works properly, but I'm not holding my breath.

Posted by Laird Nelson on September 17, 2010 at 10:20 AM CEST #

@Laird,

didn't tested 3.1b19 yet. I'm working with 3.0.1 - it works really good. I will actually show EJB 3.1 - CDI integration on stage: http://www.adam-bien.com/roller/abien/entry/my_javaone_sessions_and_interactive

Will ping the glassfish guys at JavaOne :-),

thanks!,

adam

Posted by adam-bien.com on September 17, 2010 at 12:36 PM CEST #

Hi Adam,

I don't often do this but can you tell me why when you inject @Stateful SB's into @RequestScoped beans that a new instance of the Stateful SB is created every request ? This never happens with Stateless or Singleton's and I cannot find an answer anywhere and it appears very confusing when you are trying to pickup the new spec.

Posted by Chris on October 21, 2010 at 05:06 AM CEST #

Probably because your stateful bean is considered as @Dependent bean.

Posted by Den on April 24, 2012 at 03:20 PM CEST #

Hi Adam,
I am new to CDI and EJB 3.1.
Can you please post an article regarding Integration between "CDI & EJB" and how this example could be run in Application Client Container(ACC),weld-se Contailner and in java EE-6 container ?

Posted by Dhruba on May 29, 2012 at 02:55 AM CEST #

Salut Adam,

CDI seems to be a glue between JSF and EJB. We shall
look at CDI in its entirety, i.e. like this:

https://community.jboss.org/thread/220370

Especially the uploaded EJB+CDI test application.
The absence of blog-entries or articles around
EJB and CDI shows, that there is something
overseen!

Posted by GroovieMan on January 29, 2013 at 08:12 PM CET #

@GroovieMan,

"CDI seems to be a glue between JSF and EJB"

++1

I'm absolutely with you!,

adam

Posted by 192.168.0.100 on January 30, 2013 at 05:51 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
realworldpatterns.com
...the last 150 posts
...the last 10 comments
License