Name: aaR10142 Date: 01/28/2003



This bug is filed to track decision for OMG issue 5468.
There is an ambiguity in IDL-to-JAVA documentation about ANY created by
singleton ORB. The question is: may such ANY be marshaled/demarshaled or not.
See following email for details

Date: Thu, 25 Jul 2002 13:18:14 -0700 (PDT)
From: Ken Cavanaugh <###@###.###>
Reply-To: Ken Cavanaugh <###@###.###>
Subject: Re: ?? IBM : JCK14 : org_omg/CORBA/SimpleMarshal- SecurityException
To: ###@###.###
Cc: ###@###.###, ###@###.###, ###@###.###,
   ###@###.###
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: VVjZjqaN3gvJJ3ZOusPLYQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc
Status: RO
Content-Length: 4144
Lines: 90

Some comments below.


>From: David Korbel <###@###.###>
>X-Accept-Language: en
>MIME-Version: 1.0
>To: ###@###.###, ###@###.###
>CC: ###@###.###
>Subject: ?? IBM : JCK14 : org_omg/CORBA/SimpleMarshal- SecurityException
>Content-Transfer-Encoding: 7bit
>
>Hello,
>
>This one appears straightforward as it appears the IDL-to-Java spec
>is ambiguous. IBM say our own representative on the OMG, Ken
>Cavanaugh, has already suggested that he believes the test should be
>excluded until the problems with the spec are sorted out (see last
>few paragraphs of challenge).
>
>Thanks,
>
>Dave.
>

The relevant specification is the IDL to Java mapping specification that
was used for Merlin (OMG document ptc/00-01-08 see
ftp://ftp.omg.org/pub/docs/ptc/00-01-08.pdf) section 1.21.9.3,
which discusses properties of the singleton ORB that is returned by
the default ORB.init() call. It is clear that the intent of the singleton ORB
was originally only to support the create_any call as required for
code generated by the IDL compiler, which required only support for
primitive types. This is suggested by the phrase in this section:

"The primary use of the no-argument version of ORB.init() is to provide
a factory for TypeCodes for use by Helper classes implementing the type()
method, and to create Any instances that are used to describe union
labels as part of creating a union TypeCode."

The Sun ORB actually supports full use of create_any on the singleton ORB, due
to a much later addition to the OMG specifications (Portable Interceptors)
which is also part of Merlin. It turns out that create_any must be used in
contexts where the only reasonable choice of ORB to use is the singelton ORB.
However, the IDL to Java spec has not adequately addressed this part of the
problem. The java RTF (and possibly the core RTF) at the OMG will need to decide
what to do with the specification, but of course this will only affect Tiger
and later releases of J2SE. This problem is currently being discussed in the
Java RTF as OMG issue 5468.


>--
>Test: org_omg/CORBA/SimpleMarshal - SecurityException
>
>The test first creates a CORBA 'Any' using the Java singleton ORB
>instance. This is a perfectly valid thing to do, according to the
>OMG IDL-to-Java mapping specification.
>
>The test then creates an OutputStream from the Any and marshals a
>CORBA Object reference into that stream. The IDL-to-Java spec is
>unclear as to whether this is vaild or not. The spec specifically
>forbids the creation of an OutputStream from the singleton ORB, but is
>unclear as to whether this operation should be valid via an Any created
>from the singleton. There is an implication that Anys created from the
>singleton are only meant to be used for the creation of certain kinds
>of TypeCodes, but this is not spelled out.
>
>The test then creates an InputStream from the OutputStream and tries to
>demarshal the Object reference back into a singleton-derived Any.
>However demarhsalling an Object reference requires a full-function ORB
>to which the Object can be connected but the only ORB available to the
>Any is the singleton from which it was created. The demarshal
>operation therefore fails in our JDK. Again the spec is not clear as
>to whether or not this is valid usage.
>
>We have begun the process of raising an issue against the OMG
>IDL-to-Java spec to get these issues resolved, but it will take some
>time for a conclusion to be reached. Until this happens we believe
>this JCK test should be excluded.
>
>If it helps matters Ken Cavanaugh - Sun's representive at the OMG for
>these matters - agrees with us. He made the following comments to the
>public OMG 'java-rtf' mailing list:
>
> While I still agree that there is an issue here that needs to
> be resolved ... ... Also, it is not clear to me that this needs
> to be an urgent issue, on further reflection. Ann, I think
> your main problem is the JCK tests. It seems that the tests
> should probably be waived due to an ambiguity in the
> specification. That's a discussion for the JCK team, rather
> than the Java RTF.




======================================================================