Why all the conspiracy against EJBs?

Question

Hi,
I see a lot of people (within our organization) claiming EJBs are heavy weight, while Spring is lightweight. And they hate EJBs as if it was the worst sin committed in enterprise Java. I have pretty much been a Spring and Hibernate developer for the past 1.5 years.
But on various blogs I saw positive views of EJB 3.0. So I tried building simple crud stuff using it. I found it surprisingly simpler to develop in than Spring. So, what exactly is the overhead caused by EJB 3.0 which Spring+Hibernate do not suffer from?
To put it more precisely, how do the following two cases differ to make EJB heavier than Spring?
EJB 3.0
1. Stateless EJBs managed by Java EE container.
2. EntityManager injected by container (Glassfish creates another instance of the bean with new EM instance to handle concurrent requests to same bean).
3. Container managed transactions.
4. Accessed using Local interface.
5. Injected using EJB 3.0 annotations.
Spring
1. Singleton beans managed by Spring.
2. A thread-safe proxy of EntityManager injected by Spring.
3. Spring managed transactions.
4. Accessed using Local interface.
5. Injected using Spring XML.

Answer 1

Completely agree (though I'm admittedly biased). Much of the negative perception comes from pre - EJB 3.0. Also want to point out that we're building on the success of EJB 3.0 to further simplify the programming model and add a number of long-requested features in EJB 3.1 (http://jcp.org/en/jsr/detail?id=318) To name a few :
-- Optional Local interfaces so a session bean can be developed using only a bean class
-- Packaging and deployment directly in a .war without the need of a separate ejb-jar
-- Singleton session beans
-- Application Startup/Shutdown callbacks
-- Asynchronous session bean invocations
-- Automatic timer creation and calendar-based timers
and more...
See my blog for more details. http://blogs.sun.com/kensaks/
--ken