This content has been marked as final. Show 5 replies
The object returned by Context.lookup() (the first argument to narrow()) looks just fine (to me).What is it? specifically, what is its class?
And are you using the JDK's build-in ORB?
And how was the object bound to the naming service?
What is it? specifically, what is its class?com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl@b2b5151a
And are you using the JDK's build-in ORB?Yes, I've tried both 'tnameserv' and 'orbd' with the same results.
And how was the object bound to the naming service?PortableRemoteObject.exportObject(this);
The reason it's done with a static call like this is that the code supports
both JRMP and IIOP so in the JRMP case it does this:
JRMP works just fine. IIOP used to, but it's been a long time since we've
had occasion to test it. Back then, before my time, I think Weblogic was
used for our testing.
It's very strange. The object definitely needs narrowing as you can see, it is an internal ORB class, not one of your stubs (which is what it will get narrowed to), and if the stub isn't present I would have expected a ClassNotFoundException ... but ... is the stub present at the client?
You are right, that was the problem. It happened because the nameserver and serverfactory processes referenced the product jars, but the client was running in IntelliJ using newly compiled class files. The Ant script that builds the product generates and includes the IIOP stubs, but the IJ project wasn't configured to generate them -- it is now and it works. Thanks!
But this points out a bug in the PortableRemoteObject.narrow() code that returns a null rather than thowing an exception. Is that something I should report (I don't really know how) or can you?
I don't have any greater powers than you do. You should report it via the Bug Parade, if you can get it to respond.