EJB 3.1 Cookbook - where's CDI?

[Jan Groth]

Even though JEE 6 is final since almost two years, getting some literature about it is still not an easy task. Some volumes are out, but certainly the choice is not overwhelming. So, personally I was thrilled when I heard about the new "EJB 3.1 Cookbook", and quickly gathered some information :-)

The disappointment came when I had a closer look at the contents:

I cannot understand why (yet another) book about EJB 3.1 misses the complete story behind CDI ("Context and dependency injection"). I do understand that CDI (JSR 299) is not a part of EJB 3.1 (JSR 318), but in JEE 6 those two concepts are linked that tightly that it's certainly safe to say that one cannot take full benefit of EJB if one is unaware of scopes, lifecycles and the concept of typesafe dependency injection. How am I supposed to implement a professional EJB 3.1 application if I never heard about a SFSB living in the conversation scope (something the book does not even mention)? What about Managed Beans (JSR 316)?

While one might argue that those concepts do only extend EJB 3.1 (I don't follow that path), it's getting worse in the parts where CDI replaces EJB 3.1. Take chapter 8, dealing with interceptors, as an example. The (old) EJB 3.0 style of binding the interceptor implementation directly to the intercepted method is simply repeated. This ignores the new concept of loosely binding interceptor and intercepted method with @InterceptorBinding and qualifiers.

I really don't understand why the author left out all these details. Forgive me for sounding harsh, but in my opinion this book can hardly be used to learn about EJB 3.1, it only complements other literature / sources of information.

Cheers,
Jan

[Jayr Motta]

Totally +1, I agree with everything you said, I'm studying to the EJB exam and I've read the "Enterprise Java Beans" from Andrew Lee and Bill Burke, also read the "EJB3 in Action" from Debu, Reza and Derek and they're almost the same.

Despite the little new additions and modifications, there are no information about any of this that you've said (in fact, I would appreciate if you send me some links about it), neither on the specifications itself, that sounds more like improvements than the new "EE6 style".

Mr. Richard, how about some additions there to make your book the best and only on this that Jan quoted? I'll help to spread it if you add those and also buy a copy (even already having some goods about the theme).

[Jaikiran Pai]

I don't see anything wrong in a EJB3.1 book focussing on EJB. What you guys are probably looking for is a Java EE6 book which explains other technologies like CDI and doesn't focus on a single technology. Remember that EJB3.1 can be used and is being used effectively, even without CDI in picture.

[Jan Groth]

Jaikiran Pai wrote:Remember that EJB3.1 can be used and is being used effectively, even without CDI in picture.

*... can be used...effectively...*
I doubt the part with 'effectively'. I also could drive to next supermarket without releasing the handbrake.. But: While I certainly could do so, I'd miss something important than. Can we agree that EJB 3.1 and CDI is more effective than EJB 3.1 without CDI?

*...is being used...without CDI...*
Actually I dont see where that should be the case (unless you provide more information). CDI is part of the JEE 6 spec (98% of EJB 3.1 development will take place on that stack). Should one not work with an app server, its hard to imagine that he/she would go all the way to port EJB 3.1 to some other environment, but disregard CDI in that process.

Actually, most times when I hear people argument like that, they simply did not have the time to have a look at CDI yet. That's certainly okay, but IMHO working with a technology stack (here: JEE 6) implies to be familiar with its core concepts. And CDI is certainly one of them...

[Jan Groth]

Jayr Motta wrote:Totally +1, I agree with everything you said, I'm studying to the EJB exam and I've read the "Enterprise Java Beans" from Andrew Lee and Bill Burke, also read the "EJB3 in Action" from Debu, Reza and Derek and they're almost the same.

Despite the little new additions and modifications, there are no information about any of this that you've said (in fact, I would appreciate if you send me some links about it), neither on the specifications itself, that sounds more like improvements than the new "EE6 style".

Mr. Richard, how about some additions there to make your book the best and only on this that Jan quoted? I'll help to spread it if you add those and also buy a copy (even already having some goods about the theme).

As you say: "Enterprise Java Beans" from Andrew Lee and Bill Burke covers some ground about CDI, but not much. Bookwise, I haven't found anything better (just worse).

The best documentation about CDI that I am aware of can be found here at Weld.

[Jaikiran Pai]

Jan Groth wrote:

Jaikiran Pai wrote:Remember that EJB3.1 can be used and is being used effectively, even without CDI in picture.

*... can be used...effectively...*
I also could drive to next supermarket without releasing the handbrake.. But: While I certainly could do so, I'd miss something important than.

I don't see how that fits in! Are you saying that applications that don't use CDI and just rely on EJB3.1 are a disaster? Just because CDI is available doesn't mean that you have to use it. If there are requirements in your application that aren't fulfilled by just EJB3.1 then sure use CDI or anything that fits the bill. My whole point is, you are complaining that a book, which says that it focuses on technology X, isn't covering technology Y.

[Jan Groth]

My whole point is, you are complaining that a book, which says that it focuses on technology X, isn't covering technology Y.

... and I also say that X and Y are that closely related that is doesn't make sense to cover just one of them. Definitely no apples and oranges, it's rather like covering JSP, but not HTML (or Servlet, or CSS, ...)

Are you aware that both JCP/EGs, EJB and CDI, are discussing to extract common issues (esp. transactions and related topics) from both JSRs into a joined one?

[Jaikiran Pai]

.. and I also say that X and Y are that closely related that is doesn't make sense to cover just one of them.

I disagree that it doesn't make sense covering EJB3.1 without CDI. But anyway, that's my personal opinion.

Jan Groth wrote:
Are you aware that both JCP/EGs, EJB and CDI, are discussing to extract common issues (esp. transactions and related topics) from both JSRs into a joined one?

Yes, I am.

[Jan Groth]

Jaikiran, I must admit that I did not match you against that Jaikiran who is so amazingly helpful (and knowledgeable) at jboss.org. Instead I took it for granted that you might simply not be aware of JEE 6 and its various aspects. My bad - and my apologies.

I further have to admit that it surprises me that someone with your background makes his points towards "EJB 3.1 standalone" can be a better fit than "JEE fullstack". I'm more than willing to listen to your reasons to get to this point.

As I stated before: In my eyes any picture (aka: book) with just EJB in it misses serious parts and seems unfinished in my eyes. While I agree that it's technical possible to develop something working, I feel that serious and important aspects of EJB 3.1 can only be answered with CDI in mind. "Do I need an EJB or a Managed Bean?" "How does the lifecycle of a SFSB work?" "What's the best aproach to (de)couple my (EJB)-components?" - to name just a few typical questions a developer will have to answer. We have a saying in German: If the only tool you have is a hammer, than everything starts looking like a nail.

BTW: The book does not even mention CDI (as a matter of fact the acronym "CDI" is not used at all).

I think of CDI as the offspring of the decade-old EJB spec with all its historic payload. True, JSR-wise both are separate. But also true that one spec was developed with all the good and bad experiences of the other. More and more voices are heard that EJB might completely drop out of future JEE specs. So my point is: While it is possible to use CDI without EJB, it does not make sense to use EJB without CDI. At the very least it feels like driving with the handbrake put on...

[Piotr Nowicki]

Howdy guys!

Just take a deep breath and relax - it's friendly place, not a battle field :-)

I must admit that I love the CDI-EJB-CDI design but I think it's not a must requirement when you talk about EJB, so I don't feel bad that the book doesn't mention it - it focuses on one technology - just as it states in the cover. It doesn't misguide you telling that you'll learn CDI-EJB.
On the other hand I understand Jan's frustration. CDI is probably a nice addition to the EJB's and there aren't a lot of books about this topic. However, at this point I wouldn't agree with your opinion that:

Jan Groth wrote:While it is possible to use CDI without EJB, it does not make sense to use EJB without CDI.

In CDI you don't have timer services, transaction support, asynchronous calls and Web Services (at least as far as I remember). The EJB's act great as a facade. On the other hand, the CDI are lighweight and they fit perfectly as a business logic components.
Nevertless, you can achieve all the features given by the CDI with the EJB's.

It's just a manner of picking the tool that best suits you.

Jan, you can also take a look at Adam Bien's books which talks about all Java EE stack.

I'm more interested about this part:

Jan Groth wrote:More and more voices are heard that EJB might completely drop out of future JEE specs.

Could you give any source of these voices?

Cheers friends - we're all playing in the same team! :-)

[Jan Groth]

Sure, this is a discussion, not a battle. As a non-native speaker, my English might sound more harsh that I intend to, sorry for that. I thought starting my last post with an apology is a good way to indicate my peaceful intentions ;-)

Pedro Kowalski wrote:

Jan Groth wrote:More and more voices are heard that EJB might completely drop out of future JEE specs.

Could you give any source of these voices?

Well, let me rephrase this to: In future versions of JEE, EJB will loose more and more weight. They'll probably stay there for compatibility reasons - but I see the situation more or less as you (started to) describe:

CDI will provide the foundation for business components.

Typical cross-cutting concerns (like transactions) can be added - if required - using the CDI extension mechanism. Seam 3 (JBoss) and OpenWebBeans (Apache) already have modules for that. This opens the door for even more lightweight environments than Glassfish (3.1) and JBoss AS 7.

Other classical JEE concepts - like passivation - seem to loose importance (I'm phrasing this really careful, this is my personal opinion covered by some blog-posts I read here and there.)

Regarding the sources of my (rephrased) information: I had the chance to chat with Adam Bien about this, and I follow the mailing lists around CDI / Weld / Seam. It also matches the experience I have gained after 18 months JEE 6 development. But it's certainly not an official JCP strategy

[Jaikiran Pai]

Jan Groth wrote:Jaikiran, I must admit that I did not match you against that Jaikiran who is so amazingly helpful (and knowledgeable) at jboss.org. Instead I took it for granted that you might simply not be aware of JEE 6 and its various aspects. My bad - and my apologies.

No need to apologise, I wasn't offended, you were just stating your point

Jan Groth wrote:
I further have to admit that it surprises me that someone with your background makes his points towards "EJB 3.1 standalone" can be a better fit than "JEE fullstack". I'm more than willing to listen to your reasons to get to this point.

Actually that wasn't really my point. To clarify, Java EE full stack is really vast (like you already know) and there are many technologies ranging from the view layer to the backend which are covered by the stack. CDI definitely has been a boon to Java EE6 - no doubt about that. My real point was that it would be unfair to judge a book, which says that it's targeting EJBs, on the basis that it isn't explaining or even mentioning about CDI. I can see your point that as an application developer, you would expect a book to provide the whole picture and like I said in a previous reply, a Java EE6 book is exactly what would usually cover the entire range of technologies.

Jan Groth wrote:
As I stated before: In my eyes any picture (aka: book) with just EJB in it misses serious parts and seems unfinished in my eyes. While I agree that it's technical possible to develop something working, I feel that serious and important aspects of EJB 3.1 can only be answered with CDI in mind.
"Do I need an EJB or a Managed Bean?" "How does the lifecycle of a SFSB work?"

This is a point which I have a slightly different opinion about. You ask the right questions, like should one choose EJB or a managed bean, but that question doesn't really have to be answered with CDI in picture. Note that Managed Bean is not just a CDI concept (Java EE6 has a separate Managed Bean spec).

Jan Groth wrote:
So my point is: While it is possible to use CDI without EJB, it does not make sense to use EJB without CDI.

There may be cases where using CDI with EJB would make sense but I don't see why it doesn't make sense to use EJB without CDI. Just to illustrate something with a simple example:

@javax.ejb.Singleton
@javax.ejb.Startup
public class Cache {

  private Map<String, String> dataStore;

  @PersistenceContext
  private EntityManager entityManager;

  @PostConstruct
  public void onConstruct() 
  {
    // maybe load cache from some DB store using the entityManager
  }
  
  public void addToCache(String key, String value)
  {
    this.dataStore.put(key,value); 
   
  }
 
  @Lock (value = LockType.READ)
  public String getFromCache(String key) 
  {
    return this.dataStore.get(key);
  }
  
  public void persistCache()
  {
     this.entityManager.persist(....)
  }

}    

This is a simple example of a EJB3.1 @Singleton bean which gets instantiated during application deployment (due to @Startup), performs some data load from a DB in the @PostConstruct, using a entity manager injected through the @PersistenceContext. Furthermore, the @Singleton cache has a addToCache (with a default LockType.WRITE semantic) and a getFromCache with LockType.READ and finally a persistCache method, all of which have container managed transactional semantics enabled by default.

As you can see all of this is purely EJB3.1 features and you don't have any CDI management here. So you get a lot of services (like transactions, concurrency management, lifecycle management, injection) without even CDI in picture. To me this example makes perfect sense. i.e. I don't see why EJB3.1 can't be used without CDI.

Don't get me wrong, I'm not against CDI (Infact I really like it and IMO it's one of the really well defined specs). I'm all for using CDI wherever it's necessary but it doesn't really mean that other technologies don't make sense without CDI.

[Jan Groth]

Jakiran,

I get you point, and of course you are right that the provided code snippet certainly fulfills its function. Full stop here.

But wait... What about... Hmm... Can't it be that @javax.ejb.Singleton runs into serialization / deserialization problems in distributed environments? Wouldn't it be better to use CDI @ApplicationScoped to avoid ending up with two caches???

Your point stays valid and true.

You know, I really liked Bill Burke's book on EJB 3.0. That was great stuff, and despite the title it dealt with more frameworks than just EJB (e.g. JPA). I guess that's when - for me - talking about EJBs became synonym to talking about business logic in general. Because at the end of the day I need to implement my customer's requirements - no matter which framework I choose (the customer almost never cares). That's why I'm kind of expecting that a book about EJBs should enable the reader to be able to develop state of the art business logic.

In the case of the EJB 3.1 cookbook, I would at the very least expect that the author mentions the tightly coupled concept of CDI. And I'm disappointed that he didn't - but we can certainly end the discussion at this point...

[Manuel Loayza]

@Jan Groth.

I see you've done a bad critic for the book, only you have concetrated in one aspect of the EJB Tech, EJB is not only CDI. Well, we need to behavior as developers or system analyst we should think in holistic way for everything, but you didn't.

I think that you have something with the author of the book, I don't, but it seems.

Anyway, I think that your opinion should not consider to assess the book. Your opinion is very skewed.

I'm not an expert of EJB 3.1 and also I don't have written any book. And you? did you write some java book?

Thank you, hava a great day.

Manuel Loayza
SCEA

[Richard Reese]

Interesting discussion!

Jan has some good points. However, as in most endeavors, tradeoffs are made. When I started writing this book I considered including a chapter on CDI. However, for better or worst, it was dropped. The focus of a cookbook is typically how to perform certain tasks. They do not always address a topic at a deeper level. Books have page constraints which limit what one can put into them. I enjoy large books that go into great depth and comprehensively covers a topic. However, publishers typically do not. And of course by the time they are written new technology emerges.

As you stated, CDI is not a part of EJB 3.1. That is the primary reason it was left out. Personally I would love to see a book that covers CDI and EJB. There is the book, Dependency Injection by Dhanji R. Prasanna, but I understand it is focuses on JSR330 and Spring.

A couple of points. The recipe, Using lifecycle methods in interceptors, in the interceptor chapter does addresses certain life cycle methods but not as extensively as you would like. The recipe: Creating your own interceptor, in Chapter 12 addresses the use of the @InterceptorBinding annotation. Perhaps this should have been included in the chapter dealing with interceptors.

With regards to your comment about the usefulness of the book, every technical book I know of (with the exception of initial books such as Kernighan and Ritchie C Programming Language book) cannot help but complement other literature or sources of information. Books such as this one are based on technical specifications. The question is how well they present and cover the material.

I appreciate your comments. I suspect you would make an excellent technical reviewer.