From roemer@inf.ethz.ch Fri Dec 3 17:42:19 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id RAA26652 for ; Fri, 3 Dec 1999 17:42:19 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id RAA22018 for ; Fri, 3 Dec 1999 17:42:18 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id RAA20571 for mico-devel-outgoing; Fri, 3 Dec 1999 17:24:57 +0100 (MET) Received: from tub.cisco.com (tub-hme0.cisco.com [161.44.228.20]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id RAA20566 for ; Fri, 3 Dec 1999 17:24:55 +0100 (MET) Received: from cisco.com (lowell-dhcp230-102.cisco.com [161.44.230.102]) by tub.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA04306 for ; Fri, 3 Dec 1999 11:24:54 -0500 (EST) Message-ID: <3847EF8E.6565B3AC@cisco.com> Date: Fri, 03 Dec 1999 11:27:58 -0500 From: Juan =?iso-8859-1?Q?Ram=F3n?= Acosta Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,es-MX MIME-Version: 1.0 To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: Re: MICO: Corba Namming Service with LDAP References: <007b01bf3d7f$11ff53f0$a101a8c0@interop1> Content-Type: multipart/mixed; boundary="------------D2252EC99EE353A50F55C94D" Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 1110 Lines: 43 This is a multi-part message in MIME format. --------------D2252EC99EE353A50F55C94D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello there, I read somebody is using the Event Service to fire asynchronous event from the JavaORB to a MICO object. Is there any support in MICO for Events. Second question, how long from now MICO will embrace CORBA 3.0 specifications, I am very interested on the QoS and Fault Tolerance Features. Regards JRAB --------------D2252EC99EE353A50F55C94D Content-Type: text/x-vcard; charset=us-ascii; name="juacosta.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Juan Ramón Acosta Content-Disposition: attachment; filename="juacosta.vcf" begin:vcard n:Ramón Acosta;Juan tel;fax:(978) 275-5299 tel;work:(978) 275-7611 x-mozilla-html:FALSE url:http:\www.GeoTel.com org:CISCO Systems;Application Technology Group adr:;;900 Chelmsford St, Tower II,14 FL;Lowell;MA;01851;USA version:2.1 email;internet:juacosta@cisco.com title:Principal Software Engineer fn:Juan Ramón Acosta end:vcard --------------D2252EC99EE353A50F55C94D-- From roemer@inf.ethz.ch Fri Dec 3 19:50:31 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id TAA27371 for ; Fri, 3 Dec 1999 19:50:30 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id TAA23704 for ; Fri, 3 Dec 1999 19:50:30 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id TAA21019 for mico-devel-outgoing; Fri, 3 Dec 1999 19:41:52 +0100 (MET) Received: from mailgw3a.lmco.com (mailgw3a.lmco.com [192.35.35.24]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id TAA21014 for ; Fri, 3 Dec 1999 19:41:50 +0100 (MET) Received: from emss04g01.ems.lmco.com ([166.17.13.122]) by mailgw3a.lmco.com (8.8.8/8.8.8) with ESMTP id NAA28141 for ; Fri, 3 Dec 1999 13:41:49 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38890) id <0FM600G017W0ND@lmco.com> for mico-devel@vsb.informatik.uni-frankfurt.de; Fri, 3 Dec 1999 13:41:49 -0500 (EST) Received: from lmco.com ([129.86.38.205]) by lmco.com (PMDF V5.2-32 #38890) with ESMTP id <0FM6005G9G79H5@lmco.com> for mico-devel@vsb.informatik.uni-frankfurt.de; Fri, 03 Dec 1999 13:18:47 -0500 (EST) Date: Fri, 03 Dec 1999 13:18:43 -0500 From: John Williams Subject: MICO: MICO POA with Naming Service To: mico-devel@vsb.informatik.uni-frankfurt.de Message-id: <38480983.A432D6E6@lmco.com> Organization: Information Dominance Systems MIME-version: 1.0 X-Mailer: Mozilla 4.03 [en] (X11; U; SunOS 4.1.4 sun4m) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 574 Lines: 20 Dear Sirs: I am looking for an example that implements a POA which uses COS Naming Service. I tried to modify your hello-1 example to do this, but I can't get it to work. I would like to implement a simple client-server example where the client requests a message and the server responds with a character string. Later I need to implement something like this where the server is written in C++ and the client is written in Java and COS Naming Service is used. Any help that you can give me will be greatly appreciated. John Williams john.a.williams@lmco.com 603-885-4774 From roemer@inf.ethz.ch Sat Dec 4 14:14:17 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id OAA01682 for ; Sat, 4 Dec 1999 14:14:17 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id OAA03945 for ; Sat, 4 Dec 1999 14:14:16 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id OAA21892 for mico-devel-outgoing; Sat, 4 Dec 1999 14:03:53 +0100 (MET) Received: from mout0.01019freenet.de (mout0.01019freenet.de [62.104.201.5]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id OAA21887 for ; Sat, 4 Dec 1999 14:03:52 +0100 (MET) Received: from [62.104.201.2] (helo=mx1.01019freenet.de) by mout0.01019freenet.de with esmtp (Exim 3.10 #1) id 11uEqu-0002fX-00 for mico-devel@vsb.informatik.uni-frankfurt.de; Sat, 04 Dec 1999 14:03:52 +0100 Received: from [212.81.167.210] (helo=GISMO) by mx1.01019freenet.de with smtp (Exim 3.10 #2) id 11uEqt-0005UC-00 for mico-devel@vsb.informatik.uni-frankfurt.de; Sat, 04 Dec 1999 14:03:52 +0100 From: "Gunter Miessbrandt" To: Subject: MICO: Problems runing a mico-program under vc6 Date: Sat, 4 Dec 1999 14:01:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 1468 Lines: 56 Hello! I have a big problem with runing a mico-client-program under Windows 2000 Release Candidate 2. The server-program runs under Suse Linux 6.1. The mico-version is 2.3.0. I have compiled mico under vc6sp3. Always when i run the following program, it terminates with a runtime error. "Microsoft Visual C++ Runtime Library" "Runtime Error!" "Program: client.exe" "abnormal program termination" Program-code: #include #include #include "url.h" int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ) { int i = 0; CORBA::ORB_var orb = CORBA::ORB_init(i, NULL, "mico-local-orb"); CORBA::BOA_var boa = orb->BOA_init(i, NULL, "mico-local-boa"); CORBA::Object_var obj = orb->bind("IDL:url:1.0", "inet:169.254.169.129:8888"); if (CORBA::is_nil(obj)) { MessageBox(NULL, "Verbindung konnte nicht Aufgebaut werden! Server abgestürtzt?", "ZKradio-Client", MB_OK); return 0; }; url_var client = url::_narrow(obj); CORBA::Long ID = client->check_in("Gismo"); CORBA::String_var urltext; urltext = client->get_url(ID, "Gismo"); MessageBox(NULL, "gefunden", "Info", MB_OK); return 0; } With the debugger i have worked out that the runtime error happens at the codeline "CORBA::Long ID = client->check_in("Gismo");". I hope anybody can help me!!!! Greetings Miessbrandt Gunter From roemer@inf.ethz.ch Sat Dec 4 17:05:12 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id RAA02354 for ; Sat, 4 Dec 1999 17:05:12 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id RAA04762 for ; Sat, 4 Dec 1999 17:05:11 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id QAA22077 for mico-devel-outgoing; Sat, 4 Dec 1999 16:53:54 +0100 (MET) Received: from faust27-s.rz.uni-frankfurt.de (faust27-s.rz.uni-frankfurt.de [141.2.149.151]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with SMTP id QAA22072 for ; Sat, 4 Dec 1999 16:53:53 +0100 (MET) Received: from rose.fpx.de (actually NAFp2-183.rz.uni-frankfurt.de) by faust27-eth.rz.uni-frankfurt.de with Local SMTP (PP); Sat, 4 Dec 1999 16:53:48 +0000 Received: (from fp@localhost) by rose.fpx.de (8.8.5/8.8.5) id PAA00955 for mico-devel@vsb.informatik.uni-frankfurt.de; Sat, 4 Dec 1999 15:37:02 +0100 Date: Sat, 4 Dec 1999 15:37:01 +0100 From: Frank Pilhofer To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: Re: MICO: valuetypes and inheritance Message-ID: <19991204153700.B354@rose.fpx.de> Mail-Followup-To: mico-devel@vsb.informatik.uni-frankfurt.de References: <99112622413500.01698@rws> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=1yeeQ81UyVL57Vl7 X-Mailer: Mutt 0.95i In-Reply-To: <99112622413500.01698@rws>; from Rudolf Weber on Fri, Nov 26, 1999 at 10:22:14PM +0100 Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 3133 Lines: 70 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii On Fri, Nov 26, 1999 at 10:22:14PM +0100, Rudolf Weber wrote: > > I experimented with the valuetypes. > valuetype B { .... }; > valuetype D: truncatable B { ... }; > > First I had only B, and build a Server. > Then I defined D (same Versionnumber) and build a Client first. > The Client with D and B could send Values of type B. > When it send D, then the Exception IDL:omg.org/CORBA/SystemException:1.0 (0, > not-completed) was thrown. > Actually, this works for me. I've attached a small test where only a base valuetype is registered in the server, and where the client then sends a derived but truncatable value. Works fine here. > > After the CORBA 2.3 specification Chapter 5.2.5.2 I expected, that > with the keyword truncatable the Server takes the Upper-Class definition B, > when the D-Factory is not found. > Yes, that's the way it should be. Frank -- + Frank Pilhofer fp@informatik.uni-frankfurt.de + | http://www.uni-frankfurt.de/~fp/ | +---- Life would be a very great deal less weird without you. - DA ----+ --1yeeQ81UyVL57Vl7 Content-Type: application/x-tar-gz Content-Disposition: attachment; filename="test.tar.gz" Content-Transfer-Encoding: base64 H4sIAE8mSTgAA+1YbW/iRhDO1/hXTOlVAi4mtjGhclSkS+5OitSUirT50lZosZfgq/Gi9UKU Vulv7+x615i3clIFURTPB2PvzM7MvswzMwiaifOTwxL4XrfTgRMAt9txyr+GHICu4yG1na6L 312v451A58B+KZpngnCAk/Hsv+X28V8pCXn+t+RPOo4TeiAbruNc+P7O83fb7oU5f8/vdnDE ddzOCTgH8meF3vj5WyRJAgiTmKYCMsoXlFtW/hvAiGS0NVE/w3g6S/R7i2nJFrNOp3HI7CQC 2wyui4CdSJl39dub6/79p8HdTf+nhmXlJgsbEeXxgkZr1vTomnEjy7Tfa27oxewU3uGQ8Tcw nofhlg3QlsL378EOl5JmPXK6fts6vbTO1bWt6i1UWFa+DL1POLAiZwatYpVBYWFdtjRulRyT fmrtcZRYp/gA254xgs+U2SN8KZjWhvf5bPOxS0GZjxtFSRpYp3wK9rhwYe0ahEt/J0a0Kc+Q cbp6W6H5D7QiOqNpZFkvHU2vjxT+mwM+kI09+I8JoF3gv+N1ccDpehcV/h+DrAVJ5lQ8zagK QetvC2A2HyUxgtuEcQFjxi6t50vLilNB+ZiEFD4zBlJuweIIZhwZUI9TNR+Uuoaa8dJLq+gr SMV/kcYOY2Nf/XfhL+u/jqz/XRcFqvg/Bn0bp2EyjyjU8gxcs1ZHdHlSk3mbZJmMfTUEgQSA mIs5SQxg/Nz/MET+2RYOIgkZJfQuLyyDAR1fs3kq5DdJxVWOPLlwsIYsClaaGliQJ5EHcuYY 6rUHJuC76Pe0diZBSDRyQbuHuFVvIBABPBv4sqYEYUpKAeEP4RmEEzz6Jr4vfvujoaDvuj+4 +hAE+BwukMf4CH4oD8ZpjC7ls+W8M6jllScLSWKjeA1Nop7zpvSyCQP6EGeIm4DAKRiPadZS jHNraexeOvxZ8Z/kTijLizEaTuljXjzms5/katCG3eNa7VAt1rBxN24+/hjIGYHbcnBHFuNV d27Q/Zgk8V9UHtaGJ/3RFxoKZX/G0L62lbFkQdXSce6Q0zHlNA1phvYGjAnUVFMbvX7K8j7k uggq28INgmFKOGePUJ+xXSpuSUoe1FI5TB84akJ9dk9M6HDJhXq+0PX5pQumFEi40xtrbvLl 1vWLBYpJabs3FJM4UwZAOmD3cLfjBRFUj+W7NE+ND2az7yZzEbFHHE+pLFQ5JeGERo3ltquF RGiEMzy8Xwa/fjoD+VRqORVznoKDufSAqVThf9FuHMbGvvqv63sF/nuq/pMJoML/Y9AS7Yt+ a2cK2JBdJofjoutmuLLRF4NXoziNNBJiiCsgVPEk412KYmJAUclaog9OVzKY4SjWvPVvtIU4 G6ZxAnWc08hNjwySjMr4rDJijgYjlXqg/r3bUd/4YfdMKmvFaV0rMlsodUVaV3lbtbpIq/M9 8znCCXXP31AelZR/PXao+C/154e4Y3v7P6/U/7VV/ee3nSr+j0Fr9R/eAIzmZU+obwYEIDDD hUQl1x2dIl7Mqu97bVT8/6Ox/BA29sW/3+6Y+HcvPCePf7eK/2NQ3tUtk9iWtq5/dT+UAlv6 Op0mP9IxmSdCNTKmtdvo6cqJUrdxz/k/SyUfTCcT7LC03iutWCjLXOVdY4hFt0C1jA/n6ZTw bEJK9otEuZLILwvPXvpwjkDl/H8oCNgb/x1/Gf++zP+e61f//xyF8thbKTx3QICW+Z8osFbi bgMCI/KCWFD28k3BQUUVVVRRRW+E/gUHM4niACgAAA== --1yeeQ81UyVL57Vl7-- From roemer@inf.ethz.ch Sat Dec 4 17:47:47 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id RAA02446 for ; Sat, 4 Dec 1999 17:47:47 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id RAA05005 for ; Sat, 4 Dec 1999 17:47:46 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id RAA22142 for mico-devel-outgoing; Sat, 4 Dec 1999 17:35:22 +0100 (MET) Received: from mail.rdc3.on.home.com (ha1.rdc3.on.home.com [24.2.9.68]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id RAA22137 for ; Sat, 4 Dec 1999 17:35:20 +0100 (MET) Received: from cr485815-a ([24.114.146.25]) by mail.rdc3.on.home.com (InterMail v4.01.01.02 201-229-111-106) with SMTP id <19991204163319.XOZN21594.mail.rdc3.on.home.com@cr485815-a> for ; Sat, 4 Dec 1999 08:33:19 -0800 Received: by localhost with Microsoft MAPI; Sat, 4 Dec 1999 11:38:00 -0500 Message-ID: <01BF3E4C.048F4CC0.mschinca@home.com> From: Mike Schincariol To: "'mico-devel@vsb.informatik.uni-frankfurt.de'" Subject: RE: MICO: Problems runing a mico-program under vc6 Date: Sat, 4 Dec 1999 11:37:59 -0500 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 1845 Lines: 66 To whoever is the owner of this email list, REMOVE ME FROM IT! You have mixed me up with someone else and I don't wish to receive your emails. -----Original Message----- From: Gunter Miessbrandt [SMTP:miessbra@01019freenet.de] Sent: Saturday, December 04, 1999 8:02 AM To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: MICO: Problems runing a mico-program under vc6 Hello! I have a big problem with runing a mico-client-program under Windows 2000 Release Candidate 2. The server-program runs under Suse Linux 6.1. The mico-version is 2.3.0. I have compiled mico under vc6sp3. Always when i run the following program, it terminates with a runtime error. "Microsoft Visual C++ Runtime Library" "Runtime Error!" "Program: client.exe" "abnormal program termination" Program-code: #include #include #include "url.h" int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ) { int i = 0; CORBA::ORB_var orb = CORBA::ORB_init(i, NULL, "mico-local-orb"); CORBA::BOA_var boa = orb->BOA_init(i, NULL, "mico-local-boa"); CORBA::Object_var obj = orb->bind("IDL:url:1.0", "inet:169.254.169.129:8888"); if (CORBA::is_nil(obj)) { MessageBox(NULL, "Verbindung konnte nicht Aufgebaut werden! Server abgesturtzt?", "ZKradio-Client", MB_OK); return 0; }; url_var client = url::_narrow(obj); CORBA::Long ID = client->check_in("Gismo"); CORBA::String_var urltext; urltext = client->get_url(ID, "Gismo"); MessageBox(NULL, "gefunden", "Info", MB_OK); return 0; } With the debugger i have worked out that the runtime error happens at the codeline "CORBA::Long ID = client->check_in("Gismo");". I hope anybody can help me!!!! Greetings Miessbrandt Gunter From roemer@inf.ethz.ch Sun Dec 5 07:24:28 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id HAA06414 for ; Sun, 5 Dec 1999 07:24:28 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id HAA13380 for ; Sun, 5 Dec 1999 07:24:27 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id HAA22866 for mico-devel-outgoing; Sun, 5 Dec 1999 07:14:06 +0100 (MET) Received: from Wizard.IM.ntu.edu.tw (wizard.im.ntu.edu.tw [140.112.106.36]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id HAA22861 for ; Sun, 5 Dec 1999 07:14:04 +0100 (MET) Received: from localhost (eric@localhost) by Wizard.IM.ntu.edu.tw (8.9.3/8.9.3) with ESMTP id OAA22315 for ; Sun, 5 Dec 1999 14:29:30 +0800 (CST) (envelope-from eric@Wizard.IM.ntu.edu.tw) Date: Sun, 5 Dec 1999 14:29:30 +0800 (CST) From: Eric To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: MICO: A newbie question ... In-Reply-To: <9948.991202@gmx.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 720 Lines: 23 Hihi I am trying to write a program with CORBA and chose MICO as the ORB. However , when I try to compile the code , the following errors occur : /tmp/ccm26659.o(.gnu.linkonce.t._$_t7TSeqVar1Zt18StringSequenceTmpl1ZQ25CORBA10 String_var+0xec):undefined reference to `CORBA::String_var::~String_var(void)' and other similar ones , I checked the link libraries , I used : g++ -I/usr/local/include -L/usr/local/lib/ \ -O -ftemplate-depth-42 -fexceptions \ -lstdc++ -lreadline -lncurses -lm \ -lmico2.3.0 -lmicocoss2.3.0 -lmicox2.3.0\ -o test test.cpp on a FreeBSD 4.0 box Did I miss some other libraries ? Thanks for help! Sincerely, Eric From roemer@inf.ethz.ch Sun Dec 5 16:06:59 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id QAA07712 for ; Sun, 5 Dec 1999 16:06:58 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id QAA15235 for ; Sun, 5 Dec 1999 16:06:58 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id PAA23200 for mico-devel-outgoing; Sun, 5 Dec 1999 15:53:02 +0100 (MET) Received: from mail1.gmx.net (mail1.gmx.net [194.221.183.61]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with SMTP id PAA23195 for ; Sun, 5 Dec 1999 15:53:01 +0100 (MET) Received: (qmail 17352 invoked by uid 0); 5 Dec 1999 14:53:09 -0000 Received: from 86-99.f.dial.o-tel-o.net (212.144.86.99) by mail1.gmx.net with SMTP; 5 Dec 1999 14:53:09 -0000 Date: Sun, 5 Dec 1999 14:56:14 +0100 From: Rudolf Janz X-Mailer: The Bat! (v1.36) UNREG / CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <14622.991205@gmx.net> To: Gunter Miessbrandt Subject: Re: MICO: Problems runing a mico-program under vc6 In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 921 Lines: 23 GM> Hello! GM> I have a big problem with runing a mico-client-program under Windows 2000 GM> Release Candidate 2. GM> The server-program runs under Suse Linux 6.1. The mico-version is 2.3.0. I GM> have compiled GM> mico under vc6sp3. Always when i run the following program, it terminates GM> with a runtime error. Do the demos (for example boa/account2) work?? GM> "Microsoft Visual C++ Runtime Library" GM> "Runtime Error!" GM> "Program: client.exe" GM> "abnormal program termination" I think this means an unhandled exception(for a example a communication problem) has been thrown somewhere in the code. GM> With the debugger i have worked out that the runtime error happens at the GM> codeline GM> "CORBA::Long ID = client->check_in("Gismo");". Is the client variable ok? Have you stepped into the call? Setting an breakpoint on mico_throw was sometimes quite helpful. Rudolf Janz From roemer@inf.ethz.ch Sun Dec 5 22:37:57 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id WAA11046 for ; Sun, 5 Dec 1999 22:37:57 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id WAA17402 for ; Sun, 5 Dec 1999 22:37:56 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id WAA23936 for mico-devel-outgoing; Sun, 5 Dec 1999 22:20:24 +0100 (MET) Received: from faust27-s.rz.uni-frankfurt.de (faust27-s.rz.uni-frankfurt.de [141.2.149.151]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with SMTP id WAA23931 for ; Sun, 5 Dec 1999 22:20:22 +0100 (MET) Received: from rose.fpx.de (actually NAFp2-010.rz.uni-frankfurt.de) by faust27-eth.rz.uni-frankfurt.de with Local SMTP (PP); Sun, 5 Dec 1999 22:19:13 +0000 Received: (from fp@localhost) by rose.fpx.de (8.8.5/8.8.5) id VAA00426 for mico-devel@vsb.informatik.uni-frankfurt.de; Sun, 5 Dec 1999 21:43:52 +0100 Date: Sun, 5 Dec 1999 21:43:51 +0100 From: Frank Pilhofer To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: Re: MICO: A newbie question ... Message-ID: <19991205214351.B402@rose.fpx.de> Mail-Followup-To: mico-devel@vsb.informatik.uni-frankfurt.de References: <9948.991202@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Eric on Sun, Dec 05, 1999 at 02:29:30PM +0800 Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 1221 Lines: 29 On Sun, Dec 05, 1999 at 02:29:30PM +0800, Eric wrote: > > I am trying to write a program with CORBA and chose MICO as the > ORB. However , when I try to compile the code , the following > errors occur : > and other similar ones , I checked the link libraries , I used : > > g++ -I/usr/local/include -L/usr/local/lib/ \ > -O -ftemplate-depth-42 -fexceptions \ > -lstdc++ -lreadline -lncurses -lm \ > -lmico2.3.0 -lmicocoss2.3.0 -lmicox2.3.0\ > -o test test.cpp > The ordering of libraries is significant. Try to place -lmico2.3.0 last of the MICO libraries, and all of the MICO before the non-MICO libraries: -lmicox2.3.0 -lmicocoss2.3.0 -lmico2.3.0 -lstdc++ -lreadline -lncurses -lm You don't need the readline and ncurses libraries unless you use them your- self; and dito for the `micox' and `micocoss' libraries. Finally, the stdc++ library is implicitly added by g++. So -lmico2.3.0 -lm should suffice. Frank -- + Frank Pilhofer fp@informatik.uni-frankfurt.de + | http://www.uni-frankfurt.de/~fp/ | +---- Life would be a very great deal less weird without you. - DA ----+ From roemer@inf.ethz.ch Mon Dec 6 13:45:08 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id NAA17792 for ; Mon, 6 Dec 1999 13:45:04 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id NAA00575 for ; Mon, 6 Dec 1999 13:45:03 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id NAA29034 for mico-devel-outgoing; Mon, 6 Dec 1999 13:14:03 +0100 (MET) Received: from mail1.info-com.com (ns1.info-com.com [194.130.107.25]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with SMTP id NAA29029 for ; Mon, 6 Dec 1999 13:13:57 +0100 (MET) Received: (qmail 19170 invoked from network); 6 Dec 1999 12:14:05 -0000 Received: from unknown (HELO dbell) (194.130.107.149) by ns1.info-com.com with SMTP; 6 Dec 1999 12:14:05 -0000 From: "David Bell" To: Subject: MICO: How do I make a servient? Date: Mon, 6 Dec 1999 12:14:52 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 1132 Lines: 34 Greetings all, I have written a couple of CORBA servers (call them A and B) that work fine from their own client. What I want to do is have a third (call it C) CORBA server that uses the services from A and B. I have done this by making the orb visible in the class C and using the MICO bind function: orb->bind ("IDL:A:1.0", "inet:hostname:8888"); Unfortunately this seems to cause a segv (see the gdb output - running Solaris 2.6): below here are from /usr/lib/libc.so.1 #0 0xeee5a013 in realfree() #1 0xeee4687c in cleanfree () #2 0xeee45ad8 in _malloc_unlocked () #3 0xeee459e0 in malloc () #4 0xef4e65ac in ___builtin_new (sz=16) below here are from /usr/local/mico-2.3.0/lib/libmico2.3.0.so #5 0xef51d00c in basic_string::basic_string () #6 0xef2d3cd8 in MICO::InetAddressParser::parse () #7 0xef2d05b0 in CORBA::Address::parse () #8 0xef2ec620 in CORBA::ORB::bind () #9 0xef2ec954 in CORBA::ORB::bind () Is what I am doing the right thing? Any ideas on how to make this work would be greatly appreciated. TIA Dave Bell Infocom (UK) Ltd http://www.info-com.com mailto:David.Bell@info-com.com From roemer@inf.ethz.ch Mon Dec 6 23:40:17 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id XAA25746 for ; Mon, 6 Dec 1999 23:40:13 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id XAA13683 for ; Mon, 6 Dec 1999 23:40:12 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id XAA00940 for mico-devel-outgoing; Mon, 6 Dec 1999 23:28:40 +0100 (MET) Received: from ns.ceub.edu.bo (ns.ceub.edu.bo [166.114.20.10]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id XAA00935 for ; Mon, 6 Dec 1999 23:28:33 +0100 (MET) Received: from enith.mail.ceub.edu.bo (enith.ceub.edu.bo [166.114.20.30]) by ns.ceub.edu.bo (8.8.7/8.8.7) with SMTP id SAA02334 for ; Mon, 6 Dec 1999 18:45:01 -0400 Message-Id: <3.0.6.32.19991206183508.007adda0@mail.ceub.edu.bo> X-Sender: enith@mail.ceub.edu.bo X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 06 Dec 1999 18:35:08 -0400 To: mico-devel@vsb.informatik.uni-frankfurt.de From: Enith Iriarte Caballero Subject: MICO: Compile Mico Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by diamant.vsb.informatik.uni-frankfurt.de id XAA00936 Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 310 Lines: 16 Hello I try to compile a program write in mico for WINNT and with c++. I have the Visual C++ 5.0. And the patch 3. The problem is that compiler show an error. It say that can´t find account.h library. clear.exe error. I don´t know where is that library. Could you help me please? thanks... Regards Enith From roemer@inf.ethz.ch Tue Dec 7 02:50:04 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id CAA26550 for ; Tue, 7 Dec 1999 02:50:04 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id CAA15334 for ; Tue, 7 Dec 1999 02:50:03 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id CAA01151 for mico-devel-outgoing; Tue, 7 Dec 1999 02:42:46 +0100 (MET) Received: from ygmail.kt.co.kr ([147.6.114.28]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id CAA01146 for ; Tue, 7 Dec 1999 02:42:11 +0100 (MET) Received: from kt.co.kr ([147.6.65.13]) by ygmail.kt.co.kr (8.8.8/8.8.8) with ESMTP id KAA12578 for ; Tue, 7 Dec 1999 10:45:35 +0900 (KST) Message-ID: <384C678B.46475B0@kt.co.kr> Date: Tue, 07 Dec 1999 10:48:59 +0900 From: Geunhyung Kim X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mico Development Subject: MICO: POA and Persistency Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 678 Lines: 30 Hello, Could I ask a question about POA and persistent object ? My question is that how POA support persistent object, when the POA supports ObjectId persistency. As I heard, the POA object is not persistent object and ORB is responsible of the persistency of POA object. Is that correct ? Thanks in advance I need your experty in this area. Geunhyung Kim -- - None of us is as smart as all of us - ============================================== Geunhyung Kim (ŃŃ ĐĆúű) E-mail : geunkim@kt.co.kr Tel: +82-42-870-8273 Fax: +82-42-870-8279 Research Staff Network Technology Team Telecommunication Network Lab. Korea Telecom ============================================== From roemer@inf.ethz.ch Tue Dec 7 05:01:55 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id FAA27297 for ; Tue, 7 Dec 1999 05:01:54 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id FAA16037 for ; Tue, 7 Dec 1999 05:01:54 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id EAA01255 for mico-devel-outgoing; Tue, 7 Dec 1999 04:54:05 +0100 (MET) Received: from kingcrab.informix.com (dns3.informix.com [192.147.112.7]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id EAA01250 for ; Tue, 7 Dec 1999 04:54:03 +0100 (MET) Received: from madoka.na.informix.com (madoka.na.informix.com [134.168.11.92]) by kingcrab.informix.com (8.8.5/8.7.3) with SMTP id TAA28569 for ; Mon, 6 Dec 1999 19:54:01 -0800 (PST) Received: from [134.168.9.144] by madoka.na.informix.com (NX5.67f2/NX3.0X) id AA22223; Mon, 6 Dec 99 21:54:03 -0600 Message-Id: <384C84D7.AB138C08@informix.com> Date: Mon, 06 Dec 1999 21:53:59 -0600 From: "Andrew S. Townley" X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12 i686) X-Accept-Language: en Mime-Version: 1.0 To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: MICO: Question about how to best diagnose POA problem... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 4377 Lines: 108 Hello, I am trying to figure out what's going on with a POA server I'm working on. I have an interface that will allow me to shut it down, so I wrote a simple client that just calls the interface. The problem is, I have trouble with the server crashing with the following stack trace: #0 0xffffffff in ?? () #1 0x40504c0e in MICOPOA::ObjectMap::ObjectRecord::~ObjectRecord () from /usr/local/lib/libmico2.3.0.so #2 0x4050a3b4 in MICOPOA::POA_impl::etherealize () from /usr/local/lib/libmico2.3.0.so #3 0x4050f8e2 in MICOPOA::POA_impl::destroy () from /usr/local/lib/libmico2.3.0.so #4 0x805261e in TMCServer_impl::shutdown (this=0xbffff25c) at TMCServer_impl.cpp:664 #5 0x804fd9e in TMCServer_impl::server_kill (this=0xbffff25c) at TMCServer_impl.cpp:129 #6 0x4012979e in POA_com::informix::pmd::tmc::server::TMCServer::dispatch ( this=0xbffff7e0, _req=0x80cf8e8) at tmc.cpp:19423 #7 0x4012b252 in POA_com::informix::pmd::tmc::server::TMCServer::invoke ( this=0xbffff7e0, _req=0x80cf8e8) at tmc.cpp:19626 #8 0x404fd34b in PortableServer::StaticImplementation::doinvoke () from /usr/local/lib/libmico2.3.0.so #9 0x40513a94 in MICOPOA::POA_impl::perform_invoke () from /usr/local/lib/libmico2.3.0.so #10 0x40512a2a in MICOPOA::POA_impl::local_invoke () from /usr/local/lib/libmico2.3.0.so #11 0x40512058 in MICOPOA::POA_impl::invoke () from /usr/local/lib/libmico2.3.0.so #12 0x404882d9 in CORBA::ORB::invoke_async () from /usr/local/lib/libmico2.3.0.so #13 0x404b3c64 in MICO::IIOPServer::exec_invoke_request () from /usr/local/lib/libmico2.3.0.so #14 0x404b3ec6 in MICO::IIOPServer::handle_invoke_request () from /usr/local/lib/libmico2.3.0.so #15 0x404b3931 in MICO::IIOPServer::handle_input () from /usr/local/lib/libmico2.3.0.so #16 0x404b4b3d in MICO::IIOPServer::callback () from /usr/local/lib/libmico2.3.0.so #17 0x404adc9f in MICO::GIOPConn::do_read () from /usr/local/lib/libmico2.3.0.so #18 0x404adf66 in MICO::GIOPConn::callback () from /usr/local/lib/libmico2.3.0.so #19 0x404a2ef3 in MICO::TCPTransport::callback () from /usr/local/lib/libmico2.3.0.so #20 0x4046aed5 in MICO::SelectDispatcher::handle_fevents () from /usr/local/lib/libmico2.3.0.so #21 0x4046bc1f in MICO::SelectDispatcher::run () from /usr/local/lib/libmico2.3.0.so #22 0x4048420d in CORBA::ORB::run () from /usr/local/lib/libmico2.3.0.so #23 0x804f60a in TMCServer_impl::TMCServer_impl (this=0xbffff25c, __in_chrg=1, argc=5, argv=0xbffff834) at TMCServer_impl.cpp:94 #24 0x804f016 in main (argc=5, argv=0xbffff834) at tmcd.cpp:36 Having looked at what's going on in the destructor for the ObjectRecord class, it looks like it is attempting to remove objects that no longer exist. My question is how is the best way to figure out this problem. I'm not looking for someone to do it for me, but I don't know if there happens to be an active object map dumper or something that I can use to try and figure out why it crashes. I'm reasonably sure it happens because I'm still on the upwards slope of the CORBA learning curve, but I've been fighting this for about a week now. My implementation of shutdown looks like: void shutdown() { ... poa->destroy(TRUE, TRUE); orb->shutdown(false); ... } Where I'm setting this up looks like: void initCorba(int argc, char **argv) { orb = CORBA::ORB_init(argc, argv, "mico-local-orb"); CORBA::Object_var poaobj = orb->resolve_initial_references("RootPOA"); poa = PortableServer::POA::_narrow(poaobj); PortableServer::POAManager_var mgr = poa->the_POAManager(); poa->activate_object(this); mgr->activate(); } The object is a completely self-contained server. There is only a single line of main() in the server process which is the instantiation of the object. The initCorba() method is called in the constructor and the last line of the constructor is orb->run(); Any ideas would be greatly appreciated. I'm running mico-2.3.0 on RedHat 6.0 with a 2.2.12 kernel and the standard egcs-2.91.66 19990314/Linux compiler. I can't run my server on Solaris 7 because I'm having trouble with exceptions thrown by the server to the client killing the server (another interesting question, btw). Can't figure this out either. The same code works on Linux and simple exceptions work on Solaris, so who knows. Anyway, thanks in advance for any assistance. ast From roemer@inf.ethz.ch Tue Dec 7 08:14:43 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id IAA29678 for ; Tue, 7 Dec 1999 08:14:42 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id IAA18747 for ; Tue, 7 Dec 1999 08:14:41 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id IAA01408 for mico-devel-outgoing; Tue, 7 Dec 1999 08:07:33 +0100 (MET) Received: from elch.de.uu.net (elch.de.uu.net [192.76.144.55]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id IAA01397 for ; Tue, 7 Dec 1999 08:07:31 +0100 (MET) Received: from DARTHMAUL (pec-32.au1.mg.uunet.de [149.228.22.32]) by elch.de.uu.net (5.5.5/5.5.5) with SMTP id IAA28957 for ; Tue, 7 Dec 1999 08:05:30 +0100 (MET) From: "Clemens F. Vasters, the Frogpond" To: Subject: RE: MICO: Compile Mico Date: Tue, 7 Dec 1999 08:05:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3.0.6.32.19991206183508.007adda0@mail.ceub.edu.bo> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 585 Lines: 19 -----Original Message----- From: owner-mico-devel@vsb.informatik.uni-frankfurt.de [mailto:owner-mico-devel@vsb.informatik.uni-frankfurt.de]On Behalf Of Enith Iriarte Caballero Sent: Montag, 6. Dezember 1999 23:35 To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: MICO: Compile Mico >The problem is that compiler show an error. It say that can´t find >account.h library. You need to run the IDL compiler on your IDL file before you compile w/ MSVC. The IDL compiler will create the account.h (and the accompanying account.cc implementation file) from the IDL. Cheers Clemens From roemer@inf.ethz.ch Tue Dec 7 08:14:43 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id IAA29679 for ; Tue, 7 Dec 1999 08:14:42 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id IAA18748 for ; Tue, 7 Dec 1999 08:14:41 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id IAA01410 for mico-devel-outgoing; Tue, 7 Dec 1999 08:07:33 +0100 (MET) Received: from elch.de.uu.net (elch.de.uu.net [192.76.144.55]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id IAA01399 for ; Tue, 7 Dec 1999 08:07:31 +0100 (MET) Received: from DARTHMAUL (pec-32.au1.mg.uunet.de [149.228.22.32]) by elch.de.uu.net (5.5.5/5.5.5) with SMTP id IAA28977 for ; Tue, 7 Dec 1999 08:05:32 +0100 (MET) From: "Clemens F. Vasters, the Frogpond" To: Subject: RE: MICO: POA and Persistency Date: Tue, 7 Dec 1999 08:05:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <384C678B.46475B0@kt.co.kr> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 1055 Lines: 27 -----Original Message----- From: owner-mico-devel@vsb.informatik.uni-frankfurt.de [mailto:owner-mico-devel@vsb.informatik.uni-frankfurt.de]On Behalf Of Geunhyung Kim Sent: Dienstag, 7. Dezember 1999 02:49 To: Mico Development Subject: MICO: POA and Persistency >Could I ask a question about POA and persistent object ? >My question is that how POA support persistent object, when the POA >supports ObjectId persistency. Well, the "persistent object" notion in CORBA is rather conceptual. The (arbitrary) ObjectId allows you to easily re-identify the persistent state of the object from persistent storage or any temporary caching mechanism that you built into your server. Same is valid for the other persistency facilities built into core CORBA. They allow you to load and store persistent state of stateful objects at well a defined place but will not actually take "automagic" care of the persistence your objects. Database or even flat file access is beyond the scope of an ORB specification so it isn't even supposed to do that. Cheers Clemens From roemer@inf.ethz.ch Tue Dec 7 15:37:21 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id PAA03342 for ; Tue, 7 Dec 1999 15:37:21 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id PAA29323 for ; Tue, 7 Dec 1999 15:37:20 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id PAA03503 for mico-devel-outgoing; Tue, 7 Dec 1999 15:12:04 +0100 (MET) Received: from faust27-s.rz.uni-frankfurt.de (faust27-s.rz.uni-frankfurt.de [141.2.149.151]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with SMTP id PAA03498 for ; Tue, 7 Dec 1999 15:12:03 +0100 (MET) Received: from rose.fpx.de (actually NAFp2-089.rz.uni-frankfurt.de) by faust27-eth.rz.uni-frankfurt.de with Local SMTP (PP); Tue, 7 Dec 1999 15:11:49 +0000 Received: (from fp@localhost) by rose.fpx.de (8.8.5/8.8.5) id MAA00395 for mico-devel@vsb.informatik.uni-frankfurt.de; Tue, 7 Dec 1999 12:30:52 +0100 Date: Tue, 7 Dec 1999 12:30:52 +0100 From: Frank Pilhofer To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: Re: MICO: Question about how to best diagnose POA problem... Message-ID: <19991207123052.B294@rose.fpx.de> Mail-Followup-To: mico-devel@vsb.informatik.uni-frankfurt.de References: <384C84D7.AB138C08@informix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <384C84D7.AB138C08@informix.com>; from Andrew S. Townley on Mon, Dec 06, 1999 at 09:53:59PM -0600 Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 1592 Lines: 37 On Mon, Dec 06, 1999 at 09:53:59PM -0600, Andrew S. Townley wrote: > > #1 0x40504c0e in MICOPOA::ObjectMap::ObjectRecord::~ObjectRecord () > from /usr/local/lib/libmico2.3.0.so > > Having looked at what's going on in the destructor for the ObjectRecord > class, it looks like it is attempting to remove objects that no longer > exist. My question is how is the best way to figure out this problem. > This sounds like a problem I was once having with server shutdown. The ObjectRecord destructor decrements the servant's reference count, which must of course happen as long as the servant still exists. The problem is caused by the transition from CORBA 2.2 to 2.3. In 2.2, servant memory management was entirely up to the user, while in 2.3, servants _may_ be reference counted, while non-reference counted servants are still supported. In short, you must make sure that the servant is not deleted until the ActiveObjectMap is destructed. Alternatively, and this is my suggestion, you can use reference-counted servants yourself. See the `Reference Counting' section in the docs. > > I can't run my server on Solaris 7 because I'm > having trouble with exceptions thrown by the server to the client > killing the server (another interesting question, btw). > Interesting, indeed. Let us know if you figure out anything. Frank -- + Frank Pilhofer fp@informatik.uni-frankfurt.de + | http://www.uni-frankfurt.de/~fp/ | +---- Life would be a very great deal less weird without you. - DA ----+ From roemer@inf.ethz.ch Tue Dec 7 15:37:25 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id PAA03352 for ; Tue, 7 Dec 1999 15:37:25 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id PAA29327 for ; Tue, 7 Dec 1999 15:37:25 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id PAA03576 for mico-devel-outgoing; Tue, 7 Dec 1999 15:32:55 +0100 (MET) Received: from pss201.psi.ch (pss201.psi.ch [129.129.40.201]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with SMTP id PAA03571 for ; Tue, 7 Dec 1999 15:32:53 +0100 (MET) Received: from psi11.psi.ch by pss201.psi.ch; Tue, 7 Dec 99 15:32:52 +0100 Received: from pc2251.psi.ch ([129.129.79.1]) by psi13.psi.ch with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id YBS8J7NC; Tue, 7 Dec 1999 15:32:51 +0100 Date: Tue, 7 Dec 1999 15:32:50 +0100 (MET) From: Jan Chrin To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: MICO: CDR Data Alignment Offsets Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 1041 Lines: 37 Dear All, Further to the email from Michael Boege regarding wrong padding of data types with 8 byte boundaries (JavaOrb-Mico Event Service Interoperability, Fri. Dec 3 11:43). We have observed that when implementing the MICO Event Daemon (eventd) through the MICO Daemon (micod), the alignment offset for IDL types such as "long long" and "double" is wrong by 4 bytes. This misalignment is not however evident when the Event Daemon is started independently i.e. without the connection to micod. We suspect that this is related to the redefinition of the boundary conditions from IIOP 1.0 to IIOP 1.2 (?) Can this misalignment be understood? Would welcome your input. With Thanks, *==Jan Chrin=====================================================* | SLS Beam Dynamics Tel: +41 (0)56 310 2930 | | Paul Scherrer Institut Fax: +41 (0)56 310 3151 | | CH-5232 Villigen PSI Email: Jan.Chrin@psi.ch | *================================================================* From roemer@inf.ethz.ch Tue Dec 7 22:39:13 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id WAA06683 for ; Tue, 7 Dec 1999 22:39:13 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id WAA06210 for ; Tue, 7 Dec 1999 22:39:12 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id WAA04788 for mico-devel-outgoing; Tue, 7 Dec 1999 22:30:17 +0100 (MET) Received: from kingcrab.informix.com (dns3.informix.com [192.147.112.7]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id WAA04783 for ; Tue, 7 Dec 1999 22:30:15 +0100 (MET) Received: from madoka.na.informix.com (madoka.na.informix.com [134.168.11.92]) by kingcrab.informix.com (8.8.5/8.7.3) with SMTP id NAA18981 for ; Tue, 7 Dec 1999 13:30:00 -0800 (PST) Received: from [134.168.9.194] by madoka.na.informix.com (NX5.67f2/NX3.0X) id AA27793; Tue, 7 Dec 99 15:30:00 -0600 Message-Id: <384D7C55.AA029463@informix.com> Date: Tue, 07 Dec 1999 15:29:57 -0600 From: "Andrew S. Townley" X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12 i686) X-Accept-Language: en Mime-Version: 1.0 To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: MICO: Getting client IP address? References: <384C84D7.AB138C08@informix.com> <19991207123052.B294@rose.fpx.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 748 Lines: 29 Hello, I was wondering if there was a good way to get the client's IP address from inside a server method implementation. I looked at MICO's Interceptor mechanism, but it doesn't seem to fit the bill. What I would like to do is something like: interface blah { void foo(); }; and inside blah_impl::foo() { ... cout << "connection from client" << addr << endl; ... } The reason that Interceptors don't look like they are going to work is because I need to be able to store the IP address from within the implementation of foo(). I know that the Address structure exists at the transport layer, but I couldn't find any information about how to get access of the information within the implementation of a method. Thanks in advance, ast From roemer@inf.ethz.ch Wed Dec 8 00:40:09 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id AAA07371 for ; Wed, 8 Dec 1999 00:40:08 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id AAA10341 for ; Wed, 8 Dec 1999 00:40:08 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id AAA05083 for mico-devel-outgoing; Wed, 8 Dec 1999 00:33:21 +0100 (MET) Received: from falcon.agai.com ([207.12.176.225]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id AAA05078 for ; Wed, 8 Dec 1999 00:33:05 +0100 (MET) Received: by falcon.local.agai.com with Internet Mail Service (5.5.2232.9) id ; Tue, 7 Dec 1999 15:32:22 -0800 Message-ID: <111935D98C50D111818400805FCB33870125CB17@falcon.local.agai.com> From: Huey Tran Vo To: "'mico-devel@vsb.informatik.uni-frankfurt.de'" Subject: MICO: Semaphores and MICO Date: Tue, 7 Dec 1999 15:32:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 1520 Lines: 39 Hi, I am trying to compile a MICO server using MS VC++ 5.0 (SP3) on NT. This server uses CSemaphore and CMutex so I include the include file afxmt.h. However, during the link phase, I got several "already defined" and "unresolved external symbols" errors. The MFC library it indicated is nafxcw.lib. Below is the build result. Linking... nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already defined in mico230.lib(mico230.dll) nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in mico230.lib(mico230.dll) LINK : warning LNK4098: defaultlib "msvcrtd.lib" conflicts with use of other libs; use /NODEFAULTLIB:library nafxcwd.lib(timecore.obj) : error LNK2001: unresolved external symbol __mbctype nafxcwd.lib(apphelp.obj) : error LNK2001: unresolved external symbol __mbctype nafxcwd.lib(strex.obj) : error LNK2001: unresolved external symbol __mbctype nafxcwd.lib(filelist.obj) : error LNK2001: unresolved external symbol __mbctype nafxcwd.lib(appcore.obj) : error LNK2001: unresolved external symbol ___argv nafxcwd.lib(appcore.obj) : error LNK2001: unresolved external symbol ___argc Debug/AlarmService.exe : fatal error LNK1120: 3 unresolved externals Error executing link.exe. AlarmService.exe - 9 error(s), 1 warning(s) Has anyone experienced similar problems and know how to resolve these errors? I would appreciate any help. Thanks in advance, Huey T. Vo Email: huey.vo@steag-rtp-us.com From roemer@inf.ethz.ch Wed Dec 8 02:30:53 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id CAA07997 for ; Wed, 8 Dec 1999 02:30:53 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id CAA11184 for ; Wed, 8 Dec 1999 02:30:52 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id CAA05211 for mico-devel-outgoing; Wed, 8 Dec 1999 02:23:44 +0100 (MET) Received: from csmd2.cs.uni-magdeburg.de (csmd2.CS.Uni-Magdeburg.De [141.44.22.2]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id CAA05206 for ; Wed, 8 Dec 1999 02:23:43 +0100 (MET) Received: from espe.cs.uni-magdeburg.de (aschultz@espe [141.44.21.16]) by csmd2.cs.uni-magdeburg.de (8.9.1a/8.9.1) with ESMTP id CAA24931 for ; Wed, 8 Dec 1999 02:23:42 +0100 (MET) Received: from localhost (aschultz@localhost) by espe.cs.uni-magdeburg.de (8.8.8+Sun/8.8.8) with SMTP id CAA12285 for ; Wed, 8 Dec 1999 02:22:13 +0100 (MET) X-Authentication-Warning: espe.cs.uni-magdeburg.de: aschultz owned process doing -bs Date: Wed, 8 Dec 1999 02:22:13 +0100 (MET) From: Andreas Schultz X-Sender: aschultz@espe To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: Re: MICO: CDR Data Alignment Offsets In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO X-Status: A Content-Length: 1912 Lines: 51 Hi, On Tue, 7 Dec 1999, Jan Chrin wrote: > Dear All, > > Further to the email from Michael Boege regarding wrong > padding of data types with 8 byte boundaries (JavaOrb-Mico > Event Service Interoperability, Fri. Dec 3 11:43). > > We have observed that when implementing the MICO Event > Daemon (eventd) through the MICO Daemon (micod), the alignment > offset for IDL types such as "long long" and "double" is wrong > by 4 bytes. > > This misalignment is not however evident when the Event > Daemon is started independently i.e. without the connection to > micod. I belive i have a clue whats going on here, maybe Kay can confirm it. MICO will never by itself start a GIOP 1.2 connection. It always uses what the client presents. What happens in your case is, that the JavaORB client has a GIOP 1.2 connection to micod, but micod uses a GIOP 1.0 connection to the Event Daemon. GIOP 1.0 uses diffrent alignment rules, so micod would have to realign everything. That would require some kind of demarshaling/marshaling sequence. I believe that the request object (probably a ORBRequest) is only copied beetwenn the two connection, without the nesesary realignment. You might want to try micod's --forward parameter. That should fix your problem for the moment. > > We suspect that this is related to the redefinition of the > boundary conditions from IIOP 1.0 to IIOP 1.2 (?) > > Can this misalignment be understood? Would welcome your > input. > > With Thanks, > > > *==Jan Chrin=====================================================* > | SLS Beam Dynamics Tel: +41 (0)56 310 2930 | > | Paul Scherrer Institut Fax: +41 (0)56 310 3151 | > | CH-5232 Villigen PSI Email: Jan.Chrin@psi.ch | > *================================================================* -- Andreas Schultz Student of computer science From roemer@inf.ethz.ch Wed Dec 8 09:07:31 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id JAA10939 for ; Wed, 8 Dec 1999 09:07:31 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id JAA15548 for ; Wed, 8 Dec 1999 09:07:30 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id IAA05544 for mico-devel-outgoing; Wed, 8 Dec 1999 08:57:36 +0100 (MET) Received: from Shannon.ee.wits.ac.za (shannon.ee.wits.ac.za [146.141.16.134]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id IAA05539 for ; Wed, 8 Dec 1999 08:57:31 +0100 (MET) Received: from myrrh (myrrh.ee.wits.ac.za [146.141.16.196]) by Shannon.ee.wits.ac.za (8.9.1a/8.9.1) with SMTP id JAA18632 for ; Wed, 8 Dec 1999 09:57:32 +0200 Message-ID: <001201bf4153$62574240$c4108d92@ee.wits.ac.za> From: "John Sperryn" To: References: <384C84D7.AB138C08@informix.com> <19991207123052.B294@rose.fpx.de> <384D7C55.AA029463@informix.com> Subject: Re: MICO: Getting client IP address? Date: Wed, 8 Dec 1999 10:08:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 1684 Lines: 60 > I was wondering if there was a good way to get the client's IP address > from inside a server method implementation. I looked at MICO's > Interceptor mechanism, but it doesn't seem to fit the bill. What I > would like to do is something like: > > interface blah > { > void foo(); > }; > > and inside blah_impl::foo() > { > ... > cout << "connection from client" << addr << endl; > ... > } > > The reason that Interceptors don't look like they are going to work is > because I need to be able to store the IP address from within the > implementation of foo(). I know that the Address structure exists at > the transport layer, but I couldn't find any information about how to > get access of the information within the implementation of a method. Hi Andrew, If you create a class like // some of this code comes from the demo/interceptor/server.cc file class MyConnInterceptor : public Interceptor::ConnInterceptor{ public: blah_impl *blah; MyConnInterceptor (blah_impl parent) { blah = &parent; }; Interceptor::Status client_connect (const char *addr) { /* * called whenever a new connection is opened from * a client to this server */ blah->setServer(addr); cout << "server: connect from: " << addr << endl; return Interceptor::INVOKE_CONTINUE; } ... ... } // end class MyConnInterceptor Otherwise, create a public variable char *serverIP in the MyConnInterceptor class that the the Interceptor client_connect method will set, and blah_impl can access from within it's foo() method. Does this help at all? Please forgive any dodgy syntax errors in my code - it's early (for me) :) Cheers, John. From roemer@inf.ethz.ch Wed Dec 8 12:17:29 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id MAA13293 for ; Wed, 8 Dec 1999 12:17:29 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id MAA19090 for ; Wed, 8 Dec 1999 12:17:28 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id MAA06072 for mico-devel-outgoing; Wed, 8 Dec 1999 12:09:10 +0100 (MET) Received: from ns2.kdt.de (ns2.kdt.de [195.8.224.2]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id MAA06067 for ; Wed, 8 Dec 1999 12:09:09 +0100 (MET) Received: from gateway.petig.de (line0050lf.kdt.de [195.8.241.50]) by ns2.kdt.de (8.8.8/8.8.8) with ESMTP id MAA23261 for ; Wed, 8 Dec 1999 12:09:09 +0100 Received: from wtal.de (christof@[192.168.230.9]) by gateway (8.8.8/8.8.8) with ESMTP id MAA03142 for ; Wed, 8 Dec 1999 12:07:52 +0100 Message-ID: <384E3BFB.6E83F65E@wtal.de> Date: Wed, 08 Dec 1999 12:07:39 +0100 From: Christof Petig Organization: Adolf Petig GmbH. & Co. KG X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.7 i586) X-Accept-Language: de MIME-Version: 1.0 To: Mico Development List Subject: MICO: eventd crashes on push_comsumer's exit ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 417 Lines: 15 ... if you forget to call disconnect_push_supplier() (exception thrown but not catched). Mico Version 2.3.0 (bug already present in 2.2.x) Apart from beeing annoying unless you know what you have to fix (the naming of event service methods is IMHO not very intuitive), this really hurts in production environments. Regards Christof PS: Is there any way to get access to current sources via CVS or a snapshot? From roemer@inf.ethz.ch Wed Dec 8 13:59:38 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id NAA14245 for ; Wed, 8 Dec 1999 13:59:37 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id NAA20729 for ; Wed, 8 Dec 1999 13:59:37 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id NAA06677 for mico-devel-outgoing; Wed, 8 Dec 1999 13:52:42 +0100 (MET) Received: from mail-relay-delhi.ernet.in (mail-relay-delhi.ernet.in [202.41.100.92]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id NAA06672 for ; Wed, 8 Dec 1999 13:52:33 +0100 (MET) Received: from uucp-relay-delhi.ernet.in (vikram [202.41.100.90]) by mail-relay-delhi.ernet.in (8.9.0/8.9.0) with SMTP id SAA00074 for ; Wed, 8 Dec 1999 18:09:19 -0500 (GMT) Received: from cdotd.UUCP by uucp-relay-delhi.ernet.in (4.1/SMI-4.1-MHS-7.0) id AA27867; Wed, 8 Dec 99 18:26:44+050 Received: from moon.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id OAA25079; Wed, 8 Dec 1999 14:45:05 -0500 Received: from cdotd.ernet.in by moon.cdotd.ernet.in (8.8.8/1.1.10.5/27Oct98-0333PM) id OAA07100; Wed, 8 Dec 1999 14:31:25 +0500 (GMT+0500) Message-Id: <384E256C.9E4A3AF2@cdotd.ernet.in> Date: Wed, 08 Dec 1999 14:31:24 +0500 From: raja sekhar akurathi Organization: cdot X-Mailer: Mozilla 4.5 [en] (X11; I; OSF1 V4.0 alpha) X-Accept-Language: en Mime-Version: 1.0 To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: MICO: A newbie question!! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO X-Status: A Content-Length: 1263 Lines: 41 Hello, I am relatively new to MICO. Only recently got MICO2.3 running. I am able to write some applications in MICO using C++. Now, I want to use Java and C++. Server in C++ and client in Java. My problem is the machine on which MICO is running and the java m/c are different. I generated a ObjRef in string form and transfered it to java m/c. The client now converts the string into ObjRef and tries to contact the server. Here the client throws exception saying communication failure. From java m/c I can telnet to the MICO m/c using IP address but not using machine name. NIS is not visible on Java side. Does MICO stores the IP address in ObjeRef or Machine name? In case MICO uses m/c name, can we configure MICO to use IP address in ObjRef? Thanks in adv. -- with regards, Raja Sekhar ------------------------------------------------------------------------ A. RAJA SEKHAR Office: Research Engineer +91-11-4677525 extn. 324 ATM Group C-DOT, Akbar Chanakyapuri, New Delhi Fax: INDIA-110021. +91-11-6885558 Emails: rsekhar@cdotd.ernet.in raja045@yahoo.com ------------------------------------------------------------------------- From roemer@inf.ethz.ch Wed Dec 8 14:44:25 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id OAA14650 for ; Wed, 8 Dec 1999 14:44:24 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id OAA21600 for ; Wed, 8 Dec 1999 14:44:24 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id OAA07149 for mico-devel-outgoing; Wed, 8 Dec 1999 14:38:02 +0100 (MET) Received: from alphatech.com (erebus.alphatech.com [198.112.236.2]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id OAA07144 for ; Wed, 8 Dec 1999 14:38:00 +0100 (MET) Received: from venus.alphatech.com (fw-ext.alphatech.com [198.112.236.6]) by alphatech.com (8.8.8/8.8.8) with SMTP id IAA15986 for ; Wed, 8 Dec 1999 08:35:51 -0500 (EST) Received: from winpioch by venus.alphatech.com (SMI-8.6/SMI-4.1) id IAA18185; Wed, 8 Dec 1999 08:38:20 -0500 Message-Id: <4.2.0.58.19991208083254.00a745c0@mail.alphatech.com> X-Sender: npioch@mail.alphatech.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 08 Dec 1999 08:37:23 -0500 To: mico-devel@vsb.informatik.uni-frankfurt.de From: Nick Pioch Subject: MICO: micod and idl crash Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 310 Lines: 10 I compiled mico-2.3.0 on Solaris 2.5.1 successfully using g++ 2.8.1, but I get a seg fault when I try to run micod or idl. Any suggestions? ------------------------------------------------------------------------------- Nicholas J. Pioch Alphatech, Inc. 50 Mall Rd. Burlington, MA 01803 781-273-3388 x379 From roemer@inf.ethz.ch Wed Dec 8 16:50:53 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id QAA15983 for ; Wed, 8 Dec 1999 16:50:53 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id QAA24521 for ; Wed, 8 Dec 1999 16:50:52 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id QAA07556 for mico-devel-outgoing; Wed, 8 Dec 1999 16:35:18 +0100 (MET) Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id QAA07551 for ; Wed, 8 Dec 1999 16:35:16 +0100 (MET) Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA13777 for ; Wed, 8 Dec 1999 10:35:15 -0500 (EST) Received: from mltsa.uk.lucent.com (h135-86-161-17.lucent.com [135.86.161.17]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA13739 for ; Wed, 8 Dec 1999 10:35:14 -0500 (EST) Received: by mltsa.uk.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA13422; Wed, 8 Dec 1999 15:35:00 GMT To: "mico-devel@vsb.informatik.uni-frankfurt.de" Received: from lucent.com by mltsa.uk.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA13410; Wed, 8 Dec 1999 15:34:59 GMT Message-ID: <384E7AA3.D1F7E441@lucent.com> Date: Wed, 08 Dec 1999 15:34:59 +0000 From: claire fisher Organization: Lucent Technologies X-Mailer: Mozilla 4.6C-CCK-MCD EMS-1.4 [en] (X11; I; HP-UX B.10.20 9000/778) X-Accept-Language: en MIME-Version: 1.0 Original-To: "mico-devel@vsb.informatik.uni-frankfurt.de" Subject: MICO: TclMico and Orbix. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 694 Lines: 40 Hi, I hope someone can point out where I am going wrong. I am using Orbix 2.3c server & TclMico 0.5c client (with Mico 2.3.0) So far the steps are: 1. write the orbix naming service IOR to file 2. initialise mico with the -ORBNamingIOR option. 3. resolve_initial_references to the name service. 4. then resolve the object: set obj [$nsobj resolve {{id "name" kind ""}}] This seems to work ok. Then when I try to access that interface with; $obj do_whatever I get a segmentation fault: - CORBA::ORB::get_iface (). Is the above right? NOTE: The idl is something like: module nameA { interface nameB { short do_whatever(); }; }; Thank you in advance Claire From roemer@inf.ethz.ch Wed Dec 8 16:53:22 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id QAA16005 for ; Wed, 8 Dec 1999 16:53:21 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id QAA24590 for ; Wed, 8 Dec 1999 16:53:21 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id QAA07620 for mico-devel-outgoing; Wed, 8 Dec 1999 16:47:11 +0100 (MET) Received: from kingcrab.informix.com (dns3.informix.com [192.147.112.7]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id QAA07615 for ; Wed, 8 Dec 1999 16:47:09 +0100 (MET) Received: from madoka.na.informix.com (madoka.na.informix.com [134.168.11.92]) by kingcrab.informix.com (8.8.5/8.7.3) with SMTP id HAA09346 for ; Wed, 8 Dec 1999 07:47:07 -0800 (PST) Received: from ppp_7.na.informix.com by madoka.na.informix.com (NX5.67f2/NX3.0X) id AA03740; Wed, 8 Dec 99 09:47:06 -0600 Message-Id: <384E7D78.486D7A31@informix.com> Date: Wed, 08 Dec 1999 09:47:04 -0600 From: "Andrew S. Townley" X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12 i686) X-Accept-Language: en Mime-Version: 1.0 To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: Re: MICO: Getting client IP address? References: <384C84D7.AB138C08@informix.com> <19991207123052.B294@rose.fpx.de> <384D7C55.AA029463@informix.com> <001201bf4153$62574240$c4108d92@ee.wits.ac.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 2431 Lines: 71 John, Thanks for the reply. My concern about this solution is a potential race condition if two clients are trying to call the server's foo() method at the same time. Potentially, since you're determining the client's address outside of the foo() method, by the time the foo() method gets called, the value of the IP address received from the client_connect() method gets thwacked. Client1 connect, ip = xxx.xxx.xxx.xxx Client2 connect, ip = yyy.yyy.yyy.yyy Client1 foo(), reports bogus IP (yyy.yyy.yyy.yyy) Since the IP information is kinda critical for tracking within the server, I need to make sure that the IP recorded really belongs to the client calling the methods. Maybe it isn't that big an issue since the current MICO is single threaded, but when the MT support is available, it could be a real problem. I'd have to do some serious testing to make sure that the data integrity wouldn't get messed up. I could have the client's IP passed in, but if it is possible to get it from CORBA it would definitely be better since I don't want someone playing games with DII :). I'll investigate it some. It may be "good enough" for now, but I'd still prefer a way to get the address from within the method proper. Thanks again for the suggestion. ast John Sperryn wrote: > > > I was wondering if there was a good way to get the client's IP address > > from inside a server method implementation. [snip] > > Hi Andrew, > > If you create a class like > > // some of this code comes from the demo/interceptor/server.cc file > class MyConnInterceptor : public Interceptor::ConnInterceptor{ > public: > blah_impl *blah; > MyConnInterceptor (blah_impl parent) > { > blah = &parent; > }; > Interceptor::Status client_connect (const char *addr) > { > /* > * called whenever a new connection is opened from > * a client to this server > */ > blah->setServer(addr); > cout << "server: connect from: " << addr << endl; > return Interceptor::INVOKE_CONTINUE; > } > ... > ... > } // end class MyConnInterceptor > > Otherwise, create a public variable char *serverIP in the MyConnInterceptor > class that the the Interceptor client_connect method will set, and blah_impl > can access from within it's foo() method. > > Does this help at all? > Please forgive any dodgy syntax errors in my code - it's early (for me) :) > > Cheers, > > John. From roemer@inf.ethz.ch Wed Dec 8 17:21:30 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id RAA16274 for ; Wed, 8 Dec 1999 17:21:29 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id RAA25149 for ; Wed, 8 Dec 1999 17:21:29 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id RAA07783 for mico-devel-outgoing; Wed, 8 Dec 1999 17:14:17 +0100 (MET) Received: from kla-tencor.com (mail01.kla-tencor.com [206.67.220.38]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id RAA07778 for ; Wed, 8 Dec 1999 17:14:15 +0100 (MET) Received: from jedi.kla-tencor.com (jedi.kla-tencor.com [172.20.125.84]) by kla-tencor.com (8.9.1b+Sun/KLAC-1.0i) with ESMTP id IAA07266 for ; Wed, 8 Dec 1999 08:14:13 -0800 (PST) Received: from localhost (yucao@localhost) by jedi.kla-tencor.com (8.9.1b+Sun/8.9.1) with SMTP id IAA10811 for ; Wed, 8 Dec 1999 08:11:27 -0800 (PST) X-Authentication-Warning: jedi.kla-tencor.com: yucao owned process doing -bs Date: Wed, 8 Dec 1999 08:11:26 -0800 (PST) From: Yu Cao X-Sender: yucao@jedi.kla-tencor.com To: Mico Development List Subject: Re: MICO: eventd crashes on push_comsumer's exit ... In-Reply-To: <384E3BFB.6E83F65E@wtal.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 852 Lines: 29 I remember we saw this problem for MICO 2.2.x, but I think some fixes were put into 2.3.0 and this is no longer happening for our application. Either that or we changed our code to always call disconnect_push_supplier() ... will have to check. In any case, I'd be interested in seeing a small example that demonstrates the problem (for 2.3.0). --Yu Cao On Wed, 8 Dec 1999, Christof Petig wrote: > ... if you forget to call disconnect_push_supplier() > > (exception thrown but not catched). > > Mico Version 2.3.0 (bug already present in 2.2.x) > > Apart from beeing annoying unless you know what you have to fix (the > naming of event service methods is IMHO not very intuitive), this really > hurts in production environments. > > Regards > Christof > > PS: Is there any way to get access to current sources via CVS or a > snapshot? > > From roemer@inf.ethz.ch Wed Dec 8 17:42:20 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id RAA16425 for ; Wed, 8 Dec 1999 17:42:19 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id RAA25500 for ; Wed, 8 Dec 1999 17:42:19 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id RAA08289 for mico-devel-outgoing; Wed, 8 Dec 1999 17:35:24 +0100 (MET) Received: from mdfactory.de ([194.175.113.15]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id RAA08284 for ; Wed, 8 Dec 1999 17:35:21 +0100 (MET) Received: from JU ([172.24.41.26]) by mdfactory.de (8.9.3/8.8.8) with SMTP id RAA04406 for ; Wed, 8 Dec 1999 17:35:53 +0100 (MET) Received: by JU with Microsoft Mail id <01BF41A2.1D303830@JU>; Wed, 8 Dec 1999 17:31:51 -0000 Message-ID: <01BF41A2.1D303830@JU> From: Jasper Ullrich To: "'mico mailing list'" Subject: MICO: A newbie question!! Date: Wed, 8 Dec 1999 17:31:50 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 708 Lines: 21 >> Does MICO stores the IP address in ObjeRef or Machine name?In case MICO uses m/c name, can we configure MICO to use IP address inObjRef? We had a similar problem. To solve the problem: install a DNS server or edit the /etc/host at the java-client and add the ip-address / name mapping or start your corba server with ORBIIOPAddr inet:xxx.xxx.xxx.xxx:pppp where xxx.xxx.xxx.xxx:pppp is in doted form and remove all mappings with above ip-address in the etc/host at the server-machine ( mico will/could not modify the ip-address if the mapping is absent) hope this helps jasper Jasper Ullrich MD FACTORY Bayerstrasse 21 80335 Muenchen mailto:jasper.ullrich@mdfactory.de http://www.mdfactory.de From roemer@inf.ethz.ch Wed Dec 8 18:27:42 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id SAA17254 for ; Wed, 8 Dec 1999 18:27:37 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id SAA26658 for ; Wed, 8 Dec 1999 18:27:36 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id SAA08407 for mico-devel-outgoing; Wed, 8 Dec 1999 18:16:19 +0100 (MET) Received: from ceibo.entelnet.bo (ceibo.entelnet.bo [166.114.10.11]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id SAA08402 for ; Wed, 8 Dec 1999 18:16:17 +0100 (MET) Received: from Marcelo ([166.114.7.231]) by ceibo.entelnet.bo (8.9.3/8.9.3) with SMTP id NAA22022 for ; Wed, 8 Dec 1999 13:15:23 -0400 (SAT) Message-Id: <3.0.6.32.19991208131602.007d0de0@mail.ceub.edu.bo> X-Sender: enith@mail.ceub.edu.bo (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 08 Dec 1999 13:16:02 -0800 To: mico-devel@vsb.informatik.uni-frankfurt.de From: Enith Iriarte Subject: MICO: compile mico Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by diamant.vsb.informatik.uni-frankfurt.de id SAA08403 Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 370 Lines: 18 Hello: I am trying to compile a MICO server using MS VC++ 5.0 (SP3) on NT. However, during the link phase, I got account.h library is missing clear.exe error.... Some nice boy told me that I need to compile the IDL first, I don´t know how to do it. I read the papers related with mico. But anything about compile IDL. Could you help me? Thanks in advance. Enith From roemer@inf.ethz.ch Wed Dec 8 18:33:30 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id SAA17361 for ; Wed, 8 Dec 1999 18:33:30 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id SAA26761 for ; Wed, 8 Dec 1999 18:33:29 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id SAA08455 for mico-devel-outgoing; Wed, 8 Dec 1999 18:30:28 +0100 (MET) Received: from gatekeeper.tripos.com (gatekeeper.tripos.com [192.160.145.62]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with SMTP id SAA08450 for ; Wed, 8 Dec 1999 18:30:26 +0100 (MET) Received: (from uucp@localhost) by tripos.com (SMI-8.6) id LAA07920 for <@firewall.tripos.com:mico-devel@vsb.informatik.uni-frankfurt.de>; Wed, 8 Dec 1999 11:30:25 -0600 Received: from unknown(172.20.5.15) by gatekeeper.tripos.com via smap (V5.0) id xma007823; Wed, 8 Dec 99 11:29:34 -0600 Received: from etamin (etamin [172.20.5.104]) by tripos.com (980919.SGI.STAND) via SMTP id LAA86882 for ; Wed, 8 Dec 1999 11:29:33 -0600 (CST) Message-ID: <000a01bf41a1$cb1515c0$680514ac@tripos.com> From: "David Dunn" To: "MICO Development" Subject: MICO: Handeling Windows and MICO events Date: Wed, 8 Dec 1999 11:29:33 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01BF416F.803140B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 1797 Lines: 55 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01BF416F.803140B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I searched the archive for help on this, but didn't find it. Sorry if its a repeat. Using the MICO 2.3.0 is there a way to implement a Windows MFC application that is both a CORBA client and server? The Windows application would pass a reference to an object it implements to another CORBA object as a parameter. The other object would use the passed reference to access and modify the object servered by the NT application. We would prefer not to have the GUI blocked. I think I understand how it would be done using a multithreaded ORB. I don't know if it can be done with MICO 2.3.0. I noticed the dispatcher example for Qt and X11. Can dispatcher be used with Windows/MFC? Another possibility might be to use the non blocking event interface to the ORB (i.e. work_pending...). Are there any examples of this? Any help or pointers would be a great help. I know MICO-MT is coming but... Thanks, David ------=_NextPart_000_0007_01BF416F.803140B0 Content-Type: text/x-vcard; name="David Dunn.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="David Dunn.vcf" BEGIN:VCARD VERSION:2.1 N:Dunn;David FN:David Dunn NICKNAME:dunn ORG:Tripos Inc. TITLE:Director, New Technology TEL;WORK;VOICE:314.647.1099 TEL;WORK;FAX:314.647.9241 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Tripos Inc.=3D0D=3D0A1699 S. = Hanley Rd.;St. Louis;MO;63144;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Tripos Inc.=3D0D=3D0A1699 S. = Hanley Rd.=3D0D=3D0ASt. Louis, MO 63144=3D0D=3D0AUSA EMAIL;PREF;INTERNET:dunn@tripos.com REV:19991208T172933Z END:VCARD ------=_NextPart_000_0007_01BF416F.803140B0-- From roemer@inf.ethz.ch Wed Dec 8 19:27:43 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id TAA18736 for ; Wed, 8 Dec 1999 19:27:42 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id TAA28531 for ; Wed, 8 Dec 1999 19:27:41 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id TAA08548 for mico-devel-outgoing; Wed, 8 Dec 1999 19:22:32 +0100 (MET) Received: from jackt.dialupdns.com (modemcable214.35-200-24.mtl.mc.videotron.net [24.200.35.214]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id TAA08543 for ; Wed, 8 Dec 1999 19:22:30 +0100 (MET) Received: (from jackt@localhost) by jackt.dialupdns.com (8.9.3/8.9.3) id NAA01347 for mico-devel@vsb.informatik.uni-frankfurt.de; Wed, 8 Dec 1999 13:27:07 -0500 Message-Id: <199912081827.NAA01347@jackt.dialupdns.com> Date: Wed, 8 Dec 1999 18:27:07 +0000 (GMT) To: mico-devel@vsb.informatik.uni-frankfurt.de From: jackt@gel.ulaval.ca Subject: Re[2]: MICO: Getting client IP address? In-Reply-To: <384E7D78.486D7A31@informix.com> X-Mailer: Ishmail 1.3.3-990123-linux MIME-Version: 1.0 Content-Type: text/plain Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 1450 Lines: 32 "Andrew S. Townley" wrote: > John, > > Thanks for the reply. My concern about this solution is a potential > race condition if two clients are trying to call the server's foo() > method at the same time. Potentially, since you're determining the > client's address outside of the foo() method, by the time the foo() > method gets called, the value of the IP address received from the > client_connect() method gets thwacked. > > Client1 connect, ip = xxx.xxx.xxx.xxx > Client2 connect, ip = yyy.yyy.yyy.yyy > Client1 foo(), reports bogus IP (yyy.yyy.yyy.yyy) > > Since the IP information is kinda critical for tracking within the > server, I need to make sure that the IP recorded really belongs to the > client calling the methods. Maybe it isn't that big an issue since the > current MICO is single threaded, but when the MT support is available, > it could be a real problem. I'd have to do some serious testing to make > sure that the data integrity wouldn't get messed up. I could have the > client's IP passed in, but if it is possible to get it from CORBA it > would definitely be better since I don't want someone playing games with > DII :). > This could be detected by your Interceptor since you can have access to the request before the call is mapped through the server. You can raise an exception if the client tried to fool the server or simply fix the address in the request's arguments. JT From roemer@inf.ethz.ch Wed Dec 8 22:04:20 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id WAA20621 for ; Wed, 8 Dec 1999 22:04:20 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id WAA27811 for ; Wed, 8 Dec 1999 22:04:18 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id VAA08786 for mico-devel-outgoing; Wed, 8 Dec 1999 21:57:36 +0100 (MET) Received: from mdfactory.de ([194.175.113.15]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id VAA08781 for ; Wed, 8 Dec 1999 21:57:34 +0100 (MET) Received: from JU ([172.24.41.26]) by mdfactory.de (8.9.3/8.8.8) with SMTP id VAA05243 for ; Wed, 8 Dec 1999 21:58:16 +0100 (MET) Received: by JU with Microsoft Mail id <01BF41C6.C134DB60@JU>; Wed, 8 Dec 1999 21:54:09 -0000 Message-ID: <01BF41C6.C134DB60@JU> From: Jasper Ullrich To: "'mico mailing list'" Subject: MICO: poa_impl.cc patch Date: Wed, 8 Dec 1999 21:54:07 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 246 Lines: 15 hello mico dev, in your mico-2.3.0-1.diffs you forgot the patch that fixes the handling of '/' in objectKeys !! Ciao Jasper Jasper Ullrich MD FACTORY Bayerstrasse 21 80335 Muenchen mailto:jasper.ullrich@mdfactory.de http://www.mdfactory.de From roemer@inf.ethz.ch Wed Dec 8 23:40:41 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id XAA21675 for ; Wed, 8 Dec 1999 23:40:41 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id XAA03840 for ; Wed, 8 Dec 1999 23:40:40 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id XAA09034 for mico-devel-outgoing; Wed, 8 Dec 1999 23:34:02 +0100 (MET) Received: from scapa.cs.ualberta.ca (scapa.cs.ualberta.ca [129.128.4.44]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id XAA09029 for ; Wed, 8 Dec 1999 23:34:01 +0100 (MET) Received: from darwell.cs.ualberta.ca ([129.128.4.231]:52647 "EHLO cs.ualberta.ca") by scapa.cs.ualberta.ca with ESMTP id ; Wed, 8 Dec 1999 15:33:38 -0700 Message-ID: <384EDCC1.15A8CF75@cs.ualberta.ca> Date: Wed, 08 Dec 1999 15:33:37 -0700 From: Bin Benjamin Yao Organization: Computing Science, University of Alberta, Canada X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: MICO: Distributed Database Issues Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 615 Lines: 14 Here is my situation. I have at least two databases running on different machines. The interfaces of these databases and implementation are the same, but the data contents in the databases are different. That is why I want to develop a middleware using MICO which can handle the request from the client, send the request to all the databases, intergrate the results and send back to the client. How can I deal with this situation? I want to use one same interface but different objects related to it, but how can I implement it. Do you have any examples like this? Thank you for your help. Bin Benjamin YAO From roemer@inf.ethz.ch Thu Dec 9 01:09:56 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id BAA22378 for ; Thu, 9 Dec 1999 01:09:56 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id BAA04753 for ; Thu, 9 Dec 1999 01:09:55 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id BAA09319 for mico-devel-outgoing; Thu, 9 Dec 1999 01:01:40 +0100 (MET) Received: from faust27-s.rz.uni-frankfurt.de (faust27-s.rz.uni-frankfurt.de [141.2.149.151]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with SMTP id BAA09314 for ; Thu, 9 Dec 1999 01:01:39 +0100 (MET) Received: from rose.fpx.de (actually NAFp2-087.rz.uni-frankfurt.de) by faust27-eth.rz.uni-frankfurt.de with Local SMTP (PP); Thu, 9 Dec 1999 01:01:34 +0000 Received: (from fp@localhost) by rose.fpx.de (8.8.5/8.8.5) id AAA02742 for mico-devel@vsb.informatik.uni-frankfurt.de; Thu, 9 Dec 1999 00:51:13 +0100 Date: Thu, 9 Dec 1999 00:51:12 +0100 From: Frank Pilhofer To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: Re: MICO: TclMico and Orbix. Message-ID: <19991209005112.D334@rose.fpx.de> Mail-Followup-To: mico-devel@vsb.informatik.uni-frankfurt.de References: <384E7AA3.D1F7E441@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <384E7AA3.D1F7E441@lucent.com>; from claire fisher on Wed, Dec 08, 1999 at 03:34:59PM +0000 Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 2701 Lines: 63 On Wed, Dec 08, 1999 at 03:34:59PM +0000, claire fisher wrote: > > I am using Orbix 2.3c server & TclMico 0.5c client (with Mico 2.3.0) > > set obj [$nsobj resolve {{id "name" kind ""}}] > Looks fine so far. > > Then when I try to access that interface with; > $obj do_whatever > I get a segmentation fault: - CORBA::ORB::get_iface (). > Hm, let me hazard couple of guesses. First of all, (Tcl)MICO of course should not crash. What operating system are you working on? Have you built MICO as a shared library? One guess is that MICO fails at throwing an exception out of a shared library. I would be interested to know in which line the crash happens, and also in a stack trace. As described in the manual, TclMico needs an Interface Repository con- taining all interfaces you are accessing. I presume you're doing that already (since the Naming Service access works). The course of events depends on if the object reference ($obj) contains a Repository Id. The Repo Id in an IOR is optional, and may be empty. You could check this by writing the IOR to a file (`puts [corba::object_to_string $obj]') and then using MICO's iordump utility (`cat thefile | iordump'). Does the `Repo Id' field at the beginning have the expected value? If yes, then TclMico tries to use the interface information in the local Interface Repository (i.e. the one you've fed with `mico::ir' commands), if available. If (1) your object's interface information is not available locally, or if (2) the Repo Id field was empty in the first place, or if (3) you are trying to invoke an unknown method, TclMico tries to update its type infor- mation for the object; and this is where the crash probably happens. It does this by using Object::_get_interface(), which actually asks the server for Interface Repository information. However, this needs Orbix- specific action on the server side (check the manual). So in order to avoid the crash, either of the following has to happen: (1) Make sure that the object reference ($obj) does contain Repository Id information, and feed the necessary information into the local IFR using `mico::ir'. (2) Connect your Orbix server to an Interface Repository so that it answers the _get_interface() request correctly. (You can try expli- citly using `$obj _get_interface'.) That the complete client crashes is an additional bug, which I'm also curious about. Let me know if you make any progress. Frank -- + Frank Pilhofer fp@informatik.uni-frankfurt.de + | http://www.uni-frankfurt.de/~fp/ | +---- Life would be a very great deal less weird without you. - DA ----+ From roemer@inf.ethz.ch Thu Dec 9 01:10:51 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id BAA22395 for ; Thu, 9 Dec 1999 01:10:51 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id BAA04767 for ; Thu, 9 Dec 1999 01:10:50 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id BAA09371 for mico-devel-outgoing; Thu, 9 Dec 1999 01:07:50 +0100 (MET) Received: from faust27-s.rz.uni-frankfurt.de (faust27-s.rz.uni-frankfurt.de [141.2.149.151]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with SMTP id BAA09366 for ; Thu, 9 Dec 1999 01:07:48 +0100 (MET) Received: from rose.fpx.de (actually NAFp2-087.rz.uni-frankfurt.de) by faust27-eth.rz.uni-frankfurt.de with Local SMTP (PP); Thu, 9 Dec 1999 01:07:40 +0000 Received: (from fp@localhost) by rose.fpx.de (8.8.5/8.8.5) id BAA02865 for mico-devel@vsb.informatik.uni-frankfurt.de; Thu, 9 Dec 1999 01:05:35 +0100 Date: Thu, 9 Dec 1999 01:05:35 +0100 From: Frank Pilhofer To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: Re: MICO: poa_impl.cc patch Message-ID: <19991209010535.E334@rose.fpx.de> Mail-Followup-To: mico-devel@vsb.informatik.uni-frankfurt.de References: <01BF41C6.C134DB60@JU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <01BF41C6.C134DB60@JU>; from Jasper Ullrich on Wed, Dec 08, 1999 at 09:54:07PM -0000 Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 656 Lines: 21 On Wed, Dec 08, 1999 at 09:54:07PM -0000, Jasper Ullrich wrote: > > in your mico-2.3.0-1.diffs you forgot the patch that fixes the handling > of '/' in objectKeys !! > Not really. The 2.3.0-1 patch was made before I (or rather, Andreas Hess) discovered the bug. You can find the patch in the Mailing List archive at http://www.cs.uni-magdeburg.de/~aschultz/mico/mico-devel/1999-10/msg00134.html Hope this helps, Frank -- + Frank Pilhofer fp@informatik.uni-frankfurt.de + | http://www.uni-frankfurt.de/~fp/ | +---- Life would be a very great deal less weird without you. - DA ----+ From majordomo-owner@vsb.informatik.uni-frankfurt.de Thu Dec 9 01:29:21 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id BAA22501 for ; Thu, 9 Dec 1999 01:29:20 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id BAA04892 for ; Thu, 9 Dec 1999 01:29:20 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id BAA09469; Thu, 9 Dec 1999 01:29:19 +0100 (MET) Date: Thu, 9 Dec 1999 01:29:19 +0100 (MET) Message-Id: <199912090029.BAA09469@diamant.vsb.informatik.uni-frankfurt.de> To: mico-devel-approval@vsb.informatik.uni-frankfurt.de From: majordomo@vsb.informatik.uni-frankfurt.de Subject: APPROVE mico-devel Reply-To: majordomo@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 440 Lines: 17 -- Jie Dai requests that you approve the following: unsubscribe mico-devel jiedai@cs.uidaho.edu If you approve, please send a message such as the following back to majordomo@vsb.informatik.uni-frankfurt.de (with the appropriate PASSWORD filled in, of course): approve PASSWORD unsubscribe mico-devel jiedai@cs.uidaho.edu If you disapprove, do nothing. Thanks! majordomo@vsb.informatik.uni-frankfurt.de From roemer@inf.ethz.ch Thu Dec 9 09:12:57 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id JAA26685 for ; Thu, 9 Dec 1999 09:12:55 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id JAA09712 for ; Thu, 9 Dec 1999 09:12:54 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id JAA09750 for mico-devel-outgoing; Thu, 9 Dec 1999 09:02:47 +0100 (MET) Received: from antea.pallas.DE (mailgate2.online-hanse.de [194.45.33.6]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id JAA09745 for ; Thu, 9 Dec 1999 09:02:46 +0100 (MET) Received: from fw2.pallas.de (fw2.pallas.de [194.45.33.2]) by antea.pallas.DE (8.8.8/8.8.8) with SMTP id JAA13583 for ; Thu, 9 Dec 1999 09:02:45 +0100 (MET) Received: by STX-COM with Internet Mail Service (5.0.1460.8) id ; Thu, 9 Dec 1999 09:02:42 +0100 Message-ID: From: Wolff Jan-Holger To: "'mico-devel@vsb.informatik.uni-frankfurt.de'" Subject: AW: MICO: compile mico Date: Thu, 9 Dec 1999 09:02:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by diamant.vsb.informatik.uni-frankfurt.de id JAA09746 Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 1010 Lines: 39 Hi, download the mico distribution and extract it. Then you will have a directory named 'mico'. Change into this directory. At the command line, type nmake /f makefile.win32. (last mail, you told that you are using windows). To initialize your MSDev environment, you have to run 'Vcvars32.bat' first (shipped with DevStudio). This will build all you need. You will find your newly build distribution in ./win32-bin. enjoy Jan-Holger -----Ursprüngliche Nachricht----- Von: Enith Iriarte [mailto:enith@ns.ceub.edu.bo] Gesendet: Mittwoch, 8. Dezember 1999 22:16 An: mico-devel@vsb.informatik.uni-frankfurt.de Betreff: MICO: compile mico Hello: I am trying to compile a MICO server using MS VC++ 5.0 (SP3) on NT. However, during the link phase, I got account.h library is missing clear.exe error.... Some nice boy told me that I need to compile the IDL first, I don´t know how to do it. I read the papers related with mico. But anything about compile IDL. Could you help me? Thanks in advance. Enith From roemer@inf.ethz.ch Thu Dec 9 09:19:49 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id JAA26713 for ; Thu, 9 Dec 1999 09:19:49 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id JAA09805 for ; Thu, 9 Dec 1999 09:19:48 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id JAA09823 for mico-devel-outgoing; Thu, 9 Dec 1999 09:15:35 +0100 (MET) Received: from antea.pallas.DE (mailgate2.online-hanse.de [194.45.33.6]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id JAA09818 for ; Thu, 9 Dec 1999 09:15:32 +0100 (MET) Received: from fw2.pallas.de (fw2.pallas.de [194.45.33.2]) by antea.pallas.DE (8.8.8/8.8.8) with SMTP id JAA13951 for ; Thu, 9 Dec 1999 09:15:32 +0100 (MET) Received: by STX-COM with Internet Mail Service (5.0.1460.8) id ; Thu, 9 Dec 1999 09:15:23 +0100 Message-ID: From: Wolff Jan-Holger To: "'mico-devel@vsb.informatik.uni-frankfurt.de'" Subject: MICO: DevStudio 6 integration Date: Thu, 9 Dec 1999 09:15:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 482 Lines: 18 Hi, after my first contact with MICO, I tried to build to compile the mfc c/s demo using the comand line (Win32/NT) . Everything worked fine. After that, I tried to integrate the client source into a DevStudio wizard build Win32 dialog application. Now I face a problem: compiler output: client.cpp d:\programme\microsoft visual studio\vc98\include\ios.h(146) : error C2872: 'streambuf' : ambiguous symbol ... There seems to be a conflict. Has somebody an idea? tia Jan-Holger From roemer@inf.ethz.ch Thu Dec 9 13:05:08 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id NAA28076 for ; Thu, 9 Dec 1999 13:05:07 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id NAA15039 for ; Thu, 9 Dec 1999 13:05:06 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id MAA10708 for mico-devel-outgoing; Thu, 9 Dec 1999 12:51:48 +0100 (MET) Received: from relay.unizar.es (tozal.unizar.es [155.210.3.20]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id MAA10703 for ; Thu, 9 Dec 1999 12:51:42 +0100 (MET) Received: from celes.unizar.es (celes.unizar.es [155.210.11.15]) by relay.unizar.es (8.9.3/8.9.1) with ESMTP id MAA09847 for ; Thu, 9 Dec 1999 12:51:38 +0100 (MET) Received: from cepsz.unizar.es (IDENT:jorgeof@viernes.cps.unizar.es [155.210.152.24]) by celes.unizar.es (8.9.3/8.9.1) with ESMTP id MAA06102 for ; Thu, 9 Dec 1999 12:51:37 +0100 (MET) Message-ID: <384F97C9.646E8551@cepsz.unizar.es> Date: Thu, 09 Dec 1999 12:51:37 +0100 From: Jorge Olmos Fores <407101@cepsz.unizar.es> X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: Re: MICO: compile mico References: <3.0.6.32.19991208131602.007d0de0@mail.ceub.edu.bo> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 757 Lines: 31 Enith Iriarte wrote: > Hello: > > I am trying to compile a MICO server using MS VC++ 5.0 (SP3) on NT. > However, during the link phase, I got account.h library is missing > clear.exe error.... > Could you help me? > account.h is not a library. It's a header file which (I presume) has to be generated by the idl compiler. If you are using mico, the command line is $ idl account.idl And you'll get two files: account.c., and account.h. It seems you have been trying to compile the examples. Try reading the Makefile for more information about how to compile that example. If your problem was that you didn't know that idl files have to be compiled, I think that you need a book on CORBA. -- Jorge Olmos Fores e-mail: 407101@cepsz.unizar.es From roemer@inf.ethz.ch Thu Dec 9 13:34:56 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id NAA28214 for ; Thu, 9 Dec 1999 13:34:55 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id NAA15539 for ; Thu, 9 Dec 1999 13:34:55 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id NAA10771 for mico-devel-outgoing; Thu, 9 Dec 1999 13:29:55 +0100 (MET) Received: from esrelay002.caissedesdepots.fr (esrelay002.caissedesdepots.fr [158.156.156.29]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id NAA10766 for ; Thu, 9 Dec 1999 13:29:43 +0100 (MET) Received: from esmailfed2.serv.cdc.fr (esmailfed2 [158.156.1.207]) by esrelay002.caissedesdepots.fr (8.8.8/8.8.8) with ESMTP id NAA08153; Thu, 9 Dec 1999 13:23:50 +0100 (MET) Received: from tsexchange.idt.cdc.fr (localhost [127.0.0.1]) by esmailfed2.serv.cdc.fr (8.8.8/8.8.8) with ESMTP id NAA18564; Thu, 9 Dec 1999 13:30:49 +0100 (MET) Posted-Date: Thu, 9 Dec 1999 13:30:49 +0100 (MET) Received: by TSEXCHANGE with Internet Mail Service (5.5.2448.0) id ; Thu, 9 Dec 1999 13:30:56 +0100 Message-ID: <40C4228EC468D211B04800A0C9DF1D664FB74E@TSEXCHANGE> From: "Coetmeur, Alain" To: "'mico-devel@vsb.informatik.uni-frankfurt.de'" Cc: "'jhwolff@stotax.de'" Subject: RE: MICO: DevStudio 6 integration Date: Thu, 9 Dec 1999 13:30:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by diamant.vsb.informatik.uni-frankfurt.de id NAA10767 Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 1291 Lines: 49 strange, since it works perfectly with VC6 SP2 mico 2.3.0. have you added the proposed flags in readme-win32, _windows for all user client, and BUILD_MICO_DLL and __MICO_ORB__ for building MICO code itself Select "Multithreaded debugger" for Debug and "Multithreaded" for Release as Runtime Library look also about the registry hack to make VC6 recognise .cc as C++ files... I have registry files for this, and .wsp, .dsp that you may use if needed... -- Alain Coetmeur, Informatique-CDC DTA mailto:alain.coetmeur@icdc.CaisseDesDepots.fr > -----Message d'origine----- > De: Wolff Jan-Holger [mailto:jhwolff@stotax.de] > Date: jeudi 9 décembre 1999 09:15 > Ŕ: 'mico-devel@vsb.informatik.uni-frankfurt.de' > Objet: MICO: DevStudio 6 integration > > > Hi, > > after my first contact with MICO, I tried to build to compile > the mfc c/s > demo using the comand line (Win32/NT) . Everything worked > fine. After that, > I tried to integrate the client source into a DevStudio > wizard build Win32 > dialog application. Now I face a problem: > > compiler output: > > client.cpp > d:\programme\microsoft visual studio\vc98\include\ios.h(146) > : error C2872: > 'streambuf' : ambiguous symbol > ... > > There seems to be a conflict. Has somebody an idea? > > tia > Jan-Holger > From roemer@inf.ethz.ch Thu Dec 9 15:07:11 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id PAA29201 for ; Thu, 9 Dec 1999 15:07:11 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id PAA17826 for ; Thu, 9 Dec 1999 15:07:10 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id OAA11384 for mico-devel-outgoing; Thu, 9 Dec 1999 14:58:54 +0100 (MET) Received: from penguin.xtradyne.de ([62.159.77.194]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id OAA11379 for ; Thu, 9 Dec 1999 14:58:52 +0100 (MET) Received: from xtradyne.de (eagle.xtradyne.de [192.168.1.15]) by penguin.xtradyne.de (8.9.3/8.9.3) with ESMTP id OAA15869 for ; Thu, 9 Dec 1999 14:50:43 +0100 Message-ID: <384FB577.818C6D8B@xtradyne.de> Date: Thu, 09 Dec 1999 14:58:15 +0100 From: Marcus Wittig Organization: Xtradyne Technologies AG X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mico-devel@vsb.informatik.uni-frankfurt.de Subject: MICO: [BUG] IOR decoding adds extraneous byte to profile data of unknown tagged profiles Content-Type: multipart/mixed; boundary="------------A0C90FAEB324D189707A896A" Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO X-Status: A Content-Length: 4804 Lines: 100 This is a multi-part message in MIME format. --------------A0C90FAEB324D189707A896A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, There is a bug in the IOR decoding of unknown tagged profiles. The decode routine for unknown tagged profiles adds one extra byte to the profile data. The bug can be demonstrated easily. Take a stringified IOR including an unknown tagged profile with X bytes of profile data. Now convert the string to an object and convert the object back to an string. As you can see from the resulting data the unknown tagged profile now contains X+1 bytes profile data. Please find attached an example program (including an example IOR) which demonstrates this behavior. I am not familiar with the mico sources, so it is hard for me to provide you with a proper bug fix. My guess is that code line 1448 in ior.cc, function MICO::UnknownProfile::decode() is faulty: p->tagdata.insert (p->tagdata.begin(), dc.buffer()->data() - 1, dc.buffer()->data() + len +1 ); This call inserts data from the decode buffer at the beginning of the 'tagdata' sequence. The start position of the buffer range inserted is data()-1 which looks fine to me as the decoder has already skipped the endian flag which is expected for encapsulated profile data. The end position position is data()+len+1 where len is length of profile data minus one as the endian flag expected for encapsulated data has been read already. As one can see this is odd, because the buffer range is len+2 bytes. Therefore, the end position shall be data()+len instead: p->tagdata.insert (p->tagdata.begin(), dc.buffer()->data() - 1, dc.buffer()->data() + len +1 ); Marcus Wittig Xtradyne Tech. AG, Berlin --------------A0C90FAEB324D189707A896A Content-Type: application/x-zip-compressed; name="iorBugExample.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="iorBugExample.zip" UEsDBBQAAAAIAGVmiSeTTjPirgAAAPYAAAAWABAAaW9yQnVnRXhhbXBsZS9NYWtlZmlsZVVY DACgsk84rZdPOPYB9gFNT08LgjAUP/s+xTt0SMF1F4LUVQgrwkV4i7HNGM0ZK6FTnz1Fjd7p 9+/9Hg+EtQkSpR/aKZTWaPcCME7aTmkkZHUQd30R/gnFkZ9Txq60KHGYNZrWZ91t+xbNw+qf z8ucj/6wWhurp1oiJXrhVNsQoywAjHIy2y0ulnR74iEEiyWjYU/zqtqxdM8HzOgE/+KMsiLr pbgnm6FQC5dA4BuMa4z6iGz9fB6jz/wnfAFQSwMEFAAAAAgAuXWJJ+H0w18sAwAAhAcAABQA EABpb3JCdWdFeGFtcGxlL1JFQURNRVVYDACNsk84jbJPOPYB9gHFVMlu2zAQvfMrBkULJEAi i5KjSMqlhpOgRrMhSy9FDzRF22xkUqDoOPn7DinJS+KkvZWULWE4y5vHmSG8lELZgHOQNTCo 5bwqBVhRW6iMnho2B6uhEHOtamuYFcDIeDEFqcDOBB5wXUg1BaMXVioBE21goR6VXqICm05F 4fxMZClqsnc5Gl5DFMRBeABOBNqMe1IbDH8AD43VTaOd59612A+AkHuM1KExghUeqTUYV04k Rhhd38LE6Hnj9JN4Zi6LAD1/OgCmCsK1ehLG1h5zY+nSYgr0+LfgNoBzXZZ66eUz2eg1R8hL Z46Rxow/esvWSwAOmxH1orTOuPWNHiiMX5CtUqupMMTOmNoM7rJYQw4A2ixb6D4jjGqZVLWD ORpd37TMuIScqGO5pReW0s5ICppbgYl20oJZFsCgBmndw9FwjCiEUE14uw5KOorxKquFhT3U QmWkZR/mkmPSBTKv8ZJ9DEeDs7bN5WxEI9ucbOWS7QRIyB03srJID/M8a4XELuBUcEATGuVH x3k/AZplGfk5Z4Yv6q+VUNMF1iFe81mTwa/PEPSaiiYYNQ9p2Kyz5tXP+v3+MB700+QoGeI+ jwcxjc7iVi1cfTQrStsP2noatmo0zuII7WicxKl74y8Kw8H5MN7Ui3buuPMWRv2V/51vuuu8 +3YrWyHzK+nwb+Le2ATrDG5FpWFU5ACj04v8m8C6z2kQEuJqDNoi85o/hKmlVqjpzp1kUBR4 rzVKsNdtTrMooEka0AAvCNEcOaULzZltzKTUVal53uu90ex9icKPnwatW9/FCzqLwr88MYV3 FiXk0hWj66yhnldYwwpLcJXrWoZxrhD9k9MrRI2FmpNtX0qbOStzGN1dQ5oeZYcUaUiPT+AC 7RQMymrGxtgdVzoASl4jWcpCeNve6GwINEz6iXeQxSfwcH9+SBMchMM7uDdM1RMXylGJ08l9 AU0Ox9jETv6KnDB8L/fdCzuunbdrFrr54msD+2y7hcRGC/GY+RbiuCcxw/IX/9xCfKuFRNtC wvvAFmITHm/q/bcWyna3UJp+PH/Es7TE/3UjrfAT8808S/OwnWd/AFBLAwQUAAAACACtZokn Q5x1LnEBAAC4AgAAFwAQAGlvckJ1Z0V4YW1wbGUvY2xpZW50LmNjVVgMADaYTzg1mE849gH2 AVVQy27CMBC85ysWuDgV4VH1BDQS7ZWqUjkiFDmJgUXGRo6DUCv+vetHKPXBcWZ2Z3ZngKqS bS1ggbqxRvDT6JAngzu6+wMf0PfPr7dltv5YrlaeSVBZOHFUDNyLm301hOrADTzR+7LZQpr8 JECnVQ3ulahBarUHM088Oh4DKVIvWuQSv7lFrTzjnWYzuosLyWlTwusj6FpYNHRWQ+ifsNKZ 1BWXGZX3IY0msWttDaq9VzNiFzmMewLSl0FfXPnpLMUItfECoYZBz/GQggfCRu5UwhhYLKjP GG1msEMp4EEDlLbkxmteStF3lULVcn7vF1e3xbRzuvnb51e2uw1MJ88vsI1TuAHy3BEBoCUo ElZp1diYedqxQUe31lkS9t+5i7E8isqGeMsjaVFqWd6EmKwutOeZN4oD8qYRhqBelMCmUCiZ 709Dka+j/ywvKACWZvmZBC1zUUWVbjDvF1ycX3BmBKTEhnHjprY1Cibz5Jb8AlBLAwQUAAAA CABodYknS/uhBGQAAAAVAQAAGQAQAGlvckJ1Z0V4YW1wbGUvZXhhbXBsZS5pb3JVWAwAXbJP OPSxTzj2AfYBbU7LCsAgDLvva9qmK7qbiMJOg/3/x0znAw8mSAKmIffzXsTUkJqoV9WIoM5O i4UZASwJPUbTNIjrhntT7DGGh5Q7hsFVLU+IQo5Yc7IlRhuJzv6t8u5/+Ao/l/2wsX/dvfD4 AFBLAQIVAxQAAAAIAGVmiSeTTjPirgAAAPYAAAAWAAwAAAAAAAEAAECkgQAAAABpb3JCdWdF eGFtcGxlL01ha2VmaWxlVVgIAKCyTzitl084UEsBAhUDFAAAAAgAuXWJJ+H0w18sAwAAhAcA ABQADAAAAAAAAQAAQLSB8gAAAGlvckJ1Z0V4YW1wbGUvUkVBRE1FVVgIAI2yTziNsk84UEsB AhUDFAAAAAgArWaJJ0OcdS5xAQAAuAIAABcADAAAAAAAAQAAQKSBYAQAAGlvckJ1Z0V4YW1w bGUvY2xpZW50LmNjVVgIADaYTzg1mE84UEsBAhUDFAAAAAgAaHWJJ0v7oQRkAAAAFQEAABkA DAAAAAAAAQAAQLSBFgYAAGlvckJ1Z0V4YW1wbGUvZXhhbXBsZS5pb3JVWAgAXbJPOPSxTzhQ SwUGAAAAAAQABABCAQAAwQYAAAAA --------------A0C90FAEB324D189707A896A-- From roemer@inf.ethz.ch Thu Dec 9 16:25:55 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id QAA00045 for ; Thu, 9 Dec 1999 16:25:54 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id QAA19428 for ; Thu, 9 Dec 1999 16:25:53 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id QAA12433 for mico-devel-outgoing; Thu, 9 Dec 1999 16:12:49 +0100 (MET) Received: from q-free.com (hurricane.qfree.org [62.92.116.19] (may be forged)) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with SMTP id QAA12428 for ; Thu, 9 Dec 1999 16:12:47 +0100 (MET) Received: from ntjon (ntjon.q-free.com [192.168.0.139]) by q-free.com (8.9.3/8.9.3) with SMTP id QAA29966 for ; Thu, 9 Dec 1999 16:12:26 +0100 From: "Jon Finanger" To: Subject: MICO: At the starting point Date: Thu, 9 Dec 1999 16:12:12 +0100 Message-ID: <004601bf4257$c54a6bc0$8b00a8c0@qfree.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 1526 Lines: 44 Hi all! I've just downloaded MICO and successfully compiled it for NT, also successfully executed the Server.exe and the Client.exe. Using JKD1.3 I'm currently trying to create an AccountClient.java client for the Server. Unfortunately i get some errors that raise some questions. This error: org.omg.CORBA.COMM_FAILURE: minor code: 1398079490 completed: No - makes me believe its something wrong with the naming service. I'm currently running the server.exe demo and I thought a naming service already was started. Isnt it? What am i doing wrong/forgetting? (After what i understand the only thing to do is to create an clientside orb, obtain a objectref. from the naming service and invoke its interface.) \Jon // AccountClient Java code: import org.omg.CosNaming.*; import org.omg.CORBA.*; public class AccountClient { public static void main(String args[]) { try { // Initialize the ORB ORB orb = ORB.init(args,null); // Getting the naming context org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); // Casting to NamingContext NamingContext ncRef=NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("account",""); NameComponent path[] = {nc}; // Narrowing the remote ref.(_stub) to the Account class type Account accountRef = AccountHelper.narrow(ncRef.resolve(path)); // Invoking accountRef.deposit(1000); } catch (Exception e) { e.printStackTrace(System.out); } } } From roemer@inf.ethz.ch Thu Dec 9 16:47:56 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id QAA00310 for ; Thu, 9 Dec 1999 16:47:56 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3/8.9.3) with ESMTP id QAA21379 for ; Thu, 9 Dec 1999 16:47:55 +0100 (MET) Received: (from mjdomo@localhost) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) id QAA12679 for mico-devel-outgoing; Thu, 9 Dec 1999 16:33:30 +0100 (MET) Received: from mdfactory.de ([194.175.113.15]) by diamant.vsb.informatik.uni-frankfurt.de (8.9.3+Sun/8.9.1) with ESMTP id QAA12674 for ; Thu, 9 Dec 1999 16:33:28 +0100 (MET) Received: from JU ([172.24.41.26]) by mdfactory.de (8.9.3/8.8.8) with SMTP id QAA09543 for ; Thu, 9 Dec 1999 16:33:57 +0100 (MET) Received: by JU with Microsoft Mail id <01BF4262.9ECBD550@JU>; Thu, 9 Dec 1999 16:29:52 -0000 Message-ID: <01BF4262.9ECBD550@JU> From: Jasper Ullrich To: "'mico mailing list'" Subject: MICO: Bug around POAImplName Date: Thu, 9 Dec 1999 16:29:51 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mico-devel@vsb.informatik.uni-frankfurt.de Precedence: bulk Reply-To: mico-devel@vsb.informatik.uni-frankfurt.de Status: RO Content-Length: 689 Lines: 19 Hey, i have once more a question about the implementation around the POAImplName. We have two corba services, first with POAImplName Factory, second with POAImplName Factory2. If i try to access an object at server Factory2 from server Factory (like orb->string_to_object("iioploc://.....")), server Factory crashs (no chance for the catch(...) handler). When i rename Factory2 to FactorY, it works. For me, it seems that the POAImplName where compared from left and then ....... ??! Ok, there is a workaround, but in a future release this should be fixed. Bye Jasper Jasper Ullrich MD FACTORY Bayerstrasse 21 80335 Muenchen mailto:jasper.ullrich@mdfactory.de http://www.mdfactory.de From roemer@inf.ethz.ch Thu Dec 9 16:51:19 1999 Received: from core.inf.ethz.ch (root@core.inf.ethz.ch [129.132.178.196]) by vs.inf.ethz.ch (8.8.8/8.8.8) with ESMTP id QAA00337 for ; Thu, 9 Dec 1999 16:51:19 +0100 (MET) Received: from diamant.vsb.informatik.uni-frankfurt.de (diamant-atm.vsb.informatik.uni-frankfurt.de [141.2.150.16]) by core.inf.ethz.ch (8.9.3