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 tothe stand-alone java client case. However, the complication is thatmost Java web servers set the default JNDI name provider for the JVM,which prevents our appserver naming provider from being instantiatedwhen the application uses the no-arg InitialContext() constructor. Thesolution is to explicitly instantiate an InitialContext(Hashtable) withthe properties for our naming provider, as contained inappserv-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.  

（Asmentioned in Step 1, appserv-rt.jar is needed to correclty bootstrapthe naming provider within our appserver implementation. javaee.jarcontains the API classes for Java EE 5. E.g., assuming the applicationclasses are in /home/user1/myclasses and the main client class isacme.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 includeother dependent .jars within the lib directory. When setting yourclient classpath, it is best to directly refer to the appserv-rt.jarwithin the app server lib directory rather than copying it to anotherlocation. If you do copy appserv-rt.jar, you'll need to copy additional.jars such as appserv-deployment-client.jar and appserv-ext.jar. Thefull set of .jars that might be needed by appserv-rt.jar is located inits META-INF/MANIFEST.MF file.  

Ifyour 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

Ifyour stand-alone client makes use of the Java Persistence API (e.g. itcalls a Remote EJB that returns a Java Persistence API entity ), you'llalso 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.