[omniORB] DynValueCommon and sharing semantics

[JiangWei]

http://www.omg.org/issues/corba-rtf.open.html#Issue8986

How to work-around this issues with omniORB4?

[Duncan Grisby]

Post by JiangWei
http://www.omg.org/issues/corba-rtf.open.html#Issue8986
How to work-around this issues with omniORB4?

I'm afraid I don't understand what that issue is trying to say. It seems
to be saying that the CORBA spec doesn't say values in Anys are shared.
The spec does quite clearly say that. Section 5.2.4.3 of the 2.6 spec
(which omniORB targets) says:

When an instance of the value type is passed as a parameter to an
operation of a non-local interface, the effect in all cases shall be
as if an independent copy of the instance is instantiated in the
receiving context. ... This applies to all valuetypes involved in the
invocation, including those embedded in other IDL datatypes or in an
any.

So it's quite clear that values inside Anys are shared, and omniORB
completely supports that.

The 2.6 spec does not mention anything about value sharing within
DynAny. The 3.0 spec does have some words about it, but I don't think it
makes any sense at all. It is far from complete in terms of actually
specifying the constraints, and the way I think it was meant to be
interpreted is in my opinion unimplementable.

What omniORB does is to convert an Any into a DynAny on demand, and at
that time, any sharing information is lost. Once the DynAny is converted
back into an Any, the value inside is once again a normal value, and can
be shared. Any other implementation would cause all kinds of problems, I
think.

Cheers,

Duncan.

[JiangWei]

Post by Duncan Grisby
What omniORB does is to convert an Any into a DynAny on demand, and at
that time, any sharing information is lost. Once the DynAny is converte=

d

Post by Duncan Grisby
back into an Any, the value inside is once again a normal value, and ca=

n

Post by Duncan Grisby
be shared. Any other implementation would cause all kinds of problems, =

I

Post by Duncan Grisby
think.
=20

My server want to handle some unkonwn valuetype (definition at client
side after server running ) .
I have to implement it with DSI and DynAny because
no facotries for them. But DynAny can't keep sharing semantics.

[Duncan Grisby]

Post by JiangWei
My server want to handle some unkonwn valuetype (definition at client
side after server running ) .
I have to implement it with DSI and DynAny because
no facotries for them. But DynAny can't keep sharing semantics.

How would you expect DynAny to expose the fact that two values are
shared? There's nothing in the DynAny interfaces that would permit you
to do that.

You can compare the values stored in two Anys without having to have
valuefactories for them. i.e.

CORBA::Any a1, a2;
// Populate Anys, e.g. from get_members() on a DynStruct

CORBA::ValueBase *v1, *v2;
a1 >>= CORBA::Any::to_value(v1);
a2 >>= CORBA::Any::to_value(v2);

if (v1 == v2)
// it's the same value

This is all clearly required by the CORBA spec, and completely supported
in omniORB.

Cheers,

Duncan.

[JiangWei]

Post by Duncan Grisby
You can compare the values stored in two Anys without having to have
valuefactories for them. i.e.
=20

Thank you very much.