Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — Closed Issues

  • Acronym: CORBA
  • Issues Count: 57
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA25-57 CORBAservices IDL CORBA 2.2 CORBA 2.5 Resolved closed
CORBA25-56 SYNC_WITH_SERVER CORBA 2.4.2 CORBA 2.5 Closed; No Change closed
CORBA25-55 International Strings in Encapsulations CORBA 2.3.1 CORBA 2.5 Resolved closed
CORBA25-54 Incorrect example for recursive definitions which can span multiple levels CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-53 Urgent issue: Alignment of LocateReply body CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-52 Incorrect table in section 15.4 CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-51 Incorrect text in 15.4.6.2 CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-50 GIOP 1.1 Fragment problem CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-49 tk_indirect CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-48 Table 15-2 is missing entry for tk_local_interface CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-47 GIOP 1.2 AddressingDisposition processing on the client side CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-46 Fixed point marshalling CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-45 Null termination of strings CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-44 Nil return from resolve_initial_references() CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-43 Interpretation of time field in UtcT? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-42 There is no mapping for fixed types in the COM/CORBA mapping CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-41 COBRA problem using pragma prefix for modules CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-40 CORBA 2.4.2 (01-02-01.pdf) 4.2.3.4 shutdown (relevant portion) CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-39 Local interface is-a Object? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-38 Wither pseudo-objects? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-29 Minor code CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-28 Missing POAManager identity CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-27 BAD_OPERATION needs minor code and completion status CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-26 Cross-reference refers to wrong section CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-25 Issue: Error in section 4.5.3.2 ORBInitRef CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-24 Section 10.5.22.2 what happens when conditions not met CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-23 Restrictions on native types CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-22 Clarification about include files and IDL compiler behavior CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-37 Missing TypeCode identity CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-36 Problem with resolution to 4285 and 4306 CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-35 get_interface() underspecified CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-34 Typo in UML for POA CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-33 DII create_request CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-32 Ambiguity in non_existent CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-31 String literal definition incorrect. CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-30 Inconsistent minor code for MARSHAL CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-21 Definition of NamingContextExt interface in IDL of Appendix A not consisten CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-20 3.7.4 Forward Declaration (for interfaces) doesn't mention local CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-19 What is the semantics of the DataInputStream::read_*_array() operations? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-18 #include issue CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-17 DynValueBox::set_boxed_value should also raise InvalidValue CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-16 misleading wording in 10.5.22.2 Write Interface CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-15 Inconsistent text for unknown system exception CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-14 ForwardRequest from normal operations CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-13 Introduction of identifiers CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-12 Type redefinition in derived interface CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-11 PortableServer::ObjectId CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-10 core issue: unchecked narrow CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-9 Container::lookup() ordering requirements CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-8 Section 2.1.7 of CORBA 2.3 and 2.4 CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-7 Legal IDL? CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-6 CORBA::ORB::object_to_string() raising INV_OBJREF or BAD_PARAM CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-5 ServantLocator preinvoke/ postinvoke semantics CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-4 Minor code 2 description for OBJECT_NOT_EXIST not consistent w/ use CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-3 POAManager::deactivate should not mandate ORB::shutdown implementation CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-2 POAManager::deactivate does not specify behavior for "reject" CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-1 Can a valuetype support multiple non-abstract interfaces via inheritance? CORBA 2.4 CORBA 2.5 Resolved closed

Issues Descriptions

CORBAservices IDL

  • Key: CORBA25-57
  • Legacy Issue Number: 959
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In CosStream Module the CompoundExternaliztion.idl is included
    > (needed for CosCompoundExternalization::Node), and in the
    > CosCompoundExternalization Module the Stream.idl is included (needed
    > for CosStream::Streamable and CosStream::StreamIO). Now correct me
    > if I am wrong but isn"t this self-referential loop going to cause
    > problems with the IDL compiler, in that either CosStream will not
    > know about CosCompoundExternalization or vice-versa causing a
    > compiler error.

  • Reported: CORBA 2.2 — Tue, 24 Feb 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    refer to formal/98-12-16

  • Updated: Wed, 11 Mar 2015 04:16 GMT

SYNC_WITH_SERVER

  • Key: CORBA25-56
  • Legacy Issue Number: 4317
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    On page 22-6, we say for SYNC_WITH_SERVER:

    For a server using a POA, the reply would be sent after invoking
    any ServantManager, but before delivering the request to the target
    Servant.

    What's the motivation for this? Why wait that long? The ServantManager
    may still fail to return a servant for the request, meaning that
    the ORB might as well acknowledge the request before the ServantManager is
    called without losing anything.

    Also, as specified, the receiving ORB has to first run any adapter
    activators. Again, there doesn't seem any point in waiting this long.
    Why can't the receiving ORB simply acknowledge the request as soon as
    it has read the request header off the wire?

  • Reported: CORBA 2.4.2 — Mon, 21 May 2001 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.5
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Sun, 8 Mar 2015 15:22 GMT

International Strings in Encapsulations

  • Key: CORBA25-55
  • Legacy Issue Number: 3221
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    It seems that the only time an international string will ever appear in an
    encapsulation
    would be a private IOR component.

    If we can keep the issue down to International strings in encapsulations
    this will
    simplify the solution.

    If anyone has an example of how any other GIOP header string could carry an
    international
    string please come forth with it quickly.

    The use of international strings in GIOP 1.1 and 1.2 is dependant on the
    asserted use
    of service context code set negotiation. In particular:
    1) if the negotiatiation is not initiated, then strings are passed
    as latin-1 only and wstrings are not allowed to be passed as parameters.
    2) If the negotiation is initated and successfully completed, the
    agreed codesets are used
    respectively for string and wstring
    3) If negotiation is initated by no comon codeset is agreed, then
    UTF-8 is the default for
    string and UTF-16 is the default for Wstring (note: the current codeset
    negotiation does not
    discuss the big endian or litte endian aspects of UTF-16).

    There is also text somewhere in GIOP stating that Encapsulations in IORs
    should be
    encoded in giop 1.0 for maximum interoperability.

    It just occured to me that disallowing international strings in IOR
    encapsulations (i.e., private
    IOR components) is equivalent to assuming that negotiation is not initiated
    for encapsulations.
    This seems to be a consistent set of semantics.

    The only problem with this interpretation, is that it does not allow
    international strings
    in IOR encapsulations.

  • Reported: CORBA 2.3.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    closed in interop/2000-05-01

  • Updated: Sat, 7 Mar 2015 02:37 GMT

Incorrect example for recursive definitions which can span multiple levels

  • Key: CORBA25-54
  • Legacy Issue Number: 4261
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Incorrect example for recursive definitions which can span multiple levels. I and my IDL compiler are missing an identifier in the following example union for the last struct member.

    union Bar; // Forward declaration typedef sequence<Bar> BarSeq; union Bar switch(long) { // Define forward-declared union case 0: long l_mem; case 1: struct Foo

    { double d_mem; BarSeq nested;// OK, recurse on enclosing type being defined }

    ?identifier missing?; };

  • Reported: CORBA 2.4.2 — Mon, 9 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    This has already been fixed in the previous RTF see orbrev/2001-03-01

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Urgent issue: Alignment of LocateReply body

  • Key: CORBA25-53
  • Legacy Issue Number: 4314
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    In CORBA 2.3, a GIOP 1.2 LocateReply message made no requirements as to
    the alignment of the LocateReply body. This meant that the LocateReply
    body needed to be aligned only on a 4-byte boundary. With the resolution
    for issue 2521, published with CORBA 2.4, the spec was changed to require
    alignment of the LocateReply body on an 8-byte boundary.

    The change is incompatible with the CORBA 2.3 definition because the receiver
    must know where to look for the ReplyBody in the the byte stream following
    the message header. (The LocateReply header is 12 bytes long, so changing
    the alignment rules means that the LocateReply body has to start at offset 12
    for CORBA 2.3, but has to start at offset 16 for CORBA 2.4.)

    The change in alignment did not result in a version change of GIOP,
    despite the incompatibility, so it appears that the change is simply illegal.

    There are already deployed products that use the CORBA 2.3 alignment
    rule; therefore, we cannot deploy a CORBA 2.4 compliant product without
    breaking interoperability with already deployed CORBA 2.3 compliant products.

    So, I'd like to request that we back out the change and continue to
    permit a LocateReply body to be aligned on a 4-byte boundary. There was
    never any need to change the alignment of the LocateReply body anyway because
    a LocateReply header has fixed length and, therefore, cannot ever cause
    remarshaling of the body due to a size change in the header. In other
    words, the motivation quoted in the spec for the 8-byte alignment rule
    isn't founded on fact, and the change should never have been made in the first
    place. (See issue 4309 for details.)

  • Reported: CORBA 2.4.2 — Thu, 17 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect table in section 15.4

  • Key: CORBA25-52
  • Legacy Issue Number: 4311
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The table on page 15-31 (Table 15-3 "GIOP Message Types and Originators")
    is in error. For CloseConnection, it shows that only the server can
    send this message but, in GIOP 1.2, either client or server can send
    the message, as detailed in 15.5.1 and 15.4.7.

    Also. in 15.4.7, we have:

    In GIOP version 1.2 both sides of the connection may send
    the CloseConnection message.

    That should be "must", not "may".

  • Reported: CORBA 2.4.2 — Thu, 17 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect text in 15.4.6.2

  • Key: CORBA25-51
  • Legacy Issue Number: 4309
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    15.4.6.2, "LocateReplyBody" says:

    In GIOP version 1.0 and 1.1, Locate reply bodies are marshaled into
    the CDR encapsulation of the containing Message immediately following
    the Reply Header. In GIOP version 1.2, the Reply Body is always
    aligned on an 8-octet boundary. The fact that GIOP specifies the
    maximum alignment for any primitive type is 8 guarantees that
    the ReplyBody will not require remarshaling if the Locate Reply
    Header are modified.

    The final sentence doesn't make sense because the LocateReply header is
    a fixed-length header and therefore can't possibly cause remarshalling.

    I suggest to delete the final sentence of this para.

  • Reported: CORBA 2.4.2 — Wed, 16 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see resolution of Urgent Issue 4314

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GIOP 1.1 Fragment problem

  • Key: CORBA25-50
  • Legacy Issue Number: 4299
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There is nothing in the specification that explicitly states whether the
    data in the body of a GIOP 1.1 Fragment message is marshalled relative
    to the Fragment header or relative to the unfragmented message as a
    whole.

    The restriction in GIOP 1.2 that all fragments but the last must have a
    multiple of 8 bytes, and the careful padding of the GIOP 1.2 Fragment
    header to 16 bytes both strongly suggest that GIOP 1.1 fragments should
    be marshalled only relative to the fragment header.

    Proposed Resolution:

    In section 15.4.9, right after the paragraph that reads:

    "A primitive data type of 8 bytes or smaller should never be broken
    across two
    fragments."

    add the following paragraph:

    In GIOP 1.1, the data in a fragment is marshalled with alignment
    relative to its position in the fragment, not relative to its position
    in the whole unfragmented message.

  • Reported: CORBA 2.4.2 — Fri, 11 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Accept proposal above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

tk_indirect

  • Key: CORBA25-49
  • Legacy Issue Number: 4294
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    I don't understand why tk_indirect isn't allowed as a top-level typecode.
    This causes servere performance penalties for RMI-IIOP because the Java to IDL
    mapping requires that Java objects of declared type java.lang.Object are
    marshalled as CORBA anys. In the case of a Vector or HashTable with 100
    elements, this means that 100 anys must be marshalled. If all of these are
    of actual type foo, the restriction on tk_indirect means that all 100 of
    these data values must repeat the typeCode for foo, which could be very large.
    This causes very substantial overheads, since the space and time needed to
    marshal the TypeCode for foo can greatly exceed that needed to marshal the
    data for foo.

    I understand why a nested tk_indirect cannot refer to any TypeCode outside
    the scope of its enclosing top-level TypeCode. However, I don't think this
    restriction needs to apply to a top-level TypeCode. We have made this
    change experimentally without any adverse effects and we have discovered that
    using tk_indirect for all the top-level foo TypeCodes after the first one can
    speed up some common scenarios by at least a factor of 5 on end-to-end
    measurements. There seems to be no downside to making this change.

    I would therefore like to propose the following change to the section headed
    "Indirection: Recursive and Repeated TypeCodes" within section 15.3.5.1:

    Change the first bullet from:

    The indirection applies only to TypeCodes nested within some “top-level”
    TypeCode. Indirected TypeCodes are not “freestanding,” but only exist inside
    some other encoded TypeCode.

    by the following words:

    The indirection applies only to TypeCodes nested within some “top-level”
    TypeCode, or from one top-level TypeCode to another. Indirected TypeCodes
    nested within a top-level TypeCode can only reference TypeCodes that are part
    of the same top-level TypeCode, including the top-level TypeCode itself.
    Indirected top-level TypeCodes can reference other top-level TypeCodes but
    cannot reference TypeCodes nested within some other top-level TypeCode.

    If this change finds favour, then we need to work out how it can be brought
    into GIOP without causing problems interoperating with older ORBs that insist
    on the stronger restriction of the current spec. This could perhaps be
    added to the "wish list" for GIOP 1.3.

  • Reported: CORBA 2.4.2 — Fri, 4 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Close this issue and add it to the GIOP wish list

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 15-2 is missing entry for tk_local_interface

  • Key: CORBA25-48
  • Legacy Issue Number: 4242
  • Status: closed  
  • Source: Floorboard Software ( Yvonne Biggar)
  • Summary:

    Add the missing entry with the same information as tk_objref.

  • Reported: CORBA 2.4.2 — Tue, 27 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    add the missing table entry with the same information as tk_objref

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GIOP 1.2 AddressingDisposition processing on the client side

  • Key: CORBA25-47
  • Legacy Issue Number: 4213
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    If the server ORB sends back a NEEDS_ADDRESSING_MODE reply to the client indicating the prefered
    addressing disposition, then is the client ORB required to 'cache' the prefered addressing
    disposition per object reference, and use it for further requests to the server ?

  • Reported: CORBA 2.4.2 — Wed, 28 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    to close without revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fixed point marshalling

  • Key: CORBA25-46
  • Legacy Issue Number: 4198
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    I have a query about the intended marshalling format for Fixed. Is the
    sending ORB always required to transmit the number of digits specified
    in the IDL, or is it permitted to transmit fewer if there are leading
    zeros?

    Consider transmitting 123.45 as fixed<6,2>. Is the ORB permitted to
    transmit

    12 34 5c

    or must it send the leading zero (plus another zero to pad the first
    octet):

    00 12 34 5c

    In both cases, the receiving ORB knows it is expecting a scale of 2,
    and the sign half-octet tells it where the digits end, so it can
    correctly unmarshal the value as 123.45.

    The discussion of issue 3431 suggests that the first option is not
    permitted, and leading zeros must always be sent. However, the 2.4
    GIOP spec makes no mention of how many digits should be sent. The
    specification should be clarified to either explicitly permit or
    explicitly forbid stripping of leading zeros.

  • Reported: CORBA 2.4.2 — Wed, 7 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Close with clarification revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Null termination of strings

  • Key: CORBA25-45
  • Legacy Issue Number: 4113
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Section 15.3.2.7 of the CORBA 2.3 spec, which describes the CDR encoding
    of strings, includes the following sentence in the first paragraph:

    "Both the string length and contents include a terminating null."

    It is not clear from this whether exactly one terminating null is required,
    or whether more than one null can be included, with the string being terminated
    by the first null.

    Since IDL strings cannot include nulls (see 3.10.3.2: "OMG IDL defines the string
    type string consisting of all possible 8-bit quantities except null"), any
    additional nulls following the first terminating null cannot be part of the
    string, and it therefore seems reasonable to ignore them.

    Proposed Resolution:

    Change the above sentence in section 15.3.2.7 to:

    "Both the string length and contents include at least one terminating null."

    Also make the same change to the corresponding sentence in the third paragraph
    of section 15.3.2.7 describing GIOP 1.1 wide strings.

  • Reported: CORBA 2.4.1 — Fri, 8 Dec 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    To close with clarification revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Nil return from resolve_initial_references()

  • Key: CORBA25-44
  • Legacy Issue Number: 4532
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The spec doesn't say whether or not resolve_initial_references() is allowed
    to return nil. Clearly, it doesn't make sense for it to do that – we
    should say so in the spec.

  • Reported: CORBA 2.4.2 — Thu, 23 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interpretation of time field in UtcT?

  • Key: CORBA25-43
  • Legacy Issue Number: 4468
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    in the absence of an RTF for the time service, I'm sending this to the
    core RTF. (You could argue that this is a core issue anyway, since
    the core depends on the time service for messaging.)

    What is the interpretation of the time and tdf fields in a UtcT?

    The spec shows:

    struct UtcT

    { TimeT time; // 8 octets unsigned long inacclo; // 4 octets unsigned short inacchi; // 2 octets TdfT tdf; // 2 octets // total 16 octets. }

    ;

    For TimeT, the spec says:

    TimeT represents a single time value, which is 64 bits in size, and
    holds the number of 100 nanoseconds that have passed since the base
    time. For absolute time the base is 15 October 1582 00:00.

    For UtcT, the spec says:

    UtcT defines the structure of the time value that is used
    universally in this service. The basic value of time is of type
    TimeT that is held in the time field. Whether a UtcT structure
    is holding a relative or absolute time is determined by its history.
    [...]
    The tdf field holds time zone information. Implementation must
    place the time displacement factor for the local time zone in this
    field whenever they create a UTO.

  • Reported: CORBA 2.4.2 — Thu, 9 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is no mapping for fixed types in the COM/CORBA mapping

  • Key: CORBA25-42
  • Legacy Issue Number: 4441
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There is no mapping for fixed types in the COM/CORBA mapping. Why has this been omitted? Is there a submission underway?

  • Reported: CORBA 2.4.2 — Tue, 31 Jul 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Close with answers to the qestions raised, as given above under Resolution

  • Updated: Fri, 6 Mar 2015 20:58 GMT

COBRA problem using pragma prefix for modules

  • Key: CORBA25-41
  • Legacy Issue Number: 4395
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Please have a look at the news article below. Basically, the problem is
    that we don't say in the spec what has to happen if I try to give
    conflicting prefixes/IDs/versions to a module (which can happen if a module
    is reopened).

    My feeling is that we should deal with this the same way as for forward
    declarations, that is, force the compiler to emit a diagnostic. I think
    we should also add a note that this can't be enforced by the compiler
    under all circumstances because of separate compilation.
    > Orbacus distribution contains following IDL file.
    >
    > > #pragma prefix "omg.org"
    > >
    > > module CosNaming
    > > {
    > > typedef string Istring;
    > >
    > > struct NameComponent
    > >

    { > > Istring id; > > Istring kind; > > }

    ;
    > > };
    > >
    > > #pragma prefix "ooc.com"
    > >
    > > module CosNaming
    > >

    { > > typedef string Ostring; > > }

    ;
    >
    > And here the error message of IDL to Visual Basic compiler.
    >
    > orbacusnaming.idl:16(8): Attempt to assign a different prefix
    > to a forward-declared identifier
    > orbacusnaming.idl:3(8): Position of the first identifier definition

    The error message is misleading becuase there is no forward-declared
    identifier here. But the compiler has a point – something strange is
    going on there...

    > I look in the CORBA specification and found that modules do have
    > repository ids.

    Absolutely.

    > > Forward-declared constructs (interfaces, value types, structures,
    > > and unions) must have the same prefix in effect wherever
    > > they appear. Attempts to assign conflicting prefixes
    > > to a forward-declared construct result in a compile-time
    > > diagnostic. For example:
    > [...]
    >
    > And what about reopened modules?

    This part of the spec simply doesn't apply because it talks about
    forward-declared things only.

    > Which repository id do they
    > have if someone use different prefix statements? I think
    > they can have only one because the IFR of CORBA allows only
    > one (if the repository version is equal).

    Yes. The spec isn't really clear on this point. Here is your example
    once more, simplified to the bare bones:

    #pragma prefix "X"
    module M

    { typedef string foo; }

    ;

    #pragma prefix "Y"
    module M

    { typedef string var; }

    ;

    The spec simply does not address this problem, so we have a hole. Thinking
    about it, there are two possible interpretations:

    1) Module M gets a prefix "X" initially. Then, when the prefix
    changes to "Y" and the compiler sees M for the second time,
    it could just ignore the prefix for M because M has the prefix
    "X" already.

    2) The compiler could notice that M previously got prefix "X"
    and then complain when it sees M for the second time because
    it would get a conflicting prefix.

    For forward-declared things, the spec applies the philosophy that
    the prefixes must not change. Seeing that a reopened module is somewhat
    similar to a forward declaration (because the same definition can be seen
    more than once), I'd be inclined to amend the spec to say that the prefix
    for a module must not change.

    For cases where the compiler can actually detect this, we can even force
    a diagnostic. However, as for forward-declared things, this is not always
    detectable by the compiler. In particular, if the reopened module is
    reopened in different source files and the two source files are compiled
    separately, there is no way for the compiler to detect that the module
    is getting a different prefix in each source file. If the generated code
    from the two files is linked into the same binary, you should at least
    get a multiple definition error. But if the code for the two files ends
    up in different executables, there is no way to detect the error at all
    and you will get strange things happening at run time.

    As far as the ORBAcus IDL is concerned, I think it needs fixing. The second
    prefix pragma should be inside the module, to avoid the conflict:

    #pragma prefix "omg.org"

    module CosNaming
    {
    typedef string Istring;

    struct NameComponent

    { Istring id; Istring kind; }

    ;
    };

    module CosNaming

    { #pragma prefix "ooc.com" typedef string Ostring; }

    ;

    > Is my IDL2VB compiler again buggy or the Orbacus IDL file
    > or the CORBA specification not clear?

    Well, a little bit of all three I'll raise an issue with the core RTF.

    > I recently solve all founded bugs in IDL2VB and it compiles now
    > all examples of syntax chapter in CORBA spec and find
    > all errors. CORBA is to difficult for humans...

    That's why we use compilers for IDL instead of humans

  • Reported: CORBA 2.4.2 — Sun, 24 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Clarify as described below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA 2.4.2 (01-02-01.pdf) 4.2.3.4 shutdown (relevant portion)

  • Key: CORBA25-40
  • Legacy Issue Number: 4392
  • Status: closed  
  • Source: Anonymous
  • Summary:

    CORBA 2.4.2 (01-02-01.pdf) 4.2.3.4 shutdown (relevant portion): "If the wait_for_completion parameter is TRUE, this operation blocks until the shut down is complete. If an application does this in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock."

    But does this mean that things will be as if the operation has not been called (suggested by the name of the exception raised?), or will they be as if the operation had been called with wait_for_completion FALSE (seems more appropriate)? Or should the implementation decide, and should it just use an appropriate completion code? In this case, is COMPLETION_MAYBE allowed? Letting the implementation decide puts a higher burden on the developer, though, if s/he wants to write portable code, so that developer may decide to just program for the current implementation...

    This question has additional relevance for me because I'm implementing an ORB.

  • Reported: CORBA 2.4.2 — Fri, 29 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Clarify that BAD_INV_ORDER is raised in this case with COMPLETED_NO

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Local interface is-a Object?

  • Key: CORBA25-39
  • Legacy Issue Number: 4388
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    For local interfaces, we seem to have internal inconsistencies in the spec.
    For one, it is not clear whether or not a local interface implicitly inherits
    from Object. There is one sentence in the spec that seems to imply that
    there is implicit inheritance from object, on page 3-23 of the 2.5 draft
    (http://doc.omg.org/ptc/1-6-10):

    Any attempt to marshal a local object, such as via an unconstrained
    base interface, as an Object, or as the contents of an any, or to
    pass a local object to ORB::object_to_string, shall result in a
    MARSHAL system exception with OMG minor code 4.

    This implies that I can at least try to pass local object as CORBA::Object,
    which implies that local interfaces do indeed implicitly inherit from Object.

    But then, a bit further down, it says:

    The is_a, get_interface, get_domain_managers, get_policy,
    get_client_policy, set_policy_overrides, get_policy_overrides, and
    validate_connection pseudo-operations, and any DII support
    pseudo-operations, may result in a NO_IMPLEMENT system exception
    with minor code 3 when invoked on a reference to a local object.

    "May result in a NO_IMPLEMENT system exception"? I would suggest "shall"!

    But, more seriously, I can't call is_a() on a local interface. In turn,
    that seems to imply that I can't narrow a local interface either, but
    narrowing is clearly necessary in the presence of inheritance for local
    interfaces.

    It seems that local interfaces must inherit from Object. After all,
    it would be difficult to see, for example, how resolve_initial_references
    can return a reference to the Root POA if it were otherwise... But then,
    if local interfaces do inherit from Object, It doesn't make sense to
    prohibit calling is_a() on them.

    Related to that then is the question of "What is the repository ID of
    a local interface?" Given that they can be narrowed, it would seem that
    they must have repository IDs. (Although, you could argue that narrowing
    is to be achieved via some mechanism other than repository IDs – that
    would also permit is_a() not to be supported and would make narrowing
    an issue that is specific to each language mapping.)

    But the inheritance issue seems serious – if something doesn't inherit
    from Object, I can't return or pass it as an Object, but we are doing
    just that for local objects.

    I think this will require some careful thought. We don't want to find
    ourselves in yet another maze of twisty little passages, all different,
    as we did with pseudo-objects...

  • Reported: CORBA 2.4.2 — Fri, 29 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wither pseudo-objects?

  • Key: CORBA25-38
  • Legacy Issue Number: 4387
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the terms "pseudo-object", "pseudo-interface", and "PIDL" appear in many
    places in the spec. However, there does not appear to be a definition
    of what these things actually are anywhere in the spec. Now, for many years
    now, I've been telling people that PIDL objects differ from normal ones
    in the following ways:

    • They don't inherit from Object.
    • They can't be invoked via the DII.
    • They don't have definitions in the IFR.
    • They can't be passed as arguments to remote operations
      (except for TypeCode).
    • They may have special mapping rules.

    I know that, once upon a time, when I first wrote these points into a CORBA
    training course, I didn't just make them up – I found them in the spec.
    However, I'm damned if I can find them now. I looked in the 2.0 spec as
    well as the 2.4.2 spec to no avail. Can someone help me out?

    At any rate, we should add the definition somewhere because, write now,
    we have lots of free-floating terms in the spec.

    On a related note, by searching for "pseudo", I found a few places where
    it is stated that "pseudo-objects do not have object references". That
    seems to be wrong. After all, we pass these things across (local) interfaces
    by reference (instead of by value) and, at the language mapping level,
    pseudo-objects have references that are indistinguishable from any other
    reference. We should correct this.

  • Reported: CORBA 2.4.2 — Fri, 29 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor code

  • Key: CORBA25-29
  • Legacy Issue Number: 4306
  • Status: closed  
  • Source: Anonymous
  • Summary:

    "If a ServantManager returns a null Servant (or the equivalent in a language mapping) as the result of an incarnate() or preinvoke() operation, the POA will return the OBJ_ADAPTER system exception with standard minor code 3 as the result of the request."

    Should that be minor code 2 rather than 3? I couldn't find any other reference to OBJ_ADAPTER minor code 2 and the description makes more sense for this condition.

  • Reported: CORBA 2.4.2 — Mon, 14 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Yes the minor code in this case should indeed be 2. Make it so

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing POAManager identity

  • Key: CORBA25-28
  • Legacy Issue Number: 4297
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the current way of dealing with POAManager objects is less than satisfactory.
    Consider:

    interface POA

    { // ... POA create_POA( in string adapter_name, in POAManager a_POAManager, in CORBA::PolicyList policies ) raises(AdapteraAlreadyExists, InvalidPolicy); readonly attribute POAManager the_POAManager; }

    ;

    The problem here is twofold:

    • There is no way to get at the list of all existing POA managers,
      at least not easily; I have to either keep a list myself,
      or I have to traverse the POA tree and build the list as I go.
    • POA managers have no identity. There is no name or other piece
      of state that would allow me to distinguish one POA manager from
      another.

    The second problem is the more serious one because POA managers are used
    to control the behavior of one or more transport endpoints. Most ORBs
    permit configuration control over transports. For example, it is usually
    possible to configure things such as which protocols/transports should
    be associated with a POA manager, how many protocols/transports should
    be associated, at what address/port the transport controlled by a
    POA manager should listen for requests, what timeouts to apply, etc, etc...

    Currently, ORBs have to resort to proprietary means to attach such
    configuration information. For example, in ORBacus, we use a proprietary
    POA manager factory that permits a name to be attached to a POA manager.
    That name then is used as a hook to attach configuration information
    to POA managers, so we can do things like configure port numbers, etc.

    I'd like to improve the spec such that it becomes possible to control
    identity for POA managers through a standard API. The thoughts are:

    • Add a POAManagerFactory interface that allows
    • creation of POA managers
    • listing of existing POA managers
    • searching for POA managers by name
    • Add an id() accessor to POAManager that returns the name

    For creation of POA managers, a CORBA::PolicyList can be passed into
    the call in addition to the POA manager name. That policy list would permit
    configuration of POA managers through a defined API (even though the
    actual policies that apply would still be proprietary).

    These changes would be completely backward-compatible, so no existing
    code breaks.

  • Reported: CORBA 2.4.2 — Wed, 9 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

BAD_OPERATION needs minor code and completion status

  • Key: CORBA25-27
  • Legacy Issue Number: 4285
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    "This indicates that an object reference denotes an existing object,
    but that the object does not support the operation that was invoked."

    This text does not specify a minor code nor a completion status.

    Section 11.3.4.1 (last paragraph) says:

    "If the ServantManager returns the wrong type of Servant, it is
    indeterminate when that error is detected. It is likely to result in a
    BAD_OPERATION with standard minor code 5 or MARSHAL exception at the
    time of method invocation."

    This implies that 4.11.3.13 should specify a '5' for the minor code.

    A specific minor code for this case is necessary since BAD_OPERATION
    may be raised in other contexts (e.g., IDL->Java mapping for union,
    Any, any extraction, ...).

    I am not sure why it says '5' in 4.11.3.13. Is this minor code
    specified somewhere else that I'm missing?

    Assuming that this is underspecified I would suggest:

    1. assigning a minor code for the case discussed in 4.11.3.13,

    2. making sure that 11.3.4.1 is in sync with that assignment,

    3. specifying a completion status of COMPLETED_NO (since there is no
    way anything could be completed since the call never makes it out of
    the skeleton into the servant).

  • Reported: CORBA 2.4.2 — Thu, 26 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Cross-reference refers to wrong section

  • Key: CORBA25-26
  • Legacy Issue Number: 4276
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The second paragraph of "3.10.1.7 Any Type" uses a cross-reference to explain the concept of the TypeCode in an Any value. This cross-reference refers to section 3.10, which is useless.

    Suggestion: Change this cross-reference to read as follows: '(see Section 10.7, "Type Codes", on page 10-51)'

  • Reported: CORBA 2.4.2 — Wed, 18 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Fix as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Error in section 4.5.3.2 ORBInitRef

  • Key: CORBA25-25
  • Legacy Issue Number: 4275
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    Section 4.5.3.2 says:
    <ObjectURL> can be any of the URL schemes supported by
    CORBA::ORB::string_to_object (Sections 13.6.6 to 13.6.7 CORBA 2.3
    Specification).

    Couple of problems w/ this. Shouldn't the reference be Section 13.6.10
    of this spec. Also, the ObjectURL specifications in chapter 13 include a
    "rir" protocol which obviously makes no sense for ORBInitRef.

    Proposal:

    Replace first sentence of last paragraph of section 4.5.3.2 from:

    <ObjectURL> can be any of the URL schemes supported by
    CORBA::ORB::string_to_object (Sections 13.6.6 to 13.6.7 CORBA 2.3
    Specification).

    to

    <ObjectURL> can be any of the URL schemes supported by
    CORBA::ORB::string_to_object (Section 13.6.10), with the exception of
    the corbaloc URL scheme with the rir protocol (i.e. corbaloc:rir:...).

  • Reported: CORBA 2.4.2 — Tue, 17 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Fix as suggested above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 10.5.22.2 what happens when conditions not met

  • Key: CORBA25-24
  • Legacy Issue Number: 4266
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    What happens when someone attempts to set the mode attribute while not
    adhering to the restrictions spelled out?

    We should say what happens if these conditions
    aren't met. Furthermore, a oneway method can't have exceptions.
    I suggest:

    • add a new row to the BAD_PARAM block in Table 10-1 (p.10-10):

    Exception Minor Code Explanation

    BAD_PARAM N Attempt to define a oneway
    operation with non-void result,
    out or inout parameters or
    exceptions

    • Add a similar entry to table 4.3 (p.4-61).
    • Change the last para of 10.5.22.2 to read:

    "The mode attribute can be set to OP_ONEWAY only if the result is
    TC_void, all elements of params have a mode of PARAM_IN, and the
    list of exceptions is empty. If the mode is set to OP_ONEWAY
    when these conditions do not hold, a BAD_PARAM exception is
    raised with minor code N."

    This is perhaps rather large to be a friendly ammendment. I'm
    happy to vote YES to the current resolution, which is still a
    useful change, and raise this for next time. I can't discuss
    further in this round, as I'm on vacation for a week from this
    evening.

  • Reported: CORBA 2.4.2 — Wed, 11 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Restrictions on native types

  • Key: CORBA25-23
  • Legacy Issue Number: 4264
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    The new text in 3.10.5 states: "Native type parameters are permitted
    only in operations of local interfaces or valuetypes". However, 11.4
    states that:
    a) Servant is a native type, and
    b) that it is used on the POA::get_servant operation, and
    c) that POA is not a local interface
    (Taking POA as an arbitrary example here; other POA interfaces show
    the same problem). Does that mean that CORBA 2.5 will be inconsistent?

  • Reported: CORBA 2.4.2 — Tue, 10 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification about include files and IDL compiler behavior

  • Key: CORBA25-22
  • Legacy Issue Number: 4262
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I think it would be nice to mention something about code generation in
    section 19.5.22.2. People seem to either expect that the compiler will
    generate code for everything, or that it will generate code only for
    things that are not in included files. The following might help to clear
    this up:

    "Note that whether a particular IDL compiler generates code for included
    files is an implementation-specific issue. To support separate
    compilation, IDL compilers may not generate code for included files, or
    do so only if explicitly instructed."

  • Reported: CORBA 2.4.2 — Tue, 10 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Insert the sugested text in section 3.3

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing TypeCode identity

  • Key: CORBA25-37
  • Legacy Issue Number: 4386
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Steve's and my book contains a bit of code that pretty-prints a TypeCode.
    (See page 704ff, in particular, 709-711.) No big deal – just write
    a recursive function that does a depth-first traversal of a TypeCode tree
    and prints things out, except for one thing: recursive types.

    For recursive types, the code has to be careful not to get trapped in
    infinite recursion. In essence, this means that the pretty-printer has to
    remember which TypeCodes it has already seen and end the recursion if it gets
    to a TypeCode that was printed previously. This is where we run into
    problems because there is no legal way to do this:

    • I cannot rely on the repository ID in the TypeCode to determine
      TypeCode identity because the repository ID for structs and
      unions is optional prior to GIOP 1.2, but recursion happens
      via structs and unions. (A GIOP 1.2 implementation may interoperate
      with a GIOP 1.0 or 1.1 implementation and still end up sending
      TypeCodes without repository IDs.)
    • The code in the book uses is_equivalent() to determine whether
      it has seen a TypeCode previously. However, doing this is
      completely illegal (even though it happens to work with most
      ORBs) because:
    • is_equivalent() does not provide object identity.
    • TypeCode is a pseudo-object, and pseudo-objects do
      not inherit from CORBA object. This means that TypeCode
      doesn't even have an is_equivalent() operation that I
      could call.

    So, as far as I can see, there is no compliant way to reliably and portably
    determine TypeCode identity and, as a result, I can't ever reliably parse
    a TypeCode...

    I can see several solutions for this problem, all with different drawbacks:

    1) Add an identity() operation of some kind to TypeCode.

    An ORB that receives a TypeCode would have to make sure that
    it generates a unique ID for each TypeCode. But that's not
    all that easy to implement – in particular, if we have an
    older TypeCode where all the optional bits are missing, we
    can't reliably establish object identity for a TypeCode.
    (Only structural comparison is possible.)

    2) Add an identity() operation to TypeCode, but have the TypeCode's
    identity generated at the sending end instead of the receiving
    end.

    Major drawbacks: the identity would have to large because it
    needs to be globally unique (e.g. a UUID) and it would change
    the marshaling of TypeCodes.

    3) Add is_equivalent() and hash() operations to TypeCode.

    This might break existing ORB implementations because a lot
    of ORBs seem to inherit from Object for TypeCode and other PIDL
    objects, even though they shouldn't.

    4) Make PIDL objects implicitly inherit from CORBA::Object.

    Note that making the repository ID mandatory is impossible because we
    can't legislate for existing GIOP 1.0 or 1.1 implementations...

    On a related note, we seem to have further problems with the idea that
    PIDL objects don't inherit from CORBA::Object. For example, in the C++ mapping,
    pseudo-objects such as TypeCode, ORB, etc. can be passed as Object_ptr
    (for example, to CORBA::is_nil()). This really means that the C++ mapping
    (and possible mappings for other languages) are completely in conflict
    with the core spec...

    My feeling is that option 4 is really the least-intrusive one. But I'm
    not sure that I fully understand all the ramifications of making that change.

  • Reported: CORBA 2.4.2 — Thu, 28 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problem with resolution to 4285 and 4306

  • Key: CORBA25-36
  • Legacy Issue Number: 4385
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    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?

  • Reported: CORBA 2.4.2 — Sat, 23 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Fix inconsistency as described below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

get_interface() underspecified

  • Key: CORBA25-35
  • Legacy Issue Number: 4335
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the text for get_interface() says:

    An operation on the object reference, get_interface, returns an object
    in the Interface Repository, which provides type information that may
    be useful to a program. See the Interface Repository chapter for a
    definition of operations on the Interface Repository. The
    implementation of this operation may involve contacting the ORB
    that implements the target object.

    This does not say what should happen if I call _get_interface() and

    • the interface repository isn't running,
    • the interface repository is running and can be reached, but
      doesn't contain an entry for the object's interface.

    Looking at the INTF_REPOS exception, we have:

    An ORB raises this exception if it cannot reach the interface
    repository, or some other failure relating to the interface
    repository is detected.

    This would indicate that, if the repository isn't running, the client should
    get INTF_REPOS. However, we have no idea what should happen if the repository
    is in fine shape, but no entry exists for the interface.

    Since an unpopulated interface repository is very much the same thing as
    no interface repository at all, I would like to flag both scenarios as an
    error.

    Proposal: add the following sentence to the end of 4.11.3.22:

    If the interface repository is not available, get_interface() raises
    INTF_REPOS with minor code 1. If the interface repository does not
    contain an entry for the object's (most derived) interface,
    get_interface() raises INTF_REPOS with minor code 2.

    Update the minor code table in 4.11.4 accordingly.

  • Reported: CORBA 2.4.2 — Tue, 5 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make the suggested change and the additional change suggested in the archive

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in UML for POA

  • Key: CORBA25-34
  • Legacy Issue Number: 4333
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The UML diagram on page 11-49 uses "the_manager" in two places. This
    should be "the_POAManager".

    In one place, it uses the attribute "the_servant_manager". No such attribute
    exists.

  • Reported: CORBA 2.4.2 — Mon, 4 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make the suggested corrections

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DII create_request

  • Key: CORBA25-33
  • Legacy Issue Number: 4331
  • Status: closed  
  • Source: Anonymous
  • Summary:

    CORBA 2.4.1 final, Section 7.2.1 (create_request), page 7-7, last
    paragraph reads:

    "If the name of an implicit operation that is not invocable through DII
    is passed to create_request with a "_" prepended, create_request shall
    raise a BAD_PARAM standard system exception".

    This does not specifies the minor code for the exception.

  • Reported: CORBA 2.4.2 — Fri, 1 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguity in non_existent

  • Key: CORBA25-32
  • Legacy Issue Number: 4322
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Section 4.3.5.1 non_existent last paragraph says:

    Probing for object non-existence may require contacting the ORB that
    implements the
    target object. Such an attempt may fail at either the local or the
    remote end. If non-existent
    cannot make a reliable determination of object existence due to failure,
    it
    raises an exception in the calling application code. This enables the
    application to
    distinguish among the true, false, and indeterminate cases.

    This does not define what exception gets thrown in the indeterminate
    case. I picked TRANSIENT, but COMM_FAILURE or NO_RESPONSE may also be
    valid choices.

    Proposal:

    Change the sentence in last paragraph of section 4.3.5.1:
    If non-existent cannot make a reliable determination of object existence
    due to failure, it
    raises an exception in the calling application code.

    to:
    If non-existent cannot make a reliable determination of object existence
    due to failure, it
    raises a TRANSIENT with XX minor code in the calling application code.

  • Reported: CORBA 2.4.2 — Thu, 24 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    close, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

String literal definition incorrect.

  • Key: CORBA25-31
  • Legacy Issue Number: 4320
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    The following from the CORBA 2.4.1 specification.
    3.2.5.2 Character Literals
    A character literal is one or more characters enclosed in single quotes,
    as in ’x.’
    Character literals have type char.
    A character is an 8-bit quantity with a numerical value between 0 and
    255 (decimal).

    3.2.5.4 String Literals
    A string literal is a sequence of characters (as defined in Section
    3.2.5.2, “Character
    Literals,” on page 3-9) surrounded by double quotes, as in “...”.

    The above statements together implies that a string literal may contain
    embedded NULL characters. That is incorrect. The definition of string
    literals must explicitly eliminate NULL.

    Proposal:
    Revised text:

    Section 3.2.5.4 String Literals

    replace this first paragraph
    A string literal is a sequence of characters (as defined in Section
    3.2.5.2, “Character
    Literals,” on page 3-9) surrounded by double quotes, as in “...”.

    with
    A string literal is a sequence of characters (as defined in Section
    3.2.5.2, “Character
    Literals,” on page 3-9), with the exception of the character with
    numeric value 0, surrounded by double quotes, as in “...”.

  • Reported: CORBA 2.4.2 — Mon, 21 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make it so

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent minor code for MARSHAL

  • Key: CORBA25-30
  • Legacy Issue Number: 4310
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    on page 3-23 of section 3.7.6.1, first bullet point, we find:

    Local types cannot be marshaled and references to local objects
    cannot be converted to strings. Any attempt to marshal a local
    object, such as via an unconstrained base interface, as an Object,
    or as the contents of an any, or to pass a local object to
    ORB::object_to_string, shall result in a MARSHAL system exception
    with OMG minor code 2.
    ^^^^^^^^^^^^^^^^
    However, the minor code table, page 4-59, section 4.11.4 shows:

    MARSHAL 1 Unable to locate value factory.
    2 ServerRequest::set_result called before
    ServerRequest::ctx when the operation IDL contains a
    context clause.
    3 NVList passed to ServerRequest::arguments does not
    describe all parameters passed by client.
    4 Attempt to marshal Local object.

    This is inconsisent – the text requires minor code 2, but the table
    requires minor code 4.

    I would suggest to update the first bullet of 3.7.6.1 to require minor code 4,
    in line with what is shown in the table.

  • Reported: CORBA 2.4.2 — Thu, 17 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make it so

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of NamingContextExt interface in IDL of Appendix A not consisten

  • Key: CORBA25-21
  • Legacy Issue Number: 4246
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The definition of the NamingContextExt interface in the IDL of Appendix A is not consistent with the definition in section 2.5.4.

    Specifically,

    1. The Appendix A version has an extra operation: resolve_context

    2. In Appendix A, there is an extra exception type in the raises clause of the resolve_str operation: AlreadyBound

  • Reported: CORBA 2.4.2 — Thu, 29 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

3.7.4 Forward Declaration (for interfaces) doesn't mention local

  • Key: CORBA25-20
  • Legacy Issue Number: 4241
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 3.7.4 doesn't mention local as a legal prefix for an interface
    forward declaration.

    Proposal 1:

    Change the sentence:

    "The syntax is: optionally the keyword abstract, followed by the keyword
    interface, followed by an <identifier> that names the interface."

    to:

    "The syntax is: optionally either the keyword abstract or the keyword
    local, followed by the keyword interface, followed by an <identifier>
    that names the interface."

    Proposal 2:

    Just strike the sentence entirely, since it is redundant.

  • Reported: CORBA 2.4.2 — Tue, 27 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make the recommended change in Proposal 1

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What is the semantics of the DataInputStream::read_*_array() operations?

  • Key: CORBA25-19
  • Legacy Issue Number: 4233
  • Status: closed  
  • Source: Floorboard Software ( Yvonne Biggar)
  • Summary:

    The CORBA::DataInputStream abstract valuetype has operations like:

    void read_boolean_array( inout BooleanSeq seq,
    in unsigned long offset,
    in unsigned long length);

    However, the spec says nothing about whether the provided sequence must
    already have sufficient length to satisfy the offset+length or whether
    the operation will extend the sequence to fit.

  • Reported: CORBA 2.4.2 — Fri, 23 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Clarify that the operations are expected to extend the sequence to fit

  • Updated: Fri, 6 Mar 2015 20:58 GMT

#include issue

  • Key: CORBA25-18
  • Legacy Issue Number: 4226
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    A minor issue with section 3.3 of the 2.4 specification:

    "... Text in files included with a #include directive is treated as
    if it appeared in the including file. ..."

    That is not true since, as we find out in chapter 10, included files
    behave specially with regard to assigning repository identifiers.

    e.g. in

    // a.idl
    #pragma prefix "foo"
    interface bar {};

    the repository id of bar is IDL:foo/bar:1.0, but in

    // a.idl
    #pragma prefix "foo"
    #include "b.idl"

    // b.idl
    interface bar {};

    it is just IDL:bar:1.0.

  • Reported: CORBA 2.4.2 — Tue, 20 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DynValueBox::set_boxed_value should also raise InvalidValue

  • Key: CORBA25-17
  • Legacy Issue Number: 4224
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • Summary:

    As with other DynAny operations that accept an Any parameter,
    the set_boxed_value operation should be capable of raising
    InvalidValue.

    Proposal:

    • In sections 9.2 and 9.12, add InvalidValue to the raises clause for
      set_boxed_value
    • In section 9.12, replace the text describing set_boxed_value with the
      following:

    "The set_boxed_value operation replaces the boxed value with the specified
    value. If the type of the passed Any is not equivalent to the boxed type,
    the operation raises TypeMismatch. If the passed Any does not contain a
    legal value, the operation raises InvalidValue. If the DynBoxedValue
    represents a null valuetype, it is converted to a non-null value."

  • Reported: CORBA 2.4.2 — Fri, 16 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make it so

  • Updated: Fri, 6 Mar 2015 20:58 GMT

misleading wording in 10.5.22.2 Write Interface

  • Key: CORBA25-16
  • Legacy Issue Number: 4217
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The mode attribute can only be set to OP_ONEWAY if the result is TC_void and all
    elements of params have a mode of PARAM_IN.

    which might be taken to mean that the mode attribute must be set to
    OP_ONEWAY if the signature is as described. A better wording might be

    The mode attribute can be set to OP_ONEWAY only if the result is TC_void and all
    elements of params have a mode of PARAM_IN.

    This was brought to my attention by an email question I received today, from
    someone who thought he understood CORBA oneway semantics until he
    read that sentence - then he became confused.

  • Reported: CORBA 2.4.2 — Fri, 2 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    make it so

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent text for unknown system exception

  • Key: CORBA25-15
  • Legacy Issue Number: 4189
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • Summary:

    In document 01-01-01, there are the following paragraphs which seem
    contrary to one another regarding the minor code to be used when an
    ORB receives an unrecognized system exception.

    4.11.2
    Vendors may define non-standard system exceptions, but these exceptions are
    discouraged because they are non-portable. A non-standard system exception, when
    passed to an ORB that does not recognize it, shall be presented by that ORB as an
    UNKNOWN standard system exception. The minor code and completion status from
    the unrecognized exception shall be preserved in the UNKNOWN exception.

    15.3.5.5 Exception
    Exceptions are encoded as a string followed by exception members, if any. The string
    contains the RepositoryId for the exception, as defined in the Interface Repository
    chapter. Exception members (if any) are encoded in the same manner as a struct.
    If an ORB receives a non-standard system exception that it does not support, or a user
    exception that is not defined as part of the operation's definition, the exception shall be
    mapped to UNKNOWN, with standard minor code set to 2 for a system exception, or
    set to 1 for a user exception.

  • Reported: CORBA 2.4.2 — Sat, 3 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ForwardRequest from normal operations

  • Key: CORBA25-14
  • Legacy Issue Number: 4176
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    interface Foo

    { void op() raises(PortableServer::ForwardRequest); }

    ;

    What happens if a client invokes op() and op() throws ForwardRequest?
    Is this received by the client as a locate forward or does the client
    simply receive the exception?

    The spec doesn't say either way. However, thinking about how all this is
    implemented, I strongly suspect that current implementations will simply
    marshal the exception back to the client instead of sending a locate forward
    reply.

    Personally, I think that's how it should be. If it werent, we'd have to
    insert additional code into the user exception processing path to deal
    with this special exception (which would probably set a bad precedent).

    I'd suggest to amend the spec to state that ForwardRequest has the effect
    of causing a locate forward reply only if thrown from preinvoke() and
    incarnate() and is otherwise just a normal exception.

  • Reported: CORBA 2.4.1 — Fri, 26 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate change and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Introduction of identifiers

  • Key: CORBA25-13
  • Legacy Issue Number: 4171
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    I cannot seem to come to grips with the introduction of identifiers
    by their use in a nested scope. The example on page 3-54 reads
    (simplified)

    module Inner1

    { typedef string S1; }

    ;

    module Inner2

    { typedef Inner1::S1 S2; // Inner1 introduced typedef string inner1; // Error }

    ;

    The text goes on to explain that the above construct introduces the
    identifier "Inner1", while using the absolute name, "::Inner1::S1"
    in the typedef wouldn't. Therefore, the following code would be
    legal:

    module Inner2

    { typedef ::Inner1::S1 S2; // Inner1 not introduced typedef string inner1; // legal }

    ;

    I fail to see the rationale in this. Also, this is not in sync with
    the Interface Repository, which cannot even detect that the first
    example is illegal, because it never sees relative names.

    My proposed resolution would be to get rid of "introduced names"
    altogether and to declare the above example legal.

  • Reported: CORBA 2.4.1 — Tue, 23 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Type redefinition in derived interface

  • Key: CORBA25-12
  • Legacy Issue Number: 4170
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The discussion for issue 3525 shows that it is legal to redefine a type
    in a derived interface, as in

    interface B

    { typedef string S; }

    ;
    interface D : B

    { typedef long S; }

    ;

    However, I don't think that this legality is obvious from the text. On
    page 3-52, it says that "inheritance causes all identifiers defined in
    base interfaces to be visible in derived interfaces." Then, on page
    3-56, it is said that "once a type has been defined anywhere within
    the scope of a module, interface or valuetype, it may not be redefined
    except within the scope of a nested module or interface."

    Since B::S is not "defined" but only "visible" in D, and D is not a
    nested interface but a derived interface, there seems to be a gray
    area.

    Proposed resolution:

    Edit the first paragraph of 3.15.3 (Special Scoping Rules for Type
    Names) on p 3-56 to read:

    "Once a type has been defined anywhere within the scope of a module,
    interface or valuetype, it may not be redefined except within the
    scope of a nested module, interface or valuetype, or within the
    scope of a derived interface or valuetype."

    Edit the following example to include, after interface A, but before
    the erroneous redefinition of ArgType,

    interface B : A {
    typedef long ArgType; // OK, redefined in derived interface
    struct S

    { // OK, redefined in derived interface ArgType x; // x is a long A::ArgType y; // y is a string }

    ;
    };

  • Reported: CORBA 2.4.1 — Tue, 23 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make the suggested change clarifying the inheritance case

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PortableServer::ObjectId

  • Key: CORBA25-11
  • Legacy Issue Number: 4165
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    I propose that ObjectId be changed from:

    typedef sequence<octet> ObjectId;

    to:

    typedef CORBA::OctetSeq ObjectId;

    This shouldn't cause any existing code to break. However, currently
    PortableInterceptor::ObjectId (needed so that the PI module doesn't
    depend on the PortableServer module) isn't directly assignable to
    PortableServer::ObjectId which means additional copying that doesn't
    seem necessary. It also reduces the code-size of the ORB somewhat
    (since a sequence type can be removed from the core).

  • Reported: CORBA 2.4.1 — Sat, 20 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

core issue: unchecked narrow

  • Key: CORBA25-10
  • Legacy Issue Number: 4159
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    CORBA Core should state that language mappings providing a narrowing mechanism
    are also required to provide an 'unchecked narrowing'-mechanism.

    The original CORBA Messaging specification (orbos/98-05-05) specifies an
    unchecked narrow operation that has not been changed by any Messaging RTF.
    'unchecked narrowing' is not an issue of a single language mapping. Therefore,
    it would be good if this was formulated in the CORBA Core as a general
    requirement for any language mapping.

    The originally adopted CORBA Messaging specification, orbos/98-05-05, had an
    explanatory paragraph for this purpose:

    '3.3.7 Note on Asynchrony and Narrowing of Object References
    Many programming languages map IDL interfaces to programming constructs that
    support inheritance. In those language mappings (such as C++ and Java) that
    provide
    a mechanism for narrowing an Object reference of a base interface to a more
    derived
    interface, the act of narrowing may require the full type hierarchy of the
    target. In this case, the implementation of narrow must either contact an
    interface repository or the target itself to determine whether or not it is
    safe to narrow the client’s object reference. This requirement is not
    acceptable when a client is expecting only
    asynchronous communication with the target. Therefore, for the appropriate
    languages
    this specification adds an unchecked narrow operation to the IDL mappings for
    interface. This unchecked narrow always returns a stub of the requested type
    without
    checking that the target really implements that interface. If a client narrows
    the target to an unsupported interface type, invoking the unsupported
    operations will raise the system exception CORBA::BAD_OPERATION.'

    However, the semantics of the above have obviously not made it into CORBA 2.4.

  • Reported: CORBA 2.4.1 — Fri, 19 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Container::lookup() ordering requirements

  • Key: CORBA25-9
  • Legacy Issue Number: 4152
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In the Interface Repository, Container::contents() and describe_contents()
    do not seem to have any restrictions on ordering. However, these seem to
    be necessary for interoperability, so that a dynamic bridge that tries to
    find out about a Value by using Container::contents (dk_ValueMember, 0)
    does the right thing.

  • Reported: CORBA 2.4.1 — Tue, 16 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Add language to require preservation of order of elements in IR as shown below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 2.1.7 of CORBA 2.3 and 2.4

  • Key: CORBA25-8
  • Legacy Issue Number: 4135
  • Status: closed  
  • Source: Object Management Group ( Jon Siegel)
  • Summary:

    Section 2.1.7 of CORBA 2.3 and 2.4 (and presumably all earlier
    versions) concludes with the sentence

    Object-oriented programming languages, such as C++ and Smalltalk,
    do not require stub interfaces.

    I suspect that this is a relic of some prehistoric age when early
    OMG folk imagined that OO languages would handle some stub stuff
    via language mechanisms. Since this has not turned out to be the
    case, the sentence should be excised.

  • Reported: CORBA 2.4.1 — Wed, 3 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    incorporate change and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Legal IDL?

  • Key: CORBA25-7
  • Legacy Issue Number: 4132
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Is the following legal IDL?

    module M
    {
    abstract interface I

    { string s(); }

    ;

    valuetype V supports I

    { private string s; }

    ;
    };

    Our interpretation of the spec is that it is legal but we have been informed
    that some other IDL compilers consider it an error.

  • Reported: CORBA 2.4.1 — Wed, 20 Dec 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::ORB::object_to_string() raising INV_OBJREF or BAD_PARAM

  • Key: CORBA25-6
  • Legacy Issue Number: 4128
  • Status: closed  
  • Source: Progress Software ( Eoghan Glynn)
  • Summary:

    There appears to be a contradiction in CORBA 2.4.1 (00-11-07) as to
    whether CORBA::ORB::object_to_string() should raise INV_OBJREF or
    BAD_PARAM when an invalid string is passed.

    Here's where I see a contradiction in the spec:

    CORBA 2.4.1: "4.11.3.6 INV_OBJREF
    This exception indicates that an object reference is internally
    malformed. For example, the repository ID may have incorrect syntax or
    the addressing information may be invalid. This exception is raised by
    ORB::string_to_object if the passed string does not decode correctly."

    This explicitly specifies that INV_OBJREF is thrown if a non-decodable
    stringified IOR is passed to string_to_object().

    On the other hand the table:
    CORBA 2.4.1: "4.11.4 Standard Minor Exception Codes ...
    BAD_PARAM ...
    7 string_to_object conversion failed due to bad scheme name.
    8 string_to_object conversion failed due to bad address.
    9 string_to_object conversion failed due to bad bad schema specific
    part.
    10 string_to_object conversion failed due to non specific reason."

    indicates that BAD_PARAM/10 should be raised for non-specific
    string_to_object failures, contradicting 4.11.3.6 above.

    Is this simply an editing issue in that 4.11.3.6 has not yet been
    updated to take cognizance of 4.11.4? I propose that 4.11.3.6 is updated
    to allow BAD_PARAM to be raised on string_to_object failures where the
    problem lies in the string content.

  • Reported: CORBA 2.4.1 — Tue, 19 Dec 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above, Close issue, already fixed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ServantLocator preinvoke/ postinvoke semantics

  • Key: CORBA25-5
  • Legacy Issue Number: 4117
  • Status: closed  
  • Source: Borland Software Corporation ( Andy Cutright)
  • Summary:

    the 2.4 specification states that 'preinvoke and postinvoke operations
    are always called in paris in response to any ORB activity...' the spec
    details in particular the case of what happens when preinvoke is called
    when processing a GIOP Locate message: postinvoke is called subsequent
    to calling preinvoke.

    if the preinvoke raises an exception, what is the expected behavior?
    should postinvoke be called if preinvoke raises a system exception or
    ForwardRequest? are there any situations in which postinvoke would not
    be called following a call to preinvoke?

  • Reported: CORBA 2.4.1 — Wed, 10 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Clarify the expected behavior if preinvoke raises an exception

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor code 2 description for OBJECT_NOT_EXIST not consistent w/ use

  • Key: CORBA25-4
  • Legacy Issue Number: 4037
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    I was looking at the spec to amend 4033 to not use up a new minor code but
    noticed this text for minor code 2 under OBJECT_NOT_EXIST:

    POAManager::incarnate failed to create POA.

    This is clearly not consistent with its use under the TRANSIENT POA Lifespan
    Policy description (I also found other inconsistent uses, detailed below).

    There are two things that need fixing here. The first one is probably
    straightforward.
    1. The minor code allocated for 4033 must be used in the text for TRANSIENT
    Lifespan Policy in section 11.3.7.2

    2. POAManager::incarnate is not a valid operation at all.
    I found references to OBJECT_NOT_EXIST with minor code 2 in the following
    places:

    A - Section 11.2.6, paragraph 2

    The adapter activator has the opportunity to create the required POA. If it
    does not, the client receives the
    OBJECT_NOT_EXIST exception with standard minor code 2.

    B - Section 11.2.6
    If the POA has the NON_RETAIN policy or has the RETAIN policy but didn't
    find a
    servant in the Active Object Map, the POA takes the following actions:
    Bullet 3

    • If t he USE_OBJECT_MAP_ONLY policy is in effect, the POA raises the
      OBJECT_NOT_EXIST system exception with standard minor code 2.

    C - 11.3.3.2 unknown_adapter
    If the operation returns TRUE, the ORB will
    proceed with processing the request. If the operation returns FALSE, the ORB
    will
    return OBJECT_NOT_EXIST with standard minor code 2 to the client.

    D - 11.3.3.2 unknown_adapter
    If the parent of a nonexistent POA does not have an
    associated adapter activator, the ORB will return the OBJECT_NOT_EXIST
    system
    exception with standard minor code 2.

    E - 11.3.7.6 Request Processing Policy
    USE_ACTIVE_OBJECT_MAP_ONLY - If the Object Id is not found in the
    Active Object Map, an OBJECT_NOT_EXIST system exception with standard
    minor code 2 is returned to the client.

    Cases A, C and D hint that minor code 2 should actually say "Could not
    create or locate POA" or something to that effect. Cases B and E should
    really be using another minor code ("Could not locate object in AOM?").

  • Reported: CORBA 2.4.1 — Tue, 14 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    incorporate change and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POAManager::deactivate should not mandate ORB::shutdown implementation

  • Key: CORBA25-3
  • Legacy Issue Number: 4034
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    Section 11.3.2.6 has a paragraph that states:

    If the ORB::shutdown operation is called, it makes a call on deactivate
    with a
    TRUE etherealize_objects parameter for each POA manager known in the
    process;
    the wait_for_completion parameter to deactivate will be the same as the
    similarly
    named parameter of ORB::shutdown.

    Shouldn't this be reworded to not require an explicit call to
    deactivate(but only the effect). Also, since ORB::shutdown already does
    the equivalent of destroy on the POAs shouldn't the order of these
    operations be specified. I also think they should be specified in the
    text for ORB shutdown rather than here.

  • Reported: CORBA 2.4.1 — Wed, 8 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Right, make it so

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POAManager::deactivate does not specify behavior for "reject"

  • Key: CORBA25-2
  • Legacy Issue Number: 4033
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    This is the first issue I found w/ POAManager::deactivate definition.

    The spec states in section 11.3.2.6, paragraph 1.

    Entering the inactive state causes the associated POAs to reject
    requests that have not
    begun to be executed as well as any new requests.

    However, there is no definition of what "reject" means. What does the
    client see in this case?

    Proposal:

    Add to the paragraph:
    When a request is rejected, an OBJECT_NOT_EXIST system exception with
    standard minor code XX is returned to the client.

  • Reported: CORBA 2.4.1 — Wed, 8 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    The proposal proved to be too controversial. So suggest close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Can a valuetype support multiple non-abstract interfaces via inheritance?

  • Key: CORBA25-1
  • Legacy Issue Number: 4003
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.4 specification is not clear about whether a valuetype can
    support multiple non-abstract interfaces via inheritance. Here is an
    example:

    interface I1 {};

    interface I2 {};

    valuetype V1 supports I1 {};

    valuetype V2: V1 supports I2 {};

    Is V2 legal?

    I see three possible resolutions to this issue:

    1. Make V2 illegal. A valuetype may not support a non-abstract
    interface if any of its base valuetypes supports a non-abstract
    interface. This is a pretty simple rule, but I think it is far too
    restrictive, and can get in the way of some cases where supporting
    multiple interfaces could be genuinely useful.

    2. Make V2 legal. Since we have clarified (assuming that the proposed
    resolution of 3589 passes, which it appears it will) that valuetypes
    that support an interface are not synonymous with an object reference
    that uses that valuetype as a servant, I don't see any actual core
    issues that break the object model. Also, my inspection of the language
    mappings does not reveal any problems on that front either.

    3. Make V2 illegal, but make it legal if I2 inherited from I1. The
    rule would be that a valuetype can support a non-abstract interface only
    if that interface is derived (directly or indirectly) from all other
    non-abstract interfaces that are supported by base valuetypes. This
    allows the use of the ladder inheritance pattern, which I think is very
    useful in this case:

    interface I1 {};

    valuetype V1 supports I1 {};

    interface I2 {};

    valuetype V2 supports I2 {};

    interface I3 : I1, I2 {};

    valuetype V3 : V1, V2 supports I3 {};

    Of these three posible resolutions, I prefer #2, since I don't see any
    practical implementation problems, so the restriction in #3 is really
    not necessary.

  • Reported: CORBA 2.4 — Fri, 27 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT