«

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:000000000000002f524d493a6e696e762e656e74697469 65732e42616e6b4d6772486f6d653a30303030303030303030 30303030303000000000000100000000000001780001020000 00000a3132372e302e302e31000e7400000056afabcb000000 00260000003f00000009533141532d4f524200000000000000 0200000008526f6f74504f4100000000123734363739363137 3538323037313830380000000000000d010950b76df1000000 000001ff140000000000070000000100000020000000000001 00010000000205010001000100200001010900000001000101 00000000260000000200020000000000030000001400000000 0000000a3132372e302e302e31000eec000000030000001400 0000000000000a3132372e302e302e31000f500000001f0000 00040000000300000020000000040000000100000021000000 78000000000000000100000000000000240000001c00000066 00000000000000010000000a3132372e302e302e31000eec00 40000000000008060667810201010100000017040100080606 6781020101010000000764656661756c740004000000000000 00000000010000000806066781020101010000000f
interface ninv.entities.BankMgrHome
Null Pointer

In message < .com>,
Christian Naeger <> writes
>

>
>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.



--
Jeffrey Spoon

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.j avax.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.cosnamin g.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.