Client EJB JNDI lookup broken in OC4J 9.0.2?

Question

I have a client program that connects to an EJB in the application server and invokes methods on it. If it look up the EJB using the actual JNDI binding, it works fine. If I look it up in java:comp/env (and use the ejb-ref in application-client.xml and ejb-ref-mapping in orion-application-client.xml) the client program catches the following exception:
caught : javax.naming.NameNotFoundException: No object bound for java:comp/env/ejb/logging/Logger
javax.naming.NameNotFoundException: No object bound for java:comp/env/ejb/logging/Logger
at com.sun.enterprise.naming.java.javaURLContext.lookup(javaURLContext.java:116)
at javax.naming.InitialContext.lookup(InitialContext.java:347)
at com.mycompany.common.logging.ejb.test.LoggerEJBTest.main(LoggerEJBTest.java:37)
Now, assuming I don't have any typos (and I'd be thrilled if someone pointed it out if that were the case), then it looks like this is a bug in OC4J 9.0.2: the ejb-ref and ejb-ref-mapping elements do not work. For the record, I am using the same ejb-ref and ejb-ref-mapping elements for a servlet's web.xml and orion-web.xml, respectively, without problems.
Here are relevant file excerpts:
LoggerEJBTest.java:
String hostName = "localhost";
String hostPort = "23791";
String userName = "abc";
String password = "def";
String providerURL = "ormi://" + hostName + ":" + hostPort + "/ghi";
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.ApplicationClientInitialContextFactory");
env.put(Context.PROVIDER_URL, providerURL);
env.put(Context.SECURITY_PRINCIPAL, userName);
env.put(Context.SECURITY_CREDENTIALS, password);
System.out.println("create initial context");
Context context = new InitialContext(env);
System.out.println("get home object");
//works when uncommented
//Object homeObject = context.lookup("logging/Logger");
//broken:
Object homeObject = context.lookup("java:comp/env/ejb/logging/Logger");
ejb-jar.xml:
<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
<ejb-jar>
<description>abc</description>
<display-name>abc</display-name>
<enterprise-beans>
<session>
<description>Logger Bean</description>
<display-name>Logger</display-name>
<ejb-name>Logger</ejb-name>
<home>com.mycompany.common.logging.ejb.LoggerHome</home>
<remote>com.mycompany.common.logging.ejb.Logger</remote>
<ejb-class>com.mycompany.common.logging.ejb.LoggerBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
orion-ejb-jar.xml:
<?xml version="1.0"?>
<!DOCTYPE orion-ejb-jar PUBLIC "-//Evermind//DTD Enterprise JavaBeans 2.0 runtime//EN" "http://xmlns.oracle.com/ias/dtds/orion-ejb-jar.dtd">
<orion-ejb-jar>
     <enterprise-beans>
          <session-deployment name="Logger" location="logging/Logger">
     </enterprise-beans>
</orion-ejb-jar>
application-client.xml:
<?xml version="1.0"?>
<!DOCTYPE application-client PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application Client 1.3//EN" "http://java.sun.com/dtd/application-client_1_3.dtd">
<application-client>
     <display-name>logging test</display-name>
<ejb-ref>
<ejb-ref-name>ejb/logging/Logger</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.mycompany.common.logging.ejb.LoggerHome</home>
<remote>com.mycompany.common.logging.ejb.Logger</remote>
<ejb-link>Logger</ejb-link>
</ejb-ref>
</application-client>
orion-application-client.xml:
<?xml version="1.0"?>
<!DOCTYPE orion-application-client PUBLIC "-//Evermind//DTD J2EE Application-client runtime 1.2//EN" "http://xmlns.oracle.com/ias/dtds/orion-application-client.dtd">
<orion-application-client>
<ejb-ref-mapping location="logging/Logger" name="ejb/logging/Logger" />
</orion-application-client>

Answer 1

As far as I know, the only way to lookup an EJB (deployed to
OC4J) from a regular java class using the "ApplicationClientInitialContextFactory"
class and the logical JNDI name is to include your regular java
class (i.e. the client) in your application's EAR file (the file
you use to deploy your application to OC4J).OK, but that sounds like a pretty silly constraint. Shouldn't the ApplicationClientInitialContextFactory know how to do the mapping using the application-client.xml and orion-application-client.xml settings? What does the OC4J server provide that makes this magically work?
From the information you have supplied, it appears that you may
not want to include your client (java) class in your EAR file.That is correct. It is an integration test program, not meant to be deployed into the application server.
So now the question is, "Do you want to make your client part
of your J2EE application, and include it in the application
EAR file?"
If you do, then you have made several mistakes which prevent
you from doing that, but I don't want to explain further, since
you may not want to do that, anyway!Not applicable. But on that topic, aside from being able to auto-start a client application within the OC4J JVM, are there any other reasons why I might want to deploy a client in that manner? I mean, honestly, these things are called "clients" and "servers" for a reason.
Now if you have been reading other postings to this forum,
and if you have read the documentation for OC4J, you would
know that it requires J2SDK 1.3.1 only (not 1.4.0).I am well aware of the other postings on that topic. I am, however, counting on Oracle to live up to their promise to certify 1.4 with with the next update to OC4J:
Limits of 10g
That aside, I already consider OC4J 9.0.2 to be a broken product at this point anyway, so hacking it to use Java 1.4 doesn't bother me that much. OC4J 9.0.2 works about as well with Java 1.4 as with Java 1.3, assuming one replaces the tools.jar. The other major incompatibility is that Oracle SOAP breaks if a web service EJB home&remote interface is compiled with Java 1.4:
http://forums.oracle.com/forums/message.jsp?id=936894
Alas, we're using Apache SOAP 2.3 rather than the ass-backwards stuff in OC4J, anyways, so there's no problem.