Hot questions for Using Enterprise JavaBeans in pojo

Question:

I can inject my own POJO into a managed object like this:

import javax.ejb.Stateless;
import javax.inject.Inject;
@Stateless
public class SomeEjb {
    @Inject
    private SomePojo somePojo;
}

And I have this POJO:

// No annotations
public class SomePojo {   
}

This works fine. If I inject the EJB into a JSF backing-bean, I can see that the value of somePojo is non-null value, as expected.

However, if I try to inject a java.util.Date into SomeEjb, I get the following exception on deployment:

Severe: Exception while loading the app : WELD-001408 Unsatisfied dependencies for type [Date] with qualifiers [@Default] at injection point [[field] @Inject private SomeEjb.date]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Date] with qualifiers [@Default] at injection point [[field] @Inject private SomeEjb.date]
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:311)

SomeEjb now:

// No annotations
public class SomeEjb {
    @Inject
    private Date date;    
}

Date has a public, no-argument constructor, and I thought that's all CDI would need to "satisfy the dependency". I'm sure this behaviour is "to spec", but clearly there's a big hole in my understanding of CDI.

Can someone explain why this doesn't work? What's the difference between SomePojo and java.util.Date from a CDI perspective?

Context:

  • Java EE 6
  • GlassFish 3.1.2.2
  • I don't have a use-case for this. I know that I can just specify new Date().

Answer:

I can reproduce this with EAP 6.3 as well.

The problem most likely occurs because of using Java EE 6. The java.util.Date is located in rt.jar and this JAR does not contain a beans.xml file which would enable CDI. You can only inject objects from JARs containing a beans.xml.

A common workaround is to use a producer method to inject such an object. You have to wirte this producer yourself but you will be able to inject objects from arbitrary classes regardless to which JAR they belong.

As far as I know the behaviour changed in Java EE 7, where the beans.xml is optional in some cases: https://blogs.oracle.com/theaquarium/entry/default_cdi_enablement_in_java

Hope that helps.

Question:

I am currently learning JAVA EE. I use an oracle Java EE 7 tutorial for that. According to this tutorial, section 34.1.4, they used some non-EJB helper classes for the tutorial example. http://docs.oracle.com/javaee/7/tutorial/doc/ejb-basicexamples001.htm

I'm wondering in what cases I should make a class EJB, and in what cases I should use a usual helper class. I have read what the benefits of using EJB are. But are there cases when it's better to use POJOs?


Answer:

The short answer is "always unless you need specific EJB facilities".

The longer answer is the following. Years ago when EJB prior 3.0 were used the EJB was something "heavy". You had to implement interface, inherit your bean from base class etc. Shortly EJB could be used in container only. This means that writing unit tests for EJB was very difficult.

So, people used the following strategy. They implemented everything they can in POJOs wrapped when needed by EJBs. The solution was verbose (because some stuff was duplicated) but very modular and better testable.

Since EJB 3.0 were introduced there is (almost) no difference between POJO or EJB. Actually EJB is a POJO with some annotations. This means that you do not have to create POJO and then wrap it with thin EJB layer. You can just implement everything in your class (call it POJO if you want) and then turn it into EJB using annotations. Still as delegation is good, so as more code is EJB-annotations-less as better.

Question:

I am learning Spring using this tutorial. I am unable to get my head around the following excerpt from it:

Spring enables developers to develop enterprise-class applications using POJOs. The benefit of using only POJOs is that you do not need an EJB container product such as an application server but you have the option of using only a robust servlet container such as Tomcat or some commercial product.


Answer:

In the good old days when application servers only supported EJB 2 it was a nightmare to develop services using EJBs. Each service (e.g. a stateless session bean) required a bunch of interfaces and strange additional methods to work properly (home interface, remote interface, deployment descriptors etc).

In order to run EJBs you need an application server such as Jboss or Glassfish. In order to run servlets you simply need a servlet container such as Tomcat or Jetty which is way more lightweight than an application server.

Spring offers a way of creating simple services as plain POJOs (that can be exposed via servlets). Therefore, to be able to develop services as a POJO was simply a dream come true. Services did not need all the constraining dependencies to the EJB-interfaces and they could be deployed in a lightweight servlet container.

Then came EJB3 which greatly improved life for the Java EE developer. EJBs no longer needed the dependencies for home- and remote-interfaces (at least not via inheritence). A modern EJB 3 service is very similar to a POJO-based service. The main difference is that EJBs still require an application server to be deployed.

Spring Guru Rod Johnson released the book J2EE Development without EJBs which greatly explains how to replace your old J2EE components (such as EJBs) with more lightweight Spring Pojos - good reading!

Question:

I'm developing an EJB based application, in which I have the JpaUtility utility class. To implement it, I have two choices:

  • Create a simple object JpaUtility, in which I put the getAll method static, to enable access from the class name (JpaUtility.getAll)

/* Simple Object utility */

public class JpaUtility
{
public static List<T> getAll(EntityManager manager, Class<T> clazz) {
        return manager.createQuery("...."); }
}
  • Create an EJB-Session that contains the getAll method, then inject and use when needed.

/* EJB utility */

@Stateless
public class JpaUtility
{
@PersistentContext
private EntityManager manager;
public static List<T> findAll(Class<T> clazz) {
        return manager.createQuery("...."); }
}

The question is: which one offers the best performance? Simple Object or EJB-Stateless? In other way, what does EJB offer compared to a simple object ?


Answer:

What you're trying to accomplish looks like 'Generic Pattern DAO', there're many "ready" implementations out there.One from AdamBien: "Generic CRUD Service" More elaborate, eliminating the need for custom solution and approaching the simplicity of Spring templates from Apache DeltaSpike: DeltaSpike Data module

Now back to you original question, EJB or POJO, in your case, when working in an EE container the use of Entity manager, must be "container managed", so your "correct" options are EJB or CDI but not plain unmanaged POJO.