CORBA24 — Conflict between POA & Exceptions spec for OBJECT_NOT_EXIST

There is a conflict between the specification of the OBJECT_NOT_EXIST
exception and its use in the POA spec. The exception definition says
that OBJECT_NOT_EXIST means that an object has gone away forever, and
that clients should tidy up references to it. However, the POA spec
requires an ORB to raise this exception in cases where the object may
not have gone away for ever.

In particular, 11.2.6 (in the 5 May 2.4 Draft) requires an ORB to raise
OBJECT_NOT_EXIST if request comes in for a child POA that is not active
and was not activated by the application's POA Activator. While this
may mean that the object has gone away for ever, it doesn't always
mean that. For example:

1) If the server admin has stuffed port number allocations, a server
may accidentally get requests for POAs that it doesn't know about.

2) If the server has been incorrectly (re-)built one of its "static"
child POAs might not be activate.

3) If the server is buggy and / or its persistent state is flakey,
it may temporarily fail to dynamically activate a child POA.

In each case, the problem MAY be one that can be fixed, allowing the
missing POA to reappear in a few minutes. It is therefore inappropriate
for the ORB to be telling the client that the Object has gone away for
ever.

For what it is worth, I think the ORB should raise another exception,
say OBJ_ADAPTER, in the default case. It might raise OBJECT_NOT_EXIST
if it (somehow) tracks the lifecycle of transient and / or persistent
POAs, or if the application code tells it the POA no longer exists.
Note: I'm not suggesting that an ORB be required to support such things.

The other alternative is to change the definition of OBJECT_NOT_EXIST
to remove the implication that the object has gone away forever and
the suggestion that clients should throw away references to the object.
[I think that's wrong though ...]

Close no change