CORBA formal 00-11-03 10.6.2 states

"If the actual serialization version UID for the Java class differs from
the hash code, a colon and the actual serialization version UID
(transcribed as a 16 digit upper-case hex string) shall be appended to
the RepositoryId after the hash code."

Please comment on the following assertions. The CORBA spec is vague
here, and it has resulted in incompatible interpretations which must be
resolved quickly.

1) The "actual serialization version UID" mentioned is as defined in
the Java Object Serialization specification.

http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/class.doc6.html#4100

Based on this Java specification and its note that "If the SUID is not
declared for a class, the value defaults to the hash for that class":

2) If a serialVersionUID field is defined in the class with the proper
modifiers, its value is used as the "actual serialization version UID"
mentioned in the CORBA spec

3) If a serialVersionUID field with the proper modifiers is not
explicitly defined in a class, its value is computed as explained in the
Java Object Serialization spec, and this computed value is used as the
"actual serialization version UID" mentioned in the CORBA spec

4) It is required by the CORBA spec to always include the Java
serialVersionUID (as computed in assertions 2 and 3 above) in the RMI
repository ID if the value is different than the OMG hash code (for
which the algorithm is defined in CORBA formal 00-11-03 10.6.2)

5) It is not acceptable to leave off the SUID portion of the RMI
repository ID if the serialVersionUID field is merely absent from the
Java class

closed, withdrawn by submitter

The question below was posted to the corba-dev list. I have to admit
that I don't understand the purpose of the second-least significant bit
of response_flags either. From the text in the spec, it appears that
this bit is set if a request expects a response and is not invoked via
the DII, whereas if a request is oneway or invoked via the DII with
INV_NO_RESPONSE set, the bit is clear.

closed issue ...clarified

Summary: > > Add the following paragraph to 15.8:
> >
> > "To avoid collisions of requestId in fragment messages when
> > bi-directional GIOP is in use:
> >
> > - a request may not be sent by an endpoint if a reply has been
> > sent by that endpoint without a terminating fragment.
> >
> > - a reply may not be sent by an endpoint if a request has been
> > sent by that endpoint without a terminating fragment."
> >
>
> Why is a plain (non-fragmented) request/reply prohibited here? There has
> never been and feature interaction between fragmented request/replies and
> non-fragmented ones, so why have this restriction.

Jishnu Mukerji wrote:

> After poking around some it seems to me that the following words address
> Martin"s concern and hence the issue of inadvertently disallowing something
> that wasn"t broken in the current resolution of 2801. The additional word
> "fragmented" in two places is bracekted between "*"s.
>
> "To avoid collisions of requestId in fragment messages when
> bi-directional GIOP is in use:
>
> - a fragmented request may not be sent by an endpoint if a
> fragemented reply has been sent by that endpoint without a terminating
>fragment.
>
> - a fragemented reply may not be sent by an endpoint if a
> fragmented request has been sent by that endpoint without a terminating
>fragment."

resolved, see below

Summary: I wish to raise the following as an urgent issue:

The way that message fragments are encoded in giop 1.2, in conjunction
with the giop 1.2 specification for bi-directional use of a connection,
can lead to situations where the protocol is ambiguous.

(This is urgent because it is impossible to implement the bi-directional
part of GIOP 1.2 without it.)

No Data Available

Summary: if a code set negotiation fails the CORBA 2.3 specfication says that a
CODESET_INCOMPATIBLE exception is to be raised. There doesn"t seem to be
any further reference to a CODESET_INCOMPATIBLE exception elsewhere. So
where is the CODESET_INCOMPATIBLE exception defined? Or should it read
INV_OBJREF?

No Data Available

Summary: Tom and I have discovered a minor outage in GIOP 1.2 relative to the
Messaging spec. The outage exists if we want to keep the door open for
publishing Messaging before GIOP is revved again. If we do not fix this
the publishing of Messaging will have to wait until the next rev of
GIOP. The outage is the following:

1) In the Request header the boolean field "response_expected" was
changed to an octet field "response_flags" in Messaging, with more
precise definition of the meanings of various flag values.

2) The Messaging spec defines a IOP::TaggedComponent for including QoS
policies in an IOR.

3) The Messaging service defines a ServiceContext for carrying QoS
policies in GIOP messages that carry ServiceContexts.

Close with No change required

Summary: IIOP 1.2 fragmentation presents an unrecoverable error situation
1.2 IIOP attempted to provide fragment interleaving by defining a 1.2
fragment header containing request id. This does not solve the
possibility of receiving multiple first fragments over the same
connection which do not contain request id"s. There is no way to
associate subsequent fragments with these initial fragments since the
initial request id is received after the 1.2 Fragment header specified
request_id.

No Data Available

Summary: When the new IDL types were added (fixed, long double, etc), no new
IIOP or GIOP version was introduced, and no new version of CDR was introduced.
Instead, the marshaling rules for the new types were simply added to CDR,
and the type code interface was extended to handle these.

Unfortunately, this creates some rather serious problems for interoperability.

No Data Available

Summary: Narrowing is used in CORBA to check if an object reference obtained by
a client is of the desired type, ie. supports a specific IDL interface
that the client wants to use.

The client program has static information about the interface it wants
to use from the IDL specification. However, this is not enough as it
must also be possible to invoke remote objects that support an IDL
interface derived from the interface the client knows of.

There are at least 4 possiblities how the type checking can be resolved
(+ combinations of them):

Narrow makes a query to an interface repository.
(ii) Narrow makes a call to the remote object.
(iii) The object reference contains enough information, e.g. the whole
interface type hierarchy that the remote object supports.
(iv) There is no narrow; the type check is made when a request is
received by the server-side ORB.

No Data Available

Summary: I can"t find any text in the CORBA 2.2 spec which says explicitly
whether the "component_data" field of IOP::TaggedComponent is actually
an encapsulation, or something else.

Why don"t we define a typedef "Encapsulation" for "sequence<octet>",
and use it in the IDL for those octet sequences which are really
encapsulations?

:TaggedComponent is actually

Summary: type any marshalling rules force slow implementation

Proposal: require that type any are marshalled as encapsulations

No Data Available

Summary: On page 13-14, the spec says for marshaling of type codes:

"Note that the tuples identifying struct, exception, and enum
members must be in the order defined in the OMG IDL definition
text."

This is right and proper, otherwise I wouldn"t know in what order things are
encoded or what their ordinal values are. However, the text does not
mention unions, so the order in which a type code describes the union
members is left to the implementation.

Suggestion: Require union members to also appear in the order in which
they are defined in the IDL.

No Data Available

Summary: Proposal: allow for alternate, compact encoding of typecodes
It is clear that typecodes are quite long when encoded into CDR and
transmitted over the wire. This is particularly painful when the CORBA::Any
type is used in interfaces. Besides, the use of any is becoming increasingly
important in multiple CORBA specifications, and a global solution to this
problem should be provided.

My proposal is to allow for an alternate encoding of typecodes, for those
specific cases where type identification can be achieved either by other
application specific mechanisms (for example, Name-Value pairs) or where
the Repository Id of the type is enough to reconstruct the full typecode
information locally on the receiving side.

No Data Available

Summary: If a type code does not have a repository ID

(e.g. dynamic type ) then the member names for
structs and unions etc. should be required to be
sent on the wire for GIOP marsalling of Typecodes.
This may help the type code comparision issue to be resolved.

No Data Available

Summary: I just stumbled on the following paragraph in 13.3.4 describing the CDR
encoding of TypeCodes:

"The name parameters in tk_objref, tk_struct, tk_union, tk_enum,
tk_alias, and tk_except TypeCodes and the member name parameters in
tk_struct, tk_union, tk_enum and tk_except TypeCodes are not specified
by (or significant in) GIOP. Agents should not make assumptions about
type equivalence based on these name values; only the structural
information (including RepositoryId values, if provided) is significant.
If provided, the strings should be the simple, unscoped names supplied
in the OMG IDL definition text. If omitted, they are encoded as empty
strings."

This would suggest that the name and member name parts of a typecode
should never be considered significant when an ORB compares typecodes.

Summary: We have come across the following issue with regard to typecode
indirections. The specification states:

the indirection is a numeric octet offset within the scope of some
"top level" TypeCode and points to the TCKind value for the
typecode.

The question arrises then is it legal to point to the (possible)
padding bytes preceeding the TCKind value or must the numberic value
indicate the position of the actual TCKind value. If you assume the
former then having rewound the required number of bytes you would word
align before interogating the TCKind enum value.

Summary: There seems to be no provision for numbering the fragments in fragmented
IIOP messages. It is apparently assumed that the fragments will always
be received in the order that they are generated, however in unreliable
networks, such as mobile networks, this may not be a safe assumption.

No Data Available

Summary: What is the correct encoding for an empty string according to GIOP?

In section 13.3.2, page 13-11 of CORBA 2.2, the following paragraph
describes the encoding of strings:

"A string is encoded as an unsigned long indicating the length of the string
in octets, followed by the string value in single- or multi-byte form
represented as a sequence of octets. Both the string length and contents
include a terminating null."

This does not clarify what is the correct encoding for empty strings,
as there are two possibilities:
a) length=0, no string follows
b) length=1, "\0" (one-char with the terminating null)

No Data Available

Summary: I just stumbled on the following paragraph in 13.3.4 describing the CDR
encoding of TypeCodes:

"The name parameters in tk_objref, tk_struct, tk_union, tk_enum,
tk_alias, and tk_except TypeCodes and the member name parameters in
tk_struct, tk_union, tk_enum and tk_except TypeCodes are not specified
by (or significant in) GIOP. Agents should not make assumptions about
type equivalence based on these name values; only the structural
information (including RepositoryId values, if provided) is significant.
If provided, the strings should be the simple, unscoped names supplied
in the OMG IDL definition text. If omitted, they are encoded as empty
strings."

This would suggest that the name and member name parts of a typecode
should never be considered significant when an ORB compares typecodes.

Of course, this still leaves the issue of what to do about aliases up in
the air.

Summary: With regard to the character encoding issue.

This is not just a problem with Wchar, and Wstring, it can happen
with char and string as well. Multibyte encodings are used for
normal strings in the enhanced IDL as well as for
Wchars.
I think the problem is in the definition of char. For interop, the char type could be either:
1) restricted to a syntactic thing which can only be used with single byte encodings, or
2) we need to bite the bullet and make the encoding for char a sequence
of bytes if a multibyte encoding is chosen.

No Data Available

Summary: CORBA 2.1"s GIOP Exception formatting description (12.4.2)
partitions the space of valid minor codes, with
20 bits reserved for unique vendor IDs and only 12 bits
(4096) for possible minor codes for each exception.
This seems backwards (1 million vendors each with
only 4 thousand minor codes!) and I would like
to request a change to (at least) swap these
numbers with the following textual change:

The high order 10 bits of minor_code_value contain a 10-bit
"vendor minor codeset ID" (VMCID); the low order 22 bits
contain a minor code. A vendor (or group of vendors)
wishing to define a specific set of system exception
minor codes should obtain a unique VMCID from the OMG, and
then define up to (22 bits of) 4194304 minor codes for each
system exception. Any vendor....

No Data Available

Summary: 1. When encoding a wchar, always put 4 bytes into the CDR stream,
> adding any zero pad bytes as necessary to make the value 4 bytes
> long.
2. When encoding a wstring, always encode the length as the total
> number of bytes used by the encoded value, regardless of whether the
> encoding is byte-oriented or not.

No Data Available

Summary: I"ve been reading through 98-01-03.pdf (Change pages from Interop 1.2
RTF), and come across a problem concerning version numbers.

On page 13-39, the following paragraph has been added:

"The version number published in the Tag Internet IIOP Profile body
signals the highest GIOP minor version number that the server supports
at the time of publication of the IOR"

As far as I can see, the only version information in the profile body is
"iiop_version", which has the following note in its description:

"Note - This value is not equivalent to the GIOP version number
specified in GIOP message headers. Transport-specific elements of the
IIOP specification may change independantly from the GIOP specification"

Which is correct?

No Data Available

Summary: All standard OMG IDL including the CORE and all services have implicit #pragma prefix "omg.org". Make sure this appears intext of ALL IDL that is specified, particular in CORBAServices

closed issue

Summary:

resolved, closed issue

Summary: Given the current IDL grammar, there is no way to parse any IDL containing the keyword "Object". It never appears in the grammar as a terminal symbol.

resolved, closed in "97

Summary: OTS 1.1 spec (page 10-17 and 10-18) is not clear whether the WRONG_TRANSACTION exception is intended to be a system exception or a user exception

issue resolved, see revised text

Summary: OTS 1.1 spec doesn"t clearly say which module defines the TRANSACTION_REQUIRED, TRANSACTION_ROLLEDBACK, INVALID_TRANSACTION WRONG_TRANSACTION exceptions.

resolved close issue

Summary: In the Interface Repository spec, StructDef,UnionDef, and ExceptionDef should be derived from Container,since types can be defined within structs,unions,and exceptions according to IDL gram

resolved, close issue

Summary: NVList has an item () operation, which returns a NamedValue reference. The same special memory management rules should apply to item().

Fixed by portability submission

Summary: I propose that public interface of _var types, the similar "smart pointer" types used in struct fields, and "smart pointer" types returned from sequence index operators be extended. (see file)

Fixed by Portability submission

Summary: It"s currently not possible for a C++ client or server to receive a parameter value of type Any, store that value in filesystem or a database and later reconstruct Any value from persistent represe

Fixed by portability submission

Summary: Cannot use DII to invoke an operation that expects or returns a complex user-defined type. Any needs to provide member functions for composing Any"s containing arbitrary user-defined values

Fixed by Portability submission

Summary: There hsould be a way to access an unknown type inside an Any by "iterating" over the Any to examine the type in terms of the primitive types that make it up.

Fixed by Portability submission

Summary: Here is an extremely simple extension to the any type to allow decomposition of values to their constituent parts: <EXAMPLE issue251>

Fixed by Portability submission

Summary: If all I want to do is rethrow an exception in my C++ client code, there is no convenient and compliant way. It would be useful to add extra members to allow this.

Fixed by Portability submission

Summary: Sec 16.12 Pg 16-27 CORBA2.o Why are we returning a Long * from operator[] rather than an LongArray_slice&?

Fixed by Portability submission

Summary: [Sec 16.8.1 Pg 16-14 CORBA2.0 p31, Section 3.10.1 para 14: If I have T_var referring to T. How can I take ownership?How to stop it from being deallocated when T_var goes out of scope?

Fixed by Portability submission

Summary: Standard requires that a conforming implementation must free the inaccessable storage associated with a parameter passed as a managed type(T_var). How to achieve it for out parameters??

Fixed by Portability submission

Summary: Since RTTI is not ubiquitous, the _narrow operations for Exceptions should be defined, even when RTTI available. They are trivial to implement using RTTI.

Fixed by Portability submission

Summary: Implementation dependent: Implementation of parameter passing using T_var types

Fixed by Portability submission

Summary: The typpedef enum at top of page should be called CORBA_CompletionStatus, not CORBA_ExceptionType. Second line 4th paragraph, text should refer to table 13-5, not 3-5

closed with issue 901-2 revision text