[jacorb-developer] TAO 1.7 Compatibility Issue
Johnny Willemsen
jwillemsen at remedy.nl
Fri Jun 22 11:52:33 CEST 2012
Hi,
The question is more what the logging tells you at the TAO side. When
the TAO servers gets the request of your client and the C++ client. What
does the TAO server do, is it processing the request and what does it
send back, a normal reply or the exception?
Johnny
On 06/22/2012 11:35 AM, Vasya Tretyakov wrote:
> Hi Johnny,
> Thank you for your advise.
> I did enable TAO's debug anf set it to level 10.
> The debug basically provided me with the same information I obtained
> using the packet sniffer.
> The only difference between the GIOP requests sent by a working binary
> C++ TAO-based sample and my Java JacORB-based application is the packet
> content.
> ++TAO++
> GIOP message - HEXDUMP 288 bytes
> 47 49 4f 50 01 02 01 00 14 01 00 00 02 00 00 00 GIOP............
> 03 00 00 00 00 00 18 00 1b 00 00 00 14 01 0f 00 ................
> 52 53 54 52 32 e4 4f b9 40 0f 00 02 00 00 00 01 RSTR2.O. at .......
> 00 00 00 03 00 00 00 72 10 00 00 00 53 74 61 72 .......r....Star
> 74 53 74 61 74 69 73 74 69 63 73 00 00 00 00 00 tStatistics.....
> 01 00 03 00 6e 00 6f 00 72 00 74 00 65 00 6c 00 ....n.o.r.t.e.l.
> 00 00 a7 00 78 f6 12 00 41 00 91 7c b8 12 a7 00 ....x...A..|....
> 5d 00 91 7c 50 aa a7 00 58 a7 a7 00 50 a8 a7 00 ]..|P...X...P...
> fc f5 12 00 76 02 00 00 00 00 a7 00 22 02 91 7c ....v......."..|
> 0c f6 12 00 00 00 a7 00 22 02 91 7c 04 00 00 00 ........"..|....
> 78 01 a7 00 00 00 a7 00 00 00 00 00 e4 f5 12 00 x...............
> e8 f5 12 00 30 f6 12 00 00 00 6e 00 6f 00 72 00 ....0.....n.o.r.
> 74 00 65 00 6c 00 00 00 00 00 a7 00 81 00 00 00 t.e.l...........
> 08 02 00 00 13 00 00 00 4c f8 12 00 20 e9 90 7c ........L... ..|
> ff 02 00 00 5c f8 12 00 48 a8 a7 00 46 10 91 7c ....\...H...F..|
> 00 00 00 00 00 00 00 00 00 00 a7 00 08 04 00 00 ................
> 50 a8 a7 00 80 f6 12 00 78 01 a7 00 08 04 00 00 P.......x.......
> 00 00 01 00 41 00 00 00 bc f5 12 00 00 00 00 00 ....A...........
> ++JacORB++
> GIOP message - HEXDUMP 288 bytes
> 47 49 4f 50 01 02 00 00 00 00 01 14 00 00 00 02 GIOP............
> 03 00 00 00 00 00 00 00 00 00 00 1b 14 01 0f 00 ................
> 52 53 54 52 32 e4 4f b9 40 0f 00 01 00 00 00 01 RSTR2.O. at .......
> 00 00 00 02 00 00 00 00 00 00 00 10 53 74 61 72 ............Star
> 74 53 74 61 74 69 73 74 69 63 73 00 00 00 00 00 tStatistics.....
> 00 01 00 03 00 6e 00 6f 00 72 00 74 00 65 00 6c .....n.o.r.t.e.l
> 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 . . . . . . . .
> 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 . . . . . . . .
> 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 . . . . . . . .
> 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 . . . . . . . .
> 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 . . . . . . . .
> 00 20 00 20 00 20 00 20 00 20 00 6e 00 6f 00 72 . . . . . .n.o.r
> 00 74 00 65 00 6c 00 20 00 20 00 20 00 20 00 20 .t.e.l. . . . .
> 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 . . . . . . . .
> 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 . . . . . . . .
> 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 . . . . . . . .
> 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 . . . . . . . .
> 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 . . . . . . . .
> As you may see the binary sample contains some rubish notably in the
> parameter list section and does not have the leading byte in it if
> compared to my application. The method I am calling is
> void StartStatistics(in NI_Version clVersion, in NI_UserId userId)
> raises(OperationFailed);
> where
> struct NI_Version
> {
> NTUINT16 major;
> NTUINT16 minor;
> };
> struct NI_UserId
> {
> NTCHAR username[51];
> NTCHAR password[51];
> };
> If I need to connect to such a server am I better off trying to
> mock this "dirty" patameter list section by guesing the appropriate
> NI_UserId.username and NI_UserId.password array content?
> Regards,
> Vasyl
> *From:* Johnny Willemsen <jwillemsen at remedy.nl>
> *To:* Vasya Tretyakov <vasyamn at yahoo.com>; Discussions concerning CORBA
> development with JacORB <jacorb-developer at lists.spline.inf.fu-berlin.de>
> *Cc:* Nick Cross <jacorb at goots.org>
> *Sent:* Thursday, June 21, 2012 12:21 PM
> *Subject:* Re: [jacorb-developer] TAO 1.7 Compatibility Issue
>
> Hi,
>
> Try to run the TAO side with -ORBDebugLevel 10 to see what it outputs.
>
> Johnny
>
> On 06/21/2012 11:15 AM, Vasya Tretyakov wrote:
> > Hi Nick,
> >
> > Thank you for the reply.
> >
> > Unfortunately the developer of the TAO-based CORBA server component
> doe not provide the source code for the application, hence I cannot
> undate the implementation to the up-to-date release of TAO.
> >
> > Do you have any idea whether the extra byte in the parameter list
> section of the GIOP Request packet could be the possible cause of the
> exception I am getting?
> >
> > Regards,
> > Vasyl
> >
> > ________________________________
> > From: Nick Cross <jacorb at goots.org <mailto:jacorb at goots.org>>
> > To: Vasya Tretyakov <vasyamn at yahoo.com <mailto:vasyamn at yahoo.com>>;
> Discussions concerning CORBA development with JacORB
> <jacorb-developer at lists.spline.inf.fu-berlin.de
> <mailto:jacorb-developer at lists.spline.inf.fu-berlin.de>>
> > Sent: Wednesday, June 20, 2012 2:56 PM
> > Subject: Re: [jacorb-developer] TAO 1.7 Compatibility Issue
> >
> >
> > Hi,
> >
> > JacORB has been tested for interoperability with TAO.
> >
> > TAO 1.7 is I think 3 years old now - the current version is ACE 6.x and
> > TAO 2.x (http://download.dre.vanderbilt.edu/).
> >
> > Could you retest with the current versions of TAO and JacORB ?
> >
> > Regards
> >
> > Nick
> >
> >
> >
> > On 20/06/12 11:12, Vasya Tretyakov wrote:
> >> Dear Members,
> >>
> >> I have a need to write an application that communicates with another
> >> process on a different server. The developers of the software I would
> >> like to connect to provide an IDL file to facilitate programming
> >> language and server independent communication between the interacting
> >> applications. The ORB of the server side is implemented in C++ using
> >> The ACE ORB (TAO) version 1.7 (as the folder name on the server
> >> suggests). I also have several binary pre-compiled sample client
> >> applications that successfully communicate with the server and the
> >> corresponding C++ source code.
> >>
> >> After facing many problems with the ORB implementation provided by
> >> Oracle in JDK, I came across your wonderful project.
> >>
> >> At this time I managed to connect to the server's Naming Service,
> >> receive IOR to the desired object and sucessfully execute a void
> >> method on it. However when I try calling the method that requires
> >> parameters I get an OperationFailed exception.
> >>
> >> Investigation of the possible problem causes lead me to WireShark
> >> sniffer, which I used to capture GIOP packets. Here is what I can
> >> conlude by comparing the packets sent/received during the sample C++
> >> TAO based client applicaton and my Java JacORB based application: 1)
> >> GIOP requests from Java client application have big-endian byte
> >> order, while C++ client application uses little-endian byte order. 2)
> >> Replies to Java and C++ client applications have little-endian byte
> >> order (actually, this was a problem when using JDK's ORB since it
> >> could not parse the replies while JacORB does the job). 3) GIOP
> >> requests Java and C++ applications have a lot in common (there are
> >> some minor differences), expect for the parameter list of the called
> >> method. C++ client application contains the name of the method, four
> >> zero bytes, and parameter list while Java client contains the name of
> >> the method, four zero bytes, and parameter list with a preceeding
> >> zero byte.
> >>
> >> I conlude that I am facing the following problems: 1) Incorrect byte
> >> order in reply messages (though JacORB manages to cope with it). 2)
> >> An extra zero byte in the parameter list in the Java JacORB based
> >> client implementation.
> >>
> >> Since I am quite unexperience with CORBA I would really appreciate
> >> your advice on whether the extra zero byte in the parameter list is
> >> indeed the cuase of the exception being raised by the server. If so,
> >> what is the best place to start looking at in order to fix the
> >> problem.
> >>
> >> Thank you in advance.
> >>
> >> Vasyl _______________________________________________
> >> jacorb-developer maillist -
> >> jacorb-developer at lists.spline.inf.fu-berlin.de
> <mailto:jacorb-developer at lists.spline.inf.fu-berlin.de>
> >> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer
> > _______________________________________________
> > jacorb-developer maillist -
> jacorb-developer at lists.spline.inf.fu-berlin.de
> <mailto:jacorb-developer at lists.spline.inf.fu-berlin.de>
> > https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer
> >
> >
> >
>
>
>
>
More information about the jacorb-developer
mailing list