Simplest Possible EJB 3.1

public class SimpleSample{
    public void doSomething() { /*business logic*/  }

How to compile:

You will need the the EJB 3.0 / 3.1 API in the classpath, or at least the @Stateless annotation.

How to deploy:

Just JAR the class and put the JAR into e.g: [glassfishv3-prelude-b23]\glassfish\domains\domain1\autodeploy

How to use:


import javax.ejb.EJB;
public class MyServlet extends HttpServlet{

private SimpleSample sample;


And: there is no XML, strange configuration, libraries, additional frameworks or jars needed... 

See also: EJB 3 series and EJB 3.1 From Legacy To Secret Weapon.

[See also "Real World Java EE Patterns - Rethinking Best Practices", page 36] 


Very impressive how simple EJBs are today. This changes the considerations when to use an EJB and when not. Previously I often got the recommendation to use EJB only, when absolutely required (scalability, transactions...) and use POJOs everywhere else.

However now the question seem not to be, when to use EJBs instead of POJOs, but rather, when not to use an EJB. What are your points here? When would you prefer a POJO over an EJB?

Posted by Carsten Schlipf on December 28, 2008 at 01:39 PM CET #


I'm writing a book now about this topic :-). I will try to answer your question with one of the next posts.

But: in the last projects I used exclusively EJBs instead of POJOs. Reason: less code, no plumbing, no xml, no hassle...

thank you for your comment!,


Posted by Adam Bien on December 28, 2008 at 02:30 PM CET #

Hi Adam,

Will your forthcoming book be available in English or is it planned in German only?


Posted by Rahul on December 28, 2008 at 03:36 PM CET #

Why are you posting EJB3 basics all the time. I think about cancelling your feed because of irrelevant posts like this.
Please impress me next time.

Happy New Year anyway.


Posted by Peter on December 28, 2008 at 04:39 PM CET #

I never inject EJB's into servlets. I want to inject them into POJOs. I've thought about where I would use EJB the most and I think there are two main areas:

1) DAO objects might be a good candiate for @Stateless annotation, however I've read that transactional boundaries should be managed by the service layer.

2) Service layer are also a good candiate for @Stateless, plus I need it to be an EJB so that I can inject DAOs.

I would typically need to inject a service object into a JSF Managed Bean, or whatever controller other web frameworks use. In JSF I think MBeans do support @EJB injection, but I doubt that works for any other web framework's controller.

When thinking about how this relates to Spring, it is not that different. You can't just inject class A into class B without making BOTH classes Spring beans in either XML config or using annotations. No pojo can benefit from injection without first becoming a Spring bean. I think it's the same with EJB right? WebBeans might change that a bit.

Posted by Ryan de Laplante on December 28, 2008 at 06:20 PM CET #


In English only :-),

thanks for your interests,



Posted by Adam Bien on December 28, 2008 at 06:58 PM CET #


don't take this blog too seriously. I will post from time to time more serious stuff - it depends on demand.

What topic are you interested in?



Posted by Adam Bien on December 28, 2008 at 07:00 PM CET #

Hi Adam...

i d like to accept your offer on interested topics, even if u didn't offer it to me...
I am interested in BPEL and Netbeans...especially if there's a possibility to monitor your business processes...
Greetings from my second hometown in Sweden...

Btw. If you need a picture for your new book...i can take another picture in Gothenburg...i remember u liked this city...


Posted by Daniel on December 28, 2008 at 07:15 PM CET #

Thanks for your reply.
I just thougth there were so many more new features in EJB3.1 like better TimerService, Singleton, enhacements in JPA-QL etc.

If you as me, what I was interested in, the it is your thougts about webbeans and how they could simplify or enhance j2ee development.


Posted by Peter on December 29, 2008 at 08:11 PM CET #


You can implement a Service Locator hack by injecting session beans on a servlet, cache the instances to a singleton class that wraps a synchronized map if the web controller framework does not support DI.


May I request a particular topic in line Peter's post?

I think the most dreadful thing about ORM frameworks is the first and second level cache that are left for the vendor to implement. This is also related to data inconsistencies.


Posted by Jerwin Louise Vergara Uy on January 03, 2009 at 09:46 AM CET #


Your suggestion works, but is not needed. Injection of Session Beans into Servlets works just fine with every Java EE 5 certified server. You have to be just careful with Stateful Session Beans...

thanks you!,


Posted by Adam Bien on January 03, 2009 at 10:38 AM CET #

Hi Adam,

Sorry for the misconception.

Ryan was talking about moving the business interface into a POJO. Given a web framework that does not recognize @EJB annotations (JSF 1.2 did not support DI, later versions did), I was thinking of letting the EJB Container inject the instances of the business interfaces declared as instance variables in a servlet, then caching these instances for the perusal of normal POJO classes inside a particular web framework. It would be just ugly having a servlet bloated with instance variables. :)


Posted by Jerwin Louise Vergara Uy on January 03, 2009 at 07:13 PM CET #

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