String[] orbargs= {};
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(orbargs, null);
org.omg.CORBA.Object cobj = orb.string_to_object("corbaloc:iiop:10.1.1.200:6969/OurServiceHelper");
_OurServiceHelper cpsh = _OurServiceHelperHelper.narrow(cobj); // Get's stuck
cpsh.ourMethod();
That narrow just hangs.
My servi开发者_如何学Pythonce is setup to run on a static port. And we know it works since we usually look it up through the NamingService.
What am I doing wrong?
If you're using the NamingService, you should actually be using a corbaname url instead of a corbaloc url. The below will work if your naming service is on port 6969. If "OurServiceHelper" is on 6969 but the NamingService is on a different port, you need to specify the port of the naming service in the url below instead of 6969. The port of the server object is embedded in the ior returned by the NamingService so that's why it doesn't need to be specified.
"corbaname:10.1.1.200:6969#OurServiceHelper"
Re: Comment:
First a note about IORs and serving up objects. If you want your served objects to be persistent across process restarts, you have to set the PERSISTENT
lifetime policy on the POA that contains the objects. Also, the IOR embeds the ip and port of the server, so if you want to generate IORs that remain consistent across restarts you have to use a static IP and port number as well as using the persistent lifetime policy.
The name service makes things easier by allowing you not to have to worry about a lot of this stuff. As long as the name service is reachable at a known location, all of your server objects can just register themselves with the name service when they are instantiated and clients can then access them without having to know where they're located.
If you're determined not to use the name service you're code will have to change somewhat. If you use the corbaloc
url then you are using the Interoperable Naming Service (INS). See: http://java.sun.com/j2se/1.4.2/docs/guide/idl/INStutorial.html. Using the INS, you need to use the functionality of the NamingContextExt
object. Specifically, to resolve the corabloc url that you construct you should call the NamingContextExt::resolve_str
function and pass in the url.
The key part of the corbaloc URL (string after the slash), could possibly be incorrect or not registered correctly, and the serverside orb isn't able to map the key to the object reference.
How are you running the server?
This should work:
<server> -ORBInitRef OurServiceHelper="file://server.ior"
So when the corbaloc request comes in the orb should be able to match the key to the ior and return you the ior. Different ORB's have different ways of doing this for registering an initial reference, TAO have a propriety interface called IORTable for example.
The corbaloc has no type info in it, so the ORB is checking the type you're narrowing to by making a remote call (_is_a). Try using an unchecked narrow, which won't call _is_a:
_OurServiceHelper cpsh = _OurServiceHelperHelper.narrow(cobj);
It's odd that the _is_a call doesn't return for you. My guess is that the unchecked_narrow will work work (you'll get a non-null result), but the object reference won't work.
精彩评论