<DIV>Hi,</DIV>
<DIV> </DIV>
<DIV>Thanks a lot for your reply. We need a different key in order to make JDK1.3 client understand omni generated IOR. The JDK1.3.x client reads an ior file to connect to the server.</DIV>
<DIV> </DIV>
<DIV>
<DIV>Question: if ORB_init() reads the user-specified key from the .cfg or the cmd line override, why not omniNames?</DIV>
<DIV> </DIV></DIV>
<DIV>The above question was infact prompted by a user quoting your suggestion to modify the object key to circumvent jdk 1.3 and omniORB compatibility issues.</DIV>
<DIV> </DIV>
<DIV>So I modified the files omniNames.cc and log.cc (.h) - sent in the nameservice object key - as a default parameter of type char* to the omniNameslog.init().</DIV>
<DIV> </DIV>
<DIV>Read the key from the -ORBInitRef on command line to omniNames and supplied the parameter in place of the "NameService" hard-coded string - default it to "NameService" if one is not specified on cmd line.</DIV>
<DIV> </DIV>
<DIV>This way I was able to make omniNames generate an IOR of an even number of bytes (by varying the string for the key) - 44 in our case - earlier it was 39 bytes - also divisible by 4 -- and this JDK1.3.x ORB was able to decipher this new IOR. This way we are able to circumvent the problem of the omni generated IOR not being compatible with JDK1.3.x ORB. It earlier generated the ArrayIndexOutOfBounds error. The other option was to upgrade to JDK1.4.x which we cannot readily do at this time.</DIV>
<DIV> </DIV>
<DIV>Similarly, with genior - if the GIOP version were configurable, we believe JDK1.3.x ORB would not generate the INV_OBJREF or the codeset related exception upon reading the generated ior.</DIV>
<DIV> </DIV>
<DIV>I am sort of a beginner to CORBA programming - please do correct if the above workaround is inaccurate or violates any design specification. Not sure if omniORB code can incorporate the above change.</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>Satya.<BR><BR><B><I>Duncan Grisby <duncan@grisby.org></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">On Wednesday 15 September, Satya B wrote:<BR><BR>> In the omniorb.cfg file the following is specified<BR>> <BR>> InitRef = NameService=corbaname::1.0@localhost:14003/MyService<BR>> <BR>> When omniNames is run - however - the IOR shows the object key as<BR>> "NameService" and not "MyService". I tried specifying the same on<BR>> command line -ORBInitRef - still did not work. I need omninames to<BR>> output the IOR with different object key.<BR><BR>The omniORB.cfg file is for configuring _clients_ to the naming<BR>service. omniNames does not look at it at all. omniNames is hardcoded<BR>to use the standard key "NameService". Why would you want a different<BR>key?<BR><BR>> Another issue is - genior always produces an IOR with GIOP 1.2 - is<BR>> there no way to output an IOR with GIOP 1.0?<BR><BR>Not without modifying genior,
no.<BR><BR>Cheers,<BR><BR>Duncan.<BR><BR>-- <BR>-- Duncan Grisby --<BR>-- duncan@grisby.org --<BR>-- http://www.grisby.org --<BR></BLOCKQUOTE><p>__________________________________________________<br>Do You Yahoo!?<br>Tired of spam? Yahoo! Mail has the best spam protection around <br>http://mail.yahoo.com