2 comments

Glassfish is one app server where by accessing Local Stateless Session Bean is a somewhat “confusing” as compared to other App Servers. This post will show you 3 quick, easy, straight forward, no fussed and no debates different ways that you could access your Local Session Beans to get the job done. Yes, only Local Session Beans, NOT Remote Session Beans.

Way No. 1: Accessing Local Stateless Session Bean in another Session Bean

Let say we have 2 session bean, SessionFacade1 and SessionFacade2 as well as their respective interfaces shows in the codes below:

Codes for ISessionFacade1Local:

Codes for SessionFacade1:

Codes for ISessionFacade2Local:

Codes for SessionFacade2:

In SessionFacade1, it has a very simple method generateRandomNumberStr() which generates a random number using the java.lang.Math library. As for SessionFacade2, the generateLuckyNumberStr() method will require the business logic from SessionFacade1, perform some manipulation to the number and return it.

Assuming that both EJB and all interface classes is in the same jar file. You can always access the bean itself through tagging the @EJB annotation on the interface declaration.

@EJB
private ISessionFacade1Local sf1Local;

It is that simple, there is no need to declare attributes like beanName or beanInterface in the @EJB annotation. Just plain @EJB will do.

Way No. 2: Accessing Local Stateless Session Bean in Servlet

Just like Way No. 1, @EJB annotation is usable even for a Servlet that is packaged in a different war file. I have a servlet class below which calls the generateLuckyNumberStr() from SessionFacade2 and prints the number as HTML.

Codes for LuckyNumberServlet:

Just as the example in Way No. 1, the servlet could automatically inject the sf1Local variable declaration through injection with the @EJB annotation. This is perfectly legitimate.

Way No. 3: Access Local Stateless Session Bean in JSP and Other Classes or Business Components

This is a tricky one and somewhat confusing to many developers. Unfortunately till now, there are limitations from Glassfish App Server to allow direct @EJB injection of Local Stateless Session Bean. Instead, the way to access it is through inserting snippets of <ejb-local-ref> in the web.xml and through a JNDI call.

By using the same Stateless Session Beans from the above examples: SessionFacade1 and SessionFacade2, first, we have to insert the <ejb-local-ref> tag into the web.xml file like the below:

<ejb-local-ref>
    <ejb-ref-name>SessionFacade2RefName</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <local>com.developerscrappad.demo.intf.ISessionFacade2Local</local>
    <ejb-link>LocalEJBDemo-ejb.jar#SessionFacade2</ejb-link>
</ejb-local-ref>

I’ll just give a reference name as SessionFacade2RefName and do take note that since my EJB is packaged in another jar “LocalEJBDemo-ejb.jar”, the <ejb-link> value should be the EJB name in the jar file that it is being packaged. However, <ejb-link> is optional and you can do without it.

Once after having the <ejb-local-ref> tag in the web.xml file, you can call the EJB through JNDI at the below:

String prefix = "java:comp/env/";
String ejbRefName = "SessionFacade2RefName";

String jndiUrl = prefix + ejbRefName;    //The JNDI URL should be "java:comp/env/SessionFacade2RefName"
javax.naming.Context ctx = new javax.naming.InitialContext();
ISessionFacade2Local sf2 = ( ISessionFacade2Local ) ctx.lookup( jndiUrl );

String result = sf2.generateLuckyNumberStr();

So far, we can only access Local Stateless Session Bean in JSP, class or a business component through JNDI call and make sure that <ejb-local-ref> tag is declared in the web.xml file.

Summary

This sums up the simple 3 ways that we could access Local Session Beans from either through another EJB, a JSP or a Servlet. There are reasons why Glassfish or the JSR specs would not allow the @EJB way in JSPs but I’m not going to write them here as it is not the objective of this article.

** Do take note that if you are calling a local Stateful Session Bean, it is most advisable to always access it through the JNDI call, instead of the @EJB injection, as the JNDI call will always ensure that the beans returned is of the most recent state.

Hope it helps.

Max Lam
About the Author

Born and currently resides in Malaysia, a seasoned Java developer whom had held positions as Senior Developer, Consultant and Technical Architect in various enterprise software development companies.

Related Posts

This is a quick guide on how to install a trusted SSL certificate chain, specifically Comodo on...

This is the last part in the series of “Making sense of EJB3.x Transaction Attributes“. So far,...

Oracle had extensively documented the behavior of each transaction attributes in the Java EE...