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.