About Hildeberto Mendonca

Hildeberto is a PhD in Applied Sciences working as a Senior Java Architect in the education domain. He has a special interest on Java EE technologies and love to share his knowledge with the community.

EJB Lookup in a Vaadin Application

It has been a long time since the last Service Locator I have implemented. I thought it wouldn’t be necessary anymore considering the maturity of the Java EE CDI (Contexts and Dependency Injection). My first implementation was to make use of EJBs in a Struts-based web application.

After that, I started working with JSF, which only requires annotated attributes with @EJB or @Resource to communicate with the business layer. So far, it has been a great experience until they asked me to evaluate Vaadin as a front-end technology for business applications.

Before going too far, I have read the article “Adding JPA to the Address Book Demo“, published on Vaadin’s wiki, which explains how to call EJBs from Vaadin’s classes to retrieve and persist data from the business layer. EJBs use JPA to get and put data in the database. They suggested to call EJBs from a custom servlet, which, according to the Java EE specification, has the ability to make EJB calls using CDI.

If we have 1 or 3 EJBs to call, it seems to be an appropriate solution, but what to do in the Servlet when we have ~40 EJBs to deal with? How to pass all these references to Vaadin’s application class? The interface of this class can go nuts! That’s why I believe that the lookup using JNDI is desirable.

The following code is the Service Locator that I’m using in my Proof of Concept (PoC).

import java.util.Collections;
import java.util.HashMap;
import java.util.Map;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

public class MyServiceLocator {
   private Context initialContext;
   private Map cache;
   private static ClientServiceLocator 
           ourInstance = new ClientServiceLocator();

   public static ClientServiceLocator getInstance() {
      return ourInstance;
   }

   private ClientServiceLocator() {
      try {
         this.initialContext = new InitialContext();
         this.cache = Collections.synchronizedMap(new HashMap());
      }
      catch(NamingException ne) { 
         System.err.printf(
            "Error in CTX looking up %s because of %s while %s",
            ne.getRemainingName(),
            ne.getCause(),
            ne.getExplanation());
      }
   }

   public Object lookupEjb(String ejbName) {
      if(this.cache.containsKey(ejbName)) {
         return this.cache.get(ejbName);
      }
      else {
         try {
            Object ejbRef = 
               initialContext.lookup("java:comp/env/"+ ejbName);
            this.cache.put(ejbName, ejbRef);
            return ejbRef;
         } catch (NamingException ne) {
            throw new RuntimeException(ne);
         } catch (Exception e) {
            throw new RuntimeException(e);
         }
      }
   }
}

The class MyServiceLocator follows the Singleton design pattern, making sure that there is only one instance of the object to serve all requests from the web application. The unique instance is created at the class’ initialization process and since the constructor is private, the class cannot be instantiated by another class, being available only through the method getInstance(). The constructor initializes the context and creates a synchronized map where we store all references already created. The method lookupEjb(String ejbName) locates EJBs whose names are available in the local JNDI context. This method only works for those EJBs whose references are declared in the web.xml file, as listed below.

<web-app version="2.5"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns="http://java.sun.com/xml/ns/javaee" 
    xsi:schemalocation="http://java.sun.com/xml/ns/javaee 
        http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
   
   <display-name>Information Systems</display-name>
   ...
   <ejb-local-ref>
      <ejb-ref-name>InformationSystemBean</ejb-ref-name>
      <ejb-ref-type>Session</ejb-ref-type>
      <local>
         example.business.InformationSystemBeanLocal
      </local>
      <ejb-link>
         eac-architecture-ejb.jar#InformationSystemBean
      </ejb-link>
   </ejb-local-ref>
</web-app>

The tag <ejb-local-ref> is used to declare a reference to a local EJB. The example above maps only one EJB. So, you have to repeat it for each EJB you want to map. Details about this tag can be found here. Once declared, we can get an instance of the EJB in any part of the application using the following code:

private InformationSystemLocal informationSystemBsn = 
   (InformationSystemLocal)MyServiceLocator.getInstance()
                              .lookupEjb("InformationSystemBean");

The variable is typed with the EJB local interface, which is InformationSystemLocal. The service locator returns an instance of the EJB named as InformationSystemBean, which is by default the EJB’s implementation class. Notice that none of the code above is necessary when we use CDI. The invocation of AjudaBsn would be simply like that:

@EJB
private InformationSystemLocal informationSystemBsn;

CDI is good and elegant, but not widely applicable. The way it is implemented today is the main weakness of the Java EE specification. Maybe there is some strong reason why EJB’s annotations don’t work in every Java class. I simply don’t see this misterious reason because Spring has addressed this issue since long time ago simply using aspect orientation.

Reference: EJB Lookup in a Vaadin Application from our JCG partner Hildeberto Mendonca  at the Hildeberto’s Blog

Related Articles :

Related Whitepaper:

Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions

Get ready to program in a whole new way!

Functional Programming in Java will help you quickly get on top of the new, essential Java 8 language features and the functional style that will change and improve your code. This short, targeted book will help you make the paradigm shift from the old imperative way to a less error-prone, more elegant, and concise coding style that’s also a breeze to parallelize. You’ll explore the syntax and semantics of lambda expressions, method and constructor references, and functional interfaces. You’ll design and write applications better using the new standards in Java 8 and the JDK.

Get it Now!  

Leave a Reply


+ 3 = eleven



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books