Remote EJB from a non-Java EE web container

How do I access a Remote EJB (3.0 or 2.x) from a non-Java EE web container like Tomcat or Resin?

Accessing a Remote EJB from a non-Java EE web container is similar to the stand-alone java client case. However, the complication is that most Java web servers set the default JNDI name provider for the JVM, which prevents our appserver naming provider from being instantiated when the application uses the no-arg InitialContext() constructor. The solution is to explicitly instantiate an InitialContext(Hashtable) with the properties for our naming provider, as contained in appserv-rt.jar's jndi.properties file.  

Step 1. Instantiate the InitialContext 
  Properties props = new Properties();
  props.setProperty("java.naming.factory.initial", 
  "com.sun.enterprise.naming.SerialInitContextFactory");
  props.setProperty("java.naming.factory.url.pkgs", 
  "com.sun.enterprise.naming");
  props.setProperty("java.naming.factory.state",
  "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");

  // optional. Defaults to localhost. Only needed if web server is running 
  // on a different host than the appserver  
  props.setProperty("org.omg.CORBA.ORBInitialHost", "localhost");

  // optional. Defaults to 3700. Only needed if target orb port is not 3700.
  props.setProperty("org.omg.CORBA.ORBInitialPort", "3700");

  InitialContext ic = new InitialContext(props);
Step 2. Use the global JNDI name of the target Remote EJB in the lookup.

  EJB 3.0 :  

  E.g., assuming a Remote 3.0 EJB with a global JNDI name of com.acme.FooRemoteBusiness

  FooRemoteBusiness foo = (FooRemoteBusiness) ic.lookup("com.acme.FooRemoteBusiness");



  EJB 2.x : 
  E.g., assuming a Remote 2.x EJB with a global JNDI name of com.acme.FooHome

  Object obj = ic.lookup("com.acme.FooHome");
  FooHome fooHome = (FooHome) PortableRemoteObject.narrow(obj, FooHome.class);

Step 3. Add the necessary appserver code to the web server's classpath. 
See step 3 of stand-alone client access for the list of required .jars.  

（As mentioned in Step 1, appserv-rt.jar is needed to correclty bootstrap the naming provider within our appserver implementation. javaee.jar contains the API classes for Java EE 5. E.g., assuming the application classes are in /home/user1/myclasses and the main client class is acme.MyClient :

  java -classpath $APS_HOME/lib/appserv-rt.jar:$APS_HOME/lib/javaee.jar:/home/user1/myclasses acme.MyClient

Note : appserv-rt.jar uses the JAR MANIFEST-CLASSPATH attribute to include other dependent .jars within the lib directory. When setting your client classpath, it is best to directly refer to the appserv-rt.jar within the app server lib directory rather than copying it to another location. If you do copy appserv-rt.jar, you'll need to copy additional .jars such as appserv-deployment-client.jar and appserv-ext.jar. The full set of .jars that might be needed by appserv-rt.jar is located in its META-INF/MANIFEST.MF file.  

If your stand-alone client makes use of JMS, you'll also need to add $APS_HOME/lib/install/applications/jmsra/imqjmsra.jar, $APS_HOME/lib/appserv-admin.jar and $APS_HOME/lib/appserv-ws.jar

If your stand-alone client makes use of the Java Persistence API (e.g. it calls a Remote EJB that returns a Java Persistence API entity ), you'll also need to add $APS_HOME/lib/toplink-essentials.jar

）

Step 4. For EJB 3.0 Remote access, use at least Glassfish V2 or Java EE 5 SDK(SJS AS 9) Update 1.  
Builds from this point on will contain a required bug fix.  
See https://glassfish.dev.java.net/issues/show_bug.cgi?id=920 for more details.