Bug 118

This point is under discussion in the OMG, until a final resolution is achieved
TAO supports both collocated and remote Policy objects.  This choice must be
made at compile time.

Now that TAO 1.0 is out, let's revisit these bugs.

Irfan understands the issues here, my latest take on the CORBA 2.3 spec is that
Policy objects are not locality constrained unless explicitly stated. The spec
makes no mention in that respect when defining the CORBA::Policy class.

With the new memory and upcall management semantics provided by the POA, we
need to look at the Policy classes again.  We may need a class that is locality
constrained but still registers with the POA (Local_ServantBase is locality
constrained and does not register with the POA).

In addition, we also need to look closely at all the other classes that inherit
from the Local_ServantBase. This includes Current, IOR_Manipulation,
Interceptor, PolicyManager, DynAny, and POA classes.

POA_CORBA::Policy now inherit from
TAO_Locality_Constrained_ServantBase instead of TAO_Local_ServantBase
when TAO_HAS_LOCALITY_CONSTRAINT_POLICIES is turned on.  This will
give us the locality constrained policies, while still giving the
semantics of registering with the POA.

However, the collocated stubs of most policies still use direct access
to the servant.  Therefore, if absolutely normal servant behavior is
desired, these stubs need to be changed to use the through POA policy.

Consider looking at other ORB implementations to see what they do.  Also, look
at the CORBA 2.4 specification.

I asked Michi Henning about CORBA::Policy objects while I was at COOTS 2001.  
He said that CORBA::Policy objects are *not* locality constrained unless 
explicitly marked as such.

Can we mark this bug as fixed?

I'm marking this bug as fixed.  The situation with the spec is clear:
- CORBA::Policy is a regular interface (i.e. can be global).
- Most Policies are local (if not all).

the code in both cases matches the requirements.