From gao_huang at sina.com Fri Feb 1 12:43:40 2002 From: gao_huang at sina.com (gao_huang) Date: Fri Sep 5 12:44:00 2003 Subject: [mico-devel] is the problem of my netcard? Message-ID: <20020201044340.9549.qmail@sina.com> Hi,all: I have a strange question. Now I found that if I disable my netcard, then the demo program account2 in mico can run(but client->deposit can only be called for 5 times). And if the netcard is working at the same time , the client->deposit can't work. I have download the source code from mico cvs, and meet the same problem. Thanks! Goerge Hayne ______________________________________ =================================================================== 新浪免费电子邮箱 (http://mail.sina.com.cn) 新浪分类信息：轻松订阅，量身定制,好信息来找你! (http://classad.sina.com.cn/) 新浪闪烁短信闪亮登场 传情无限 (http://sms.sina.com.cn/cgi-bin/sms/smspic.cgi?spec=11&type=0) _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From kgardas at iol.cz Fri Feb 1 08:39:42 2002 From: kgardas at iol.cz (Karel Gardas) Date: Fri Sep 5 12:44:01 2003 Subject: [mico-devel] is the problem of my netcard? In-Reply-To: <20020201044340.9549.qmail@sina.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 1 Feb 2002, gao_huang wrote: > Hi,all: > > I have a strange question. > Now I found that if I disable my netcard, then the demo program account2 in mico can run(but client->deposit can only be called for 5 times). And if the netcard is working at the same time , the client->deposit can't work. > I have download the source code from mico cvs, and meet the same problem. > Thanks! > Hi, Can you give us more information about your hardware(NIC)/software(OS/libs) Cheers, Karel - -- Karel Gardas e-mail: kgardas@iol.cz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE8WkZBqREvenJ7UIYRAvnVAKCUsNw286WK/0X/CAHMfQ5zOV2rhwCeIfff J0/tWRFbLH+UoBjXMw5O0Mo= =ie/5 -----END PGP SIGNATURE----- _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From p.klotz at icoserve.com Fri Feb 1 08:45:59 2002 From: p.klotz at icoserve.com (p.klotz@icoserve.com) Date: Fri Sep 5 12:44:01 2003 Subject: [mico-devel] Re: Compiling Mico with GCC 3 Message-ID: > FYI: > > GCC 3.1 snapshots taken (including) between 13.12.2001 and 22.1.2002 are > not able to compile MICO well. For more information please see bugreport > #5453 on http://gcc.gnu.org/cgi-bin/gnatsweb.pl Thanks for that information. Yesterday I tried gcc 3.1-0.19 (dated 2002-01-30) from Rawhide which agains works fine for MICO. Bye, Peter. _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From gao_huang at sina.com Fri Feb 1 17:35:17 2002 From: gao_huang at sina.com (gao_huang) Date: Fri Sep 5 12:44:01 2003 Subject: [mico-devel] is the problem of my netcard? Message-ID: <20020201093517.16272.qmail@sina.com> Hi, Cheers: Thank you for your response. My machine is IBM thinkpad 600x, the netcard is cisco 340 wireless card(and I have tested on 3com pc card and meet the same problem). My OS. is win2000 work station, and I use vc 6.0 IDE to debug the mico application. regards Gorege Hayne ----- Original Message ----- From:Karel Gardas To:gao_huang Subject:Re: [mico-devel] is the problem of my netcard? Date:Fri, 1 Feb 2002 15:39:42 +0800 >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Fri, 1 Feb 2002, gao_huang wrote: > >> Hi,all: >> >> I have a strange question. >> Now I found that if I disable my netcard, then the demo program account2 in mico can run(but client->deposit can only be called for 5 times). And if the netcard is working at the same time , the client->deposit can't work. >> I have download the source code from mico cvs, and meet the same problem. >> Thanks! >> > >Hi, > >Can you give us more information about your >hardware(NIC)/software(OS/libs) > >Cheers, > >Karel >- -- > Karel Gardas e-mail: kgardas@iol.cz > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.0.6 (GNU/Linux) >Comment: Made with pgp4pine 1.75-6 > >iD8DBQE8WkZBqREvenJ7UIYRAvnVAKCUsNw286WK/0X/CAHMfQ5zOV2rhwCeIfff >J0/tWRFbLH+UoBjXMw5O0Mo= >=ie/5 >-----END PGP SIGNATURE----- > > > > ______________________________________ =================================================================== 新浪免费电子邮箱 (http://mail.sina.com.cn) 新浪分类信息：轻松订阅，量身定制,好信息来找你! (http://classad.sina.com.cn/) 新浪闪烁短信闪亮登场 传情无限 (http://sms.sina.com.cn/cgi-bin/sms/smspic.cgi?spec=11&type=0) _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From gao_huang at sina.com Fri Feb 1 17:35:31 2002 From: gao_huang at sina.com (gao_huang) Date: Fri Sep 5 12:44:01 2003 Subject: [mico-devel] is the problem of my netcard? Message-ID: <20020201093531.7535.qmail@sina.com> Hi, Karel: Thank you for your response. My machine is IBM thinkpad 600x, the netcard is cisco 340 wireless card(and I have tested on 3com pc card and meet the same problem). My OS. is win2000 work station, and I use vc 6.0 IDE to debug the mico application. regards Gorege Hayne ----- Original Message ----- From:Karel Gardas To:gao_huang Subject:Re: [mico-devel] is the problem of my netcard? Date:Fri, 1 Feb 2002 15:39:42 +0800 >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Fri, 1 Feb 2002, gao_huang wrote: > >> Hi,all: >> >> I have a strange question. >> Now I found that if I disable my netcard, then the demo program account2 in mico can run(but client->deposit can only be called for 5 times). And if the netcard is working at the same time , the client->deposit can't work. >> I have download the source code from mico cvs, and meet the same problem. >> Thanks! >> > >Hi, > >Can you give us more information about your >hardware(NIC)/software(OS/libs) > >Cheers, > >Karel >- -- > Karel Gardas e-mail: kgardas@iol.cz > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.0.6 (GNU/Linux) >Comment: Made with pgp4pine 1.75-6 > >iD8DBQE8WkZBqREvenJ7UIYRAvnVAKCUsNw286WK/0X/CAHMfQ5zOV2rhwCeIfff >J0/tWRFbLH+UoBjXMw5O0Mo= >=ie/5 >-----END PGP SIGNATURE----- > > > > ______________________________________ =================================================================== 新浪免费电子邮箱 (http://mail.sina.com.cn) 新浪分类信息：轻松订阅，量身定制,好信息来找你! (http://classad.sina.com.cn/) 新浪闪烁短信闪亮登场 传情无限 (http://sms.sina.com.cn/cgi-bin/sms/smspic.cgi?spec=11&type=0) _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From gao_huang at sina.com Fri Feb 1 17:58:41 2002 From: gao_huang at sina.com (gao_huang) Date: Fri Sep 5 12:44:01 2003 Subject: [mico-devel] Re:mico with vc++ Message-ID: <20020201095841.17251.qmail@sina.com> Hi, Dinesh: I haven't meet the problem you wrote, ( but I really have some problems about mico..) ). Ok, I can give you a concrete steps to make account demo work, hope it can help you. 1 download mico from www.mico.org(either archive file or cvs) 2 set the path to vc(or you can use other c++ compilor such as cygnus): include :Microsoft Visual Studio\VC98\Bin and Microsoft Visual Studio\Common\MSDev98\Bin 3 update the MakeVars.win32 from "SRCDIR = C:\Frank\mico" to "SRCDIR = your mico directory" and type nmake /f Makefile.win32 -all in a console window. 4 there will be a win32-bin sub-directory in mico directory. set the options of vc point correctly to this diretory:open menu->tools->optioins->Directories. include: Include files:add "mico\include" and "mico\include\windows" Library files:add "mico\win32-bin\lib" 5 new a win32 project as what you need 6 update the settings of your project: open menu->settins->c/c++, and add"_WINDOWS"; open menu->settins->Link, and add" mico236.lib wsock32.lib"; 7.Add diretoty "mico\win32-bin" to your machine path. 8.enter mico\demo\boa\account diretory and type idl --boa --no-poa account.id8 and now you got two files account.cc and account.hh without poa support(this demo doen't use poa). 9.include these two files in both your client and server project. 10.run again, I think this time your demo is ok. good luck! > Hi George, > Thank you for your email.I can compile and vc++ generated the >account.cpp and account.h files.How do I proceed further?My question is >1.When I try to compile the implementation file ,I get an error > >account_impl.cpp >d:\mico\account\account_impl.cpp(35) : error C2664: 'object_to_string' : >cannot convert parameter 1 from 'class Account_impl *' to 'class >CORBA::Object *' > Types pointed to are unrelated; conversion requires >reinterpret_cast, C-style cast or function-style cast >d:\mico\account\account_impl.cpp(50) : error C2665: 'release' : none of the >4 overloads can convert parameter 1 from type 'class Account_impl *' >Error executing cl.exe. > >account_impl.obj - 2 error(s), 0 warning(s) > > > >Any clue?? >Do you have the implementation file for the account example in the tutorial >so that I could take a look > >Thank you for your help, >Dinesh > > ______________________________________ =================================================================== 新浪免费电子邮箱 (http://mail.sina.com.cn) 新浪分类信息：轻松订阅，量身定制,好信息来找你! (http://classad.sina.com.cn/) 新浪闪烁短信闪亮登场 传情无限 (http://sms.sina.com.cn/cgi-bin/sms/smspic.cgi?spec=11&type=0) _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From ruff at swand.lake.de Fri Feb 1 11:05:08 2002 From: ruff at swand.lake.de (Marcel Ruff) Date: Fri Sep 5 12:44:01 2003 Subject: [mico-devel] Compiling mico with STLport Message-ID: <3C5A6854.9020707@swand.lake.de> Hi, i try to use mico in my app. This runs fine. Now i need to migrate to STLport and can't compile my app anymore. MICO Version 2.3.6 g++ --version 2.95.3 Linux 2.4.10-4GB i686 STLport-4.5.1 Error: ======================================= STLport-4.5.1/stlport/stl/_algo.h:180: declaration of `operator MICO_LongDouble' as non-function ======================================= Where MICO_LongDouble is in mico/include/mico/types.h: typedef long double MICO_LongDouble; In 1998 this was reported already, did anybody solve the mystery? thanks, Marcel -- Marcel Ruff mailto:ruff@swand.lake.de http://www.xmlBlaster.org _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From Arnaud.Bailly at lifl.fr Fri Feb 1 11:31:23 2002 From: Arnaud.Bailly at lifl.fr (Arnaud Bailly) Date: Fri Sep 5 12:44:01 2003 Subject: [mico-devel] Dynamic loading Message-ID: <15450.28283.746102.188775@argus.lifl.fr> Hello, I'm new to MICO (and CORBA by the way :-)) and experimenting with it. I ran accross a problem trying to build dynamic loadable modules of CORBA objects. The problem : I have two interfaces, one factory and one real object. The factory builds object on request from clients. The whole code is in a .so file. The _init() function of the .so creates the POA and servant for the factory and the POA for objects. On request for new objects, the factory register an object and returns a reference to it (sorry for ugly code, it's still new for me) : ostrstream ostr; ofstream log("ventes.log",ios::out|ios::app); ostr << venteNr++ << ends; char* str = ostr.str(); log << "Creating vente nr " << str << endl; ObjectId_var oid = string_to_ObjectId(str); // enregistre l'identifiant dans le POA des ventes Vente_impl* vte = new Vente_impl(); // active l'objet vente ventesPOA->activate_object_with_id(oid,vte); // narrow et retourne l'objet delete str; return vte->_this(); There is a simple server program that starts the ORB and loads the shared object. When client invoke a method on the returned object, I get a segfault. I have tried to produce a server without dll loading, and it works fine so I feel the problem comes from the dll stuff. I have tried debugging the whole stuff and the problem lies in the marshalling of the returned object : the address of ServantBase is shown (in GDB) as invalid. I'm wondering if the fact that my implementation classes inherit from PortableServer::StaticImplementation is not cause for the problem. I'm running mico2.3.6 (from CVS) on linux 2.4.17 with gcc 2.95.3 20010315 Thank you for your help Arnaud Bailly LIFL - France _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From kgardas at iol.cz Fri Feb 1 16:48:15 2002 From: kgardas at iol.cz (Karel Gardas) Date: Fri Sep 5 12:44:01 2003 Subject: [mico-devel] Dynamic loading In-Reply-To: <15450.28283.746102.188775@argus.lifl.fr> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, May I suggest you to use excellent CCM (CORBA Component Model) implementation which MICO has? It's written by Frank Pilhofer in Alcatel sponsorship and you'll be able to do what you would like in more easy and standard way. Please look at various examples in mico/demo/ccm directory. Cheers, Karel On Fri, 1 Feb 2002, Arnaud Bailly wrote: > Hello, > I'm new to MICO (and CORBA by the way :-)) and experimenting with it. > I ran accross a problem trying to build dynamic loadable modules > of CORBA objects. > The problem : > I have two interfaces, one factory and one real object. The factory builds > object on request from clients. The whole code is in a .so file. The _init() > function of the .so creates the POA and servant for the factory and the > POA for objects. > On request for new objects, the factory register an object > and returns a reference to it (sorry for ugly code, it's still new for me) : > > ostrstream ostr; > ofstream log("ventes.log",ios::out|ios::app); > ostr << venteNr++ << ends; > char* str = ostr.str(); > log << "Creating vente nr " << str << endl; > ObjectId_var oid = string_to_ObjectId(str); > > // enregistre l'identifiant dans le POA des ventes > Vente_impl* vte = new Vente_impl(); > // active l'objet vente > ventesPOA->activate_object_with_id(oid,vte); > // narrow et retourne l'objet > delete str; > return vte->_this(); > > There is a simple server program that starts the ORB and loads the shared > object. > > When client invoke a method on the returned object, I get a segfault. > > I have tried to produce a server without dll loading, and it works fine so > I feel the problem comes from the dll stuff. I have tried debugging the > whole stuff and the problem lies in the marshalling of the returned > object : the address of ServantBase is shown (in GDB) as invalid. > > I'm wondering if the fact that my implementation classes inherit from > PortableServer::StaticImplementation is not cause for the problem. > I'm running mico2.3.6 (from CVS) on linux 2.4.17 with gcc 2.95.3 20010315 > > Thank you for your help > > Arnaud Bailly > LIFL - France > > > _______________________________________________ > mico-devel mailing list > mico-devel@mico.org > http://www.mico.org/mailman/listinfo/mico-devel > - -- Karel Gardas e-mail: kgardas@iol.cz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE8WrjCqREvenJ7UIYRAjLzAJ96ndAXfvUiapaNIzPJ5scl4o9KYACfeGe8 Yt49bihvIeJKzOVtu5pUdbo= =wCid -----END PGP SIGNATURE----- _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From twall at oculustech.com Fri Feb 1 12:59:28 2002 From: twall at oculustech.com (Timothy Wall) Date: Fri Sep 5 12:44:01 2003 Subject: [mico-devel] Re: Mico <--> JacORB using SSL Message-ID: <3C5AD77F.9F8298FC@oculustech.com> Check the options being passed into SSLComponent for supports/requires to make sure they match that in Jacorb. Your jacorb options probably need to be at least 0x66 to match the defaults in mico. T. _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From david at 2good.nu Sun Feb 3 16:28:03 2002 From: david at 2good.nu (David Eriksson) Date: Fri Sep 5 12:44:01 2003 Subject: [mico-devel] No CORBA namespace in fixed.h? Message-ID: <5.1.0.14.2.20020203162432.00bc0898@mail> Hi! Why is the contents of MICO's fixed.h not in the CORBA namespace? Regards, -\- David Eriksson -/- _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From apm35 at student.open.ac.uk Sun Feb 3 20:30:00 2002 From: apm35 at student.open.ac.uk (Andrew Marlow) Date: Fri Sep 5 12:44:02 2003 Subject: [mico-devel] MICO, namespaces and older compilers In-Reply-To: <200202032010.g13KAA306582@mico.org> References: <200202032010.g13KAA306582@mico.org> Message-ID: I have followed MICO development for some years now and even made a few small contributions. However as of MICO 2.3.6 I will no longer be able to do this which is IMO a pity. Up until now it has been my favourite ORB. This is because MICO must be compiled by a compiler that supports namespaces. I have a Sun workstation with the Sparcworks 4.2 compiler and an HP workstation running HPUX 10.20 with a rather old CC compiler (which is fairly standard for HP 10.20). This means that I cannot build MICO on Solaris or HPUX whereas I used to be able to. I have discussed this with Frank who made the change and I do understand why the change has been made. I know that the code was getting a bit of of control in this area and using namespaces provides a great opportunity to tidy it up. However it also shuts me out except on Linux. I suspect it will also do this for a great many other developers including those that would try to introduce free software ORBs to commercial environments. Perhaps this decision can be reconsidered ? What if I offered to help make the code portable to namespaces or struct simulation via a macro set via ./configure ? I will not have the time to do all the work but I am willing to help. Regards, Andrew M. _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From kgardas at iol.cz Sun Feb 3 22:09:23 2002 From: kgardas at iol.cz (Karel Gardas) Date: Fri Sep 5 12:44:02 2003 Subject: [mico-devel] MICO, namespaces and older compilers In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Sun, 3 Feb 2002, Andrew Marlow wrote: > I have followed MICO development for some years now and even made a few > small contributions. However as of MICO 2.3.6 I will no longer be able to > do this which is IMO a pity. Up until now it has been my favourite ORB. > > This is because MICO must be compiled by a compiler that supports > namespaces. I have a Sun workstation with the Sparcworks 4.2 compiler and > an HP workstation running HPUX 10.20 with a rather old CC compiler (which > is fairly standard for HP 10.20). > > This means that I cannot build MICO on Solaris or HPUX whereas I used to > be able to. I have discussed this with Frank who made the change and I do > understand why the change has been made. I know that the code was getting > a bit of of control in this area and using namespaces provides a great > opportunity to tidy it up. However it also shuts me out except on Linux. I > suspect it will also do this for a great many other developers including > those that would try to introduce free software ORBs to commercial > environments. > I just don't know why don't you use GCC on your OSes? I think that it is supported on both platforms and supports namespaces quite well. > Perhaps this decision can be reconsidered ? What if I offered to help make > the code portable to namespaces or struct simulation via a macro set via > ./configure ? I will not have the time to do all the work but I am willing > to help. > Hmm, I saw your discussion with Frank. I think this is a problem, because the group of people who need this feature will be smaller in the future and from this point of view it's not so good to make any difficulties in maintaining MICO sources. I'd like to say you something more possitive and so look at the future, we have great free c++ orb, which has CCM implementation and I hope that in the future it will has multi-threading support, portable interceptors, security service, wireless support, messaging etc., so don't be sad that it'll not support c++ compilers without namespace support. :-) Cheers, Karel - -- Karel Gardas e-mail: kgardas@iol.cz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE8XacGqREvenJ7UIYRAroNAJ9Tm6h4XOug0FHBca6nAcfUJe6JAACeKLp7 ds84r5k6zLUKjkXemN8qy/k= =Uo0N -----END PGP SIGNATURE----- _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From ctxbsw at comp.leeds.ac.uk Mon Feb 4 10:01:27 2002 From: ctxbsw at comp.leeds.ac.uk (Ben) Date: Fri Sep 5 12:44:02 2003 Subject: [mico-devel] Compile problems Message-ID: Hi there. I'm having real problems getting any ORB to work. Mico looks promising, but I can't compile it. The makefile i downloaded seems to be written for nmake - gnu make doesnt understand the !include parts etc. I changled the compiler from cl to gcc and dumped everything in one file. I then get a bit further but itlooks like gcc doesnt understand compiler flags such as /nologo etc. Im sure there must be an easier way! My output: C:\files\source\mico>make -f makefile.win32 mkdir win32-bin A subdirectory or file win32-bin already exists. make: [system] Error 1 (ignored) mkdir win32-bin\lib A subdirectory or file win32-bin\lib already exists. make: [system] Error 1 (ignored) cd orb make /nologo /f Makefile.win32 lib make[1]: Entering directory `C:/files/source/mico' make[1]: *** No rule to make target `/nologo'. Stop. make[1]: Leaving directory `C:/files/source/mico' make: *** [system] Error 2 BTW I dont have access to visual studio...! Kind Regards Ben -- ctxbsw@comp.leeds.ac.uk _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From kgardas at iol.cz Mon Feb 4 11:46:44 2002 From: kgardas at iol.cz (Karel Gardas) Date: Fri Sep 5 12:44:02 2003 Subject: [mico-devel] Compile problems In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, it looks like you are working on M$ os with gnu gcc. I assume that you have installed gcc as part of cygnus cygwin product. If so, then you can easily follow UNIX installation instructions and use ./configure; make; make install. Please read file mico/INSTALL Cheers, Karel On Mon, 4 Feb 2002, Ben wrote: > > Hi there. I'm having real problems getting any ORB to work. Mico looks > promising, but I can't compile it. The makefile i downloaded seems to be > written for nmake - gnu make doesnt understand the !include parts etc. I > changled the compiler from cl to gcc and dumped everything in one file. I > then get a bit further but itlooks like gcc doesnt understand compiler > flags such as /nologo etc. Im sure there must be an easier way! > > My output: > > C:\files\source\mico>make -f makefile.win32 > mkdir win32-bin > A subdirectory or file win32-bin already exists. > make: [system] Error 1 (ignored) > mkdir win32-bin\lib > A subdirectory or file win32-bin\lib already exists. > make: [system] Error 1 (ignored) > cd orb > make /nologo /f Makefile.win32 lib > make[1]: Entering directory `C:/files/source/mico' > make[1]: *** No rule to make target `/nologo'. Stop. > make[1]: Leaving directory `C:/files/source/mico' > make: *** [system] Error 2 > > > BTW I dont have access to visual studio...! > > Kind Regards > Ben > > -- > ctxbsw@comp.leeds.ac.uk > > > _______________________________________________ > mico-devel mailing list > mico-devel@mico.org > http://www.mico.org/mailman/listinfo/mico-devel > - -- Karel Gardas e-mail: kgardas@iol.cz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE8XmaXqREvenJ7UIYRAgXVAJ992QJvdaf8XyFinBqRDLANIGztCQCfZFoX MHseoVrpgo82NMHznHkCeb0= =3C50 -----END PGP SIGNATURE----- _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From reiter at norcom.de Mon Feb 4 12:01:16 2002 From: reiter at norcom.de (Reiter, Konrad) Date: Fri Sep 5 12:44:02 2003 Subject: [mico-devel] AW: Mico <--> JacORB using SSL Message-ID: <30F837C65B8FB64090375BEF7EAD3B6D042986@mailsrv1.norcom.de> Hi Thimothy, thanks a lot for your response. I tried this out with 0x66 in support/required but it still does not work. The serverside message (org.omg.CORBA.NO_PERMISSION: Connection should be SSL, but isn't ... ) is still the same. Did you already successfully connect Mico 2.3.6 with Jacorb 1.3.30 under Windows NT using SSL? If so, did you have to change anything in the sources? Thanks in advance, Konrad -----Urspr?ngliche Nachricht----- Von: Timothy Wall [mailto:twall@oculustech.com] Gesendet: Freitag, 1. Februar 2002 18:59 An: mico-devel@mico.org Cc: Reiter, Konrad Betreff: Re: Mico <--> JacORB using SSL Check the options being passed into SSLComponent for supports/requires to make sure they match that in Jacorb. Your jacorb options probably need to be at least 0x66 to match the defaults in mico. T. _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From rmartony at cue.com.uy Mon Feb 4 11:15:13 2002 From: rmartony at cue.com.uy (=?iso-8859-1?Q?Rafael_M=E1rtony?=) Date: Fri Sep 5 12:44:02 2003 Subject: [mico-devel] Using Valuetypes... Message-ID: Hello MICO users, I'm relatively new to CORBA and MICO. I would need help to solve the following problem. I have a simple IDL like this: --- valuetype CPerfilC { long getId(); void setId(in long id); string getNombre(); void setNombre(in string name); private long Id; private string Name; }; interface CBDPerfilC { void updatePerfil(in CPerfilC perfil,in string mode); CPerfilC getPerfil(in long Id); }; --- Now, I implemented CPerfilC_impl.cpp and CBDPerfil_impl.cpp. In particular, the problem is in "getPerfil", I guess. I have tested all other methods succesfully. --- CPerfilC* CBDPerfilC_impl::getPerfil(CORBA::Long perfilId) { // ... do some stuff here CPerfilC_var result = new CPerfilC_impl(); result->setIdentificador(someLong); result->setNombre(someString); return result; } --- On the client side, I get an error whenever I try to execute the last of these sentences: --- obj = orb->bind ("IDL:CBDPerfilC:1.0", dir_inet); if (CORBA::is_nil (obj)) { AfxMessageBox ("Error: Bind failed.\n"); return FALSE; } CBDPerfilC_ptr perbd = CBDPerfilC::_narrow (obj); CPerfilC *perf = perbd->getPerfil(3); --- The idea is that getPerfil should return a pointer to a copy of result. What can I do to solve the problem? Thank you in advance, Rafael Martony. -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2196 bytes Desc: not available Url : http://www.mico.org/pipermail/mico-devel/attachments/20020204/883556f4/winmail.bin From rigriff at chimera.grc.nasa.gov Mon Feb 4 09:49:22 2002 From: rigriff at chimera.grc.nasa.gov (Robert I Griffin) Date: Fri Sep 5 12:44:02 2003 Subject: [mico-devel] Best way to shut down a remote service Message-ID: <02020409492201.00718@chimera> What is the best way to shut-down a remote service? I need to do this to free up the port that I am using. The remote service has been subclassed from Life Cycle Object (that was a pain), but I am starting the server process from a different machine using a Globus-derived CORBA service and need to terminate the Job altogether. I am using Mico-2.3.5 on an SGI Origin 2000. -Bob _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From ctxbsw at comp.leeds.ac.uk Mon Feb 4 15:22:01 2002 From: ctxbsw at comp.leeds.ac.uk (Ben) Date: Fri Sep 5 12:44:02 2003 Subject: [mico-devel] Compile problems In-Reply-To: Message-ID: > it looks like you are working on M$ os with gnu gcc. I assume that you > have installed gcc as part of cygnus cygwin product. If so, then you can > easily follow UNIX installation instructions and use ./configure; make; > make install. Please read file INSTALL. Thanks, thats very helpful. I apprecaite this isnt the best place to ask, but does anyone know whick package the configure program lives in. I have downloaded make, automake, autoconf, etc- but my comp still doesnt know of a configure program. I am using cygwin, but Im sure it is available still. Regards Ben -- Ben Wootton ctxbsw@comp.leeds.ac.uk _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From Arnaud.Bailly at lifl.fr Mon Feb 4 16:39:48 2002 From: Arnaud.Bailly at lifl.fr (Arnaud Bailly) Date: Fri Sep 5 12:44:02 2003 Subject: [mico-devel] Dynamic loading In-Reply-To: References: <15450.28283.746102.188775@argus.lifl.fr> Message-ID: <15454.43844.516121.16244@argus.lifl.fr> Thanks for your answer, although it is not the one I intended to get :-) Yes, I know there exists a CCM implementation in MICO and I played with it a little. I have already used CCM on OpenCCM (the LIFL one) and find the model very convenient. I think I will use it anyway. But I just tried to use plain CORBA and experiment with it so I'm a bit disappointed I can't manage to run my example as a shared library. By the way, I am interested in Interceptors. I have read the demo but I can't manage to link the example with the specs. I am wrong or the Interceptor in the demo is not up-to-date with the CORBA specs ? Arnaud Bailly _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From kgardas at iol.cz Mon Feb 4 17:06:15 2002 From: kgardas at iol.cz (Karel Gardas) Date: Fri Sep 5 12:44:03 2003 Subject: [mico-devel] Dynamic loading In-Reply-To: <15454.43844.516121.16244@argus.lifl.fr> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 4 Feb 2002, Arnaud Bailly wrote: > Thanks for your answer, although it is not the one I intended to get :-) > > Yes, I know there exists a CCM implementation in MICO and I played with it > a little. I have already used CCM on OpenCCM (the LIFL one) and find the > model very convenient. I think I will use it anyway. > > But I just tried to use plain CORBA and experiment with it so I'm a bit > disappointed I can't manage to run my example as a shared library. > > By the way, I am interested in Interceptors. I have read the demo but > I can't manage to link the example with the specs. I am wrong or the > Interceptor in the demo is not up-to-date with the CORBA specs ? > I think that it was in CORBA 2.5 where there are interceptor chapter replaced with portable interceptors. So if you are using CORBA2.5 or 2.6 then the interceptors in spec. looks really different than the mico implementation. Cheers, Karel PS: ObjectSecurity Ltd. (http://www.objectsecurity.com) has Portable Interceptors implementation for MICO and it looks like they will contribute it into main mico in the future. -- Karel Gardas e-mail: kgardas@iol.cz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE8XrF5qREvenJ7UIYRAnSgAJ98z6jF0n38wJG6SCfgNkSN03GjmQCdGWaX k6pX3XLv43z8H5NtuSmWlmw= =F+J+ -----END PGP SIGNATURE----- _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From kgardas at iol.cz Mon Feb 4 17:08:11 2002 From: kgardas at iol.cz (Karel Gardas) Date: Fri Sep 5 12:44:03 2003 Subject: [mico-devel] Compile problems In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 4 Feb 2002, Ben wrote: > > > it looks like you are working on M$ os with gnu gcc. I assume that you > > have installed gcc as part of cygnus cygwin product. If so, then you can > > easily follow UNIX installation instructions and use ./configure; make; > > make install. Please read file INSTALL. > > Thanks, thats very helpful. I apprecaite this isnt the best place to ask, > but does anyone know whick package the configure program lives in. I have > downloaded make, automake, autoconf, etc- but my comp still doesnt know of > a configure program. I am using cygwin, but Im sure it is available still. > Script mico/configure is a result of processing file configure.in by autoconf. It's already included in mico so you don't need to run autoconf yourself. Just start it with ./configure in cygwin's shell. Cheers, Karel - -- Karel Gardas e-mail: kgardas@iol.cz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE8XrHuqREvenJ7UIYRAkJJAJ40PzlxBTFCZAf+Fsd3LgC+1atqkwCcCHYO xLp53CFenAsMUeE0A468ueY= =gSO0 -----END PGP SIGNATURE----- _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From begic at cs.tu-berlin.de Mon Feb 4 17:31:39 2002 From: begic at cs.tu-berlin.de (Slaven Begic) Date: Fri Sep 5 12:44:03 2003 Subject: [mico-devel] LINK_BUG_OBJS in Makefile.win32 Message-ID: <001301c1ad99$6d2aaf40$a0199582@ivs26> Hi, I would like to compile mico as static librarys in Visual C++. Do i need to use LINK_BUG_OBJS from Makefile.win32 and how? thanks, Slaven -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.mico.org/pipermail/mico-devel/attachments/20020204/75d1d6dc/attachment.htm From Dominic.Pellerin at ericsson.ca Mon Feb 4 13:24:57 2002 From: Dominic.Pellerin at ericsson.ca (Dominic Pellerin (LMC)) Date: Fri Sep 5 12:44:03 2003 Subject: [mico-devel] Compilation problem with postgresql Message-ID: <7B2A7784F4B7F0409947481F3F3FEF8301E2E34D@eammlnt051.lmc.ericsson.se> Does anybody have an idea why make fails when I try to compile with pgsql? pgsql is needed for auditing (CorbaSec) so I installed it (ver 7.1.3) because I need it. Mico seems to find it during configuration... I configure mico this way: ./configure --with-ssl=/usr/local/ssl --with-pgsql=/usr/local/pgsql --enable-csl2 --enable-debug loading cache ./config.cache checking for extra include and lib directories... + found /usr/local/include + found /usr/local/lib + found /usr/local/ssl/include + found /usr/local/ssl/lib + found /usr/local/ssl/bin + found /usr/local/pgsql/include + found /usr/local/pgsql/lib + found /usr/local/pgsql/bin checking host system type... i686-pc-linux-gnu ... then... [root@pc5 mico]# make for i in admin include; do make -C $i adm || exit 1; done make[1]: Entering directory `/usr/local/mico/admin' c++ -I../include -g -O -fpermissive -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/pgsql/include -c mkdepend.cc -o mkdepend.o c++ -I../include -g -O -fpermissive -L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/pgsql/lib -rdynamic mkdepend.o -lpq -lssl -lcrypto -ldl -lbsd -lm -o mkdepend sed -e s,@TCLSH@,/usr/bin/tclsh,g < mkbook.in > mkbook chmod +x mkbook make[1]: Leaving directory `/usr/local/mico/admin' make[1]: Entering directory `/usr/local/mico/include' make[1]: Nothing to be done for `adm'. make[1]: Leaving directory `/usr/local/mico/include' for i in orb ir idl auxdir coss ccm; do make -C $i lib || exit 1; done make[1]: Entering directory `/usr/local/mico/orb' echo '# Module dependencies' > .depend /usr/local/mico/./admin/mkdepend -I../include -g -O -fpermissive -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/pgsql/include *.cc >> .depend /usr/local/mico/./admin/mkdepend: error while loading shared libraries: libpq.so.2: cannot load shared object file: No such file or directory make[1]: *** [.depend] Error 127 make[1]: Leaving directory `/usr/local/mico/orb' make: *** [system] Error 1 but the file libpq.so.2 is present! [root@pc5 mico]# ll /usr/local/pgsql/lib/ total 332 -rw-r--r-- 1 root root 45214 Feb 1 15:22 libecpg.a lrwxrwxrwx 1 root root 16 Feb 1 15:22 libecpg.so -> libecpg.so.3.2.0 lrwxrwxrwx 1 root root 16 Feb 1 15:22 libecpg.so.3 -> libecpg.so.3.2.0 -rwxr-xr-x 1 root root 38675 Feb 1 15:22 libecpg.so.3.2.0 -rw-r--r-- 1 root root 6592 Feb 1 15:22 libpgeasy.a lrwxrwxrwx 1 root root 16 Feb 1 15:22 libpgeasy.so -> libpgeasy.so.2.1 lrwxrwxrwx 1 root root 16 Feb 1 15:22 libpgeasy.so.2 -> libpgeasy.so.2.1 -rwxr-xr-x 1 root root 10777 Feb 1 15:22 libpgeasy.so.2.1 -rw-r--r-- 1 root root 67500 Feb 1 15:22 libpq.a lrwxrwxrwx 1 root root 12 Feb 1 15:22 libpq.so -> libpq.so.2.1 lrwxrwxrwx 1 root root 12 Feb 1 15:22 libpq.so.2 -> libpq.so.2.1 -rwxr-xr-x 1 root root 63168 Feb 1 15:22 libpq.so.2.1 -rwxr-xr-x 1 root root 80234 Feb 1 15:22 plpgsql.so ??? Why ??? _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From kgardas at iol.cz Mon Feb 4 19:59:54 2002 From: kgardas at iol.cz (Karel Gardas) Date: Fri Sep 5 12:44:03 2003 Subject: [mico-devel] Compilation problem with postgresql In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF8301E2E34D@eammlnt051.lmc.ericsson.se> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 4 Feb 2002, Dominic Pellerin (LMC) wrote: > Does anybody have an idea why make fails when I try to compile with pgsql? > pgsql is needed for auditing (CorbaSec) so I installed it (ver 7.1.3) > because I need it. > > Mico seems to find it during configuration... > > I configure mico this way: > > ./configure --with-ssl=/usr/local/ssl --with-pgsql=/usr/local/pgsql > --enable-csl2 --enable-debug > loading cache ./config.cache > checking for extra include and lib directories... > + found /usr/local/include > + found /usr/local/lib > + found /usr/local/ssl/include > + found /usr/local/ssl/lib > + found /usr/local/ssl/bin > + found /usr/local/pgsql/include > + found /usr/local/pgsql/lib > + found /usr/local/pgsql/bin > checking host system type... i686-pc-linux-gnu > ... > > > then... > > > [root@pc5 mico]# make > for i in admin include; do make -C $i adm || exit 1; done > make[1]: Entering directory `/usr/local/mico/admin' > c++ -I../include -g -O -fpermissive -I/usr/local/include > -I/usr/local/ssl/include -I/usr/local/pgsql/include -c mkdepend.cc -o > mkdepend.o > c++ -I../include -g -O -fpermissive -L/usr/local/lib -L/usr/local/ssl/lib > -L/usr/local/pgsql/lib -rdynamic mkdepend.o -lpq -lssl -lcrypto -ldl -lbsd > -lm -o mkdepend > sed -e s,@TCLSH@,/usr/bin/tclsh,g < mkbook.in > mkbook > chmod +x mkbook > make[1]: Leaving directory `/usr/local/mico/admin' > make[1]: Entering directory `/usr/local/mico/include' > make[1]: Nothing to be done for `adm'. > make[1]: Leaving directory `/usr/local/mico/include' > for i in orb ir idl auxdir coss ccm; do make -C $i lib || exit 1; done > make[1]: Entering directory `/usr/local/mico/orb' > echo '# Module dependencies' > .depend > /usr/local/mico/./admin/mkdepend -I../include -g -O -fpermissive > -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/pgsql/include > *.cc >> .depend > /usr/local/mico/./admin/mkdepend: error while loading shared libraries: > libpq.so.2: cannot load shared object file: No such file or directory > make[1]: *** [.depend] Error 127 > make[1]: Leaving directory `/usr/local/mico/orb' > make: *** [system] Error 1 > > > but the file libpq.so.2 is present! > > [root@pc5 mico]# ll /usr/local/pgsql/lib/ > total 332 > -rw-r--r-- 1 root root 45214 Feb 1 15:22 libecpg.a > lrwxrwxrwx 1 root root 16 Feb 1 15:22 libecpg.so -> > libecpg.so.3.2.0 > lrwxrwxrwx 1 root root 16 Feb 1 15:22 libecpg.so.3 -> > libecpg.so.3.2.0 > -rwxr-xr-x 1 root root 38675 Feb 1 15:22 libecpg.so.3.2.0 > -rw-r--r-- 1 root root 6592 Feb 1 15:22 libpgeasy.a > lrwxrwxrwx 1 root root 16 Feb 1 15:22 libpgeasy.so -> > libpgeasy.so.2.1 > lrwxrwxrwx 1 root root 16 Feb 1 15:22 libpgeasy.so.2 -> > libpgeasy.so.2.1 > -rwxr-xr-x 1 root root 10777 Feb 1 15:22 libpgeasy.so.2.1 > -rw-r--r-- 1 root root 67500 Feb 1 15:22 libpq.a > lrwxrwxrwx 1 root root 12 Feb 1 15:22 libpq.so -> > libpq.so.2.1 > lrwxrwxrwx 1 root root 12 Feb 1 15:22 libpq.so.2 -> > libpq.so.2.1 > -rwxr-xr-x 1 root root 63168 Feb 1 15:22 libpq.so.2.1 > -rwxr-xr-x 1 root root 80234 Feb 1 15:22 plpgsql.so > > Hi, It looks like that you don't have /usr/local/pgsql/lib/ in your LD_LIBRARY_PATH. Please enter this: ''export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib/'' on your commandline and then try make again Cheers, Karel - -- Karel Gardas e-mail: kgardas@iol.cz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE8XtovqREvenJ7UIYRAqsVAKCYmvefFCcV/taXqsrwrBthLVlc/ACeOXB6 3ph+DaEqHF/EQhKwOcAgQfU= =N52N -----END PGP SIGNATURE----- _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From ras at objectsecurity.com Mon Feb 4 20:41:01 2002 From: ras at objectsecurity.com (Rudolf Schreiner) Date: Fri Sep 5 12:44:03 2003 Subject: [mico-devel] Compilation problem with postgresql In-Reply-To: <7B2A7784F4B7F0409947481F3F3FEF8301E2E34D@eammlnt051.lmc.ericsson.se> Message-ID: On Mon, 4 Feb 2002, Dominic Pellerin (LMC) wrote: > [root@pc5 mico]# make > /usr/local/mico/./admin/mkdepend: error while loading shared libraries: > libpq.so.2: cannot load shared object file: No such file or directory > make[1]: *** [.depend] Error 127 > make[1]: Leaving directory `/usr/local/mico/orb' > make: *** [system] Error 1 Is your /etc/ld.so.conf correct? Did you run ldconfig? Cheers, Rudi ps: BTW, please send MICOSec related questions to micosec@objectsecurity.com. ------------------------------------------------------------------------ Rudolf Schreiner, CTO, ObjectSecurity Ltd. St John's Innovation Centre, Cowley Rd., Cambridge CB4 0WS Tel. +44 1223 420252, Fax. +44 1223 420844 ras@objectsecurity.com, www.objectsecurity.com ------------------------------------------------------------------------ _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From trtrash at gmx.de Tue Feb 5 17:49:45 2002 From: trtrash at gmx.de (Torsten Rohlfs) Date: Fri Sep 5 12:44:03 2003 Subject: [mico-devel] Problems with the account demo Message-ID: <30918.1012927785@www51.gmx.net> Hi there, I have a little problem which I can't solve: I have installed mico on my Suse Linux 7.3 machine with the usual procedure unzip, configure, gmake Everything works fine to this point so I started with the Online manual and tried the first demo that account thing. The first point creating the account.idl works fine but after that I can't compile the main.cc I get an error message like this and it doesn't matter which compiler I use (gcc or the mico one): 6: parse error before '{' In function 'void deposit(long unsigned int)': 17: '_current_ballance' undeclared (first use this function) and so on.... So the second step was to write the demo by myself but it did not work I get the same error message... I would be gratefull for any help... -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From PWallenda at t-online.de Thu Feb 7 18:16:50 2002 From: PWallenda at t-online.de (Peter Wallenda) Date: Fri Sep 5 12:44:03 2003 Subject: [mico-devel] Unshared Server Message-ID: Hello all together, I'm developing a client/server-application under VC++ and MICO 2.3.6. The server processes have to run under Windows NT and(!) Sun OS, where the one and only client is a windows-programm (NT/2000/XP). Because it will be possible that different users start the windows-client on different stations, I decided to implement the servers as "unshared". Now I'm very happy that I have a projekt that compile and link under VC++ and under GNU-C++ and the resulting programs are running on both systems - Windows and Sun - perfectly. But I detected that unshared servers under Windows NT are not running unshared (I didn't test this under Sun yet) - there is only one process!!! Again and again I looked in the Impl.Repository - everything seems to be ok - I can see the word "unshared". Then I compared my server-sources with the mico-samples and the advices in the documents for unshared servers - everything seems to be ok too. Than I took an "unshared" sample-program from the mico-samples, compiled it under VC++ and let it run - there was just one(!) server-process, although there were two (and more) clients! I'm despairing! Who can help me? Many thanks in advance! Peter _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From kgardas at iol.cz Thu Feb 7 20:13:22 2002 From: kgardas at iol.cz (Karel Gardas) Date: Fri Sep 5 12:44:04 2003 Subject: [mico-devel] Unshared Server In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Thu, 7 Feb 2002, Peter Wallenda wrote: > Hello all together, > > I'm developing a client/server-application under VC++ and MICO 2.3.6. The > server processes have to run under Windows NT and(!) Sun OS, where the one > and only client is a windows-programm (NT/2000/XP). Because it will be > possible that different users start the windows-client on different > stations, I decided to implement the servers as "unshared". Now I'm very I think it is a bad assumption. You don't need to use unshared, for many client on many stations. > happy that I have a projekt that compile and link under VC++ and under > GNU-C++ and the resulting programs are running on both systems - Windows and > Sun - perfectly. But I detected that unshared servers under Windows NT are > not running unshared (I didn't test this under Sun yet) - there is only one > process!!! Again and again I looked in the Impl.Repository - everything > seems to be ok - I can see the word "unshared". Then I compared my Can you provide us with imr listing? > server-sources with the mico-samples and the advices in the documents for > unshared servers - everything seems to be ok too. Than I took an "unshared" > sample-program from the mico-samples, compiled it under VC++ and let it > run - there was just one(!) server-process, although there were two (and > more) clients! > May I suggest you rewritting your application into POA-based? It'll be more uptodate to today's standard. Cheers, Karel - -- Karel Gardas e-mail: kgardas@iol.cz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE8YtHUqREvenJ7UIYRAhJ8AJ9XartgEGXtg6vEqMYbvXBeLXWLVACeII2f u5PVuWuM7k+qaqnk+sbtnto= =DT78 -----END PGP SIGNATURE----- _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From PWallenda at t-online.de Fri Feb 8 20:27:42 2002 From: PWallenda at t-online.de (Peter Wallenda) Date: Fri Sep 5 12:44:04 2003 Subject: [mico-devel] Unshared Server Message-ID: Hi Karel, thank you for your answer! I think it'll be good to provide you (and the others here) with more information about my "Mico-Program": The software which I develop is a peace of a more bigger complex of processes - some of them uses CORBA too, but with the "BOA" approach. This is from former times where the use of the BOA was the only possible way under CORBA. Now it's one of the circumstances in this project I have to accept. I'm not the only one developer in our company, there are much more and some parts of the software are developed from foreign companies. So it's impossible for me to decide everything for my own, but - in the next project meeting I will ask for changing from BOA to POA... But nevertheless - BOA, POA, what ever else ... - the "unshared" mode must work under both versions - I know it from years ago where I worked with IONA's Corba and it wasn't a great deal to start servers unshared. You say I haven't to use unshared servers for many clients, but let me tell you why I had the idea for the unshared servers - maybe my thinking was/is wrong... Each server holds an object which is designed as factory for other (different) objects, one is for database access, the other is for browsing XML documents, the next for ... At the time where one of the clients stops accessing one of the servers the reference count in the factory object reaches 0 and the factory object calls "orb->shutdown()". Now imagine another client somewhere in the network calls a method from the factory object in the shared(!) server just before the code reaches the shutdown-method. Because the object is still known for the BOA, it will say: "Ok I have an instance of this object in a running server, you can have it!". The BOA will try to delegate the call but - meanwhile the shutdown method in the server process is called and the object instance isn't valid. There will be a crash, isn't it? That was for me a reason to think that this problem is easy solved when I use unshared server - each client starts its own server with a factory for object instances which are only accessible for the calling client. Because I'm not a CORBA profi it's possible that I will not overlook everything in this context and my thinking is definitely wrong - it'll be nice if you or somebody else can bring me on the right way :-) Here is the content of my IMR - maybe there(!) is something wrong? 4 NCBegIfFactory unshared C:\\Develop\\beg\\bin\\WinNT\\Debug\\beg IDL:NCFactoryInterface/NCBegIfFactory:1.0 NCXmlIfFactory unshared C:\\Develop\\beg\\bin\\WinNT\\Debug\\xml IDL:NCFactoryInterface/NCXmlIfFactory:1.0 NCBrowseClarifyIfFactory unshared C:\\Develop\\beg\\bin\\WinNT\\Debug\\BrowseClarify IDL:NCFactoryInterface/NCBrowseClarifyIfFactory:1.0 NCBrowseMdbeIfFactory unshared C:\\Develop\\beg\\bin\\WinNT\\Debug\\BrowseMdbe IDL:NCFactoryInterface/NCBrowseMdbeIfFactory:1.0 Many thanks for everything and have a nice weekend! Peter _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From kgardas at iol.cz Fri Feb 8 22:37:25 2002 From: kgardas at iol.cz (Karel Gardas) Date: Fri Sep 5 12:44:04 2003 Subject: [mico-devel] Unshared Server In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 8 Feb 2002, Peter Wallenda wrote: > Hi Karel, > > thank you for your answer! > > I think it'll be good to provide you (and the others here) with more > information about my "Mico-Program": > > The software which I develop is a peace of a more bigger complex of > processes - some of them uses CORBA too, but with the "BOA" approach. This > is from former times where the use of the BOA was the only possible way > under CORBA. Now it's one of the circumstances in this project I have to > accept. I'm not the only one developer in our company, there are much more > and some parts of the software are developed from foreign companies. So it's > impossible for me to decide everything for my own, but - in the next project > meeting I will ask for changing from BOA to POA... OK, you have some code - let say legacy - which uses BOA, because it was written before POA arrived. I don't understand for which reason you can not use POA for app developed today? > But nevertheless - BOA, POA, what ever else ... - the "unshared" mode must > work under both versions - I know it from years ago where I worked with NO! Look. BOA as a basic object adapter wasn't too sucessfull with separation of word of CORBA Objects and word of Servants. Both words are mixed in BOA and so you have to use various ''activation'' modes for various kind of CORBA Objects. It's not true with POA. For example MICO Implementation Repository supports five activations mode for BOA-based servers: persistent, shared, unshared, permethod and library. At the oposite it supports the only one mode for POA-based server - it is called simple ''poa'' It would be great if you can read some chapters from famous ''Advanced CORBA Programming with C++'' book or if you don't have it, you can download four papers from Douglas Schmidt's web site which explains main features behind POA. > IONA's Corba and it wasn't a great deal to start servers unshared. > You say I haven't to use unshared servers for many clients, but let me tell > you why I had the idea for the unshared servers - maybe my thinking was/is > wrong... Each server holds an object which is designed as factory for other > (different) objects, one is for database access, the other is for browsing > XML documents, the next for ... At the time where one of the clients stops > accessing one of the servers the reference count in the factory object > reaches 0 and the factory object calls "orb->shutdown()". Now imagine But this is only behaviour of your application not generall behaviour of CORBA app! > another client somewhere in the network calls a method from the factory > object in the shared(!) server just before the code reaches the > shutdown-method. Because the object is still known for the BOA, it will say: > "Ok I have an instance of this object in a running server, you can have > it!". The BOA will try to delegate the call but - meanwhile the shutdown > method in the server process is called and the object instance isn't valid. > There will be a crash, isn't it? That was for me a reason to think that this > problem is easy solved when I use unshared server - each client starts its > own server with a factory for object instances which are only accessible for > the calling client. > OK, lets write POA-based server: It'll have N+1 POAs where N is number of different object you have. All factories objects will be activated in RootPOA and will create it's objects and activate them in POA provided for this kind of object. For destroying object you can write 'destroy' operation. Is there any reason for destroying factories? If so and if you'd like to exit server process after destroying all factories then you have to properly implement 'destroy' operations on your factories objects. Maybe you can look at mico/demo/poa and study these examples. Cheers, Karel - -- Karel Gardas e-mail: kgardas@iol.cz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE8ZEUYqREvenJ7UIYRAs49AJ9vNU0sG8+LyVXuNoiGZS+uvOHJMgCgjD+6 68RjElz3Hm98inDCYp9g00I= =9UXr -----END PGP SIGNATURE----- _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From dirk at srx6.de Mon Feb 11 09:37:05 2002 From: dirk at srx6.de (Dirk Thomalla) Date: Fri Sep 5 12:44:04 2003 Subject: [mico-devel] Mico + fork(), empty ORB::destroy implementation Message-ID: I have a problem with Mico and a server process forking childs. Only the corba calls in one process are working as expected; the others are blocked/hanging. If the corba stuff (and ORB_init) in the parent is omitted, both childs work fine. I think the problem is an incomplete implementation of ORB::destroy in mico. This function is empty in orb.cc: CORBA::ORB::destroy() { // XXX shutdown and destroy ORB; calling ORB_init() afterwards // must create a new ORB instance } Any hints or comments? Pseudo code below: ///////////// void main(...) { orb = ORB_init(...); call_some_corba_things(); // works fork_child_1(...); fork_child_2(...); call_some_corba_things(); // blocked } void fork_child_1(...) { pid_t pid = fork(); switch (pid) { case -1: // error break; case 0: // child orb->shutdown(true); orb->destroy(); orb = ORB_init(...); call_some_other_corba_things(); // works _exit(0); break; default: // parent return; } } void fork_child_2(...) { pid_t pid = fork(); switch (pid) { case -1: // error break; case 0: // child orb->shutdown(true); orb->destroy(); orb = ORB_init(...); call_some_other_corba_things(); // blocked _exit(0); break; default: // parent return; } } ///////////// -- - Dirk http://www.srx6.de/dirk/ _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From kgardas at iol.cz Mon Feb 11 09:58:38 2002 From: kgardas at iol.cz (Karel Gardas) Date: Fri Sep 5 12:44:04 2003 Subject: [mico-devel] Re: Sorry In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 11 Feb 2002, Peter Wallenda wrote: > Hello Karel, > > I beg your pardon, but - I have the first problem with this POA! > > To get more experience with CORBA I took your advice and ordered this book > "Advanced CORBA Programming with C++" from AMAZONE - I hope to get it in the > next days (huh - it's expensive!). Good! It's expensive but *excelent* about CORBA programming in C++. You'll see! > But not to wait so long until I have this book, I compiled the POA sample > account-3 from the MICO sources under VC++. I start the client in debug mode I assume that you've started with more simpler examples hello-1, hello-2, inherit, account-1, account-2. Am I right? Do you have any problems with them? > and can see that the server starts the first time with the first call > "bank->create()" and ends with the first "bank->shutdown()" call. But with > the next call "account->deposit(700)" the client crashes with an unhandled > exception in the msvcrt(d).dll, the shell output from the client is > "unhandled WSAGetLastError() result WSA:10061 = WSAECONNREFUSED". I checked > the project settings for all the MICO stuff that it was linked with > multithreaded DLL version of the runtime libraries (with the original > make-files it's not made!) - ok! Then I checked my project settings for the > client and the server - both are linked with the multithreaded DLL version > of the runtime libraries - ok! Then I searched for similar problems in the > mico-mailing-list and found that some other had the same problem with this > or other samples in case of POA and CORBA under Windows, but there wasn't > any answer for their problem. [...] > What do you think? Do you have any solutions for this problems or some tips > where I can look what might be? > This example (poa/account-3) runs well on my Debian GNU/Linux 3.0, so it looks like there is windows related problem either Windows or MICO code (for platform Windows) is buggy. I have Windows 2000 (bought with computer :-((((), but I don't have VC++ (too expensive and very buggy) so I can not track the problem down. Cheers, Karel - -- Karel Gardas e-mail: kgardas@iol.cz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE8Z4fDqREvenJ7UIYRAuZkAJwOf+tzN/GG3KITuS3ZdXXX7QZHAgCdEIoB Eh2KUKh4pBxoZp5WC0EoREc= =fai9 -----END PGP SIGNATURE----- _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From lhillion at harris.com Mon Feb 11 05:19:27 2002 From: lhillion at harris.com (Hillion, Lionel) Date: Fri Sep 5 12:44:04 2003 Subject: [mico-devel] while we're on the subject of examples. (LifeCyc le) Message-ID: <7521AC4066EED111842500A0C9B42289F34C9F@rnsmx1.bpd.harris.com> > I'm using 2.3.6 and am having an absolutely horrible time trying to get >the lifecycle example to compile. First, the idl chokes on the idl-file (with the flags used in the 'Makefile'): Hi Bob, I have encountered the same problem than you with Mico 2.3.5 and the LifeCycle service & its examples. Obviously, the lifecycle service isn't ready at all since it was remarked in mico's makefile. Consequently, I have renounce to use it. I am disapointed on this since the LifeCycle service was stated available in Mico's features List. I assume we have to wait and see when it is ready. But maybe, did you manage to make the examples work since your post in december ??? Cheers. Lionel H _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From 520065607613-0001 at t-online.de Mon Feb 11 12:01:46 2002 From: 520065607613-0001 at t-online.de (Frank Pilhofer) Date: Fri Sep 5 12:44:04 2003 Subject: [mico-devel] On Open Source (was: while we're on the subject of examples.) In-Reply-To: <7521AC4066EED111842500A0C9B42289F34C9F@rnsmx1.bpd.harris.com>; from lhillion@harris.com on Mon, Feb 11, 2002 at 05:19:27AM -0500 References: <7521AC4066EED111842500A0C9B42289F34C9F@rnsmx1.bpd.harris.com> Message-ID: <20020211120146.F543@rose.fpx.de> Hillion, Lionel wrote: > > I assume we have to wait and see when it is ready. > No, don't wait. Contribute. Working with Mico is not a one-way street. Mico is an open source project. There are some people who are working on the Mico core, but we have our own schedules, priorities, deadlines, and interests. Waiting for a fix to happen is a good bet in some areas but like the lottery in others. If there's something that "bugs" you, fix it. Then post a patch. Frank -- Frank Pilhofer ........................................... fp@fpx.de If at first you don't succeed ... you're about normal. - A. E. Neuman _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From 520065607613-0001 at t-online.de Mon Feb 11 12:05:08 2002 From: 520065607613-0001 at t-online.de (Frank Pilhofer) Date: Fri Sep 5 12:44:04 2003 Subject: [mico-devel] Using Valuetypes... In-Reply-To: ; from rmartony@cue.com.uy on Mon, Feb 04, 2002 at 11:15:13AM -0300 References: Message-ID: <20020211120508.G543@rose.fpx.de> Rafael M?rtony wrote: > > I'm relatively new to CORBA and MICO. > > In particular, the problem is in "getPerfil", I guess. > Don't forget to register a Valuetype Factory for your Valuetype (see e.g. demo/obv/date/). Frank -- Frank Pilhofer ........................................... fp@fpx.de Some minds are like concrete ... all mixed up and permanently set. - Alfred E. Neuman _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From 520065607613-0001 at t-online.de Mon Feb 11 12:10:58 2002 From: 520065607613-0001 at t-online.de (Frank Pilhofer) Date: Fri Sep 5 12:44:04 2003 Subject: [mico-devel] MICO, namespaces and older compilers In-Reply-To: ; from apm35@student.open.ac.uk on Sun, Feb 03, 2002 at 08:30:00PM +0000 References: <200202032010.g13KAA306582@mico.org> Message-ID: <20020211121058.H543@rose.fpx.de> Andrew Marlow wrote: > > This is because MICO must be compiled by a compiler that supports > namespaces. I have a Sun workstation with the Sparcworks 4.2 compiler and > an HP workstation running HPUX 10.20 with a rather old CC compiler (which > is fairly standard for HP 10.20). > Hi, sorry about that. I won't repeat the arguments here, but what about a new one. Both HP and Sun have updated compilers available that support namespaces and therefore work with Mico. So you want to upgrade Mico, but refuse to upgrade your environment? I understand that this is probably because of legacy libraries that were built with the old compiler, but they shouldn't be impossible to upgrade, are they? Frank -- Frank Pilhofer ........................................... fp@fpx.de The reason most people are lost in thought is because it's unfamiliar territory. - Alfred E. Neuman _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From 520065607613-0001 at t-online.de Mon Feb 11 12:13:08 2002 From: 520065607613-0001 at t-online.de (Frank Pilhofer) Date: Fri Sep 5 12:44:04 2003 Subject: [mico-devel] No CORBA namespace in fixed.h? In-Reply-To: <5.1.0.14.2.20020203162432.00bc0898@mail>; from david@2good.nu on Sun, Feb 03, 2002 at 04:28:03PM +0100 References: <5.1.0.14.2.20020203162432.00bc0898@mail> Message-ID: <20020211121308.I543@rose.fpx.de> David Eriksson wrote: > > Why is the contents of MICO's fixed.h not in the CORBA namespace? > Historic. When namespaces could still be emulated by structures, templates might not be in them. Frank -- Frank Pilhofer ........................................... fp@fpx.de Experience is something you never have until just after you need it. - Alfred E. Neuman _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From alastairg at pearpoint-ips.co.uk Mon Feb 11 11:49:42 2002 From: alastairg at pearpoint-ips.co.uk (Alastair Growcott) Date: Fri Sep 5 12:44:05 2003 Subject: [mico-devel] Bugs and stuff Message-ID: <000e01c1b2f2$31cc0ad0$0d7d28c3@alastair2000> Hi, I am trying to use MICO with VC++ 6.0 service pack 2 at least, and yes I know it is highly recommended not to. I have the 3rd edition of the manual, and the CD-ROM that came with it. I was trying to use the idl tool that came with the version 232 of MICO on my CD-ROM, and I get a message telling me that the DLL MSVCP50D.dll cannot be found. This tells me two things, firstly that the tool that was built and and released was a debug build and not a release build, and secondly that it was built with an older version of Windows than mine. I know the last because my computer has MSVCP60.dll, MSVCP60D.dll, and MSVCP50.dll (obviously included for backwards compatibility). I then had a look on the website, and was advised to search the mailing list archives before posting a question. After following two or three more links, I find that apparently the only way to do that is to download the entire archive - no thanks. Anyway, since rebuilding the tool is bound to be a total nightmare, I wondered if anyone could point me in the direction of, or email to me, a version of the idl tool that is a release build and preferably recent enough to be built to link with version 6.0 of the MSVCP DLL. Many thanks, Alastair Growcott. _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From 520065607613-0001 at t-online.de Mon Feb 11 14:08:14 2002 From: 520065607613-0001 at t-online.de (Frank Pilhofer) Date: Fri Sep 5 12:44:05 2003 Subject: [mico-devel] Bug in _is_a() implementation In-Reply-To: ; from Rick_Hennig@csgsystems.com on Thu, Jan 31, 2002 at 11:50:52AM -0700 References: Message-ID: <20020211140814.J543@rose.fpx.de> Rick Hennig wrote: > > I've been converting an application that was using a different ORB vendor to > use MICO and have found an interesting problem with using _is_a() > > It seems that is_a() returns TRUE for any derived object that is derived > from a common base class. > Which MICO version is that? I cannot reproduce the problem here. If the problem persists with the current version, please send a test case. Frank -- Frank Pilhofer ........................................... fp@fpx.de I'm a pessimist so that I can be positively suprised by reality. - FP _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From 520065607613-0001 at t-online.de Mon Feb 11 14:13:30 2002 From: 520065607613-0001 at t-online.de (Frank Pilhofer) Date: Fri Sep 5 12:44:05 2003 Subject: [mico-devel] Persistemt POA and IMR In-Reply-To: ; from mmckinla@cs.rmit.edu.au on Tue, Jan 29, 2002 at 10:17:35AM +1100 References: Message-ID: <20020211141330.K543@rose.fpx.de> Mark McKinlay wrote: > > Just wondering if someone could clarify how to get persistent objects with > POA working. I am tring to get a server using POA to register to be > activated by the imr when first accessed by a client. I cannot get the > demo explained in section 4.4.5 of documentation to work either. > > However when I run any server (including supplied demo) using persistent > POA, the exported IOR contains the address of the server not micod, so > this will never work - it is not persistent at all. > The server needs to know the address of the IMR, so you'd have to add either -POARemoteIOR or -POARemoteAddr to point to the "POA Mediator" object within micod. This option is added automatically to the command line by micod, so you shouldn't be starting the server yourself but via "imr activate" after registering the server properly. Frank -- Frank Pilhofer ........................................... fp@fpx.de Live every day as if it were your last, because one of these days you will be right! - Alfred E. Neuman _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From 520065607613-0001 at t-online.de Mon Feb 11 14:32:43 2002 From: 520065607613-0001 at t-online.de (Frank Pilhofer) Date: Fri Sep 5 12:44:05 2003 Subject: [mico-devel] What about _narrow_helpers In-Reply-To: <3C67CB8E.6000508@informatik.hu-berlin.de>; from boehme@informatik.hu-berlin.de on Mon, Feb 11, 2002 at 02:47:58PM +0100 References: <3C67CB8E.6000508@informatik.hu-berlin.de> Message-ID: <20020211143243.L543@rose.fpx.de> Harald B?hme wrote: > > In <20011021165743.D650@rose.fpx.de> it was stated that _narrow_helpers > will not longer be used from 2.3.6 on. So my review show that ist still > in use even for local interfaces where it is not needed. > > So what will be the real state of _narrow_helpers ? > They have disappeared as of version 2.3.6. Are you probably mixing up _narrow_helpers with the _narrow_helper method that every interface still has? What about 'em? Frank -- Frank Pilhofer ........................................... fp@fpx.de Ever notice that to entertain some people all you have to do is listen? - Alfred E. Neuman _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From boehme at informatik.hu-berlin.de Mon Feb 11 14:47:58 2002 From: boehme at informatik.hu-berlin.de (Harald =?UTF-8?B?QsO2aG1l?=) Date: Fri Sep 5 12:44:05 2003 Subject: [mico-devel] What about _narrow_helpers Message-ID: <3C67CB8E.6000508@informatik.hu-berlin.de> Hi all In <20011021165743.D650@rose.fpx.de> it was stated that _narrow_helpers will not longer be used from 2.3.6 on. So my review show that ist still in use even for local interfaces where it is not needed. So what will be the real state of _narrow_helpers ? Regards, Harald -- <<<< Harald B?hme, Berlin 12489 >>>> <<<< Radickestr. 52 >>>> <<<< boehme@informatik.hu-berlin.de >>>> _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From 520065607613-0001 at t-online.de Mon Feb 11 15:59:05 2002 From: 520065607613-0001 at t-online.de (Frank Pilhofer) Date: Fri Sep 5 12:44:05 2003 Subject: [mico-devel] problem with mico-ccm "Hello World" example In-Reply-To: <001d01c1b30f$b89c58e0$030010ac@lema.lt>; from tomas_kaminskas@lema.lt on Mon, Feb 11, 2002 at 05:21:03PM +0200 References: <001d01c1b30f$b89c58e0$030010ac@lema.lt> Message-ID: <20020211155905.N543@rose.fpx.de> Tomas Kaminskas wrote: > > I tried to run "Hello World" example from mico-ccm tutorial. Everything > went write, untill hello_impl.cc compilation. This file is : > > CCM_HelloWorld_ptr create () > { > return new HelloWorld_impl (_initial_message); > } > Hi, sorry, I must have missed this occurence in the code. According to a change that was made in the Language Mapping, this must be Components::EnterpriseComponent_ptr create () { return new HelloWorld_impl (_initial_message); } Frank. -- Frank Pilhofer ........................................... fp@fpx.de A lawyer is someone who writes an eighty-page document and calls it a brief. - Alfred E. Neuman _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From tomas_kaminskas at lema.lt Mon Feb 11 17:21:03 2002 From: tomas_kaminskas at lema.lt (Tomas Kaminskas) Date: Fri Sep 5 12:44:05 2003 Subject: [mico-devel] problem with mico-ccm "Hello World" example Message-ID: <001d01c1b30f$b89c58e0$030010ac@lema.lt> I tried to run "Hello World" example from mico-ccm tutorial. Everything went write, untill hello_impl.cc compilation. This file is : ////////////////////////////////////////////////////////////////////////////////////////////////////////////// #include "hello.h" class HelloWorld_impl : virtual public CCM_HelloWorld { private: CORBA::String_var _message; public: HelloWorld_impl (const char * initial) { _message = initial; } void sayHello () { cout << _message << endl; } void message (const char * val) { _message = val; } char * message () { return CORBA::string_dup (_message); } }; class HelloHome_impl : virtual public CCM_HelloWorld { private: CORBA::String_var _initial_message; public: HelloHome_impl () { _initial_message = CORBA::string_dup ("Hello World"); } CCM_HelloWorld_ptr create () { return new HelloWorld_impl (_initial_message); } void initial_message (const char * val) { _initial_message = val; } char * initial_message () { return CORBA::string_dup (_initial_message); } }; extern "C" { Components::HomeExecutorBase_ptr create_HelloHome () { return new HelloHome_impl; } } ////////////////////////////////////////////////////// I get such error: sorry, not implemented:adjusting pointers for convariant returns. Has anybody got the same error??? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.mico.org/pipermail/mico-devel/attachments/20020211/20be6ae6/attachment.htm From rigriff at chimera.grc.nasa.gov Mon Feb 11 11:10:45 2002 From: rigriff at chimera.grc.nasa.gov (Robert I Griffin) Date: Fri Sep 5 12:44:05 2003 Subject: [mico-devel] Different Binding Mechanisms Message-ID: <02021111104500.21706@chimera> Hello all, I am having problems with different binding mechanisms I am trying to bind to services on a remote machine and have tried 2 different clients using 2 different methods for binding to 2 different services on 2 different machines. Client 1 / Server 1 - poa/account-2/Client Banking Examples Client 2 / Server 2- more complex client requesting open/read/write/close (POSIX-style File IO) operations from a Server Both Clients reside on a 32-bit Linux Cluster and are built using libmico2.3.6 Both Services are Built on SGI Origins Using 64-bit libmico2.3.5 Bind Methods used Method 1 - orb->string_to_object (uri): using a file reference Method 2 - orb->bind("IDL:Bank:1.0","inet:REMOTEADDR:REMOTEPORT"): using known service address; Client Host : Linux Cluster Service Host 1: SGI Origin machine on same network located at this facility; Service Host 2: SGI Origin machine on located at remote facility (on the other side of the USA). I am having 100% success using both Client versions and both Service binding methods to Both Services on Service Host 1. I am having sporadic successes with binding Clients to their respective Services on Service Host 2 The Break down is as follows: Client 1/Server 1: Method 1 Total 23 Attempts at Connection 17 Attempts Resulted in IDL:omg.org/CORBA/COMM_FAILURE:1.0 (0,not-completed) 6 Attempts Resulted in Transactions and return of a Balance Client 1/Server 1: Method 2 Total 36 Attempts at Connection 13 Attempts Resulted in IDL:omg.org/CORBA/COMM_FAILURE:1.0 (0,not-completed) 5 Attempts Resulted in Transactions and return of a Balance 18 Attempts Resulted in Communication, but an inability to get a valid Bank Reference (CORBA::is_nil(obj) = true) Client 2/Server 2: Method 1 Seems to work about 100% of the time (i.e. successful file ops occur); Client 2/Server 2: Method 2 Seems to work sporadically at best with success rates similar to those of Client 1 by either of the binding methods above. Please Note : I have not tested Client2->Server2 as much as I have Client1->Server1. These observation bring some questions to mind: Why would Method1 work better for a more complex service as opposed to a simple service? Why would Method1 work better than Method 2 in the case of a more complex service? Can network Latency or some other speed factor cause the COMM_FAILURES observed in very remote hosts? If so, is it possible to lengthen the Time-Out when contacting these hosts? Could the job priority (NICE-ness) of the server side job affect the successful return of a reference? That is, is it possible that nil object references are returned because of the run priority of the Service? I am assuming that firewalls are not playing a role in causing failure as one would expect 100% Communication Failure if the firewall were prohibiting communication between nodes. I am sure that there could be exceptions, but am not aware of any. If anyone has any particular insight on this subject please feel free to comment. Please Help. Regards, Robert I. Griffin email : rigriff@chimera.grc.nasa.gov phone : (216) 433-2382 NASA Glenn Research Center Building 142, Room 274 21000 Brookpark Rd. Cleveland, OH 44135 _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From agnes.portal at thalesatm.com Mon Feb 11 18:11:18 2002 From: agnes.portal at thalesatm.com (Agnes PORTAL) Date: Fri Sep 5 12:44:05 2003 Subject: [mico-devel] "assertion failed" at run time Message-ID: <3C67FB36.71FF1F56@thalesatm.com> Hello, I work on a dec-alpha Tru64 and I'm trying to compile MICO with gcc 3.0.3. The exe "idl" has been generated but it produces a "core dump" at run time with following error message: > address.cc:524: assertion failed > IOT trap (core dumped) The source line 524 in address.cc is : assert (_ipaddr.size() == sizeof (sin.sin_addr.s_addr)); I get the same error if I try to run "micod". Did anybody meet this problem and have any answer, any advise? Thanks, Agn?s. -------------- next part -------------- A non-text attachment was scrubbed... Name: agnes.portal.vcf Type: text/x-vcard Size: 319 bytes Desc: Carte pour ???? Url : http://www.mico.org/pipermail/mico-devel/attachments/20020211/bd1caee5/agnes.portal.vcf From gthaker at atl.lmco.com Mon Feb 11 14:32:56 2002 From: gthaker at atl.lmco.com (Gautam H Thaker) Date: Fri Sep 5 12:44:06 2003 Subject: [mico-devel] components that support > 1 interface and operation name clashes. Message-ID: <20020211193256.GA19899@atl.lmco.com> Hi, I am trying to modify the "hello" example that comes with mico-ccm. I did: interface Hello { void sayHello (); }; interface Account { typedef sequence opayload; void othruput(in opayload p); }; component HelloWorld supports Hello, Account { attribute string message; }; home HelloHome manages HelloWorld { }; Now my HelloWorld_impl looks like: class HelloWorld_impl : virtual public CCM_HelloWorld { private: CORBA::String_var _msg; public: // from interface Hello void sayHello () { cout << _msg << endl; } char * message () { return CORBA::string_dup (_msg); } void message (const char * msg) { _msg = CORBA::string_dup (msg); } // from interface Account void othruput(const opayload& p) { // do nothing. } }; Everything works fine but what would I have to do if interface "Hello" and "Account" had a operation with same name and signature? -- Gautam H. Thaker Distributed Processing Lab; Lockheed Martin Adv. Tech. Labs A&E 3W; 1 Federal Street; Camden, NJ 08102 856-338-3907, fax 856-338-4144 email: gthaker@atl.lmco.com _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From wasefmasood at yahoo.com Mon Feb 11 11:35:49 2002 From: wasefmasood at yahoo.com (Syed W. Masood) Date: Fri Sep 5 12:44:06 2003 Subject: [mico-devel] Portable Interceptors Message-ID: <20020211193549.97591.qmail@web21406.mail.yahoo.com> Hello, I have installed Mico 2.3.2 (from CD in 3rd edition of Mico Book) on Red Hat Linux 7.1. I understand it does not support Portable Interceptors. Source: My questions are: 1. Do current versions of Mico support Portable Interceptors or is it planned. 2. Is the IIOP implementation in MICO pure/CORBA compliant? Can it be used separately from the rest of MICO. 3.(what subdirectory of Mico/src can i look at the code for MICO IIOP. 4.The Mico Book 3rd edition does not give detailed information about either Interceptors or IIOP. Could you point me to a reference for these. Thanks, Wasef. __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From ras at objectsecurity.com Mon Feb 11 21:12:38 2002 From: ras at objectsecurity.com (Rudolf Schreiner) Date: Fri Sep 5 12:44:06 2003 Subject: [mico-devel] Portable Interceptors In-Reply-To: <20020211193549.97591.qmail@web21406.mail.yahoo.com> Message-ID: On Mon, 11 Feb 2002, Syed W. Masood wrote: > 1. Do current versions of Mico support Portable > Interceptors or is it planned. Our internal MICOSec version supports Portable Interceptors. It will be synced with MICO and released when implementing CSIv2 is finished. Cheers, Rudi ------------------------------------------------------------------------ Rudolf Schreiner, CTO, ObjectSecurity Ltd. St John's Innovation Centre, Cowley Rd., Cambridge CB4 0WS Tel. +44 1223 420252, Fax. +44 1223 420844 ras@objectsecurity.com, www.objectsecurity.com ------------------------------------------------------------------------ _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From 520065607613-0001 at t-online.de Tue Feb 12 09:05:43 2002 From: 520065607613-0001 at t-online.de (Frank Pilhofer) Date: Fri Sep 5 12:44:06 2003 Subject: [mico-devel] components that support > 1 interface and operation name clashes. In-Reply-To: <20020211193256.GA19899@atl.lmco.com>; from gthaker@atl.lmco.com on Mon, Feb 11, 2002 at 02:32:56PM -0500 References: <20020211193256.GA19899@atl.lmco.com> Message-ID: <20020212090543.B429@rose.fpx.de> Gautam H Thaker wrote: > > I am trying to modify the "hello" example that comes with mico-ccm. I did: > > component HelloWorld supports Hello, Account { > attribute string message; > }; > > Everything works fine but what would I have to do if interface "Hello" > and "Account" had a operation with same name and signature? > Hi, this is not allowed; since the equivalent interface for the component inherits all supported interfaces, the same rules as for interface inhe- ritance apply. The alternative would be to have a component that provides the two interfaces as separate facets. Frank -- Frank Pilhofer ........................................... fp@fpx.de When you're in deep water, it's a good idea to keep your mouth shut! - Alfred E. Neuman _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From Arnaud.Bailly at lifl.fr Tue Feb 12 09:25:57 2002 From: Arnaud.Bailly at lifl.fr (Arnaud Bailly) Date: Fri Sep 5 12:44:06 2003 Subject: [mico-devel] Shared Library again ! Message-ID: <15464.53653.479699.748928@argus.lifl.fr> Hello, I come back with my problem yet unsolved. I recall that I am trying to implement dynamically loadable "component modules" : the implementation is compiled into a shared library that is loaded by a unique server. Everything works fine until I try to call a method in my service : I get a Seg fault in the server. Here is the backtrace : #0 0x402591d1 in CORBA::StaticAny::marshal (this=0xbfffefa4, ec=@0x805fc78) at static.cc:137 #1 0x40233f37 in MICO::GIOPRequest::set_out_args (this=0x805fb98, res=0xbfffefa4, oparams=0x805fd3c) at iop.cc:1825 #2 0x4025ba7c in CORBA::StaticServerRequest::write_results (this=0x805fd08) at static.cc:2518 #3 0x409884a1 in POA_DAO::DAOManager::dispatch (this=0x805d864, __req=0x805fd08) at dao_skel.cc:712 #4 0x40988a11 in POA_DAO::DAOManager::invoke (this=0x805d864, __req=0x805fd08) at dao_skel.cc:735 #5 0x402934a5 in PortableServer::StaticImplementation::doinvoke ( this=0x805d85c, req=0x805fd08) at poa_base.cc:414 #6 0x402a8f10 in MICOPOA::POA_impl::perform_invoke (this=0x805e5d8, ir=0x805fcb0) at poa_impl.cc:3364 #7 0x402a7962 in MICOPOA::POA_impl::local_invoke (this=0x805e5d8, ir=0x805fcb0) at poa_impl.cc:3005 #8 0x402a6ed3 in MICOPOA::POA_impl::invoke (this=0x805d870, msgid=3, obj=0x805faf0, req=0x805fb98, pr=0x805f930, response_exp=1) at poa_impl.cc:2870 #9 0x40209fb6 in CORBA::ORB::invoke_async (this=0x805b640, obj=0x805faf0, req=0x805fb98, pr=0x805f930, response_exp=1 '\001', cb=0x805b9d4, msgid=3) at orb.cc:1933 #10 0x4023f048 in MICO::IIOPServer::exec_invoke_request (this=0x805b9d0, in=@0xbffff308, obj=0x805faf0, req=0x805fb98, pr=0x805f930, resp_exp=1 '\001', conn=0x805f2d0, orbid=3) at iop.cc:3896 #11 0x4023f4d4 in MICO::IIOPServer::handle_invoke_request (this=0x805b9d0, conn=0x805f2d0, in=@0xbffff308) at iop.cc:3947 #12 0x4023e714 in MICO::IIOPServer::handle_input (this=0x805b9d0, conn=0x805f2d0) at iop.cc:3826 #13 0x40240f50 in MICO::IIOPServer::callback (this=0x805b9d0, conn=0x805f2d0, ev=InputReady) at iop.cc:4328 #14 0x40235d21 in MICO::GIOPConn::do_read (this=0x805f2d0) at iop.cc:2359 #15 0x40236009 in MICO::GIOPConn::callback (this=0x805f2d0, ev=Read) at iop.cc:2408 #16 0x40226346 in MICO::TCPTransport::callback (this=0x805f560, disp=0x805b6c8, ev=Read) at transport.cc:173 #17 0x401e6680 in MICO::SelectDispatcher::handle_fevents (this=0x805b6c8, rset=@0xbffff6bc, wset=@0xbffff63c, xset=@0xbffff5bc) at dispatch.cc:246 #18 0x401e7430 in MICO::SelectDispatcher::run (this=0x805b6c8, infinite=0 '\000') at dispatch.cc:400 #19 0x40205ab0 in CORBA::ORB::run (this=0x805b640) at orb.cc:1346 #20 0x804bae5 in main (argc=1, argv=0xbffff804) at server.cc:13 #21 0x408572eb in __libc_start_main (main=0x804ba30
, argc=3, ubp_av=0xbffff804, init=0x804b470 <_init>, fini=0x8050728 <_fini>, rtld_fini=0x4000c130 <_dl_fini>, stack_end=0xbffff7fc) at ../sysdeps/generic/libc-start.c:129 I have tried to track the problem using gdb and a debug enabled version of mico but ... Of course, when I integrate the same code in a standalone server, everything runs fine. If someone has got an hint or is willing to help, I can send the source code. Thanks Arnaud Bailly LIFL _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From richard.bonichon at free.fr Tue Feb 12 11:58:55 2002 From: richard.bonichon at free.fr (richard bonichon) Date: Fri Sep 5 12:44:06 2003 Subject: [mico-devel] using multiple interfaces with components Message-ID: <20020212115855.0faab95d.richard.bonichon@free.fr> hi everyone, i am trying to play around components and would like to have philosophers with a random number of forks (not only 2) determined dynamically...i thought of using "uses multiple fork" instead of "uses fork_left", "uses fork_right".... but when compiling the generated code "philo.cc", i get the following error: philo.cc: In method `class SequenceTmpl * Dinner::Philosopher_stub::get_connections_forks()': philo.cc:3800: `_marshaller__seq_Dinner_Philosopher_forksConnection' undeclared (first use this function) philo.cc:3800: (Each undeclared identifier is reported only once philo.cc:3800: for each function it appears in.) looks like there is a problem due to the use of multiple interfaces? does anyone know where that comes from? Thanks Richard _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From tomas_kaminskas at lema.lt Tue Feb 12 13:03:23 2002 From: tomas_kaminskas at lema.lt (Tomas Kaminskas) Date: Fri Sep 5 12:44:06 2003 Subject: [mico-devel] How to run mico-ccm "hello" example? Message-ID: <001801c1b3b4$e3932100$030010ac@lema.lt> Hello, thank You for Your help, now everything compiles well, but i didn;t run the example, can You write how to run server and client, in standalone mode and as loadable components??? Thank You. Tomas Kaminskas. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.mico.org/pipermail/mico-devel/attachments/20020212/ec057f95/attachment.htm From gthaker at atl.lmco.com Tue Feb 12 10:34:17 2002 From: gthaker at atl.lmco.com (Gautam H Thaker) Date: Fri Sep 5 12:44:06 2003 Subject: [mico-devel] a component that holds a ref. to another component.. Message-ID: <200202121534.g1CFYHY27731@zoe.atl.lmco.com> Hi, I am trying to modify the "hello" example of Mico-CCM to learn more about how all this works. What i am trying to do is to have my client application generate two components (of the same type) and have each hold a reference to the other. The client then asks one component to make a call to other. This way, the client to first component call is between two processes but the component to component call should be within a single container and thus happen very efficiently. So far I can't make this work. I suspect this is because I dont' understand some important point but thought I would ask for help in case anyone has any ideas. My program dies with a msg: "pure virtual method called" /// on running ./hello zoe> ./hello Starting Naming Service ... Starting Server Activator ... Loading HelloWorld component ... Creating ComponentServer ... ok. Creating Container ... ok. Installing Home ... ok. Registering Home with Naming Service ... done. IOR:010000001200000049444c3a48656c6c6f486f6d653a312e3000000002000000000000003600000001010000110000007a6f652e61746c2e6c6d636f2e636f6d0000faec160000002f32373730342f313031333532373335322f312f5f3200000100000024000000010000000100000001000000140000000100000001000100000000000901010000000000 Running Client ... Hello World Hello World - 2 just before hw->ask_other_to_say_hello() pure virtual method called uncaught MICO exception: IDL:omg.org/CORBA/TRANSIENT:1.0 (0, maybe-completed) ./hello: line 46: 27706 Aborted (core dumped) ./client -ORBInitRef NameService=file://`pwd`/nsd.ior /// hello.idl interface Hello { void sayHello (); void ask_other_to_say_hello(); }; component HelloWorld supports Hello { attribute string message; attribute HelloWorld other_component; }; home HelloHome manages HelloWorld { }; // client.cc #include #include #include "hello.h" int main (int argc, char *argv[]) { CORBA::ORB_var orb = CORBA::ORB_init (argc, argv); CORBA::Object_var obj = orb->resolve_initial_references ("NameService"); CosNaming::NamingContextExt_var nc = CosNaming::NamingContextExt::_narrow (obj); assert (!CORBA::is_nil (nc)); obj = nc->resolve_str ("HelloHome"); assert (!CORBA::is_nil (obj)); HelloHome_var hh = HelloHome::_narrow (obj); HelloWorld_ptr hw = hh->create (); hw->message ("Hello World"); hw->sayHello (); HelloWorld_ptr hw2 = hh->create (); hw2->message ("Hello World - 2"); hw2->sayHello (); hw->other_component(hw2); hw2->other_component(hw); cout << "just before hw->ask_other_to_say_hello() " << flush; hw->ask_other_to_say_hello(); cout << "just before hw2->ask_other_to_say_hello() " << flush; hw2->ask_other_to_say_hello(); hw->remove (); hw2->remove (); return 0; } // hello_iml.cc #include "hello.h" #include #include #include #include extern "C" { #include "hist.h" } class HelloWorld_impl : virtual public CCM_HelloWorld { private: CORBA::String_var _msg; HelloWorld_ptr _other_component; public: void sayHello () { cout << _msg << endl; } void ask_other_to_say_hello() { _other_component->sayHello(); } char * message () { return CORBA::string_dup (_msg); } void message (const char * msg) { _msg = CORBA::string_dup (msg); } HelloWorld_ptr other_component() { return _other_component;} void other_component(HelloWorld_ptr x) { _other_component = x;} }; class HelloHome_impl : virtual public CCM_HelloHome { public: Components::EnterpriseComponent_ptr create () { return new HelloWorld_impl; } }; extern "C" { Components::HomeExecutorBase_ptr create_HelloHome () { return new HelloHome_impl; } } _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From 520065607613-0001 at t-online.de Tue Feb 12 16:43:48 2002 From: 520065607613-0001 at t-online.de (Frank Pilhofer) Date: Fri Sep 5 12:44:06 2003 Subject: [mico-devel] How to run mico-ccm "hello" example? In-Reply-To: <001801c1b3b4$e3932100$030010ac@lema.lt>; from tomas_kaminskas@lema.lt on Tue, Feb 12, 2002 at 01:03:23PM +0200 References: <001801c1b3b4$e3932100$030010ac@lema.lt> Message-ID: <20020212164348.F488@rose.fpx.de> Tomas Kaminskas wrote: > > Hello, thank You for Your help, now everything compiles well, > but i didn;t run the example, can You write how to run server > and client, in standalone mode and as loadable components??? > This is sort of documented in the documentation. You can also simply go to the demo/ccm/hello and demo/ccm/hello2 directories, which con- tains scripts to run each example. The hello example uses a standalone component while the hello2 example shows a loadable component. Frank -- Frank Pilhofer ........................................... fp@fpx.de Experience is something you never have until just after you need it. - Alfred E. Neuman _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From tomas_kaminskas at lema.lt Wed Feb 13 15:12:57 2002 From: tomas_kaminskas at lema.lt (Tomas Kaminskas) Date: Fri Sep 5 12:44:07 2003 Subject: [mico-devel] again mico-ccm "helloworld" example. Message-ID: <000801c1b490$2a0d4e90$030010ac@lema.lt> Hello everybody, can anybody comment every line of client.cc of "helloworld" example?? I mean i want to exactly know what every code line means, what does it do. Thank You. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.mico.org/pipermail/mico-devel/attachments/20020213/bad7d258/attachment.htm From kgardas at iol.cz Wed Feb 13 14:45:22 2002 From: kgardas at iol.cz (Karel Gardas) Date: Fri Sep 5 12:44:07 2003 Subject: [mico-devel] again mico-ccm "helloworld" example. In-Reply-To: <000801c1b490$2a0d4e90$030010ac@lema.lt> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 13 Feb 2002, Tomas Kaminskas wrote: > Hello everybody, can anybody comment every line of client.cc of > "helloworld" example?? I mean i want to exactly know what every code > line means, what does it do. Thank You. > I'll try. #include #include #include "hello.h" int main (int argc, char *argv[]) { CORBA::ORB_var orb = CORBA::ORB_init (argc, argv); This is a classical begining of CORBA client. E.g. ORB initialization. CORBA::Object_var obj = orb->resolve_initial_references ("NameService"); CosNaming::NamingContextExt_var nc = CosNaming::NamingContextExt::_narrow (obj); assert (!CORBA::is_nil (nc)); It looks like that our client is using Name Service. The first line obtaining reference to NS. The second line is narrowing to right type e.g NamingContextExt. The third line: is nc right? E.g. Do we have really NamingContextExt object reference in nc? obj = nc->resolve_str ("HelloHome"); Obtaining of HelloHome reference. assert (!CORBA::is_nil (obj)); Is that reference not null. If so continue HelloHome_var hh = HelloHome::_narrow (obj); Narrowing this reference to right type: e.g. HelloHome. HelloWorld_var hw = hh->create (); Creating of component HelloWorld and assigning it's reference to 'hw' hw->message ("Hello World"); Seting message (HelloWorld component's attribute) to ''Hello World'' hw->sayHello (); Invoking operation ''sayHello'' on our Hello World component hw->remove (); Removing of our component from Hello Home return 0; Finish Cheers, Karel - -- Karel Gardas e-mail: kgardas@iol.cz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE8am30qREvenJ7UIYRArkmAKCP6TnfYWB5LqqHknR8Bye8Q7lszACfSV2Z 6LhWmtUZx/v8gWkQ78b9y00= =mZbY -----END PGP SIGNATURE----- _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From 520065607613-0001 at t-online.de Wed Feb 13 15:34:23 2002 From: 520065607613-0001 at t-online.de (Frank Pilhofer) Date: Fri Sep 5 12:44:07 2003 Subject: [mico-devel] Re: a component that holds a ref. to another component.. In-Reply-To: <200202121534.g1CFYHY27731@zoe.atl.lmco.com>; from gthaker@atl.lmco.com on Tue, Feb 12, 2002 at 10:34:17AM -0500 References: <200202121534.g1CFYHY27731@zoe.atl.lmco.com> Message-ID: <20020213153423.F521@rose.fpx.de> Gautam H Thaker wrote: > > What i am trying to do is to have my client application > generate two components (of the same type) and have each hold a reference to > the other. The client then asks one component to make a call to other. > So far I can't make this work. > > class HelloWorld_impl : virtual public CCM_HelloWorld { > private: > HelloWorld_ptr _other_component; > Suggestion: use a HelloWorld_var here (so that the reference is released automatically if the component instance is deleted). > > HelloWorld_ptr other_component() { return _other_component;} > void other_component(HelloWorld_ptr x) { _other_component = x;} > Should be HelloWorld_ptr other_component() { return HelloWorld::_duplicate (_other_component_); } void other_component (HelloWorld_ptr x) { _other_component = HelloWorld::_duplicate (x); } You will then find that your HelloWorld reference is not prematurely destructed ... Frank -- Frank Pilhofer ........................................... fp@fpx.de If most people said what's on their minds, they'd be speechless. - Alfred E. Neuman _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From 520065607613-0001 at t-online.de Wed Feb 13 16:02:06 2002 From: 520065607613-0001 at t-online.de (Frank Pilhofer) Date: Fri Sep 5 12:44:07 2003 Subject: [mico-devel] using multiple interfaces with components In-Reply-To: <20020212115855.0faab95d.richard.bonichon@free.fr>; from richard.bonichon@free.fr on Tue, Feb 12, 2002 at 11:58:55AM +0100 References: <20020212115855.0faab95d.richard.bonichon@free.fr> Message-ID: <20020213160206.H521@rose.fpx.de> richard bonichon wrote: > > i am trying to play around components and would like to have philosophers > with a random number of forks (not only 2) determined dynamically...i > thought of using "uses multiple fork" instead of "uses fork_left", > "uses fork_right".... > but when compiling the generated code "philo.cc", i get the following error: > > does anyone know where that comes from? > Yes, it comes from a bug. Please apply the following patch to Mico. Using multiplex receptacles hasn't been well tested yet, so please go ahead with your testing! Frank -- Frank Pilhofer ........................................... fp@fpx.de When money talks, nobody criticises its accent! - Alfred E. Neuman -------------- next part -------------- Index: idl/ccm-transform.cc =================================================================== RCS file: /home/mico/cvsroot/mico/idl/ccm-transform.cc,v retrieving revision 1.9 diff -c -r1.9 ccm-transform.cc *** idl/ccm-transform.cc 2002/01/23 21:07:38 1.9 --- idl/ccm-transform.cc 2002/02/13 14:48:11 *************** *** 1409,1414 **** --- 1409,1418 ---- seqid.name += "Connections"; CORBA::SequenceDef_var dummy = _repo->create_sequence (0, conn); + + string pseudoid = _db.gen_pseudo_repoid (dummy); + _db.register_repoid (pseudoid, fname); + conns = dest->create_alias (seqid.get(), seqid.name.c_str(), seqid.version.c_str(), From 520065607613-0001 at t-online.de Wed Feb 13 16:09:03 2002 From: 520065607613-0001 at t-online.de (Frank Pilhofer) Date: Fri Sep 5 12:44:07 2003 Subject: [mico-devel] Different Binding Mechanisms In-Reply-To: <02021111104500.21706@chimera>; from rigriff@chimera.grc.nasa.gov on Mon, Feb 11, 2002 at 11:10:45AM -0500 References: <02021111104500.21706@chimera> Message-ID: <20020213160903.I521@rose.fpx.de> Robert I Griffin wrote: > > Bind Methods used > Method 1 - orb->string_to_object (uri): using a file reference > Method 2 - orb->bind("IDL:Bank:1.0","inet:REMOTEADDR:REMOTEPORT"): using > known service address; > > I am having 100% success using both Client versions and both Service binding > methods to Both Services on Service Host 1. > > I am having sporadic successes with binding Clients to their respective > Services on Service Host 2 > Hi, I have no idea why the second method should work randomly. I would ex- pect it to either work fine or not at all. However, it may be a good idea to stay with Method 1 anyway, and to avoid the Mico-specific binding service. If you don't want to transport IOR files through a sneakers network, I would recommend (1) putting the file on a Web server and using http: IORs, (2) placing the IORs in a well-known (hardcoded) Naming Service, or (3) using persistent IORs. Frank -- Frank Pilhofer ........................................... fp@fpx.de Astronomers point out that the universe is racing away from the Earth at 15,000 miles per second. Can you blame it? - A. E. Neuman _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From 520065607613-0001 at t-online.de Wed Feb 13 20:21:58 2002 From: 520065607613-0001 at t-online.de (Frank Pilhofer) Date: Fri Sep 5 12:44:07 2003 Subject: [mico-devel] failed assertion while loading orb.idl into inteface repository In-Reply-To: <1012887560.1014.11.camel@europa>; from Frank.Bielig@onestepahead.de on Tue, Feb 05, 2002 at 06:39:19AM +0100 References: <1012887560.1014.11.camel@europa> Message-ID: <20020213202158.A23541@rose.fpx.de> Frank Bielig wrote: > > I get following failed assertion when I try to load orb.idl into > interface repository. > > idl: ir-copy.cc:356: class CORBA::Contained * > IRCopy::copy_Contained(CORBA::Contained *): Assertion `0' failed. > Aborted > Okay, this should be fixed now. Frank -- Frank Pilhofer ........................................... fp@fpx.de Today's "non-conformists" are getting harder and harder to tell apart. - Alfred E. Neuman _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From rigriff at chimera.grc.nasa.gov Thu Feb 14 11:31:13 2002 From: rigriff at chimera.grc.nasa.gov (Robert I Griffin) Date: Fri Sep 5 12:44:07 2003 Subject: [mico-devel] Linux to SGI Problems -> COMM_FAILURE Exceptions and Binding and Library Differences Message-ID: <02021411311300.28171@chimera> Same Problem as Monday's Post, more information. Still requesting help. Anyone have any idea on this one? Could it be a hardware / networking issue? Client Located on Linux Cluster OS: Debian Linux 2.4.12-xfs SMP Compiled with gcc 2.95.4 MICO Libs : 2.3.5 / 2.3.6 32-bit varied as below Code Base : Derived from /doc/mico/examples/poa/account-2/client.cc See Code Listing Below. Please note HOSTADDR has been replaced. Server Located on SGI Origin OS: IRIX64 6.5 10120733 IP27 Compiled with CC - MIPSpro Compiler: Version 7.3.1.1m (Avoids SGI GCC bug in inet_ntoa, and semctl - see article: http://www.cs.uni-magdeburg.de/~aschultz/mico/mico-devel/2000-10/msg00057.html) MICO Lib : 2.3.5 64-bit Code Base : /doc/mico/examples/poa/account-2/server.cc 4 Trials of 100 executions each for orb->bind(IDL, INETAddr Bind) IDL-Binding Errors Frequency mico lib 2.3.6 2.3.5 trial Failure Point 1 2 1 2 --------------------------------------------------------- 1 File Bind 0 0 0 0 2 IDL Bind 0 0 0 0 3 Bank Narrow 0 0 0 0 4 Nil Bank 45 49 49 44 5 Account Create 30 18 29 27 6 Nil Account 0 0 0 0 7 Transaction 11 19 12 13 8 No Failure 14 14 10 16 4 Trials of 100 executions for orb->string_to_object (uri); where uri is the location/name of the IOR file. FILE:: Binding Error Frequency mico lib 2.3.6 2.3.5 trial Failure Point 1 2 1 2 --------------------------------------------------------- 1 File Bind 0 0 0 0 2 IDL Bind 0 0 0 0 3 Bank Narrow 0 0 0 0 4 Nil Bank 0 0 0 0 5 Account Create 53 52 49 55 6 Nil Account 0 0 0 0 7 Transaction 18 20 23 23 8 No Failure 29 28 28 22 Note Failure Points 1,2,3,5,7 are caught exceptions (COMM_FAILURE from my experience). Comments: First, it stands out that there is no single place at which the clients fail reliably. Nor is there consistent success. Also, the percentage of failure at each failure point for both Binding methods is very consistent . Second, it looks there is no statistical between libmico2.3.5 and libmico2.3.6 Clients. It looks like the IDL/InetAddr Bind method often (nearly 50% of the time) fails to get a non-nil Bank (Factory) Object, whereas the FILE:IOR Method reliably produces a non-nil Bank object. The FILE:IOR Method then fails only at Account Creation and During Transactions. These Failures are thrown COMM_FAILURES, but I have yet to discern their source. Finally, although I have not provided it, the data does not seem to indicate any consistent pattern of failure. For example, it does not appear that a Success always follows an Account Transaction Failure or Account Creation Failure. Code Listing: #include "account.h" #ifdef HAVE_UNISTD_H #include #endif #ifdef _WINDOWS #include #endif HOSTADDR = "inet:sgi.machine.FQDN:99999" int main (int argc, char *argv[]) { CORBA::ORB_var orb = CORBA::ORB_init (argc, argv); /* * IOR is in Bank.ref in the local directory */ #ifdef BY_FILE // cout << "BY File" << endl; char pwd[256], uri[300]; sprintf (uri, "file://%s/Bank.ref", getcwd(pwd, 256)); CORBA::Object_var obj; try { obj = orb->string_to_object (uri); } catch ( ... ) { cout << "1"; exit(1); } #endif #ifdef BY_IDL_BIND // cout << "By IDL Binding to " << HOSTADDR << endl; CORBA::Object_var obj; try { obj = orb->bind("IDL:Bank:1.0",HOSTADDR); } catch ( ... ) { cout << "2"; exit (1); } #endif Bank_var bank; try { bank = Bank::_narrow (obj); } catch ( ... ) { cout << "3"; exit (1); } if (CORBA::is_nil (bank)) { cout << "4"; exit (1); } /* * Open an account */ Account_var account; try { account = bank->create (); } catch (...) { cout << "5"; exit(1); } if (CORBA::is_nil (account)) { cout << "6"; exit (1); } /* * Deposit and withdraw some money */ try { account->deposit (700); account->withdraw (450); account->balance(); cout << "8"; return(0); } catch ( ... ) { cout << "7"; exit(1); } return (1); } _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From Christian.Loose at hamburg.de Fri Feb 15 09:04:00 2002 From: Christian.Loose at hamburg.de (Christian Loose) Date: Fri Sep 5 12:44:07 2003 Subject: [mico-devel] Fix for ccm example makefiles Message-ID: <001d01c1b5f7$53a42360$0a00a2c6@zeus> Hello everybody, the Makefiles of the ccm examples 'hello' and 'hello2' have a small bug. After calling 'make install', not all source files are copied to the installation directory. The following bug fixes should correct this. Bye Christian Index: Makefile =================================================================== RCS file: /home/mico/cvsroot/mico/demo/ccm/hello/Makefile,v retrieving revision 1.2 diff -u -3 -p -u -r1.2 Makefile --- Makefile 2002/01/23 21:07:38 1.2 +++ Makefile 2002/02/14 22:58:45 @@ -5,7 +5,7 @@ DIR_PREFIX=../ include ../../MakeVars INSTALL_DIR = ccm/hello -INSTALL_SRCS = Makefile client.cc hello.idl +INSTALL_SRCS = README Makefile client.cc hello.idl hello_impl.cc INSTALL_SCRIPTS = hello client: client.o hello.o $(DEPS) Index: Makefile =================================================================== RCS file: /home/mico/cvsroot/mico/demo/ccm/hello2/Makefile,v retrieving revision 1.2 diff -u -3 -p -u -r1.2 Makefile --- Makefile 2002/02/13 19:11:47 1.2 +++ Makefile 2002/02/14 22:59:18 @@ -5,7 +5,7 @@ DIR_PREFIX=../ include ../../MakeVars INSTALL_DIR = ccm/hello2 -INSTALL_SRCS = Makefile client.cc hello.idl +INSTALL_SRCS = README Makefile client.cc hello.idl hello_impl.cc INSTALL_SCRIPTS = hello all_target: .depend client hello.$(SOEXT) _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From uma at webde-ag.de Fri Feb 15 13:02:51 2002 From: uma at webde-ag.de (Uwe Maurer) Date: Fri Sep 5 12:44:08 2003 Subject: [mico-devel] Mico + fork(), empty ORB::destroy implementation Message-ID: <82C891B6DD60D411A6F200508BC5D6030624B47A@exchange1.cinetic.de> Hi, I encountered the same problems as Dirk. The problem seems to be the inherited IIOPServer socket handle in the child processes. ORB::destroy() should clean this up properly, I think. I am willing to implement the missing ORB::destroy() method and contribute it. Could someone with a better understanding of the ORB Architecture give me some hints what has to be cleaned up to be able to initialize a new clean orb afterwards? Thanks for any comments. -- Uwe > -----Original Message----- > From: Dirk Thomalla [mailto:dirk@srx6.de] > Sent: Monday, February 11, 2002 9:37 AM > To: mico-devel@mico.org > Subject: [mico-devel] Mico + fork(), empty ORB::destroy implementation > > > I have a problem with Mico and a server process forking childs. > > Only the corba calls in one process are working as expected; the > others are blocked/hanging. > > If the corba stuff (and ORB_init) in the parent is omitted, both > childs work fine. > > I think the problem is an incomplete implementation of ORB::destroy in > mico. This function is empty in orb.cc: > CORBA::ORB::destroy() > { > // XXX shutdown and destroy ORB; calling ORB_init() afterwards > // must create a new ORB instance > } > > Any hints or comments? > > > Pseudo code below: > > ///////////// > void main(...) > { > orb = ORB_init(...); > call_some_corba_things(); // works > > fork_child_1(...); > fork_child_2(...); > > call_some_corba_things(); // blocked > } > > void fork_child_1(...) > { > pid_t pid = fork(); > switch (pid) { > case -1: // error > break; > case 0: // child > orb->shutdown(true); > orb->destroy(); > orb = ORB_init(...); > call_some_other_corba_things(); // works > _exit(0); > break; > default: // parent > return; > } > } > > void fork_child_2(...) > { > pid_t pid = fork(); > switch (pid) { > case -1: // error > break; > case 0: // child > orb->shutdown(true); > orb->destroy(); > orb = ORB_init(...); > call_some_other_corba_things(); // blocked > _exit(0); > break; > default: // parent > return; > } > } > > ///////////// > > > -- > - Dirk > http://www.srx6.de/dirk/ > _______________________________________________ > mico-devel mailing list > mico-devel@mico.org > http://www.mico.org/mailman/listinfo/mico-devel > _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From Arnaud.Bailly at lifl.fr Fri Feb 15 13:34:20 2002 From: Arnaud.Bailly at lifl.fr (Arnaud Bailly) Date: Fri Sep 5 12:44:08 2003 Subject: [mico-devel] Dynamic loading problem solved Message-ID: <15469.76.869748.634697@argus.lifl.fr> Hi, I found the answer to my dynamic loading problem : it is a C++ error, not a mico one. The problem lies in my misunderstanding of dynamic loading for C++ libraries : you have to call constructors for static objects. If - as I did - you define your own _init() function, these constructors are not called, which is definitely a problem for type code marshallers which are static objects constructed in the stub code generated by IDL parser. Thank you to Karel, Arnaud _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From tomas_kaminskas at lema.lt Fri Feb 15 15:41:10 2002 From: tomas_kaminskas at lema.lt (Tomas Kaminskas) Date: Fri Sep 5 12:44:08 2003 Subject: [mico-devel] Problem with mico-ccm hello-2 (loadable component)!!! Message-ID: <000501c1b626$6da1b050$030010ac@lema.lt> Hello I wanted to try mico-ccm hello2 example (with loadable components), everything compiled well (with makefile), but when I ried to run this example I got such error: [tomas@localhost hello2]$ ./hello Starting Naming Service ... Starting Server Activator ... Loading HelloWorld component ... Creating ComponentServer ... ok. Creating Container ... ok. Installing Home ... Cannot open `/home/tomas/mico-ccm-020124/demo/ccm/hello2/hello.so': no shlib support My system: gcc version 2.96 Red Hat Linux 7.1 2.96-98, kernel 2.7.10 on i686. And one more question how to compile this example in command line, not with makefile, I was good until linking loadable component, with what command i can link it??? Thank You. Tomas Kaminskas. _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From Christian.Loose at hamburg.de Sat Feb 16 01:11:44 2002 From: Christian.Loose at hamburg.de (Christian Loose) Date: Fri Sep 5 12:44:08 2003 Subject: [mico-devel] [PATCH] small clean-up of idl/db.cc Message-ID: <000a01c1b67e$84ac3f60$0a00a2c6@zeus> Hello, during my quest of trying to understand the mico source code, I created a small patch for the source file db[.cc|.h] and the source files that were affected by the changes: - improved const-correctnes - made names of operation more consistent - some small code clean-up - moved #include-statement to source file to decrease dependency (faster compilation) - some small style changes (hope you don't mind) I hope you find the attached patch useful, Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: db-cleanup-path.tgz Type: application/x-compressed Size: 2638 bytes Desc: not available Url : http://www.mico.org/pipermail/mico-devel/attachments/20020216/94ab91f7/db-cleanup-path.bin From kgardas at iol.cz Sun Feb 17 18:26:40 2002 From: kgardas at iol.cz (Karel Gardas) Date: Fri Sep 5 12:44:08 2003 Subject: [mico-devel] Problem with mico-ccm hello-2 (loadable component)!!! In-Reply-To: <000501c1b626$6da1b050$030010ac@lema.lt> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 15 Feb 2002, Tomas Kaminskas wrote: > Hello I wanted to try mico-ccm hello2 example (with loadable components), > everything compiled well (with makefile), but when I ried to run this > example I got such error: > > [tomas@localhost hello2]$ ./hello > Starting Naming Service ... > Starting Server Activator ... > Loading HelloWorld component ... > Creating ComponentServer ... ok. > Creating Container ... ok. > Installing Home ... Cannot open > `/home/tomas/mico-ccm-020124/demo/ccm/hello2/hello.so': no shlib support > > > My system: gcc version 2.96 Red Hat Linux 7.1 2.96-98, kernel 2.7.10 on > i686. Hi, 1) did you try it with supported compiler (note that redhat's is unsupported) such as gcc 2.95.3 ? 2) please look at last checking line of configure script output. Did you see: ''checking for dynamic loading... ok, using dlopen() family''? If not, then you have a problem with your linux distro (mainly caused by wrong c++ compiler). > And one more question how to compile this example in command line, not with > makefile, I was good until linking loadable component, with what command i > can link it??? I think that loadable component is shared library and for making shared library mico provides script mico-shld. Cheers, Karel - -- Karel Gardas e-mail: kgardas@iol.cz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE8b+fSqREvenJ7UIYRAoMQAJsH+3Szj9X//ePLO1DrHY3xxon2RwCfRETw RwW75N9omdnZ46i9w5WvkJg= =35U+ -----END PGP SIGNATURE----- _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From kgardas at iol.cz Sun Feb 17 19:28:45 2002 From: kgardas at iol.cz (Karel Gardas) Date: Fri Sep 5 12:44:08 2003 Subject: [mico-devel] Mico + fork(), empty ORB::destroy implementation In-Reply-To: <82C891B6DD60D411A6F200508BC5D6030624B47A@exchange1.cinetic.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 15 Feb 2002, Uwe Maurer wrote: > Hi, > > I encountered the same problems as Dirk. The problem seems to be the > inherited IIOPServer socket handle in the child processes. ORB::destroy() > should clean this up properly, I think. > > I am willing to implement the missing ORB::destroy() method and contribute > it. > Hi, What about to give a try to MICO/MT project? I hope that it is pretty stable (ORB/GIOP/IIOP/POA - not IMR) and it really needs more testing! I know about several bugs (read README.mt), which I would like to fix in future and that would be great if I have a set of examples which fails on MICO/MT and run well on MICO (if possible), or on another MT orb like TAO or ORBacus. Thanks, Karel - -- Karel Gardas e-mail: kgardas@iol.cz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Made with pgp4pine 1.75-6 iD8DBQE8b/ZgqREvenJ7UIYRAhjVAJ0Q/Rvl2jlsosEZotke0NTh0CX2QACeI/7r G+sWPYGzA09dpyjw4Wrlz/Q= =IOv5 -----END PGP SIGNATURE----- _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From uma at webde-ag.de Mon Feb 18 12:04:18 2002 From: uma at webde-ag.de (Uwe Maurer) Date: Fri Sep 5 12:44:08 2003 Subject: [mico-devel] Mico + fork(), empty ORB::destroy implementation Message-ID: <82C891B6DD60D411A6F200508BC5D6030624B47E@exchange1.cinetic.de> Hi again, > > I am willing to implement the missing ORB::destroy() method > and contribute > > it. > > I've tried to implement a very basic version of ORB::destroy() and it works for my simple test case (ORB_init(), fork(), and then in the child process(es): ORB::destroy(), ORB_init()). Below you will find a "diff -u" against the MICO CVS Head for the file orb/orb.cc. After reading the sources more carefully I found out, that ORB::shutdown() closes all socket handles properly. So the only thing preventing a successful re-initialization in a child process was, that orb_instance singleton variable was not reset to nil. So my implementation does this, after releasing it first. However, the reference count in my simple test program was still 7, so that calling CORBA::release(orb_intance) does not really free the memory allocated by that object. > What about to give a try to MICO/MT project? I hope that it is pretty > stable (ORB/GIOP/IIOP/POA - not IMR) and it really needs more > testing! I would like to ... but: The fork() problem pops up in integrating MICO in another application wich uses a parent-worker-child model with processes. It would be much more work to change this into an application using threads. And of course, time is pretty limited as always... I hope we can use MICO/MT within a project for a student's diploma starting here next few weeks. -- Uwe Maurer Index: orb/orb.cc =================================================================== RCS file: /home/mico/cvsroot/mico/orb/orb.cc,v retrieving revision 1.134 diff -u -r1.134 orb.cc --- orb/orb.cc 2001/10/11 18:08:53 1.134 +++ orb/orb.cc 2002/02/18 10:31:59 @@ -1374,8 +1374,19 @@ void CORBA::ORB::destroy () { - // XXX shutdown and destroy ORB; calling ORB_init() afterwards - // must create a new ORB instance + // XXX: Detect, if orb is servicing requests. If so: + // mico_throw (CORBA::BAD_INV_ORDER (3, CORBA::COMPLETED_NO)); + + if (!_is_stopped) + shutdown (TRUE); + + if (MICO::Logger::IsLogged (MICO::Logger::Info)) { + MICO::Logger::Stream (MICO::Logger::Info) + << "ORB::shutdown : orb_instance->_refcnt() = " << orb_instance->_refcnt() << endl; + } + + CORBA::release(orb_instance); + orb_instance = _nil(); } CORBA::BOA_ptr _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From 520065607613-0001 at t-online.de Mon Feb 18 17:47:34 2002 From: 520065607613-0001 at t-online.de (Frank Pilhofer) Date: Fri Sep 5 12:44:08 2003 Subject: [mico-devel] Mico + fork(), empty ORB::destroy implementation In-Reply-To: <82C891B6DD60D411A6F200508BC5D6030624B47A@exchange1.cinetic.de>; from uma@webde-ag.de on Fri, Feb 15, 2002 at 01:02:51PM +0100 References: <82C891B6DD60D411A6F200508BC5D6030624B47A@exchange1.cinetic.de> Message-ID: <20020218174734.A1127@rose.fpx.de> Uwe Maurer wrote: > > Could someone with a better understanding of the ORB Architecture give me > some hints what has to be cleaned up to be able to initialize a new clean > orb afterwards? > Hi, thanks for your initial destroy() implementation. While working on that, it would be nice to abolish all (or most) usage of global data; this would allow us to keep multiple ORBs in one process, and to destroy them individually. For an estimate what's to do here, do a grep for CORBA::ORB_instance(); such references would have to be replaced with a "real" pointer to the parent ORB. Once all global information is collected in the ORB class, completing destroy() shouldn't be too hard. Frank -- Frank Pilhofer ........................................... fp@fpx.de The reason most people are lost in thought is because it's unfamiliar territory. - Alfred E. Neuman _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From alain.bedu at ota.fr.socgen.com Mon Feb 18 18:46:10 2002 From: alain.bedu at ota.fr.socgen.com (alain.bedu@ota.fr.socgen.com) Date: Fri Sep 5 12:44:08 2003 Subject: [mico-devel] How to use DeMarshaling functions ? Message-ID: Hi all, I'm new to mico, and want to use it under Linux instead of Visibroker 4.5 for cpp. My goal is very simple : I write my classes with java, make an idl with java2idl, and then get back a cpp class with idl2cpp. The first part is done with Visibroker for java, and I want to achieve the second one with mico. I can do this easily, no problem. But I want to use my C++ classes to convert a byte array into an object, with demarshaling methods. With Visibroker, I use the MarshalInBuffer method, like shown below : CORBA::MarshalInBuffer mIBuf((char*)rateCurveStream, len, 0, FALSE); mIBuf >> *rateCurve; But I don't know how to use demarshal method generated by mico. So I just want a sample code which shows me how to use demarshaling with mico. I Hope my message is clear enough. Thanks alain. _______________________________________________ mico-devel mailing list mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel From 520065607613-0001 at t-online.de Mon Feb 18 20:23:58 2002 From: 520065607613-0001 at t-online.de (Frank Pilhofer) Date: Fri Sep 5 12:44:08 2003 Subject: [mico-devel] How to use DeMarshaling functions ? In-Reply-To: ; from alain.bedu@ota.fr.socgen.com on Mon, Feb 18, 2002 at 06:46:10PM +0100 References: Message-ID: <20020218202358.L1127@rose.fpx.de> alain.bedu@ota.fr.socgen.com wrote: > > But I want to use my C++ classes to convert a byte array into an object, with > demarshaling methods. > > With Visibroker, I use the MarshalInBuffer method, like shown below : > > CORBA::MarshalInBuffer mIBuf((char*)rateCurveStream, len, 0, FALSE); > mIBuf >> *rateCurve; > > But I don't know how to use demarshal method generated by mico. > If you have an IDL type such as typedef sequence Cur