Narrow returns null

[Christian Naeger]

Hi all,

I desperately need your help.

I have written a simple Statless Session Bean and successfully deployed
it to Sun App Server 8.2. Moreover, I have written a small Java
application (a standalone application, with the jar from asadmin
get-client-stubs on the classpath) that looks up the Session Bean. The
look up is successful and I get an object of the correct type. The
narrowing does not throw an exception but unfortunately it does return
a null pointer. Please, have a look at the client code and the output
below.

I have tried everything I can think of and I believe I have done
everything correctly. Yet, it just doesn't work. Could anyone please
give a hint what I am probably doing wrong (the API does not mention
narrow returning null and google didn't bring up a solution either)?

Any help is greatly appreciated.
Greetings, Chris

Client-Code:
=========

Hashtable props = new Hashtable();
props.put("java.naming.factory.initial",
"com.sun.jndi.cosnaming.CNCtxFactory");
props.put("java.naming.provider.url", "iiop://localhost:3700");
Context ic = new InitialContext(props);
Object o = ic.lookup("ejb/BankMgr");
if (o == null)
System.out.println("Null Pointer");
else
System.out.println("No Null Pointer");
System.out.println(o.getClass().getName());
System.out.println(o.toString());
System.out.println(BankMgrHome.class);
o = PortableRemoteObject.narrow(o, BankMgrHome.class);
if (o == null)
System.out.println("Null Pointer");
else
System.out.println("No Null Pointer");



Output:
=======

No Null Pointer
com.sun.corba.se.impl.corba.CORBAObjectImpl
IOR:000000000000002f524d493a6e696e762e656e7469746965732e42616e6b4d6772486f6d653a303030303030303030303030303030300000000000010000000000000178000102000000000a3132372e302e302e31000e7400000056afabcb00000000260000003f00000009533141532d4f5242000000000000000200000008526f6f74504f41000000001237343637393631373538323037313830380000000000000d010950b76df1000000000001ff14000000000007000000010000002000000000000100010000000205010001000100200001010900000001000101000000002600000002000200000000000300000014000000000000000a3132372e302e302e31000eec0000000300000014000000000000000a3132372e302e302e31000f500000001f00000004000000030000002000000004000000010000002100000078000000000000000100000000000000240000001c0000006600000000000000010000000a3132372e302e302e31000eec00400000000000080606678102010101000000170401000806066781020101010000000764656661756c74000400000000000000000000010000000806066781020101010000000f
interface ninv.entities.BankMgrHome
Null Pointer

 

[Jeffrey Spoon]

Any help is greatly appreciated.
Greetings, Chris

Client-Code:
=========

Hashtable props = new Hashtable();
props.put("java.naming.factory.initial",
"com.sun.jndi.cosnaming.CNCtxFactory");
props.put("java.naming.provider.url", "iiop://localhost:3700");
Context ic = new InitialContext(props);
Object o = ic.lookup("ejb/BankMgr");
if (o == null)
System.out.println("Null Pointer");
else
System.out.println("No Null Pointer");
System.out.println(o.getClass().getName());
System.out.println(o.toString());
System.out.println(BankMgrHome.class);
o = PortableRemoteObject.narrow(o, BankMgrHome.class);
if (o == null)
System.out.println("Null Pointer");
else
System.out.println("No Null Pointer");

This is going to be no help whatsoever, but why do you use == to test
the equality of Object o? If you use if(o.equals(null)) you'll get a
null pointer exception.

 

[Christian Naeger]

Hi,

I had a few problems with accessing an EJB application in a J2EE
container from a stand-alone Java client. As I have found several
postings of people who described similar problems as I had (with no
real response), I thought I should share the results of my research:

I found the following three ways to successfully access a J2EE
application form a stand-alone client. They differ in
- the way the InitialContext is created
- the parameters of the JVM when starting the client and
- the ApplicationClient.jar needed on the classpath of the client.

The following assumes that you have successfully deployed the EJB
application on the server. Furthermore, I am using Sun's Java System
Application Server 8.2. (Does anyone know which of these ways is the
preferred way for the other application servers?)

1. Way:
Initial Context:
Context ic = new InitialContext(); // no arguments

No ApplicationClient.jar needed on the classpath
No JVM Parameters needed

--> Preferred way (according to SUN Application Server documentation)

2. Way:
InitialContext:
Hashtable props = new Hashtable();
props.put("java.naming.factory.initial",
"com.sun.jndi.cosnaming.CNCtxFactory");
props.put("java.naming.provider.url", "iiop://localhost:3700");
Context ic = new InitialContext(props);

No ApplicationClient.jar / RMI Stubs needed on the classpath

JVM Parameters for the client:
-Djavax.rmi.CORBA.UtilClass=com.sun.corba.ee.impl.javax.rmi.CORBA.Util
-Dorg.omg.CORBA.ORBClass=com.sun.corba.ee.impl.orb.ORBImpl
-Dorg.omg.CORBA.ORBSingletonClass=com.sun.corba.ee.impl.orb.ORBSingleton
-Djava.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory

(see application server documentation)

3. Way:
InitialContext:
Hashtable props = new Hashtable();
props.put("java.naming.factory.initial",
"com.sun.jndi.cosnaming.CNCtxFactory");
props.put("java.naming.provider.url", "iiop://localhost:3700");
Context ic = new InitialContext(props);

An ApplicationClient.jar must be on the classpath
(generated with asadmin deploy --retrieve=. --generatermistubs ... DO
NOT FORGET --generatermistubs, the ApplicationClient.jar with
--retrieve alone won't suffice. This is what costed me several hours of
my life ..grrr)

No Options for the JVM needed.

--> This is the way that is often described in J2EE books/tutorials.