Eduard, you are right that it might not be that much work to move to non-static ORB_instance variable. I already also suggested to you to have a look at static variables for IIOPProxy and IIOPServer objects since you will need to decide if you like to have them static (as they are now) and hence shared between several ORBs or you would like to have them allocated per ORB instance basis. Seeing your direction I would prefer later.
On the other hand, I'm not sure I share your view about elegant or not-elegant OCP POA solution. I think it's quite elegant to use ORB_init to get one ORB per whole application in whatever library you use and use OCP to set appropriate IP endpoint as you require. Cheers, Karel Siemens Eduard wrote: > Karel, > thanks for your prompt answer. > The point is - it seems to be not so difficult to move from a static variable > to member, since the variable seems to be really used only within the file > orb.cc. > Hovewer, in total, mico is a lot of code, so may be I have overseen some > details. So it would be fine, if one of the mico gurus could give hist > comment. Nevertheless, it seems to me be worth enough to spent a couple of > hours at least to try with different orb instances... > > BTW, the way with different POAs seems to me not to be such an elegant way. > The background of the problem is - I use CORBA within different libraries > totally independently. This couple of libraries are tight together in diffent > application in a different way. So, sometimes I have only one Corba instance, > somtimes two. So, I don't have a clear master-slave relation between > instances. So I can't presume one orb is always there and can initialize the > whole orb stuff. > > > Regards, > Eduard > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karel Gardas > Sent: Donnerstag, 3. April 2008 10:31 > To: Siemens Eduard > Cc: mico-devel@mico.org > Subject: Re: [mico-devel] Multiple orb instances > > > Eduard, > > good catch! The restriction you describe exists probably from time where > nobody expected that there will be more than one ORB instance running in the > process. It would be great if you like to change this behavior to allow > multiple ORB instance coexists. Please make sure you also solve issue with > static variables holding references to IIOPProxy and IIOPServer objects. I > guess you will need to make them per-ORB allocated. If you do anything on > this task, please do not forget to post your changes (preferably in a form of > unified or context diff) here. > > Thanks, > Karel > > Siemens Eduard wrote: >> Hello folks, >> I'm just struggling on the following issue. >> Although mico accepts an id string for orb initialization (ORB_init(..., >> id)). >> Hovewer, it accepts only one id - namely "mico-local-orb". >> Initializations with other ids will fail. >> I just browsed through the code and find out that the main reason for that >> the orb_instance is defined as a singleton. >> >> Does anybody know, why this restrictoin exists. At the first glance I would >> say the instance could be a member of CORBA, isn't it? >> In the worst case it could be an static array of instance pointers, isn't it? >> Or are there other restrictions, I have just not noticed jet? >> Best regards, >> Eduard >> >> >> ========================================================================== >> Dr. Eduard Siemens mailto:[EMAIL PROTECTED] >> Senior R&D Engineer Hannover Network Protocols Lab (HNP) >> Phone : +49 511 418 2168 >> Fax : +49 511 418 2483 >> >> Deutsche Thomson OHG >> Corporate Research Hannover >> Technology Group >> Karl-Wiechert-Allee 74 >> 30625 Hannover, Germany >> >> Offene Handelsgesellschaft, Sitz Hannover, Registergericht Hannover >> HRA 24616 Generalbevollmächtigte : >> Horst Kuhn, Dr. Hans-J. Platte, Vincent Rimbeau, Dietmar Uhde >> Persönlich haftende Gesellschafterinnen: >> Société Française d'Investissement et d'Arbitrage SOFIA Boulogne, >> Handelsregister R.C.S. Nanterre 785610932 Thomson Multimedia Sales >> International SAS, Boulogne, Handelsregister R.C.S. Nanterre 439290735 >> >> >> >> >> _______________________________________________ >> Mico-devel mailing list >> Mico-devel@mico.org >> http://www.mico.org/mailman/listinfo/mico-devel >> > > -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com _______________________________________________ Mico-devel mailing list Mico-devel@mico.org http://www.mico.org/mailman/listinfo/mico-devel
