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: Does Bounds have data members or not? At what scope should Bounds be defined? Given that Bounds exception is also used by Request interface, I suspect what is meant is CORBA::Bounds

no change to spec., close issue

Summary: It would make iDL definition of an interface much more complete if they were permitted. X/Open would like OMG to consider permitting listing of Standard Exceptions in raises clauses.

Duplicate of issue # 389...closed

Summary: Do simple types like "long" have specified repository IDs? ("IDL:CORBA/long:1.0") How about anonymous types, like "sequence <long, 10>"?

clarified, close issue

Summary: Is it permissible to declare an exception as an explicit parameter?

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: There is an inconsistency between the IDL grammar as defined in chapter 3 of CORBA2.0 spec and an IDL example from same chapter(Example p. 3-16..rule 71 and rule 36 specify different

resolved, close issue

Summary: Last sentence: Seems like an odd thing to say. All X/Open specs only guarantee that they are correct if system is configured correctly. Not a big deal

resolved, close issue

Summary: Unacceptable to say that "calling the ORB_init function multiple times for the same ORB may be required where an ORB is implemented as a shared library."

defer to portability

Summary: X/Open would like to see either the provision for a system default ORB or an interface that application could use to get list of available ORBs from which to choose.

No change to the specification. The existing spec supports a default ORB

Summary: Para describes implementation strategies that ORB implementors might use to ensure ORBS remain synchronized about presence of objects.Info really appropriate for this spec?

no change required, close issue

Summary: Concept of "type safe narrow" isn"t really described. What"s it"s importance, announcement mechanism, and whether it can be portably relied on by programmers. Where"s more info in spec??

resolved, close issue

Summary: Para 1-comment: These interfaces are very important parts of ORB interface. Their semantics are very unclear. What exceptions are they permitted to raise? Expand on this definition.

resolved, close issue

Summary: it"s not clear from this whether the string generated by object_to_string is portable accross ORBs or among clients. Please add text clarifying portability of generated string.

resolved, close issue

Summary: The mention of the kind attribute should be bold-face

resolved, close issue

Summary: The trailing period is missing.

changed, close issue

Summary: Change "...not by modify..." to "...not by modifying..."

resolved, close issue

Summary: Numbered bullet list following this para is formatted poorly. Text items should be alligned and offset from the numbers in a consistent way

resolved, close issue

Summary: Paragraph 1 - editorial: Change the reference to "get_interface" to the appropriate type-face

resolved, close issue

Summary: Paragraph starts off by explaining that previous versions of CORBA weren"t complete. Not necessary to belabor this point. It"s not clear whether or not this lack has been repaired.

This is fixed by the new DSI text from the Portability FP

Summary: Para 4: editorial Change "..OMG IDL for operation.." to "..OMG IDL for the operation...:.

resolved, close issue

Summary: Change "value(s) values" to "value(s)

resolved, close issue

Summary: Para 0 - editorial: Add a line containing ");" to the PIDL for get_response, to match the PIDL given in section 4.2.

resolved, close issue

Summary: Paragraph 1 - editorial : The leading "c" in create_request is not boldface

resolved, close issue

Summary: There is an extra space between the table reference "Table 21" and the period

resolved, close issue

Summary: Dynamic Invocation Interface is a proper name, and should be capitalized and italicized

resolved, close issue

Summary: Change "This standard system exception" to "The OBJECT_NOT_EXIST exception", to make explicit which exception is being discussed

resolved, close issue

Summary: Para last, comment: We understand why standard exceptions may not be listed on a raises expression, but it would make IDL definition of interface more complete if permitted.

resolved, close issue

Summary: Para 2, editorial: Change "...(as specified by the <member> in its declaration." to "...(as specified by the <member> in its declaration)."

resolved, close issue

Summary: Paragraph 2, editorial: Change " registration of implementations" to "Registration of implementations"

resolved, close issue

Summary: Paragraph 1, editorial: Change "....up the "request." to "....up the request."

resolved, close issue

Summary: Change "Descriptions of the values and exceptions...." to "For descriptions of the values and exceptions..."

resolved, close issue

Summary: Para points to C Language Binding chapter and the DII for info on dynamic invocation of objects. It implies that DII is only available in C. Text should pobably be more clear

resolved, close issue

Summary: Page 3-35 doesn"t really say that the list of standard exceptions belong to the CORBA module, although 3.12 seems to clarify.

resolved, close issue

Summary: How is it possible in IDL to specify a union with an enum discriminator type?

no change necessary, close issue

Summary: What should _is_a() return when invoking it with an input parameter designating CORBA::Object?

closed with revised text

Summary: CORBA says "Once an unqualified name is used in a scope, it cannot be redefined", but my IDL compiler allows it. Is it legal?

no change to spec., close issue

Summary: Is there a difference between standard/system exception? Can an implementation raise both? Is raising a standard exception the recommended way to handle errors while setting an attribute?

resolved, close issue

Summary: For the DII, what value if any can be placed into the Any in the NamedValue corresponding to an OUT parameter? Must it be NULL, or is it legal to include a storage pointer? Also for DSI.

resolved, close issue

Summary: Can a Request pseudo object be invoked multiple times?

resolved, close issue

Summary: It is uncertain whether or not the explicit value used to discriminate between various arms of a union is information which is required to be supported.

resolved, close issue

Summary: What does "semantically constrained" mean in section 3.8.2 under the discussion of recursive type specifications.

closed issue, resolved

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