${taskforce.name} Avatar
  1. OMG Task Force

Core RTF — All Issues

Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA26-99 Include GIOP over Bluetooth into Wireless CORBA 1.1 CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-96 New core issue: need UNKNOWN reply status CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-98 TypeCode interface issue CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-97 Valuetype initialzers need exceptions CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-95 Syntax error in CORBA IDL CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-87 Length of wstring in GIOP 1.1 CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-86 padding at the end of a non-fragmented 1.2 request message CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-83 IANA ports for IIOP need to be documented in Ch 13 and 15 CORBA 2.3 CORBA 2.6.1 Resolved closed
CORBA26-85 Interop, 15.7.3 unclear wording CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-84 Is GIOP 1.x sustainable any more? CORBA 2.3 CORBA 2.6.1 Resolved closed
CORBA26-82 Use of undefined "id" attribute CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-93 Question about corbaname URL CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-92 Incomplete grammar in section 15.3.4.8 CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-91 Indirections with chunking & fragmentation CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-89 In RMI rep Id, when is inclusion of SUID legal? CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-88 GIOP is silent about extra data in the Request or Reply body CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-90 GIOP issue : fragmented replies with exceptions CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-94 Changing VSCID prefix to 24 bits CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-72 Component port introspection CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-71 "supports" terminology issue for CCM CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-77 CCM: Definition of import declaration unclear CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-70 CCM: Chapter 66 should be removed CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-69 IDL out parameters can't map to EJB? CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-74 explicit definition of CCM exceptions mapped from EJB standard exceptions CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-73 Incorrect syntax in Components::Enumeration CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-81 minor IDL changes required in CCM API CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-80 Little problem with introspection API CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-79 CCM: Meaning of "exposed" scopes unclear. CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-68 CCM: usage of the MOF profile CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-76 CCM: Isolated scope tokens CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-75 Issue for Components: Missing language mapping CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-78 CCM: import and re-opening of modules CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-63 Extended Interface Repository CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-62 Problems with the Components Notification Event Interface CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-61 Component home interface inheritance CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-56 Components, Facets, and Object References Unclear CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-55 New component issue: connection failure recovery CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-65 Components FTF: TypeCodeFactory CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-64 ComponentIR Interface fixes CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-58 Component assemblies do not follow composition pattern CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-57 Inter-component type semantics unclear CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-54 Typo in assembly element paragraph heading CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-53 grammar rule for home_executor_body contradicts description CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-52 No Access to event filter form component CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-60 Component home polymorphism CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-59 Component assembly templates CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-67 CCM : Session2Context naming CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-66 CCM : Session2Context and Servants CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-51 No user access to filterable body in CCM spec. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-50 IDL question concerning CCM CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-49 CCM Events issue CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-48 typo in connections element definition CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-45 Deployment Object Life Cycles CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-44 Services available for a basic container CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-43 push() versus push_event() CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-41 An assembly is always mono-vendor ??? CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-40 Intent of Components::Events::(un)subscribe to bypass the notif. service ? CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-39 Channel Setup for Emits ports. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-38 exception raised by Components::Events::subscribe() CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-37 ExecutablePlacement definition CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-36 Local push() operation. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-47 repository element needed by softpkg DTD CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-46 description element need to be added to corbacomponent.dtd CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-42 equivalent interfaces issue CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-32 operation get_implementation() referenced but not declared CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-31 Pbl: Improper mapping rule from IDL3 to IDL2 when dealing with events. CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-30 Issue on Assemblies and descriptors CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-33 What about valuetype factories? CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-35 simple ELEMENT definition CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-34 range description in CPF files. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-23 Bridge Interoperability of the Java mapping with the EJB-to-CCM mapping CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-22 CCM issue chapter 69 ptc/99-10-04 CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-21 Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01 CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-20 EJB/CCM mappings for the IR CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-19 IFR backward compatibility broken CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-18 Missing Rights Combinator in Security deployment descriptor CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-13 Purpose of "name" element CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-12 CCM Issue: CIDL Syntax doesn't allow for modules CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-29 Issue On the use of typed home (or CCMHome subtypes) CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-28 Where is HomeExecutorBase interface defined? CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-27 In example p.615-86 CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-26 p.615-85 ToonTownImpl CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-25 Why does not CCMHome include the operation create_component() ? CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-24 operation CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-15 PACKAGING AND DEPLOYMENT METAMODEL CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-14 atribute not part of definition CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-11 Versioning needed for CORBA Core CORBA 2.2 CORBA 2.6.1 Resolved closed
CORBA26-17 Components: readonly_attr_declarator slightly ambiguous CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-16 Components: Relationship of CIDL and PSDL unclear CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-10 section 7.1.1 claims to define the "NVList structure", but doesn't CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-9 Implied IDL for interfaces in modules CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-8 IDL for ORB::resolve_initial_references CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-7 set_length operation of the DynSequence interface CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-6 the IDL include directive should introduce declarations into the namespace CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-5 DynUnion operations CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-4 Problem with IDL Context interface CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-3 Chapter 11, section 11.3.8.19 (WrongPolicy)" CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-2 Support for is_a for local interfaces CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-1 Section 11.3.8.16 - ambiguity CORBA 2.5 CORBA 2.6 Resolved closed

Issues Descriptions

Include GIOP over Bluetooth into Wireless CORBA 1.1

  • Key: CORBA26-99
  • Legacy Issue Number: 5994
  • Status: closed  
  • Source: Nokia ( Kimmo Raatikainen)
  • Summary:

    Include GIOP over Bluetooth into Wireless CORBA 1.1

  • Reported: CORBA 2.5 — Mon, 14 Jul 2003 04:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see below

  • Updated: Sun, 8 Mar 2015 21:43 GMT

New core issue: need UNKNOWN reply status

  • Key: CORBA26-96
  • Legacy Issue Number: 4747
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    The Java RTF recently passed a resolution to fix some problems with the
    use of portable interceptors with the co-located call optimization. This
    resolution introduced a new abstract class ServantObjectExt that extends
    org.omg.CORBA.portable.ServantObject with methods for reporting
    normal and exceptional completion of the co-located call.

    When we look at the issue of mixed versions of stubs and ORBs with
    this change, there is one case that is particularly interesting:
    an old stub (uses only ServantObject) with a new ORB (provides
    ServantObjectExt). In this case, the ORB can detect that an old
    stub was used, because neither one of the two new methods was called.
    However, this leaves the ORB with no way to report the reply status
    correctly in the RequestInfo::reply_status attribute.

    To handle this special case, I propose that we add a new value of
    UNKNOWN for the reply status. This will only be used if the ORB
    cannot determine the reply status of an operation. This occurs
    with any co-located optimized call with the existing Java mapping.
    With the passage of the resolution to issue 4701, the scope of
    this occurence is smaller but still possible.

    Revised text:

    In section 21.3.12.10, add after PortableInterceptor::TRANSPORT_RETRY:

    PortableInterceptor::UNKNOWN

    In section 21.3.12.10, replace the third bullet under client with:

    Within the receive_other interception point, this attribute will
    be any of: SUCCESSFUL, LOCATION_FORWARD, TRANSPORT_RETRY, or UNKNOWN.
    SUCCESSFUL means an asynchronous request returned successfully.
    LOCATION_FORWARD means that a reply came back with LOCATION_FORWARD
    as its status. TRANSPORT_RETRY means that the transport mechanism
    indicated a retry - a GIOP reply with a status of NEEDS_ADDRESSING_MODE,
    for instance. UNKNOWN means that the ORB was unable to determine
    the correct status. This can occur for example in the Java language
    mapping when the optimized path for a co-located call is used.

    In section 21.3.12.10, replace the third bullet under server with:

    Within the send_other interception point, this attribute will
    be any of: SUCCESSFUL, LOCATION_FORWARD, or UNKNOWN.
    SUCCESSFUL means an asynchronous request returned successfully.
    LOCATION_FORWARD means that a reply came back with LOCATION_FORWARD
    as its status. UNKNOWN means that the ORB was unable to determine
    the correct status. This can occur for example in the Java language
    mapping when the optimized path for a co-located call is used.

    In section 21.10, add the following after const ReplyStatus TRANSPORT_RETRY = 4:

    const ReplyStatus UNKNOWN = 5;

  • Reported: CORBA 2.5 — Wed, 12 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    No Data Available

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

TypeCode interface issue

  • Key: CORBA26-98
  • Legacy Issue Number: 4803
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The section concerning with the TypeCode interface was removed from the Interface Repository chapter into the ORB Interface chapter, but the Minimum CORBA chapter refers to it in the old place.

  • Reported: CORBA 2.5 — Thu, 10 Jan 2002 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    No Data Available

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

Valuetype initialzers need exceptions

  • Key: CORBA26-97
  • Legacy Issue Number: 4785
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Valuetype initializers need exception declarations in order to provide
    complete mapping of Java declarations to IDL declarations in Java to IDL
    mapping.

    Discussion: This was discussed in te past and rejected because of the
    backward non-compatible changes required in the IFR. This time
    around.... the IFR changes are already part of the backward compatible
    changes maded in connection with the addition of exeptions to attributes
    etc in CCM in resolution to issue 3233. So all that is needed is change
    to one grammar rule and provision of language mappings. As the results
    of Components FTF is merged into Core to create CORBA Core 3.0
    everything then falls into place to give us initializers with exceptions
    for valuetypes.

    Issue 3641 in Java-IDL RTF is handling the Java language mapping issue,
    and Simon is shepherding that.

    We need to create a C++ language mapping issue and resolve it with the
    obvious mapping in C++ (Michi?)

    Specfic text changes:

    All changes specified here relative to document ptc/01-06-10:

    1. On page 3-13 change grammar production rule 23 to read:

    (23) <init_dcl> ::= “factory” <identifier>
    “(“ [ <init_param_decls> ] “)” [ <raises_expr> ] “;”

    instead of:

    (23) <init_dcl> ::= “factory” <identifier>
    “(“ [ <init_param_decls> ] “)” “;”

    2. On page 3-26 in section 3.8.1.5 change grammar production
    rule 23 to read:

    (23) <init_dcl> ::= “factory” <identifier>
    “(“ [ <init_param_decls> ] “)” [ <raises_expr> ] “;”

    instead of:

    (23) <init_dcl> ::= “factory” <identifier>
    “(“ [ <init_param_decls> ] “)” “;”

  • Reported: CORBA 2.5 — Mon, 17 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    Accept the proposed change based on discussion above

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

Syntax error in CORBA IDL

  • Key: CORBA26-95
  • Legacy Issue Number: 4742
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    In formal/01-11-01.txt, the second occurrence of create_native reads

    NativeDef create_native(
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    );

    This is incorrect; the comma after version must be removed.

  • Reported: CORBA 2.5 — Sun, 9 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see below

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

Length of wstring in GIOP 1.1

  • Key: CORBA26-87
  • Legacy Issue Number: 3075
  • Status: closed  
  • Source: Fujitsu ( Masayoshi Shimamura)
  • Summary:

    I have a question about GIOP wstring encoding. Section "15.3.2.7 Strings
    and Wide Strings" in CORBA 2.3.1 says:

    For GIOP version 1.1, a wide string is encoded as an unsigned long
    indicating the length of the string in octets or unsigned integers
    (determined by the transfer syntax for wchar) followed by the
    individual wide characters. Both the string length and contents
    include a terminating null. The terminating null character for a
    wstring is also a wide character.

    In the sentence above, I believe that the "length" represents number of
    octets (in the case of byte oriented codeset) or number of unsigned
    integers (in the case of non-byte oriented codeset).

    For example,

    "abc" (ASCII code) ----> length is 4 (including one null terminate)
    L"abc" (Unicode, USC2) ----> length is 4 (including one null terminate of wchar)

    Is my understanding right?

  • Reported: CORBA 2.3.1 — Fri, 3 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

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

padding at the end of a non-fragmented 1.2 request message

  • Key: CORBA26-86
  • Legacy Issue Number: 3014
  • Status: closed  
  • Source: AT&T ( Sai-Lai Lo)
  • Summary:

    Suppose a GIOP 1.2 request message is sent for an operation with no
    argument. In this case the request body is empty because there is no
    argument.

    Furthermore, the whole request message is non-fragmented, i.e. the
    2nd least significant bit of Flags in the request header is 0. Now if the
    request message header ends on a boundary which is not 8-byte
    aligned. Should the request message be extended with extra padding after the
    request message header to make the whole request message multiple of 8?

    I think the relevant statement is in section 15.4.1 (page 15-31):

    "For GIOP version 1.2, if the second least significant bit of Flags is 1,
    the sum the message_size value and 12 must be evenly divisible by 8"

    My intepretation of the statement is that the condition I just described
    does not meet this critera. Hence the message should not be padded to
    multiple of 8. It should just be ended with the end of the message header,
    just like previous GIOP versions.

    I'm asking for clarification on this issue because I'm seeing a different
    behaviour in another ORB implementation and would like to pre-empt any
    interoperability problem in future.

  • Reported: CORBA 2.3.1 — Tue, 9 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

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

IANA ports for IIOP need to be documented in Ch 13 and 15

  • Key: CORBA26-83
  • Legacy Issue Number: 2939
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Chapter 15 (formal/99-07-19), page 15-51 last para of section 15.7.2, and
    Chapter 13 (formal/99-07-17), page 13-36 last para, assert that "no 'well known'
    ports have been allocated", and then proceeds to state that individual
    implementations must use some unallocated port and document it.

    The statement about "no well known port has been allocated" needs to be revised
    to reflect that a well known port (683 for IIOP) has been allocated. Then we can
    change the statement about what individual implementations are expected to do by
    merely replacing the "must use some unallocated port" by a "may use the well
    known port or may use some unallocated port and document it" or some such.

  • Reported: CORBA 2.3 — Tue, 21 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Interop, 15.7.3 unclear wording

  • Key: CORBA26-85
  • Legacy Issue Number: 2952
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I do have a quick question on one part and that is
    Section 15.7.3 IIOP IOR Profile Components. This first paragraph has the
    following line in it: " All these components are optional presence in the
    IIOP profile
    and cannot be dropped from an IIOP 1.1 or 1.2 IOR". Now I must admit that I
    am
    new to this CORBA thing, but is there something wrong with this sentence?
    I am not quite sure what this means and the grammar seems quite odd ("are
    optional prensence"?). Any chance someone could translate?

  • Reported: CORBA 2.3.1 — Fri, 15 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

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

Is GIOP 1.x sustainable any more?

  • Key: CORBA26-84
  • Legacy Issue Number: 2941
  • Status: closed  
  • Source: ( Adrian St. John)
  • Summary:

    Is GIOP 1.x really sustainable any more?
    We've got implementation nightmares because:

    • Features haven't been thought through properly
      eg Fragment in 1.1, BiDir in 1.2
    • Simple backwards compatibility is being lost
      eg ReplyHeader v1.2 has fields in completely different places to
      previous versions, albeit for very good reasons.
    • The TypeCode CDR version problems
    • Not enough information in certain messages
      eg MessageError can't indicate which message may have caused a
      problem, and certainly can't describe in what way there was an error.
  • Reported: CORBA 2.3 — Thu, 23 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

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

Use of undefined "id" attribute

  • Key: CORBA26-82
  • Legacy Issue Number: 3197
  • Status: closed  
  • Source: Ericsson ( John-Luc Bakker)
  • Summary:

    I have a number of issues with the Software Package Descriptor section of
    the CCM specification (Component Spec - Volume I, orbos/99-07-01.) I have
    not found answers to issues raised below in either the components-ftf
    archive, or the issues list.

    ISSUE - The softpkg descriptor example uses an "id" attribute, which isn't
    defined in the softpkg.dtd.

    >From page 10-305, 10.2.1 A softpkg Descriptor Example, CORBA Components -
    orbos/99-07-01:

    <idl id="IDL:M1/Bank:1.0" ><link href="ftp://x/y/Bank.idl"/></idl>

    According to the softpkg.dtd, (page B-435, B.1 softpkg.dtd, CORBA Components

    • orbos/99-08-05, ) the idl element is defined as follows:

    <!ELEMENT idl
    ( link

    fileinarchive
    repository
    ) >

    The same definition can also found in section 10.2.2.14, The idl Element (,
    page 10-311, CORBA Components - orbos/99-07-01.) There are no attributes
    defined for the idl element.

  • Reported: CPP 1.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Question about corbaname URL

  • Key: CORBA26-93
  • Legacy Issue Number: 4342
  • Status: closed  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

    I have an interoperability question regarding the
    corbaname URL in the CORBA 2.4.2 specification and would appreciate
    clarification.

    In 13.6.7.3, it states that for a corbaloc URL which
    uses IIOP, if the port number of the endpoint is
    not specified, then the IIOP profile should default
    to port 2809 which is specified by IANA as the corbaloc
    port.
    eg.
    corbaloc:iiop:myhost.com/SomeKey

    In 13.6.7.5, the corbaname URL is described.
    If a corbaname URL is specified for IIOP, but the port
    number is omitted, should the ORB assume that the
    root naming context will be on port 2809 of the host
    specified?

    eg.
    corbaname:iiop:myhost.com:3000#path/obj

    will look for the root naming context on port
    3000 of myhost.com.

    eg.
    corbaname:iiop:myhost.com#path/obj

    Should this look to port 2809 for the root
    naming context?

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

    see above

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

Incomplete grammar in section 15.3.4.8

  • Key: CORBA26-92
  • Legacy Issue Number: 4339
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    In orbrev/01-03-01:

    Production rule two at the end of this sections has a comment that it
    should include all IDL types, but in actuality is missing "long long",
    unsigned long long" and "long double".

    Suggest we add these to the production rule in question.

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

    No Data Available

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

Indirections with chunking & fragmentation

  • Key: CORBA26-91
  • Legacy Issue Number: 4328
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    When chunking and fragmenting, it is possible for a chunk length to be
    inserted between the indirection tag and indirection offset.
    Implementations must be careful to compute the indirection offset
    correctly both when writing and reading to avoid errors.

    For interoperability, we should elminate this possibility. From an
    implementation point of view, the code for handling this special case
    should already be there. Please see the original message (see
    attachment) for a detailed description of the problem scenario and two
    implementation possibilities.

    Proposed resolution:

    Elminate the possibility of chunk lengths between indirection tag and
    indirection offset by changing the following paragraph in CORBA formal
    00-11-03 15.3.4.6.

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

    see below

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

In RMI rep Id, when is inclusion of SUID legal?

  • Key: CORBA26-89
  • Legacy Issue Number: 4280
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    In formal 00-11-03 10.6.2 in the discussion of the serial version UID in
    the RMI hashed format, the spec defines the repository ID format as

    RMI: <class name> : <hash code> [ : <serialization version UID> ]

    and says

    "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."

    The Java to IDL spec ptc-00-01-06 1.3.5.7 says

    "The syntax of the repository ID is the standard OMG RMI Hashed format,
    with an initial “RMI:” followed by the Java class name, followed by a
    hash code string, followed optionally by a serialization version UID
    string."

    Questions:

    1) Is it legal to include the serial version UID in the repository ID
    even when it is equal to the hash code? (Alternatively: Is it legal
    for an ORB to throw an exception/fail if the hash code and serial
    version UID in the repository Id are the same?)

    2) If it is not legal to include the serial Version UID in the
    repository ID when equal to the hash code, what should an ORB do?

    Discussion:

    Other than it not harming anything to include the SUID, there are rare
    cases that the same Java class compiled with different compilers can
    result in different default serial version UIDs, so it would be wise to
    explicitly specify the serialVersionUID field even in the first version
    of a class. If it is legal to always include the serial version UID
    part of the repository ID, ORBs with classes from two different
    compilers would still be able to interoperate.

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

    see below

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

GIOP is silent about extra data in the Request or Reply body

  • Key: CORBA26-88
  • Legacy Issue Number: 4273
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The specification does not say whether extra data after the invocation
    parameters in a Request or Reply body is ignored or considered an
    error. For interoperability purposes, the spec should require one or
    the other.

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

    see below

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

GIOP issue : fragmented replies with exceptions

  • Key: CORBA26-90
  • Legacy Issue Number: 4289
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    Let us assume that the server has sent a few reply fragments. But before sending all the reply
    fragments, an exception occurs (say while marshalling the response).
    What does the server and the client (which has already seen reply fragments) do ?

    Just to note, notice that if the same problem happens while the client is in the midst of sending
    request fragments, the client can choose to send a CancelRequest message to intimate the server.

    Since there are various possible behaviours for the client and server, the GIOP specification needs
    to clarify the standard behaviour, in order for different implementations to remain interoperable.

    One possible behaviour :

    The server could send back a seperate response (containing the exception with
    CompletionStatus.COMPLETED_YES). The client on receipt of the new reply, and noticing the fact that
    another reply with the same requestId is pending, could discard the pending reply and process the
    latest reply.

    Another behaviour :

    The client could simply timeout the request and discard any new reply streams (with the same
    requestId), and raise an exception with CompletionStatus.COMPLETED_MAYBE.

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

    This issue is resolved by the resolution to issue 4273.

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

Changing VSCID prefix to 24 bits

  • Key: CORBA26-94
  • Legacy Issue Number: 4618
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    In section 13.6.8 of CORBA 2.4.2 (formal/01/02-01), at the top of page
    13-29, it says:

    The high-order 20 bits of service-context ID contain a 20-bit vendor
    service context codeset ID (VSCID); the low-order 12 bits contain the rest
    of the service context ID. A vendor (or group of vendors) who wish to
    define a specific set of system exception minor codes should obtain a
    unique VSCID from the OMG, and then define a specific set of service
    context IDs using the VSCID for the high-order bits.

    The VSCID of zero is reserved for use for OMG-defined standard service
    context IDs (i.e., service context IDs in the range 0-4095 are reserved as
    OMG standard service contexts).

    The VSCID-related text was added by the Interop 1.2 RTF as per RTF report
    as in document number interop/98-01-04, and revised pages as in document
    number interop/98-01-03. However, at about the same time OMG staff
    established a convention that OMG should allocate vendors a 24-bit "service
    tag", which is in fact the same as a VSCID. Since then, some 47 of these 24
    bit service tags have been assigned to various vendors.

    At the risk of having the tail wag the dog, I propose we resolve this
    conflict by revising these paragraphs in the CORBA spec as follows:

    The high-order 24 bits of a service context ID contain a 24-bit vendor
    service context codeset ID (VSCID); the low-order 8 bits contain the rest
    of the service context ID. A vendor (or group of vendors) who wishes to
    define a specific set of system exception minor codes should obtain a
    unique VSCID from the OMG, and then define a specific set of service
    context IDs using the VSCID for the high-order bits.

    The VSCIDs of zero to 15 inclusive (0x000000 to 0x00000f) are reserved for
    use for OMG-defined standard service context IDs (i.e., service context
    IDs in the range 0-4095 are reserved as OMG standard service contexts).

  • Reported: CORBA 2.5 — Fri, 12 Oct 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Component port introspection

  • Key: CORBA26-72
  • Legacy Issue Number: 4412
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The Components::Navigation interface that is implemented by all
    components provides introspection ("generic navigation") capabilities.
    There are lots of use cases for introspection, so I wonder why there
    is introspection for facets, but not for receptacles or event ports.
    I suggest to add such introspection capabilities. All introspection
    features should be alike as much as possible for ease of usage.

  • Reported: CORBA 2.4.2 — Mon, 16 Jul 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

"supports" terminology issue for CCM

  • Key: CORBA26-71
  • Legacy Issue Number: 4329
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    . I don't
    think OMG specifications should use a single term in two distinctly
    different ways. The text of the issue starts with the sentence,
    "the Components spec and valuetype spec treat "supports" exactly
    *OPPOSITE* in semantics regarding widening/narrowing." and continues
    for about 3 or 4 paragraphs. Ed's comment should go in there too.

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

    rejected

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

CCM: Definition of import declaration unclear

  • Key: CORBA26-77
  • Legacy Issue Number: 4577
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    After reading the definition of the import declaration, it is not at
    all clear what its effect is.

    Suppose the "well-known set of IDL specifications" consists of

    module A {
    module B {
    interface C {
    struct S

    {long a;}

    ;
    };
    };
    };

    Now consider the import statement

    import A::B;

    According to the draft, "Names that occur in IDL declarations within
    the importing specification may be resolved to definitions in imported
    scopes." What is a "Name" in this context? Is it an <identifier>, or
    is it a "<scoped_name>"?

    It is unclear whether in this context, the definition

    interface D : C {};

    would be correct or not. The spec may be interpreted that name "C"
    resolves to ::A::B::C, i.e. that the name "C" is appended to the
    imported scopes, forming a fully-scoped name. If that is the intended
    meaning, the text should explain how to deal with conflicts.

    Alternatively, given the text "Imported IDL name scopes exist in the
    same space as names defined in subsequent declarations in the
    importing specification." would suggest that

    interface D : B::C {};

    is well-formed: "B" would be the name of the imported scope, so it
    exists in the same space "D", and can thus be used for qualifications.

    Furthermore, the text could be understand to mean that

    interface D : ::A::B::C {};

    is allowed. The "definition in the imported scope" has the name
    "A::B::C", so this is the name to be used in the importing
    specification.

  • Reported: CORBA 2.5 — Mon, 17 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM: Chapter 66 should be removed

  • Key: CORBA26-70
  • Legacy Issue Number: 4307
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    Looking at ptc/99-10-04, it is not clear to me which parts of this
    document are intended as normative.

    For example, the introduction to chapter 66, "Component Container
    Architecture", states that the presented design "is not the only
    possible design choice." Consequently, it appears that the entire
    chapter 66 is not intended as normative. However, looking at the
    actual text, a reader might be easily confused into taking aspects of
    the design as normative.

    While this text was helpful in the submission to give readers an
    insight how the submitters might design their implementations, it
    should be removed from the specification, to really give implementors
    the freedom of design choice that was apparently intended with the
    submission.

  • Reported: CORBA 2.4.2 — Tue, 15 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

IDL out parameters can't map to EJB?

  • Key: CORBA26-69
  • Legacy Issue Number: 4269
  • Status: closed  
  • Source: Progress Software ( Alan Conway)
  • Summary:

    Section 8.3.1 says "The signatures of the CORBA component operations are mapped to signatures of EJB remote interface methods following the IDL to Java mapping rules."

    As far as I can see, this only works if the IDL signature has no out or inout parameters. The Holder classes for out and inout parameters cannot be used in an EJB interface signature because they need not be Serializable, which breaks the rules for an RMI compliant class. Even if they could the EJB stubs and skeletons would not implement their special return value behavior without modifications to the EJB spec.

    Someone please tell me I've missed something!

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

    see below

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

explicit definition of CCM exceptions mapped from EJB standard exceptions

  • Key: CORBA26-74
  • Legacy Issue Number: 4540
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    The CCM exceptions mapped from EJB standard exceptions need to be defined
    explicitly in OMG IDL. The resolution to issue 3182 introduces new CCM
    standard exceptions Components::CreateFailure, Components::FinderFailure
    and Components::RemoveFailure but it does not define them explicitly.

  • Reported: CORBA 2.4.2 — Wed, 29 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Incorrect syntax in Components::Enumeration

  • Key: CORBA26-73
  • Legacy Issue Number: 4529
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    The use of the state keyword in the Components::Enumeration valuetype,
    introduced by issue 3099 and extended in issue 3418, is not correct
    syntactically. Also, anonymous sequences have been deprecated, so the
    definition of the Components::Enumeration state is incorrect in this sense
    as well.

  • Reported: CORBA 2.4.2 — Fri, 13 Jul 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

minor IDL changes required in CCM API

  • Key: CORBA26-81
  • Legacy Issue Number: 4717
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In order to compile the Components.idl file with a compiler
    compliant with OMG IDL2/IDL3/CIDL/PSDL grammars simultaneously,
    it is required to apply some changes in CCM APIs:

    • In ptc/2001-11-03 draft chapter 61 page 61-225, the following IDL

    valuetype FacetDescription : PortDescription

    { public Object facet; }

    ;

    should be replaced by

    valuetype FacetDescription : PortDescription

    { public Object facet_ref; }

    ;

    because 'facet' is a CIDL keyword.

    • In ptc/99-10-04 chapter 62 page 62-141, the following IDL is defined

    exception Rollback { };
    // ...
    local interface Transaction

    { // ... void commit () raises (Rollback, NoTransaction, HeuristicMixed, HeuristicRollback, Security, SystemError); void rollback () raises (NoTransaction, Security, SystemError); // ... }

    ;

    Here there is a conflit name between the exception Rollback
    and the operation rollback.

    In order to avoid this, the exception Rollback should be renamed
    RollbackError. Then the previous IDL should be replaced by:

    exception RollbackError { };
    // ...
    local interface Transaction

    { // ... void commit () raises (RollbackError, NoTransaction, HeuristicMixed, HeuristicRollback, Security, SystemError); void rollback () raises (NoTransaction, Security, SystemError); // ... }

    ;

    In the commit operation description page 62-142, the Rollback exception
    should be replaced by RollbackError.

    In table 64-7 page 64-197, the Rollback exception of the commit operation
    should be replaced by RollbackError.

    • In ptc/99-10-04 chapter 62 page 62-151, the 1st 'home' parameter
      of the HomeRegistration::register_home and unregister_home operations
      implies a parser error with a CCM IDL compiler as 'home' is a keyword.

    The 'home' parameters should be replaced by 'home_ref'
    Ditto in the following 'register_home' and 'unregister_home'
    operation descriptions.

    • In ptc/99-10-04 chapter 62 page 62-155, the following IDL

    get_oid_from_ref (in Object ref)

    should be replaced by

    get_oid_from_ref (in Object objref)

    because 'ref' is a PSDL keyword.

    In the 'get_oid_from_ref' operation description page 62-156,
    replace 'The ref parameter' by 'The objref parameter'.

    • In ptc/99-10-04 chapter 62 page 62-162, the following IDL

    get_cid_from_ref (in Object ref)

    should be replaced by

    get_cid_from_ref (in Object objref)

    because 'ref' is a PSDL keyword.

    In the 'get_cid_from_ref' operation description page 62-163,
    replace '(ref)' by '(objref)'.

    • In ptc/2001-11-03 draft chapter 69 page 69-551, the following IDL

    void remove_container(in Container ref) raises (RemoveFailure);

    should be read as

    void remove_container(in Container cref) raises (RemoveFailure);

    because 'ref' is a PSDL keyword.

    • In ptc/2001-11-03 draft chapter 69 page 69-553, the following IDL

    void remove_home(in CCMHome ref) raises (RemoveFailure);

    should be read as

    void remove_home(in CCMHome href) raises (RemoveFailure);

    because 'ref' is a PSDL keyword.

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

    Accept the previous required changes.

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

Little problem with introspection API

  • Key: CORBA26-80
  • Legacy Issue Number: 4716
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I wanted to point out that the use of the name "ref" or "Ref" in
    > the introspection API may be a problem because "ref" is a
    > reserved word in PSDL and therefore any PSDL file that
    > includes the CCM IDL file will cause compiler errors (this has
    > happened to me when using the OpenORB PSDL compiler). If at
    > all possible we should change the use of "ref" to "reference"
    > or something else in the final version of the spec.

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

    see below

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

CCM: Meaning of "exposed" scopes unclear.

  • Key: CORBA26-79
  • Legacy Issue Number: 4579
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    ccm/01-08-04 says

    "When a name scope is imported, the names of the enclosing scopes in
    the fully-qualified pathname of the enclosing scope are exposed within
    the context of the importing specification, but their contents are not
    imported. An importing specification may not re-define or re-open a
    name scope which has been exposed (but not imported) by an import
    statement."

    Now consider the following "well-defined set of IDL specs":

    module X {
    module Y {
    module Z{};
    };
    };

    and the following import statement

    import X::Y;

    Now, it appears that this declaration would make it ill-formed to
    specify

    module X{
    interface another_interface{};
    };

    since "X" is an exposed scope. That appears to be inconsistent, since
    clearly, reopening "X" is allowed without the import statement.

  • Reported: CORBA 2.5 — Mon, 17 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM: usage of the MOF profile

  • Key: CORBA26-68
  • Legacy Issue Number: 4214
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    The CCM MOF IR draft (ptc/99-10-05) uses UML to denote the MOF model
    of the IR. Without missing elaboration, it is not possible to mentally
    construct the metamodel. For example, the enumeration, primitive, and
    unchangeable stereotypes don't have a well-defined relationship to MOF
    concepts. It seems that the MOF chapter should use the UML MOF profile
    (ad/01-02-29). In addition, it would be desirable if a normative XML
    document that defines the metamodel (following the MOF DTD) is
    provided.

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

    see below

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

CCM: Isolated scope tokens

  • Key: CORBA26-76
  • Legacy Issue Number: 4576
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    In ccm/01-08-03, section 3.6, there is a sentence

    "In isolation, the scope token represents the scope of the
    specification in which it occurs."

    It is not clear what an "isolated scope token" is, since the scope
    token is allowed only as part of a <scoped_name>, but never appears in
    isolation. The intended meaning of this sentence should be clarified.

  • Reported: CORBA 2.5 — Mon, 17 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Issue for Components: Missing language mapping

  • Key: CORBA26-75
  • Legacy Issue Number: 4574
  • Status: closed  
  • Source: Humboldt-Universitaet ( Harald Boehme)
  • Summary:

    in both documents orbos/99-07-01/6.3 and ptc/99-10-40/615.3 the language
    mapping is noted as open issue.
    Where are the language mappings for components ?

  • Reported: CORBA 2.5 — Mon, 17 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM: import and re-opening of modules

  • Key: CORBA26-78
  • Legacy Issue Number: 4578
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    In ccm/01-08-03, a sentence says "IDL module definitions may re-open
    modules defined in imported name scopes."

    Now, consider the following "well-defined set of IDL definitions":

    module Y{};
    module A{
    module Y{};
    };
    module B{
    module Y{};
    };

    and the import statements

    import A;
    import B;

    Clearly, A::Y and B::Y are "modules defined in imported name
    scopes". Does that mean that specifying

    module Y{
    interface another_interface{};
    };

    is now valid? If so, which namespace is extended?

    It may be that this is meant to be an error (if so, where does it say
    that?). In that case, consider the case that there was only a single
    import:

    import A;

    Then, if this means that A::Y is extended, how could I specify a
    re-opening of ::Y?

    Alternatively, it may be that the authors thought of re-opening Y in
    the form of

    module A::Y{
    interface another_interface{};
    };

    That, of course, is illegal syntax. Yet another interpretation is that
    the draft intended to allow

    module A{
    module Y{
    interface another_interface{};
    };
    };

    However, this appears to be possible even without any import
    statement.

  • Reported: CORBA 2.5 — Mon, 17 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 4577.

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

Extended Interface Repository

  • Key: CORBA26-63
  • Legacy Issue Number: 4116
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    I am somewhat surprised over the ExtendedIR interface in 00-11-01.
    I am very aware of problems with extensibility in the Interface Repo-
    sitory. In the past, a lot of problems have been caused because modi-
    fications like InterfaceDef::is_abstract have been worked in and out.
    We certainly desperately need a backwards-compatible Interface Repo-
    sitory.

    This is unachievable with version pragmas, because then a client's
    is_a inquiries with "old" Repository Ids will fail, and the client
    will refuse to talk any further.

    Backward compatibility is instead achieved by not changing data types
    (such as InterfaceDescription) and by not changing the signature of
    existing attributes and operations.

    Adding new types that are used by new operations on existing interfaces
    does not break compatibility, because the client will simply be unaware
    that there are more operations than it knows of (such as describe_inter-
    face_2_3).

    Whether changing interfaces sensible is debatable, surely it's more
    consistent to use derived interfaces instead – this has the least im-
    pact on compatiblity.

    In that light, I wonder whether the proposal in 00-11-01 gets us any
    further. It adds more fixed interfaces in another module, and this new
    ExtendedIR module is just as static as the old ones have been. If any
    further changes were necessary, backwards-incompatible changes were
    just as necessary.

    The proposal in 00-11-01 also adds a lot of unnecessary verbose baggage
    with its use of "extended" everywhere, and its usage of multiple inheri-
    tance from the original interfaces is confusing.

    Yet there is one item from 00-11-01 that I like much better than the
    proposal in 99-10-03, and that is the usage of AbstractInterfaceDef and
    LocalInterfaceDef. I think that's the way to go.

    Therefore, I tend to vote against issue 3233 and its proposed resolution
    in 00-11-01.

    Rather, I propose to go back to the original version instead, and

    • to add AbstractInterfaceDef, LocalInterfaceDef and the related
      container operations
    • to add an AttributeWithExceptionsDef and InterfaceDef::create_
      attribute_with_exceptions and ValueDef::* operations.

    Whether the Interface Repository should be moved to a different module
    should be a separate discussion. I support the idea, but I don't think
    that the implementation should be forced to offer access to the IFR
    using both the CORBA:: and IR:: modules.
    Note that vendors could still offer the old interfaces in their imple-
    mentation.

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

    see below

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

Problems with the Components Notification Event Interface

  • Key: CORBA26-62
  • Legacy Issue Number: 4081
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    The CCM standard indicates that all CCM Event functions will delegate to
    the container. Chapter 7 of the CCM Volume 1 further dictates the
    interface the container will provide to the component, called
    Components::Notification::Event, referred to as the "Event Interface"
    hereafter. This interface contains many problems and does not address
    all the required functionality. The problems are listed below:<p>

    • The create_channel() method returns an EventConsumerBase for the
      publisher to use to publish events to the channel. It is not possible
      for the Event Interface to construct a concrete EventConsumerBase,
      specifically the interface defined as
      <publishing_component>EventConsumers::
      <event_type>Consumer (per section 5.6.6 and 5.6.7 giving the
      publisher and emitter IDL expansion). The Event::obtain_channel()
      method has the same problem
    • The subscribe() method implies that the container supplying events
      will hold the supplier proxy that will be used to send events to the
      subscriber’s EventConsumerBase. This is an inefficient model. Also,
      this model is in direct conflict with the listen() method, which
      supports a more efficient model (see next bullet).
    • The standard does not provide any documentation on when a consumer
      would call the listen() method. The standard also does not provide a
      means for the consumer’s component to realise the "csmr_name", the
      name used to find the ConsumerAdmin from the Naming Service [see
      possibly related issue #3940]. Nor does the standard indicate when
      the ConsumerAdmin would have ever been added to the Naming Service.
      It might be possible that this would work for emitters, but it does
      not work for publishers (the standard dictates that a consumer cannot
      distinguish between being connected to an emitter or a publisher).
      This method does imply that the consuming component will have a proxy
      local to its container, separate from the publishing component’s
      container (contradictory to the subscribe() method, see previous
      bullet).
    • The push() method does not provide a means to indicate which channel
      the event should be pushed to see possibly related issue #3928.<p>

    The Event Interface is a local interface ­ that is, the client will
    never see this interface, and so it is possible to hide the use of this
    interface inside the generated code and thus replace the interface.
    Internally we have added a PortManager interface to be used in place of
    the Event Interface. This interface provides better management of the
    Event Channels and it also manages receptacle connections. Two
    interfaces will derive from the PortManager, a TransientPortManager and
    a PersistentPortManager. These two derived interfaces will permit
    connections between components to be managed as defined by the type of
    the container. Where meaningful, this permits the port connections to be
    made persistent as part of the overall state so that connections
    (specifically, notification channels) can be more reliably and robustly
    managed. The CCM2Context::get_event() operation is replaced by
    get_port_manager()

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 3937. rejected

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

Component home interface inheritance

  • Key: CORBA26-61
  • Legacy Issue Number: 4080
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    The definition of homes does not permit interface inheritance. It
    appears this is an oversight as the omission seems unreasonable and
    counter-intuitive, especially since homes must follow a parallel
    derivation hierarchy with their component types. I have found cases in
    which a home would expose the same interface as its component in which
    the home subsequently delegates to a specific component instance (even a
    persistent instance) however selected. (The component instance may or
    may not be hidden from the client.) Interfaces are a perfect mechanism
    whereby the operational signatures could be standardized, thus
    eliminating potential errors caused by changing one but not the other.
    This could be accomplished using a supports clause in the inheritance
    specification similar to that of valuetypes.

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Components, Facets, and Object References Unclear

  • Key: CORBA26-56
  • Legacy Issue Number: 4073
  • Status: closed  
  • Source: Anonymous
  • Summary:

    See the CORBA Components specification, orbos/99-07-01, chapters 5, 6,
    7, and 9. The semantics, life cycle, and mechanisms behind components,
    facets, "regular" objects, and their related object references is weakly
    specified. In particular, it is not clear how a component interacts
    with a container to generate an object reference to a facet, especially
    a facet in a secondary segment. The description of component
    identifiers indicates that the component object id, the facet number,
    and the segment number are used to generate the facet's object reference
    (or perhaps only the ObjectId), but the sequence of operations is not
    given. It appears that not all the necessary methods have been formally
    specified, nor are the code generation examples adequate for this
    siutation.

    Consider the following IDL:

    interface A {};
    component C

    { provides A a_facet; A get_another_A(); }

    ;

    What is the life-cycle of the A object returned as the provided facet?
    Is it limited to the life-cycle of the component? Is the member
    operation returning an object of the same type as a provided facet
    permitted? Should this return the same object as the facet? If not, is
    the life-cycle of this extra object limited to the life-cycle of the
    component? Should such objects be considered facets, even if not
    explicitly declared such (which, please note, provides the equivalent of
    the deprecated "provides multiple" capability)? What information needs
    to be encoded in its object reference, especially for component
    dependency? How will the context for this be established, and are any
    additional interfaces or operations required to accomplish this?

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

    rejected

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

New component issue: connection failure recovery

  • Key: CORBA26-55
  • Legacy Issue Number: 4025
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The CCM does not describe the behavior of the system in case of various fault situations. In particular, this issue only concerns itself with the recovery mechanisms of event subscriptions or facet receptacles that were automatically established through an assembly. While it is outside the scope of the CCM to describe general fault behavior, it is felt that recovery mechanisms (or their absence) should be explicitly identified for connections automatically built between ports. Otherwise, why go to the trouble of building them, since error detection and recovery wrappers would be needed around any use of them?

    The following scenario highlights the various situations. It assumes that the components are deployed in separate processes on different platforms so that one of the two components remains operational despite failure or inaccessibility of the other. The scenario primarily deals with the recovery of an interface provided by Component X and used by Component Y. Appropriate questions related to event channels are also given where applicable. Event channels are themselves more difficult because the notification services adds yet another object to the set that may fail during the scenario.

    Scenario: Component X declares that it provides an interface A. Likewise, Component Y declares that it uses interface A. (Or, X emits or publishes event A to which Y subscribes.) Instances of the components are combined through an assembly. Now, the assembly description indicates that a connection is to be built between X and Y. That is, the descriptor defines connections in which a connection element defines the association. Said element’s providesport acquires X’s facet A and assigns that through the usesport to Y’s interface receptacle. (For events, read these as emitsport or publishesport and subscribesport.)

    The following questions arise:

    When does the connection take place, during assembly construction or on reference to the port’s receptacle inside Y? That is, is this immediate or lazy initialization? When are event channels created or attached? Can the producer delay creation or attachment until a push() operation? Can the consumer accomplish the creation? Can an m:n emitter to consumer notification matrix be built? (The specification is unclear on this.)
    What happens if the interface reference to A cannot be acquired because (1) X has failed or is inaccessible, (2) X fails during the get operation, or (3) X returns a nil reference?
    What happens during run-time when Y invokes an operation on A and:
    The application server process containing X has terminated (COMM_FAILURE returned)?
    Derived valuetype arguments cannot be marshalled (MARSHALL/BAD_PARAM returned)?
    The underlying object supporting A in X has been deleted (INV_OBJREF returned)?
    An unexpected application error occurs (UNKNOWN returned)?
    With respect to error detection and recovery:
    How does one indicate the set of objects that can detect the error? Possible objects are Y, Y’s home, Y’s container, X’s container, X’s home, the assembly, an independent third party.
    How does one indicate the set of objects that can recover the error?
    How does one indicate whether the error should be detected?
    How does one indicate whether recovery should be attempted?
    How does one indicate the recovery strategy, especially if there are several objects that can recover the error?
    If the strategy has multiple fallback conditions, should this logic be placed into a single object or should it be given as a precedence-ordered list?
    Where should this information be specified: IDL, CIDL, or XML?
    What are the implications when the components have different type and container semantics?
    Let component X be transient and component Y be an entity. If component X fails, can a new X be safely created for its corresponding Y?
    Assume a new X was created and the old X still exists but became inaccessible. Can the old X be detected and one of the X’s be deleted [dismissed] after the old X is again accessible?
    Assume a request to X completes successfully in X but fails during the reply to Y. Can the operation be retried or the previous results retransmitted, either on the old X after recovery or on a new X?
    In these questions, what happens if X is an entity and Y is transient?
    In these questions, what happens if Y aborts rather than X?

    Ideally, it would be nice if either the IDL extensions or the CIDL constructions permitted specification of an error recovery wrapper around access to a receptacle (or event channel). This could actually work as a general mechanism for any component and not just components grouped in an assembly. The wrapper would be a specialized object implemented specifically in the context of the component or assembly that provided the desired error detection and recovery behavior. It would be a proxy similar to a stub: it would have the same interface as the target object to which it delegates. Errors would be caught (as described) and recovered automatically, if possible. This includes the initial reference to an object, which would now be built or acquired dynamically at run-time rather than semi-statically at assembly instantiation. Multiple inheritance, in languages that support it, would be very useful in standardizing proxy behavior. The component DTD could be used to specify desirable run-time operation and associated characteristics.

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

    rejected

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

Components FTF: TypeCodeFactory

  • Key: CORBA26-65
  • Legacy Issue Number: 4140
  • Status: closed  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    The third part of the adopted CCM submission (orbos/99-07-03)
    moves all the create_..._tc operations from the ORB interface
    to a new PIDL interface, CORBA::TypeCodeFactory.

    This change breaks source-compatibility: source code that creates
    typecodes with a pre-CORBA 3.0 ORB will need to be updated to use
    a CORBA 3.0 ORB with such a TypeCodeFactory interface.

    And there is no clear benefit from this update:

    • ORB is still PIDL – it even creates an additional PIDL
      interface.
    • type code kinds are not more extensible (TCKind is still an
      enum)

    I suggest to undo this update, i.e. keep the create_..._tc
    operations on the CORBA::ORB interface.

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

    see below

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

ComponentIR Interface fixes

  • Key: CORBA26-64
  • Legacy Issue Number: 4136
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    While reviewing the ComponentIR interfaces in 00-11-01, I have found
    some problems with it. (These are unrelated to the current discussion
    about the Interface Repository itself.)

    Many interfaces inherit Contained::describe(), which is supposed to
    return information about the element. In the basic IFR, this data is
    designed to contain all possible information about that type. This
    is very convenient, since then a map mapping RepositoryIds to
    Contained::Description contains all of the IFR's information.

    By referring to InterfaceDefs rather than RepositoryIds, the client
    will need to store that association elsewhere, or repeatedly invoke
    the Interface Repository.

    Suggested resolution:

    • In ProvidesDescription, replace
      InterfaceDef interface_type
      with
      RepositoryId interface_type
    • Ditto for UsesDescription
    • In EventDescription, replace
      ValueDef event
      with
      RepositoryId event
    • In ComponentDescription, replace
      ProvidesDefSeq provides_interfaces
      UsesDefSeq uses_interfaces
      EmitsDefSeq emits_events
      PublishesDefSeq publishes_events
      ConsumesDefSeq consumes_events
      with
      ProvidesDescriptionSeq provides_interfaces
      UsesDescriptionSeq uses_interfaces
      EmitsDescriptionSeq emits_events
      PublishesDescriptionSeq publishes_events
      ConsumesDescriptionSeq consumes_events
    • In PrimaryKeyDescription, replace
      ValueDef primary_key
      with
      RepositoryId primary_key
    • In HomeDescription, replace
      PrimaryKeyDef primary_key_def
      FactoryDefSeq factories
      FinderDefSeq finders
      with
      PrimaryKeyDescription primary_key
      OpDescriptionSeq factories
      OpDescriptionSeq finders

    Next, all parts of the "basic" Interface Repository are mutable, but
    most attributes of the Components interfaces are declared as readonly.
    I propose to remove the readonly modifier from

    • ProvidesDef::interface_type
    • UsesDef::interface_type
    • UsesDef::is_multiple
    • EventDef::event
    • ComponentDef::supported_interfaces
    • ComponentDef::base_component
    • ComponentDef::provides_interfaces
    • ComponentDef::uses_interfaces
    • ComponentDef::emits_events
    • ComponentDef::publishes_events
    • ComponentDef::consumes_events
    • PrimaryKeyDef::primary_key
    • HomeDef::base_home
    • HomeDef::managed_component
    • HomeDef::primary_key
    • HomeDef::factories
    • HomeDef::finders

    Last but not least, there seems to be some confusion about Primary Keys.
    When a Home is created with Repository::create_home, a ValueDef should
    be passed, while the terminology seems to dictate a PrimaryKeyDef instead.
    You can get a PrimaryKeyDef using HomeDef::create_primary_key, but that
    would be a chicken-egg scenario.

    Proposed resolution:

    • Change the ValueDef in Repository::create_home to PrimaryKeyDef
    • Move the create_primary_key() operation from HomeDef to Repository
  • Reported: CORBA 2.4.1 — Fri, 5 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Component assemblies do not follow composition pattern

  • Key: CORBA26-58
  • Legacy Issue Number: 4077
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    I have noticed that assemblies do not follow the composition pattern.
    Thus, assemblies cannot themselves be used as building blocks for other
    assemblies. I think part of this comes from the fact that installation
    and management of assemblies is mostly "magic" done behind the scenes by
    various installation and support utilities. In order to "reuse" an
    existing assembly, one must copy an existing assembly definition (I
    guess constructed completely by hand) to a new definition, which must
    then be tailored to incorporate the new strategy and pieces. This seems
    counter-intuitive, besides being manually intensive, for if an assembly
    does useful work, why would I want to expose its internal details just
    to take advantage of that usefulness? As pointed out by Mr. Dubois in
    issue 3939, because all of that "magic" is not specified by various
    formal interfaces, it is highly likely approaching certainty that
    assemblies will only work for the particular vendor on which they were
    built. Since I believe the intention was to promote interoperability in
    general and as much code automation as possible for components in
    particular, it would seem that we want to restrict the "magic" by taking
    the formalisms behind assemblies to another level.<p>

    I suggest that, just as a <i>composition</i> exists to tie a component,
    its home, and various configuration properties together, we can create
    for the CIDL grammar productions for an <i>assembly</i> to tie multiple
    compositions together. Subsequently, an assembly could be treated as a
    composition, to be used by other assemblies, only exposing selected
    facets or events from its constituent entities. I think there are a
    number of advantages to this approach: (1) It solves certain semantic
    ambiguities with assemblies, for instance whether facets, receptacles,
    and events are private or public to the assembly. (2) The assembly
    implementation, its XML, and its relation to its constituents and home,
    can be generated automatically from the CIDL description [we have been
    working on this extensively]. Our approach is to use an assembly
    exactly like a composition, as the realization of a component and home
    definition. Our research efforts imply that all of the assembly
    component and home code can be automatically generated - no user
    tailoring will be needed. (3) Because the assembly now acts as a
    component (composition), it can be reused by other assemblies without
    knowledge of its internal structure. (4) Activation of an assembly
    appears the same as for any other component; it merely requires formal
    specification of previously undefined interfaces to accomplish it, thus
    promoting portability and interoperability. (5) The assembly
    "deployment magic" becomes exposed through the interfaces above, thus
    removing several of the deployment tools and servers/services identified
    in the specification. The only real drawbacks I see are the complexity of the assembly
    productions (we can really get out of control with this) and that
    assemblies now have an actual code base rather than being "magical
    creatures" managed by the deployment tools. I guess these are both
    two-edged swords. There might be a run-time footprint change for all of
    these extra interfaces, but those had to be lying around in other places
    anyway.

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

Inter-component type semantics unclear

  • Key: CORBA26-57
  • Legacy Issue Number: 4075
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    The semantics of components of a particular type (session, entity)
    residing in a compatible container type that access components of a
    different type residing in a corresponding but different compatible
    container type are unclear. Are there any expected or preferred
    combinations? Are any disallowed or discouraged? See, for example, the
    discussion under issue 4025 on automated recovery. In his replies, Mr.
    Dubois seems to assume that entity components create transient (service
    or session) components but not the reverse. In the telecommunications
    domain, however, a session object may share access to an entity, and
    then create additional entities based on external events, even though
    the session itself is not persistent. Could someone please articulate
    the possibilities and their utility (or lack thereof)?

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

    rejected

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

Typo in assembly element paragraph heading

  • Key: CORBA26-54
  • Legacy Issue Number: 4024
  • Status: closed  
  • Source: Anonymous
  • Summary:

    See the CORBA Components Model specification, orbos/99-07-01, paragraph
    10.6.2.52, page 10-365. See also the DTD appendices document, orbos/99-08-05.

    The title of this paragraph heading is incorrect. The element is "usesport",
    not "usingcomponent". It has occasionally been hard to find the description
    because of this textual error.

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

    see below

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

grammar rule for home_executor_body contradicts description

  • Key: CORBA26-53
  • Legacy Issue Number: 4011
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In ptc/99-10-04 on page 15 the grammar rule of home_executor_body in chapter
    60.7 "Home Executor Definition" contains bars implying alternatives. These
    bars have to be removed to match the subsequent description.

  • Reported: CORBA 2.4 — Wed, 1 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

No Access to event filter form component

  • Key: CORBA26-52
  • Legacy Issue Number: 3998
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    As the CCM spec is not giving any mean (or very little) to fill in the
    filterable body part, no services are provided for a component to set its
    event filters when sending or receiving events.

    This seems to be a very usefull service to me for application such as:

    • limiting the number of events emitted by a component based on a config
      parameter (like messages with priority > config value can go out, other are
      discarded. when the config value change at runtime the filter could also
      change.
    • filtering events received from a notification channel.

    I agree that these 2 function could be achieve by user code in the component
    but it means that unecessary events are passed between components and the
    netwok load and CPU load is higher than necessary.

    I guess the point I am trying to make is that using the notification service
    without using filters and/or filterable body doesn't seem to make a lot of
    sense.

    What is the intend of the sepc on this issue?

  • Reported: CORBA 2.4 — Wed, 25 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 3938. rejected

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

Component home polymorphism

  • Key: CORBA26-60
  • Legacy Issue Number: 4079
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    See the CORBA Component Specification, orbos/99-07-01, and Persistent
    State Service issue #4074. Is there any reason why homes cannot support
    (manage) multiple component types? This seems like a perfect case for
    polymorphism; the only time you really need a new home type is when you
    change the behavior or have some other incompatibility. Is it possible
    to do instances of homes, one per component type (perhaps instances of
    components acting as managers for other components)? I simply do not
    understand why these are one-to-one with parallel but distinct
    derivations. I realize the requirements were to maximize code
    generation, but I don't see that this is a conflict.

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

Component assembly templates

  • Key: CORBA26-59
  • Legacy Issue Number: 4078
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    In a complex distributed environment, the implementation of highly
    available and highly reliable services requires redundant placement of
    software components in all their manifestations. Assemblies provide a
    nice, convenient way of specifying the deployment and activation of
    components and the connections that relate them for a particular
    purpose. Now, for various reasons and Fault Tolerant CORBA
    notwithstanding, in corporate reality this sequence and specification
    will occur in multiple places in basically identical fashion. About the
    only thing that changes are the host names and their network addresses;
    everything else from the hardware configuration to the size of the disk
    drives and file systems is (and inherently must be) exactly the same
    among all deployments. This, for example, is one technique to support
    geographic site failover.

    My question is, has anyone thought of a two or more stage XML process,
    one in which the package or assembly composition and deployment XML is
    specified as a template or configurable, parameterized entity, and
    another where the parameters have been substituted for "finalization"?
    This can occur at two distinct points in the life-cycle: one set of
    substitutions occurring when an artifact is deployed (installed?) on the
    various computer systems involved, and another when the home [and
    possibly individual instances] of the artifacts are activated
    (instantiated?) to run on those computer systems. My work in the
    telecom and defense industries has show that deployment of anything is
    rarely a singleton event; there are always redundancies, replications,
    and backups to take into account. Templates seem to provide a nice
    solution to all of the manual editing required.

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

CCM : Session2Context naming

  • Key: CORBA26-67
  • Legacy Issue Number: 4204
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Is there any reason to name the context interface for extended session
    components as Session2Context in module Components::Extended? Why not simply
    SessionContext like in the Basic module?

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

    see below

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

CCM : Session2Context and Servants

  • Key: CORBA26-66
  • Legacy Issue Number: 4203
  • Status: closed  
  • Source: Anonymous
  • Summary:

    How to activate servants by only using the Session2Context interface from
    the Extended module? It only offers operations to create references like
    create_ref() and create_ref_from_id() similar to those from the POA but no
    means to activate servants are available in the whole container API!

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

    see below

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

No user access to filterable body in CCM spec.

  • Key: CORBA26-51
  • Legacy Issue Number: 3997
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    The CCM spec seems to have make the choice to prevent the component
    implementor to fill in the filterable body part of a structured event sent
    to the a notification channel.

    What are the reasons of this choice?

    2 remarks:

    • The filtrable body part of a structured event seems to be the most usefull
      part of the event. Not using it (or leaving it to the container to fill in
      from obscure sources) doesn't seem to make a lot of sense.
    • Other standard bodies (like T1M1.5) are using the filterable body part of
      the event and are making the remainder of the boby (where the EventBase
      derived value type should be put) optional and unnecessary.

    Any comment/explanation of the choice is welcome.

  • Reported: CORBA 2.4 — Wed, 25 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 3938. rejected

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

IDL question concerning CCM

  • Key: CORBA26-50
  • Legacy Issue Number: 3996
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I have the following question (problem). The Corba Component Model Spec
    (volume 1) defines the following :
    module CORBA_3 {
    module Components {
    interface Events

    { ... }

    ;
    ...
    module Events

    { ... }

    ;
    };
    };

    So the word 'Events' is used for defining an interface and a module!! Is
    this correct IDL, because ther JavaORB idl-compiler nor the ORBACUS
    idl-compiler is able to compile such idl.

  • Reported: CORBA 2.4 — Sat, 21 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM Events issue

  • Key: CORBA26-49
  • Legacy Issue Number: 3993
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I was researching the CCM Event Corba 3 to Corba 2.3 mappings in
    chapter 5 of Volume I, and found that the resulting interfaces did not
    permit a consumer to subscribe to a publisher because the interface
    type returned by the get_consumer_<name>() does not match the
    subscribe_<name)() parameter. I am not sure if I made a mistake when
    mapping the 3.0 to 2.3 idl or if it is a problem in the standard. I
    also provide an alternative that might work, though I'm sure it will
    need some work.

  • Reported: CORBA 2.4 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    Resolved by reference/clarification to 3746

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

typo in connections element definition

  • Key: CORBA26-48
  • Legacy Issue Number: 3987
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    in 99-08-05 the componentassembly DTD has a typo in the "connections"
    element definition. "connecthome" should be spelled "connecthomes"

    <!ELEMENT connections
    ( connectinterface

    connectevent
    connecthomes
    extension
    )* >
  • Reported: CORBA 2.4 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Deployment Object Life Cycles

  • Key: CORBA26-45
  • Legacy Issue Number: 3982
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The description of the life cycle and system dynamics of the various
    objects that contribute to component deployment and execution is
    incomplete. From an implementation perspective, there are many run-time
    objects involved that contribute to, or are required for, the overall
    operation of a component. But the CCM does not adequately show the
    interrelationships among such objects. Even the most rudimentary
    implementation depends on the assumptions hidden behind these
    interrelationships.

    The following questions need to be addressed in order to build a
    portable implementation:

    1. Deployment support services:

    • What is the life cycle of the support services needed to create an
      Assembly object?
    • Do these already need to be executing in, known to, or exposed by one
      or more servers?
    • How are these services contacted in a dynamic environment?
    • Is this structure equivalent to the TINA DPE concepts?
    • What is the life cycle of the Assembly object itself?
    • When and how is an Assembly object deleted?

    2. Application servers, containers, homes, components:

    • What is the exact life cycle of these various objects?
    • The specification identifies how component instances are created. How
      are they deleted?
    • When and how is a home removed from a container?
    • When and how is a container removed from an application server?
    • When and how is an application server terminated?

    3. Related or referenced objects:

    • What is the life cycle of event channels?
    • Does the life cycle of objects vary if they are "private" to an
      assembly?
    • When and how are event subscriptions released from their publisher or
      emitter?
    • When and how are objects "registered" with the naming service or
      trader unregistered?

    A full and representative life cycle description of the run-time objects
    denoted above is necessary to understand the dynamic system model and
    its inherent limitations. This will be critical for systems that must
    exhibit very high reliability and availability. There appear to be many
    assumptions, particularly with respect to the deployment tools, that
    affect recovery operations from fault conditions. These must all be made
    explicit. Thus, the CCM description should include a comprehensive state
    transition model. This may be documented as cooperating or nested state
    machines for the various pieces.

  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Services available for a basic container

  • Key: CORBA26-44
  • Legacy Issue Number: 3977
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The CCM describes the services available for a basic container as being
    one of two sets: security, transactions, and naming or security,
    transactions, and persistence. Could someone please describe the exact
    services available to basic containers and the particular semantics for
    each? Are these differences related to one set for the component home
    and the second set for the instance?

  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

push() versus push_event()

  • Key: CORBA26-43
  • Legacy Issue Number: 3955
  • Status: closed  
  • Source: Anonymous
  • Summary:

    See the CORBA Components Model specification, orbos/99-07-01, section
    5.6, pages 5-84 through 5-89, approximately.
    Could someone clarify the push() and push_event() operations, their
    purposes, and their interaction, if any. There is no description
    whatsoever of the relationship between the push() and push_event()
    operations, even though push_event() is declared in the
    inherited Components::EventConsumerBase. The producing component
    invokes its push() operation, which then performs any peculiar
    formatting to the event before transmission to the underlying channel
    through its container. It is unclear when, if ever, the push_event()
    operation will be invoked. A text search of the document reveals the
    operation appears only in the interface definition and its immediate
    descriptive paragraphs.

    Would a better model be to use push_event() as the interface to and from
    the container? (Perhaps this should be independent operations,
    produce_event() and consume_event()?) On the producer side, let push()
    perform any component specific formatting of the event before passing
    the [now modified] event on to push_event(). This latter interacts with
    the container to send the event to the event channel, as
    described. (Most push() implementations will do nothing to the event.
    This could be provided as a default generated implementation.) On the
    consumer side, push_event() will be invoked by the container as part of
    event delivery. The push_event() operation performs type checks, as
    described, before it invokes the consumer agent’s push() operation. This
    process correctly handles the semantics and permits suitable places to
    intercept or override event processing.

  • Reported: CORBA 2.4 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

An assembly is always mono-vendor ???

  • Key: CORBA26-41
  • Legacy Issue Number: 3939
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    Because the interfaces between the Assembly and the
    container/componentServer/servantActivator is not defined, these ones have
    to be vendor specific.

    Because the ExecutorSegmentBase and the HomeExecutorBase are not specified a
    component is always container specific.

    As a result an assembly provided by one vendor can only speak to
    container/componentServer/servantActivator provided by the same vendor and
    the container can only run (even in Java???) components that have
    specifically ported to it.

    The conclusion is that it is not possble to build an asembly that combine
    components build on different CCM platform. All of the component have to be
    ported to a single CCM platform.

    Is it what is intended?

  • Reported: CORBA 2.4 — Thu, 5 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Intent of Components::Events::(un)subscribe to bypass the notif. service ?

  • Key: CORBA26-40
  • Legacy Issue Number: 3938
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    a component wants to publish an event. So, it calls
    Components::Notification::Event::create_channel(). The container contact the
    (remote) Notification service, create a dedicated channel, connect to it and
    return an EventConsumerBase to be used by the component to push any event to
    the channel. Each time the push() method is called on the EventConsumerBase
    it will create a structured_event and push it to the notification channel.

    Now, another component (in another container/memory space/system) wants to
    receive these events. So it calls Components::Event::subscribe() on the
    first component passing a reference to an EventConsumerBase. The component
    internally calls Components::Notification::Event::subscribe() passing the
    remote EventConsumerBase reference. So now the container has to create a
    (local) strutured_push_consumer and connect it to the channel it has
    created. By doing this any event that it send to the channel will be bounced
    back to it so that it can then push them to the (remote) EventConsumerBase
    that have subscribed to the publish port.

    This scenario doesn't seem right to me because the notification service is
    then useless as all events are bounced back to the publisher. The container
    could just call the push() method on each registered EventConsumerBase.

    What seems to be really needed is a way to pass the reference to the
    NotificationAdmin back to the second component so that the second component
    can then subscribe through its own container to the Notification channel.

    Another possiblity would be that the subscribe call accept a (remote)
    strutured_push_consumer as parameter instead of the EventConsumerBase.

    The last solution is that the publisher port is not designed to work with
    the notification service but on its own.

    I am certaimly missing something!!!!!

    Could you explain how it is supposed to work?

  • Reported: CORBA 2.4 — Thu, 5 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected, see above

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

Channel Setup for Emits ports.

  • Key: CORBA26-39
  • Legacy Issue Number: 3937
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    I found 2 (possibly) contradictory statement in 99-10-04 for "emits" ports.

    1) in 62.4.1.2 The Event Interface

    EventConsumerBase obtain_channel (in string supp_name, in EventHeader hdr)
    raises (InvalidName);

    The obtain_channel operation is used by the component to obtain an
    EventConsumerBase which it can use to push events. This operation
    corresponds to an emits declaration in component IDL. The supp_name string
    identifies an Interoperable Naming Service (INS) name which is used to
    identify the SupplierAdmin to be used by CORBA notification. The name is
    associated with the SupplierAdmin thorough container specific configuration
    data. The obtain_channel operation may optionally specify the EventHeader
    required by CORBA notification which will be used for all events pushed to
    this channel. If hdr is present, it is prefixed to all events pushed to this
    channel. If not, it is defaulted as described in Section 66.4, "Event
    Management Integration," on page 66-252. If the supp_name is not recognized,
    the InvalidName exception shall be raised.

    2) in 66.4.2 Transmitting an event

    . channel lookup - for emitted events, this is the channel configured for
    general use at container start-up, for published events, this is the channel
    established by the container for the purpose of pushing this event type.

    Section 62.4.1.2 seems to imply that there can be a different event channels
    for each emit port while 66.4.2 seems to imply that there is only one event
    channel shared by all emits ports.

    What means "general use"?

    What is the truth/intent?.

    Could you make things clear?

    I certainly preffer 1)

  • Reported: CORBA 2.4 — Thu, 5 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

exception raised by Components::Events::subscribe()

  • Key: CORBA26-38
  • Legacy Issue Number: 3930
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    The exception raised by Components::Events::subscribe() doesn't include the
    Components::ExceededConnectionLimit exception raised by the
    subscribe_source_name() 2.3 equivalent interface.

    It should be added.

  • Reported: CORBA 2.4 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

ExecutablePlacement definition

  • Key: CORBA26-37
  • Legacy Issue Number: 3929
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    In the componentAssembly DTD the executablePlacement is defined as follow:

    <!ELEMENT executableplacement
    ( usagename?
    , componentfileref
    , componentimplref
    , invocation?
    , destination?
    , extension*
    )>
    <!ATTLIST executableplacement
    id ID #REQUIRED
    cardinality CDATA "1" >

    It seems to me that the DTD should not enforce the componentimplref as this
    might depend on the deployment And there is no reason the assembler should
    know where the executable is going to be deployed. For example the
    componentimplref should be different between a Solaris, a Linux or an NT
    placement.

    Therefore I would propose to make componentimplref optional (as it is in
    homePlacement) and change the executablePlacement definition to:

    <!ELEMENT executableplacement
    ( usagename?
    , componentfileref
    , componentimplref?
    , invocation?
    , destination?
    , extension*
    )>
    <!ATTLIST executableplacement
    id ID #REQUIRED
    cardinality CDATA "1" >

  • Reported: CORBA 2.4 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Local push() operation.

  • Key: CORBA26-36
  • Legacy Issue Number: 3928
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    When the component implementor wants to emits an event it has to use the
    push() operation from the local Event interface.

    It is not clear how the container will manage to discriminate the event and
    select the channel this event need to be send to.

    Nothing prevent a component to define several publisher and several emitters
    and nothing force the events to be of different types on all of these
    channels.

    So either the spec is not clear enough on this process or the local push
    method is missing some a parameter (like the emitter/publisher port name) to
    help the container do his job.

  • Reported: CORBA 2.4 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

repository element needed by softpkg DTD

  • Key: CORBA26-47
  • Legacy Issue Number: 3986
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    in 99-08-05 the softpkg DTD is missing the "repository" element
    specification. It could be copied from corbacomponent DTD.

    <!ELEMENT repository
    ( ins

    objref
    link
    ) >
    <!ATTLIST repository
    type CDATA #IMPLIED >
  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

description element need to be added to corbacomponent.dtd

  • Key: CORBA26-46
  • Legacy Issue Number: 3985
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    in 99-08-05, the corbacomponent DTD is missing the "description" element
    specification. It should be the same as the other DTDs and can be copied
    from them

    <!ELEMENT description ( #PCDATA ) >

  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

equivalent interfaces issue

  • Key: CORBA26-42
  • Legacy Issue Number: 3954
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The equivalent interfaces as described within the document result in type mismatches when code is built to implement the functions generated from the CIDL component specification. That is, you cannot assign a consumer to a subscriber because the interfaces are parallel derivations and not an inheritance compatible derivations. The code prototypes must be changed to overcome this problem. We have tried three different approaches, but the one that seems to work best has the most impact to the IDL revisions.

  • Reported: CORBA 2.4 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    Resolved by reference/clarification to 3746/ duplicate

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

operation get_implementation() referenced but not declared

  • Key: CORBA26-32
  • Legacy Issue Number: 3785
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In chapter 69.9.1.2 Deployment Scenario on page 329 of ptc/99-10-04.pdf the
    operation get_implementation() is refered as if it belongs to the
    ComponentInstallation interface (called only "Installation"), but the
    specification of that interface lacks it.

  • Reported: CPP 1.1 — Thu, 17 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    Duplicate, close

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

Pbl: Improper mapping rule from IDL3 to IDL2 when dealing with events.

  • Key: CORBA26-31
  • Legacy Issue Number: 3746
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    Dealing with the following IDL3 definition, a problem arises when
    generating the IDL2 definitions (complete IDL2 mapping is enclosed at
    the end of this mail).

    module example {
    valuetype AnEvent : Components::EventBase

    { public string value; }

    ;

    component Producer

    { publishes AnEvent output; }

    ;

    component Consumer

    { consumes AnEvent input; }

    ;
    };

    According to the chapter 5 of the CCM specification, the publishes
    definition of the Producer component is mapped to the following
    definition (excerpt).

    interface Producer : Components::CCMObject

    { Components::Cookie subscribe_output(in ::example::ProducerEventConsumers::AnEventConsumer consumer) raises (Components::ExceededConnectionLimit); }

    ;

    In the mean time, the consumes definition of the Consumer component is
    mapped to the following definition.

    interface Consumer : Components::CCMObject {

    ::example::ConsumerEventConsumers::AnEventConsumer
    get_consumer_input();

    };

    We can see that two versions of the "AnEventConsumer" interface have
    been defined in two distincts modules. Thus the following Java
    lines are not correct:

    example.Producer p = ...;
    example.Consumer c = ...;

    p.subscribe_output(c.get_consumer_input());

    The Java compiler will refuse to compile the last one, producing an
    error like "BadTypeCoerce". However, in the IDL3 definitions, both
    components have been defined in order to be used together. (sic!)

    Thus, we think that the mapping for a Consumer should not be based on
    the component definitions, but on the event definition itself. It
    would then avoid multiple (incompatible) definitions of the consumers.
    This mapping could be defined in two distinct ways.

  • Reported: CPP 1.1 — Tue, 18 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Issue on Assemblies and descriptors

  • Key: CORBA26-30
  • Legacy Issue Number: 3726
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    Looking a the <Assembly> interface, a question arises. When providing
    the assembly descriptor location, a logic description of the
    application to deploy is provided. But, how are set the pysical hosts
    to be used for the deployemnt of the logic configuration? No hooks is
    provided to the deployment tool (as there are no interfaces for the
    tool) in order to provide these information, and no operation is
    available on the assembly interface to do so. Is there an extension of
    the <Assembly> interface in order to contain this information?
    Otherwise, how could the application be deployed?

    Thinking about what should be provided, it is necessary to assign a
    logical name contained in the assembly descriptor to a physical host
    name. Maybe an extension to the assembly descriptor filled at
    deployment time is the solution? The second possible choice crossing
    my mind is an IDL structure (in fact sequence of structure) that could
    be provided to the assembly object.

  • Reported: CPP 1.1 — Mon, 26 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

What about valuetype factories?

  • Key: CORBA26-33
  • Legacy Issue Number: 3786
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    What about <i>valuetype factories</i>?

    <p>In the context of a component dealing with events, the aspect of
    <i>valuetype</i> factories has not been really mentionned in the spec,
    especially in the deploiement process.
    If I am right, dealing with <i>valuetypes</i> in a program means to
    instantiate and to register a factory for this <i>valuetype</i> to the
    ORB. In the context of the CCM, a component and its home is installed
    into a generic container which may not know the <i>valuetype</i>.
    Thus, the <i>valuetype factory</i> may have to be installed at
    deployment time. </p>
    <p> According
    to the similarity in the <i>home</i> and <i>valuetype factory</i>
    concepts, it may be a good solution to add an entry in the CORBA
    Component Descriptor OSD file to define the <i>valuetype factory</i>
    (which would have to be included in the component package) required by
    the component as well as to define a standard name scheme for their
    entry points. Here is an draft example of what it could look
    like. Relationships / dependencies between components and <i>valuetype
    factories</i> also have to be introduced.</p>

    <!--
    <softpkg>
    ...
    <implementation id="...">
    ... all the environment stuff ...
    <descriptor type="Event Factory">
    <fileinarchive>...</fileinarchive>
    </descriptor>
    <code type="DLL">
    <fileinarchive name="bank.dll" />
    <entrypoint>createEventFactory</entrypoint>
    </code>
    </implementation>
    ...
    </softpkg>
    -->

    <p><tt><softpkg>
    <br>  ...
    <br>  <implementation id="...">
    <br>    ... all the environment stuff ...
    <br>    <descriptor type="Event Factory">
    <br>      <fileinarchive>...</fileinarchive>
    <br>    </descriptor>
    <br>    <code type="DLL">
    <br>      <fileinarchive name="bank.dll" />
    <br>      <entrypoint>createEventFactory</entrypoint>
    <br>    </code>
    <br>  </implementation>
    <br>  ...
    <br></softpkg></tt></p>

    <p>The second solution could be to include the code for <i>valuetype
    factory</i> creation in the <i>home</i> implementation, which mean
    less specification: "The home has to install any valuetype factory
    required by the component." would be enough. However, this second
    approach may not be as much portable as the first one (as long as a
    <i>home</i> may be portable between containers, which IMHO should be
    possible).</p>

  • Reported: CPP 1.1 — Thu, 24 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

simple ELEMENT definition

  • Key: CORBA26-35
  • Legacy Issue Number: 3926
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    I have a question about the property.dtd file provided with the CCM spec.

    in this file "simple" is described as follow:

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , defaultvalue?
    ) >

    This seems to indicate that a "simple" element has to have a value in the
    file. Therefore it is not clear how usefull is the optional "defaultvalue"
    field. It also means that if the component or assembly provider wants to
    provide the CPF files with the CCD and CAD files it has to put values into
    them instead of just setting the default value. Obviously the best thing to
    do would be to repeat the default value into the value but it seems strange
    to me. The point is that if there is a default value provided the value
    doesn't seem to be mandatory.

    Also, in a way similar to the CAD file, where placement information are
    added at deployment time, we may want to enable the component/assembly
    provider to provide CPF skeleton files together with the CCD files and
    skeleton CAD files. In this case the "simple" element may not contain any
    "value".

    I propose to replace this definition with:

    <!ELEMENT simple
    ( description?
    , value?
    , choices?
    , defaultvalue?
    ) >

    Any thought

  • Reported: CORBA 2.4 — Mon, 2 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

range description in CPF files.

  • Key: CORBA26-34
  • Legacy Issue Number: 3925
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    The definition for "choices" is as follow in the properties.dtd file:

    <!ELEMENT choice ( #PCDATA ) >
    <!ELEMENT choices ( choice+ )

    knowing that the PCDATA for choice is supposed to hold one possible value
    for the "simple" if I am right

    I believe this is missing a bit of descriptive power. In case you want to
    specify a range of 100 values you will have to give the 100 different values
    each in its own "choice" element. It is very verbose !!!

    We could add a range ELEMENT to the DTD as follow:

    <!ELEMENT range (value, value)>

    We could then change the choices ELEMENT as follow:

    <!ELEMENT choices ( range | choice )+>

    Any thought.

  • Reported: CORBA 2.4 — Mon, 2 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Bridge Interoperability of the Java mapping with the EJB-to-CCM mapping

  • Key: CORBA26-23
  • Legacy Issue Number: 3419
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    he following sub-issues need to be addressed to make sure that CCM/EJB
    bridge implementations are interoperable. In particular, these sub-issues
    have in common that the current definition of the bridge relies on the
    Java-to-IDL mapping, which in certain cases does not match the requirements
    of the EJB-to-CCM mapping.

    Sub-issue: METHOD NAMES IN STANDARD INTERFACES

    The names for some methods defined on standard interfaces, for example
    <home-name>Implicit.find_by_primary_key or <home-name>Implicit.create,
    differ from the names that their EJB counterparts get mapped to under
    Java-to-IDL (in the example these would be
    <home-name>.findByPrimaryKey and create__keytype, respectively). When
    this happens, the translation from one form of the name to the other
    can happen at either the client or the server side of the bridge. FOR
    INTEROPERABILITY, it is necessary to eliminate this ambiguity. Choices
    for doing this include requiring the client stub to always do the
    translation or requiring the server skeleton to take into account both
    name forms.

    The actual problem we are getting hit by here is overloaded names. Methods
    like remove and create in EJBHome and user-defined EJB homes can only be
    mapped to remove_XXX and create_XXX under Java-to-IDL, yet the
    definitions of the corresponding methods in <home-name>Implicit are remove
    and create, respectively. I can understand that these implicit home names
    were defined as such because <home-name>Implicit is a standard interface
    (although the fact that its name is prefixed by <home-name> is a bit
    troubling) and, if for no other reason, because the XXX in create_XXX
    cannot be known in general. So, if we stick to the standard names, there is
    a mismatch. Notice however that I said that the mapping is done under
    Java-to-IDL. Perhaps I should not say that but the CCM spec is not clear
    about this and in fact it states that the create methods in an EJB home are
    mapped to factory names under Java-to-IDL. So we may actually be talking
    about two different issues: (1) use different mapping rules for create with
    no primary key, in which case we need to ammend the spec to this effect;
    (2) perform a translation, in which case we have an interoperability issue.

    Sub-issue: HANDLING STANDARD EXCEPTIONS

    Standard exceptions thrown by EJB methods, such as
    DuplicateKeyException, have a mapping specification to IDL (under the
    current Java-to-IDL specification) that does not match the exceptions
    that they map to under the CCM spec (in the example this would be
    DuplicateKeyValue). This requires that the bridge perform a run-time
    translation of exceptions from the Java-to-IDL mapping to the CCM
    mapping at either the client stub or the server skeleton. FOR
    INTEROPERABILITY, it is further necessary that the location of the
    translation be fixed. Early prototype implementation suggests that it
    is more advantageous for the client stub to perform the translation
    since otherwise the server skeleton would need to know what kind of
    client it is talking to: a CCM client or an EJB client. A larger issue
    that this falls under is the reconciliation of the Java-to-IDL mapping
    with the EJB-to-CCM mapping. If and when the larger issue is resolved,
    this issue would largely disappear.

    This also falls under the Java-to-IDL mismatch. Our choices seem to be: (1)
    define the standard exceptions, e.g. Components::DuplicateKeyValue, as if
    they had been mapped from Java under Java-to-IDL, (2) map the exceptions
    from Java under rules different from those on Java-to-IDL; (3) perform a
    translation. Choice (1) may be too intrusive but it could be rationalized
    with a "integration with EJB" argument. Choices (2) and (3) are similar to
    the above.

    Sub-issue: PASSING A PRIMARY KEY PARAMETER

    A number of methods defined by standard interfaces, such as remove
    defined by EJBHome, include in their signature a primary key value and
    define its type to be java.lang.Object, which under RMI-IIOP is mapped
    to CORBA::Any. Since the primary key is actually an object passed by
    value and thus mapped to an IDL value type, a run-time translation
    must be performed from the value type to Any and viceversa whenever a
    method that includes a primary key is called. FOR INTEROPERABILITY, it
    is necessary that the location of this translation be fixed. Choices
    for doing this include requiring the client stub to always do the
    translation or requiring the server skeleton to take into account both
    a value or an Any that could possibly be coming from any given
    client. In additon, if a primary key is returned it may be more
    advantageous for the client to perform this translation, since the
    server skeleton may not know what form the client is expecting.

    Here again the problem is that, under Java-to-IDL, java.lang.Object gets
    mapped to ::java::lang::Object (not CORBA::Any actually, as per the actual
    Java-to-IDL I am looking at) for methods like EJBHome.remove, whereas the
    key is expected to be passed as a value type. So the choices seem to be:
    (1) use rules other than those in Java-to-IDL for the mapping or (2)
    perform a translation.

  • Reported: CPP 1.1 — Tue, 14 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM issue chapter 69 ptc/99-10-04

  • Key: CORBA26-22
  • Legacy Issue Number: 3412
  • Status: closed  
  • Source: Anonymous
  • Summary:

    What exactly is meant in chapter 69.7.2.3 by component archive file? It is
    not defined anywhere. Is it a software package descriptor or a software
    package? At least it is not a CORBA component descriptor as shown in the
    example in chapter 69.7.1. The text there is like:

    <componentfile id="A">
    <fileinarchive name="ca.ccd"/>
    ...

    Is the sufix ccd right?

  • Reported: CPP 1.1 — Mon, 13 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01

  • Key: CORBA26-21
  • Legacy Issue Number: 3299
  • Status: closed  
  • Source: Ericsson ( John-Luc Bakker)
  • Summary:

    Document orbos/99-08-13, line 9 and further, contradicts with
    orbos/99-07-01,
    Chapter 4.4. The production rules for typePrefix and typeId contain a
    ";",
    where file orbos/99-08-13 omits them.

    Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01,
    Chapter 4.2. The production rules for import contain a ";",
    where file orbos/99-08-13 omits them.

  • Reported: CPP 1.1 — Mon, 7 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

EJB/CCM mappings for the IR

  • Key: CORBA26-20
  • Legacy Issue Number: 3260
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    The mapping between EEJB metadata and the IR is missing in the
    current specification .Resolution: Define the mapping

  • Reported: CPP 1.1 — Thu, 27 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above, rejected

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

IFR backward compatibility broken

  • Key: CORBA26-19
  • Legacy Issue Number: 3233
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Moving existing interfaces from the CORBA module to a new IR module breaks
    backward compatibility. Hence they should be moved back to the CORBA module. The
    elements that are newly added can go into a new module, and interfaces
    corresponding to the existing ones with the same names can be placed in the new
    module, with these interfaces deriving from the existing corresponding
    interfaces in the CORBA module, thus allowing all CORBA3 IR interfaces to be
    accessed from a single module.

    This also fixes a related problem regarding separation of the TypeCode stuff,
    specifically TypeCode factory. It is broken in the current spec because certain
    types used by the typecode factory were inadvertently moved to the IR module.

  • Reported: CPP 1.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Missing Rights Combinator in Security deployment descriptor

  • Key: CORBA26-18
  • Legacy Issue Number: 3232
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    In section 69.4.5.45, the "rights" element is mentioned, but the "rights
    combinator" elemnt is not. Given a set of "rights" it is not possible to
    determine how to cobine them without the "rights combinator" as specified in
    CORBAsec. Suggest we add a "rights cobminator" element, consistent with the
    definition of rights combinator in CORBAsec.

  • Reported: CPP 1.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Purpose of "name" element

  • Key: CORBA26-13
  • Legacy Issue Number: 3198
  • Status: closed  
  • Source: Ericsson ( John-Luc Bakker)
  • Summary:

    ISSUE - What is the purpose of the "name" element as used in the
    "dependency" element?

    See section 10.2.2.7, The dependency Element (, page 10-308, 10.2.1 A
    softpkg Descriptor Example, CORBA Components - orbos/99-07-01.) Section
    10.2.2.20, The name Element, describes the name element as an optional
    element of the "author" element, and is meant to identify the author. So
    does the name element identify the author of the dependency, or is it used
    to identify the dependency itself?

  • Reported: CPP 1.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM Issue: CIDL Syntax doesn't allow for modules

  • Key: CORBA26-12
  • Legacy Issue Number: 3065
  • Status: closed  
  • Source: Oracle ( Dan Frantz)
  • Summary:

    The FTF draft does not allow a CIDL composition to be
    included in a module.

    Discussion: In the FTF Draft, the CIDL BNF (Section 60.3) is not yet
    tied into IDL syntax. As it stands, a composition cannot be embedded
    in a module. The draft recognizes that with the note (Section 60.4):

  • Reported: CORBA 2.3.1 — Thu, 2 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Issue On the use of typed home (or CCMHome subtypes)

  • Key: CORBA26-29
  • Legacy Issue Number: 3725
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    When a component type is implemented, it inherits a specialized
    interface for callback functions, for example SessionComponent. In
    this context, why should home implementations be unspecialized? Using
    a specific home type, deployment could be improved when performed in a
    multi-actor context. As the cooperation between containers and homes
    is unspecified, using multi-actors components seems unreachable. One
    particular aspect is how the container <Context> interface si provided
    to the component instance. Using a well defined specialized home
    interface would solve this problem easily. Thus, avoiding the use of
    wrappers for example which are another solution, but far more complex.
    Such an interface should be defined for each component type category.

    As an example the following interface could be a basis for session
    component homes. (there must be other operations to add here, but I
    have not foudn them yet.)

    interface SessionCCMHome : CCMHome

    { // or CCMHomeKeyless void set_session_context ( in SessionContext sc ) ; }

    ;

  • Reported: CPP 1.1 — Mon, 26 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

Where is HomeExecutorBase interface defined?

  • Key: CORBA26-28
  • Legacy Issue Number: 3651
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    7. Where is HomeExecutorBase interface defined? I only saw it used in
    the packaging and deployment model. If it is a standard interface
    which is returned (how could it be non standard), shouldn't it be
    defined somewhere? (Same remark for ExecutorSegmentBase
    interfaces. It may be defined in the last Components.idl, but I did
    not find one more recent than orbos/99-08-13.)

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See the resolution for issue 4574.

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

In example p.615-86

  • Key: CORBA26-27
  • Legacy Issue Number: 3650
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    6. In example p.615-86, shouldn't myToonImpl extends ToonSessionImpl
    (presented in the previous pages) instead of ToonImpl (which is not
    defined)? The same classname is used in pages 96-98, but it seems
    correct in this case.

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

p.615-85 ToonTownImpl

  • Key: CORBA26-26
  • Legacy Issue Number: 3649
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    5. Even if it is only an example, p.615-85 ToonTownImpl implements
    ExecutorSegmentBase, shouldn't it be HomeExecutorBase?

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Why does not CCMHome include the operation create_component() ?

  • Key: CORBA26-25
  • Legacy Issue Number: 3648
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    4. Why does not CCMHome include the operation create_component() ? I
    understand that a component created by a home with keys should not
    offer this interface, however according to the exemple in the spec
    Container operation install_home() returns a CCMHome, thus how
    could a component be created in this context? Does it imply that
    you know if the home is keyless or not, thus narrowing it before
    use? Don't you find strange to have the remove operation but not a
    default create in the CCMHome interface?

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

operation

  • Key: CORBA26-24
  • Legacy Issue Number: 3647
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    3. Why isn't the operation <string get_implementation(in string iuuid)>
    defined in the interface ComponentInstallation while being used in
    ptc/99-10-04 p.69-329 item 9? (Where Installation should be
    replaced by ComponentInstallation don't you think?) Moreover, this
    operation is required for an Assembly to find the location of a
    component implementation in order to load it in a container.

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

PACKAGING AND DEPLOYMENT METAMODEL

  • Key: CORBA26-15
  • Legacy Issue Number: 3208
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    1) Some concepts from the CORBA metamodel (component, facet, receptacle,
    event publishing/emission/consumption) are also in P/D metamodel but the
    definitions from the CORBA metamodel are not directly reused.

    Recommendation: Analyze where reuse is appropriate and adjust the P/D
    metamodel accordingly.

    2) The P/D metamodel has the notion of files (e.g. configuration property
    files and some other files) where some metadata are stored. The hand-coded
    DTDs treat these files as types in their own right, i.e. they conceptualize
    them as files, and some of the other types point to the file types. This
    is approach is mimicked in the metamodel. However, it might not make sense
    in the metamodel because, in a repository context, you are referencing
    other information in the repository and not necessarily a file. The way
    the metamodel is now, when something references one of these files you lose
    the metadata trail. The file metaclass itself does not have structural
    features pointing to metaclasses that define the contents of the file. You
    have to go elsewhere (i.e. to the property file Package) to get that
    metadata and there is no reference to the property file Package.

    Recommendation: It might make more sense for references to the file
    metaclass to instead reference the top level element of the property file
    Package so that you can "follow the metadata trail." If someone wants to
    break out the properties metadata in a file, then the generated DTD should
    allow that, i.e. the part that needs to go into a properties file should be
    able to be self-contained without external references.

  • Reported: CPP 1.1 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected, See issue 4575.

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

atribute not part of definition

  • Key: CORBA26-14
  • Legacy Issue Number: 3199
  • Status: closed  
  • Source: Ericsson ( John-Luc Bakker)
  • Summary:

    ISSUE - The description of the "implementation" element explains the
    "variation" attribute, but the attribute is not part of the definition.

    >From page 10-32, CORBA Components - orbos/99-07-01: "The variation attribute
    is used to indicate a variation from a normal implementation." But the
    definition of the implementation attribute list only lists the "id"
    attribute. The variation attribute is not part of the definition as given in
    softpkg.dtd either (, page B-419, B.1 softpkg.dtd, CORBA Components -
    orbos/99-08-05.)

  • Reported: CPP 1.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Versioning needed for CORBA Core

  • Key: CORBA26-11
  • Legacy Issue Number: 2227
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: At present there is no formal mechanism or process for versioning the
    CORBA Core. Indeed, it is somewhat hard to figure out what is part of
    the CORBA Core. In Rev 2.3 we tried to at least bring all the IDL for
    the Core together in pieces at logical places, e.g. ORB interface,
    Object interface, IR Interfaces etc. In addition we also have the
    PortableServer module and the GIOP and related modules, the versions of
    all of which have to match for the resulting system to have any hope of
    working as advertized. I guess the basis of the current state of
    affairs is that - the vendor delivers the core, and therefore one can
    trust the vendor to deliver the right things. This model tends to break
    down in situations where people can download bits and pieces of a Java
    ORB at different times and then try to make the whole thing work
    together.

  • Reported: CORBA 2.2 — Mon, 23 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected, see above

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

Components: readonly_attr_declarator slightly ambiguous

  • Key: CORBA26-17
  • Legacy Issue Number: 3230
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    In ptc/99-10-04, the production 104

    <readonly_attr_declarator >::=
    <simple_declarator> [ <raises_expr> ]

    <simple_declarator> { "," <simple_declarator> }*

    is ambiguous, since a sole <simple_declarator> could either denote the
    first alternative (with no <raises_expr>), or the second alternative
    (with the simple-declarator-list omitted). Even though this does not
    constitute a serious problem, it is also easy to fix:

    <readonly_attr_declarator >::=
    <simple_declarator> <raises_expr>
    | <simple_declarator> { "," <simple_declarator> }

    *

  • Reported: CPP 1.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Components: Relationship of CIDL and PSDL unclear

  • Key: CORBA26-16
  • Legacy Issue Number: 3229
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    The draft component specification (ptc/99-10-04) explains that CIDL is
    a superset of IDL. This is a derivation from the specification
    voted-on in the PTC (orbos/99-07-01), which specified that CIDL is a
    superset of PSDL.

    Also, declaring CIDL not to be a superset of PSDL means that the
    <catalog_use_dcl>, <abstract_storage_home_binding> etc become
    meaningless, as they refer to entities from PSDL.

    Proposed Resolution: Declare CIDL to be a superset of PSDL.

  • Reported: CPP 1.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 3065.

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

section 7.1.1 claims to define the "NVList structure", but doesn't

  • Key: CORBA26-10
  • Legacy Issue Number: 4722
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the Corba 2.5 spec,
    section 7.1.1 claims to define the "NVList structure",
    but doesn't. Section 7.5 defines the "NVList interface".
    Is this a typo in 7.1.1, then?

    This is a bit confusing. Is NVList a struct, or an interface?
    Inquiring minds want to know

  • Reported: CORBA 2.5 — Thu, 15 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see below

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

Implied IDL for interfaces in modules

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

    The Messaging Programming Model introduces implied interfaces. These
    interfaces have the same name as the original interface, but with an
    AMI_ prefix.

    What happens if the original interface is in a module? Will AMI_ be
    prepended to the unqualified name, or to the absolute name? E.g.

    module Stock {
    interface StockManager

    { ... }

    ;
    };

    In this case, will the absolute name of the ReplyHandler be
    ::AMI_Stock::StockManagerHandler, or ::Stock::AMI_StockManagerHandler ?

    All examples in the spec (formal/2001-09-26) are outside any module.
    Since it never talks about absolute names, but only of names, it might
    indicate that it should be the latter (AMI_ prepended to the unquali-
    fied name).

    However, the precedent for prefixes, the POA, always prepends the POA_
    prefix to the absolute name, and I would find it confusing if the AMI_
    prefix was used differently.

  • Reported: CORBA 2.5 — Fri, 30 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see below

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

IDL for ORB::resolve_initial_references

  • Key: CORBA26-8
  • Legacy Issue Number: 4718
  • Status: closed  
  • Source: Hewlett-Packard ( Michael Matzek)
  • Summary:

    The IDL for ORB::resolve_initial_references declares that it may throw the standard user exception InvalidName, however the Specification does not specify when, if ever the ORB may do so. Two cases of interest are an unknown name such as a misspelled well-known name and an unimplemented well-known name such as Trading Service.

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

    close, no change

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

set_length operation of the DynSequence interface

  • Key: CORBA26-7
  • Legacy Issue Number: 4713
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Jason Courage)
  • Summary:

    The set_length operation of the DynSequence interface is defined as:

    void set_length(in unsigned long len) raises(InvalidValue);

    in the IDL but is defined as:

    void set_length(in unsigned long len) raises(TypeMismatch, InvalidValue);

    in the discussion that follows the IDL in section 9.2.8. The TypeMismatch exception appears inconsistently in the definition of the operation.

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

    see below

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

the IDL include directive should introduce declarations into the namespace

  • Key: CORBA26-6
  • Legacy Issue Number: 4709
  • Status: closed  
  • Source: Hewlett-Packard ( Michael Matzek)
  • Summary:

    The IDL specification for the include directive follows the ANSI C++ specification. This means that the include statement is replaced by the included file's text. The C++ mapping then calls for the generation of stubs and skeletons for the now inline included interfaces. But if the same IDL file, for example CosTransactions.idl, is included in multiple compilation units, the included interfaces become multiply defined. It's like including C++ class definitions rather than class declarations in a C++ program. The problem arises because IDL language mappings specify implementation. Wrapping include directives in different modules has the undesirable effect of requiring multiple implementations of the same operations that differ only in their qualified names. The IDL specification should provide a specification similar to the Java language import statement. That is, the IDL include directive should introduce declarations into the namespace but not implementation via the language. mappings.

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

    close, no change

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

DynUnion operations

  • Key: CORBA26-5
  • Legacy Issue Number: 4708
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Jason Courage)
  • Summary:

    In the section describing DynUnion operations, the restatement of the IDL definition of the get_discriminator() operation includes a raises (InvalidValue) clause. This exception is not discussed in the paragraph describing the operation, nor does it appear in the IDL definintion of this operation anywhere else in the chapter.

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

    see below

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

Problem with IDL Context interface

  • Key: CORBA26-4
  • Legacy Issue Number: 4657
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    a few problems with IDL contexts:

    1) On page 4-32, with have:

    "CORBA::CTX_DELETE_DESCENDENTS deletes the indicated context
    ^^^^^^^^^^^
    object and all of its descendent context objects, as well."
    ^^^^^^^^^^
    The standard system exception BAD_PARAM is raised if there are one
    or more child context objects and the CTX_DELETE_DESCENDENTS
    ^^^^^^^^^^^
    flag was not set."

    That's a bit embarrassing because the correct spelling is "descendants",
    not "descendents".

    2) For the get_values() operation, we have:

    "Scope indicates the context object level at which to initiate the
    search for the specified properties (e.g. "_USER", "_SYSTEM"). If
    the property is not found at the indicated level, the search
    continues up the context object tree until a match is found
    or all context objects in the chain have been exhausted."

    This does not say exactly how this is meant to work. I assume that
    the idea is to start at the current context object, checking whether its
    name matches the start_scope parameter. If it does, start the search here;
    otherwise, go up a level and repeat. Once a context object has been found
    with a matching name, then start looking for the properties and collect
    them together, with lower level settings overriding higher level settings,
    until either all property values have been determined or we run out of
    context objects.

    If this is the intended interpretation, the words in the spec are a long
    way from actually expressing that...

    3) Context objects have names. Those names are used to control the behavior
    of get_values(). However, we have two problems:

    • The top-level context object does not have a defined name, so
      I can't specify its name for get_values().
    • Once I've given a context object a name, I can't get it back out.
      (Yet another case where I am forced to give identity to an object
      only to be denied any opportunity of ever asking what that
      identity is...)

    4) For create_child(), what happens if I:

    • specify a name that doesn't look like an IDL identifier?
    • call create_child() twice with the same name on the same
      parent context?

    5) For delete_values(), what is the behavior if the specified property
    does not exist?

    6) For delete(), what is the minor code of the BAD_PARAM exception
    if I don't set the CTX_DELETE_DSCENDENTS [sic] flag and the context
    has child contexts?

    7) For get_values(), what does it mean to "omit" the scope name? The only
    way to omit it, as far as I can see, is to pass the empty string. If so,
    that should be stated.

    8) For get_values(), what exception is raised if the specified scope name
    is not found?

    9) get_values() and delete() accept a Flags parameter. It is not specified
    how to not set a flag (only what it may be set to). Given that Flags
    is an unsigned long, presumably I have to pass zero to indicate that a
    flag is not set. However, this is not specified.

    10) For get_values(), what is the minor code of the BAD_CONTEXT system
    exception if a property isn't found? Why a BAD_CONTEXT exception? Why
    an exception at all (instead of returning an empty sequence)?

    11) For get_values(), it says:

    The NO_MEMORY exception is raised if dynamic memory allocation fails.

    This sentence is utterly redundant.

    12) For get_values(), we have:

    The values returned may be freed by a call to the list free operation.

    What "list free operation"? There is no such operation on NVList.
    There is CORBA::free, but that is specific to the C mapping.

    13) For get_values(), we have:

    "Scope indicates the context object level at which to initiate the
    search for the specified properties (e.g. "_USER", "_SYSTEM")."

    However, for create_child(), we have:

    "Context object names follow the rules for OMG IDL identifiers."

    "_USER" and "_SYSTEM" are not valid IDL identifiers (at least they were
    not at the time this was written, and you can argue that they still are
    not valid IDL identifiers because the underscore is stripped immediately
    by the IDL compiler).

    14) What happens if I call get_default_context() multiple times? Presumably,
    I will get a reference to the same single context object?

    15) In the first para of page 4-29, it says:

    "... although a specified property may have no value associated
    with it"

    This would appear to be impossible. If the property itself exists,
    it always has a value, namely a string. The closest thing to "no value"
    would appear to be the empty string (or a property doesn't exist at all).

    16) "An operation definition may contain a clause specifying those context
    properties that may be of interest to a particular operation. These
    context properties comprise the minimum set of properties that will
    be propagated to the server's environment..."

    So, what happens if I have

    interface I

    { void op() context("C"); }

    ;

    and no property "C" exists in the context object passed by the client?

    Does this mean that the call will be made, but no property "C" will
    be available to the server? (I don't think so, because that would
    contradict the above words about "minimum set of properties that will
    be propagated")

    Or does it mean that the call will be made, but that the value of "C"
    will be the empty string?

    Or does it mean that the call will be refused because the caller has
    not supplied the required properties? If so, what exception is be
    raised?

    17) "Context property names (which are strings) typically have the
    form of an OMG IDL identifier, or a series of OMG IDL identifiers
    separated by periods."

    This is in conflict with the words about property name syntax elsewhere.

    This is a total mess. One interface with six operations, and about a dozen
    bugs. Impressive!

  • Reported: CORBA 2.5 — Thu, 1 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    Indeed it is hopelessly broken. Fix as suggested below.:

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

Chapter 11, section 11.3.8.19 (WrongPolicy)"

  • Key: CORBA26-3
  • Legacy Issue Number: 4654
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Jason Courage)
  • Summary:

    In chapter 11, section 11.3.8.19, the "raises (WrongPolicy)" clause has been omitted from the specification of the create_reference_with_id operation. (This exception clause is included in the IDL definition in section 11.4.)

  • Reported: CORBA 2.5 — Thu, 1 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see above

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

Support for is_a for local interfaces

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

    Proposal: Section 3.7.6.1: Change the bullet that 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.

    to:

    • The 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.
  • Reported: CORBA 2.5 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    Reflect this fact as follows

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

Section 11.3.8.16 - ambiguity

  • Key: CORBA26-1
  • Legacy Issue Number: 4620
  • Status: closed  
  • Source: Anonymous
  • Summary:

    My issue is the ambiguity surrounding the following statement:

    "If the POA has the SYSTEM_ID policy and it detects that the Object Id value was not generated by the system or for this POA, the activate_object_with_id operation may raise the BAD_PARAM system exception."

    So the spec says the operation may raise the BAD_PARAM exception, but doesn't have to. It would be nice if the spec were to clarify the exact behaviour that should be followed to remove ambiguity, because I'm finding some ORB implementations are throwing a BAD_PARAM exception whereas others are not raising an error condition at all.

  • Reported: CORBA 2.5 — Tue, 16 Oct 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    No Data Available

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