views:

235

answers:

3
    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 service 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?

+1  A: 

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 PERSISTENTlifetime 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 corbalocurl 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_strfunction and pass in the url.

bshields
But I don't want to go through the Naming or Trading.If I print out my servers IOR when I start it up, I can use that to recreate a reference from the client side.But the IOR is this huge string that changes if we restart the server.So what I am looking for is a way to connect to my server based on some URL type string.This might be useful if say, the machine that the Naming and Trading is on goes down, our other systems can still talk to our servers.
Megasaur
So in the end, the comment about the lifetime policy and stuff was what we really should have been doing all along and my question was the wrong thing to ask.
Megasaur
A: 

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.

toby
We are running the server with the following CORBA properties<java stuff> Server -pss -ORBProfile=pss -ORBPort=6969 -ORBInitRef TradingService=corbaloc::[email protected]:2011/TradingService -ORBInitRef NameService=corbaloc::[email protected]:2001/NameServiceSo I guess what you are telling me, is that I should write out the IOR to somewhere first. And then use that to connect directly when I need to.
Megasaur
A: 

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.

John Black