[omniORB] Need a special omniINSPOA

[Wernke zur Borg]

Thanks Renny,

Sorry but you have missed my point. I am familiar with the existing
omniINSPOA and I use it a lot. What I need is a variant of it with a
different thread policy, say SINGLE_THREAD_MODEL or MAIN_THREAD_MODEL.

What I gather from the docs is that you cannot dynamically change the
POA's policy, so you have to create a new one with the right policy. I
can create a new POA with SINGLE_THREAD_MODEL and USER_ID policy, yet
the special key handling which the omniINSPOA does, is missing.

Thanks for your posting anyway.

Regards, Wernke

> -----Original Message-----
> From: renny.koshy at rubixinfotech.com 
> [mailto:renny.koshy at rubixinfotech.com] 
> Sent: 12 January 2006 17:25
> To: Wernke zur Borg
> Subject: Re: [omniORB] Need a special omniINSPOA
> 
> It works for us ... here's the code that we use... this gives 
> consistent
> CORBALOC URI's that can be used to access the objects.
> 

 <code deleted>

> 
> Renny Koshy
> President & CEO
> 
> --------------------------------------------
> RUBIX Information Technologies, Inc.
> www.rubixinfotech.com
> 
> 
 
> 
> Dear list,
> 
> for a special case I need a POA that behaves like omniINSPOA but only
> with a different thread policy. In particular, it must have 
> the USER_ID
> policy and it must create "simple" object keys, so that the 
> objects can
> be located with a corbaloc URI.
> 
> Whenever I try to create an own child POA with USER_ID policy, it does
> not use simple keys, thus the object cannot be found in the object
> table.
> 
> How can I achieve the "special" behaviour of the omniINSPOA 
> with respect
> to the object keys created?
> 
> Any hint will be appreciated.
> 
> Regards, Wernke
> 
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> 
> 
>