OpenEJB at SourceForge     OpenEJB at Exolab     
 

Main
   Welcome!
   Download
   Mailing Lists
   The Team
Users
   Quickstart
   Support
   Request Feature
Servers
   Local Server
   Remote Server
Adapters
   Tomcat
Integrators
   Why OpenEJB
   Overview
   Design
   Specification
   Presentation
Developers
   Release Plan
   Source Code
   SourceForge
  



Accessing EJBs Locally
OpenEJB embedded in your app, server, or IDE


Accessing EJBs locally
Passing initialization parameters
The conf directory gotcha
Embedded OpenEJB FAQ
Why do I need so many OpenEJB specific files to implement a client?
What Security Service to I get?

Accessing EJBs locally

If you wish to access ejbs locally and not in client/server mode, for example if your application is a server or other middleware, you can do so by embedding OpenEJB as a library and accessing ejbs through OpenEJB's built-in IntraVM (Local) Server.

In this case, your application, server, or other middleware accesses beans as you would from any other server. The server just happens to be running in the same virtual machine as your application. The server is thusly called the IntraVM Server, and, for all intense purposes, your application or server is an IntraVM Client.

You may have read in the OpenEJB specification that you need to call OpenEJB's init method and the invoke method for all ejb calls thereafter. If you need to propagate a Transaction or Security context from your application to OpenEJB, this is true, otherwise none of this is necessary and you can simply access the IntraVM Server directly as an ordinary non-J2EE client does.

Try something like this for a simple IntraVM (Local) Client:

c:\my\app\MyEjbApplication.java

import java.util.Properties;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import FooHome;

public class MyEjbApplication {

public static void main( String args[]) {
  try{
    
    Properties properties = new Properties();
    
    properties.put(Context.INITIAL_CONTEXT_FACTORY, 
        "org.openejb.core.ivm.naming.InitContextFactory");
    
    InitialContext ctx = new InitialContext(properties);
    
    Object obj = ctx.lookup("my/bean/Foo");
    
    FooHome ejbHome = (FooHome)
        PortableRemoteObject.narrow(obj, FooHome.class);
  
  } catch (Exception e){
    e.printStackTRace();
  }
}
}

That would be the simplest spec compliant client you could create. If you don't care about spec compliance and just want to "cheat", you can do this:

c:\my\app\MyEjbApplication.java

import javax.naming.InitialContext;
import FooHome;

public class MyEjbApplication {

public static void main( String args[]) {
  try{
    
    FooHome ejbHome = (FooHome)new InitialContext().lookup(
                            "java:openejb/ejb/my/bean/Foo");
  
  } catch (Exception e){
    e.printStackTRace();
  }
}
}

Now keep in mind, that is not spec compliant. Also keep in mind that we provide it as a convenience, so if there is something you don't like or think should be changed, send code.

Passing initialization parameters

When accessing OpenEJB in local (intra-vm) mode, the IntraVM server will instantiate OpenEJB for you. When it instantiates OpenEJB, it puts default values for the items in the Properties object OpenEJB needs to actually instantiate.

If you want to pass OpenEJB specific parameters, you can do this in two ways:

  1. Call init yourself before any JNDI calls are made
  2. Pass the parameters in the InitialContext hashtable

Refer to the OpenEJB Specification for information on the init method or the parameters you can pass to OpenEJB.

Here is an example of passing the initialization parameters in to OpenEJB via the first InitialContext creation. I stress, this is only applicable the very first time and InitialContext is created within your Virtual Machine. After that, OpenEJB will have been initialized and the parameters will be ignored.

c:\my\app\MyEjbApplication.java

import FooHome;
import java.util.Properties;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;

public class MyEjbApplication {

public static void main( String args[]) {
  try{
    
    Properties p = new Properties();
    
    p.put(Context.INITIAL_CONTEXT_FACTORY, 
          "org.openejb.core.ivm.naming.InitContextFactory");
    
    p.put("openejb.home", "c:\dir\openejb");
    
    p.put("openejb.assembler", 
          "org.openejb.alt.assembler.classic.Assembler");
    
    p.put("openejb.configurator", 
          "org.openejb.alt.config.ConfigurationFactory");
    
    p.put("openejb.configuration", 
          "c:\my\app\conf\openejb.conf");
    
    InitialContext ctx = new InitialContext( p );
    
    Object obj = ctx.lookup("my/bean/Foo");
    
    FooHome ejbHome = (FooHome)
        PortableRemoteObject.narrow(obj,FooHome.class);
  
  } catch (Exception e){
    e.printStackTRace();
  }
}
}

The conf directory gotcha

We are working on functionality that will allow you to set a openejb.home system variable, then you can execute clients anywhere you want. This is partially implemented now and is used to resolve relative paths using the openejb.home to create absolute paths. This, unfortunately, has not been implemented to work for configuration files yet.

For now, you have to move *all* the files to your conf directory. Yes, this bites. Eventually all the default.* files will be packed in the jar and retrieved from there. If you want to help out with this functionality, great! Email the development list and we'll have you coding in no-time.

Here is an example of how to workaround this.

OpenEJB was unpacked in the directory in c:\dir\openejb, but, your app is executed from the directory c:\my\app. You need to copy the c:\dir\openejb\conf directory to c:\my\app\, giving you the new directory c:\my\app\conf. Then you can execute your app from the command line like this:

c:\my\app> java MyEjbApplication

You must also include the c:\dir\openejb\lib directory in your classpath.

Also, if the beans in your app are the directory c:\my\app\my\beans, then you must add this line near the bottom of your OpenEJB configuration file:

c:\my\app\conf\openejb.conf

<openejb>
...

<Deployments dir="dist\beans\" />
<Deployments dir="beans\" />
<Deployments dir="c:\my\app\my\beans\" />
</openejb>

Embedded OpenEJB FAQ

Why do I need so many OpenEJB specific files to implement a client?

This is the bane you face when running OpenEJB in the same VM, you have to configure OpenEJB as well as your client. Any server has configuration files, you can't change that. When you run the server in the same vm as your application, you take on some additional responsibility. But as I mentioned, we are implementing some things to make even that "additional" responsibility more transparent.

When your clients run OpenEJB in the same VM using the IntraVM Server, you're using OpenEJB as an embedded EJB Server just like InstantDB and Cloudscape are embedded databases servers. Just like InstantDB and Cloudscape, OpenEJB needs configuration files and other files to do it's job.

OpenEJB is the only EJB server that I know of that you can run as an embedded library, so the fact that you can even do it is a real feather in our cap. If anyone knows of another, please tell me.

In fact, anyone already using InstantDB or Cloudscape as embedded database servers in a product could just as easily use OpenEJB as an embedded EJB Server and add instant EJB support to the product as well. OpenEJB can easily play with InstantDB or Cloudscape, so it would be pretty slick. This would be extremely useful for IDEs like Visual Cafe, JBuilder, Visual Age, etc.

What Security Service to I get?

OpenEJB doesn't not come with a valid SecurityService, this has been considered the role of the application server vendor since the beginning of the project. However, no app servers have yet created a SecurityService as we had hoped. Months down the road, we will create a simple SecurityService provider if one is not contributed.

OpenEJB can do without a server and use the IntraVM Server, but it still needs a SecurityService, therefore, a fake SecurityService implementation is used by default. This PseudoSecurityService just allows you to use OpenEJB without a valid security service, it basically says everyone is a valid user.


 
 
   
 SourceForge Logo 
   
 


Java, EJB, JDBC, JNDI, JTA, Sun, Sun Microsystems are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries. XML, XML Schema, XSLT and related standards are trademarks or registered trademarks of MIT, INRIA, Keio or others, and a product of the World Wide Web Consortium. All other product names mentioned herein are trademarks of their respective owners.