tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From suhaas <>
Subject Re: Help required with OpenEJB integration with JSF Hibernate and Spring
Date Wed, 22 Oct 2008 02:00:40 GMT

At this point in time,  I have drilled down the problem to Spring 2.0 and
OpenEJB 3.0 integration.

As mentioned in the original problem statement older application (without
OpenEJB) is using JSF -> backing bean -> service locator  flow to call a DAO
implementaion which is composed of HibernateTemplate (
org.springframework.orm.hibernate3.HibernateTemplate ).

I looked up Log "Bootstrapping OpenEJB in Spring"
I am at a loss to understand, how  OpenEjbFactoryBean class mentioned in
this log, will call the openejb stateless session bean in my new
scenario that is to be  be looked up using service locator (with suggested
code from

I am very sure I am obviously missing something here.

Referring to same log page above, Also what property is this? <prop
type=DataSource</prop> (mentioned in  "Bootstrapping OpenEJB in Spring")

Also I presume datasource entry in openejb.xml would be redundant, as in
would get mentioned in Spring Application Context file.

I am aware of one more way of using OpenEJb 3.0 or EJB3 with Spring
2.0, but I want to achieve this either without 1) adding another
layer like Spring bean and/or 2) breaking my existing code.

Thanks in advance

David Blevins wrote:
> On Oct 20, 2008, at 3:01 PM, suhaas wrote:
>> Here is the problem statement
>> We currently have an application that uses Spring 2.0, Hibernate 3.X,
>> JSF1.1/Myfaces/Richfaces 3.1.X on Tomcat 5.5.27
>> The current layers are :
>> The JSF UI calls backing bean that in turn calls service locator  
>> that calls
>> Hibernate DAO implementation. So in terms of Eclipse projects in my
>> workspace I have :
>> 1) Webapp (JSF/Richfaces part), backing bean and service locator
>> 2) Service  Layer
>> 3) Hibernate Implementation Layer
>> Now I have been asked to add an OpenEJB layer. So I understand the  
>> new flow
>> will be
>> The JSF UI calls backing bean that in turn calls service locator which
>> locates OpenEJB Stateless Session Bean that calls Hibernate DAO
>> implementation.
>> Here is what I have done so far
>> 1) Installed Tomcat plug in for OpenEJB.
>> 2) Added a Listener for openejb in server.xml file that is managed by
>> Eclipse
>> 3) Added datasource for Oracle in openejb.xml
>> (thought it is already there in  which  
>> gets
>> used by spring-app.xml in webapp, Hibernate Implementation and the  
>> new EJB
>> l;ayer created)
>> 4) Have written stateless session bean EJB implementation and tested  
>> it.
>> I have read the docuemtnation available on website, but I am still  
>> not clear
>> about the following
>> 1) Creating JNDI names
>> 2) What Service Locator should look like
> There are two types of JNDI names to be aware of:
>    - the java ee 5 spec standard ones available in the webapp under  
> "java:comp/env"
>    - the vendor specific "global jndi" names available from  
> org.apache.openejb.client.LocalInitialContextFactory
> All of the global jndi names are printed in the OpenEJB log.  This  
> document shows how to change them:
> These are available like so:
>    Properties properties = new Properties();
>    properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,  
> "org.apache.openejb.client.LocalInitialContextFactory");
>    InitialContext context = new InitialContext(properties);
>    FooLocal foo = (FooLocal) context.lookup("FooBeanLocal");
> For this scenario, the sky is the limit on your service locator, it  
> can really be anything you want. It all depends on how you set your  
> openejb.jndiname.format.  This doc describes a few approaches you  
> could use to writing a service locator: 
> We in fact do include a couple of "boiler plate" service locators in  
> the openejb-client jar that are really meant to serve as starter code  
> for writing your own:
> Take as much of that code as you like, that's what it's there for.   
> You'd probably want to update yours to use the  
> LocalInitialContextFactory as the RemoteInitialContextFactory is  
> intended to be used when the client itself is in another VM than your  
> ejbs.
> The Java EE 5 spec names are created using annotations in code or xml  
> in the deployment descriptor.  Unlike the LocalInitialContextFactory  
> jndi namespace, no Java EE 5 spec names are created unless you declare  
> them (again via annotations or xml).  There will be some neat  
> functionality in Java EE 6 around this, but in Java EE 5 you have to  
> explicitly ask for EJBs to be available in "java:comp/env"
> An easy way to get the EJBs into "java:comp/env" of the webapp is to  
> add a servlet with these annotations at the top of the servlet class:
>      @EJBs(
>              @EJB(name = "foo", beanInterface = FooLocal.class),
>              @EJB(name = "bar", beanInterface = BarLocal.class),
>              @EJB(name = "baz", beanInterface = BazLocal.class)
>      )
>      public class MyServlet ... {
>          ....
>      }
> That will make the names "java:comp/env/foo", "java:comp/env/bar", and  
> "java:comp/env/baz" available to everything the entire webapp via code  
> like the following:
>    InitialContext context = new InitialContext(); // note there are no  
> parameters to InitialContext
>    FooLocal foo = (FooLocal) context.lookup("java:comp/env/foo");
> When writing a service locator for this style of lookup, it's  
> completely up to you how the names look.  There's no "auto creation"  
> of names and no way to specify the format you want, you have to type  
> up each name individually as you want it.  Your service locator would  
> follow the design you chose for the names you add.
> Note that from a technical perspective both approaches are identical  
> under the covers and internally map to exactly the same object,  
> there's no speed or technical difference between them.  Choosing which  
> one all depends on if you want to do it the spec way or the openejb- 
> specific way.
>> (there seem to be gaps and compile
>> time problems with the example on the openejb site)
> If you have any specific compile issue to report, we're happy to look  
> at it.  There was a recent thread on the examples last week or the  
> week before and all the OpenEJB 3.0 examples were checked and double  
> checked for compile issues.  That doesn't mean there might not be  
> something specific to your machine that we could check for, so  
> definitely feel welcome to post the details.
> Hope this helps!
> -David

View this message in context:
Sent from the OpenEJB User mailing list archive at

View raw message