CORBA25 — Problem with resolution to 4285 and 4306

Please take a look at the resolution of issues 4285 and 4306 in
> ptc/2001-06-08 - the RTF report that is up for recommendation to adopt
> at this upcoming meeting, and see if they do not fix these problems.
> 4285 fixes the BAD_OPERATION problem most definitely. 4306 seems to fix
> the OBJ_ADAPTER problem too, although slightly differently from how you
> suggest. If these fixes address the problem that you raise in your
> message, could you please ask Juergen to not create an issue?I didn't CC issues, so I don't think Juergen will create an issue (at least,
that was the intent). My apologies for the duplication. However, looking
at 4285 once again, I think there may be a problem:

In order to return something that means "ServantManager returned wrong
servant type", I think the ORB core has to insert an active check
at the point where the servant manager returns. If it doesn't, it will
either get an unmarshaling error or return a BAD_OPERATION exception with
some other minor code when it detects that the operation isn't in the
function pointer table for the servant. In the latter case, the ORB won't
know anymore why the operation is missing (for example, it could also
be missing because the client used the DII to invoke a non-existent operation.)

I am also not sure whether BAD_OPERATION is really the correct exception to
use. To me, BAD_OPERATION tells the client "you invoked an operation that
doesn't exist". If we give this exception to the client when it invokes
an operation that's perfectly good, that's highly misleading because the
actual problem isn't with the client, but with the servant manager.

So, I think that using OBJ_ADAPTER, as I suggested, would be better.

For the resolution to 4306, I think we also have something that is suboptimal.
That's because minor code 2 say "Servant not found" in table 4-3. But
I don't see how this is possible. Basically, a servant manager isn't allowed
to return a null servant. If it can't find the servant, it's supposed to
throw a system exception. So, a servant manager that returns null is simply
broken and needs to be recoded. 4306 (by using "Servant not found" as
the explanation of minor code 2) is misleading, because that condition simply
can't happen.

So, without trying to create a procedural mess, could we reconsider the
resolution to these two issues, maybe for the next vote?

Fix inconsistency as described below