Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA24-197 Conflict between POA & Exceptions spec for OBJECT_NOT_EXIST CORBA 2.3.1 CORBA 2.4.2 Closed; No Change closed
CORBA24-185 Definition of TRANSIENT minor code 1 confusing CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-184 IDL format for RepositoryId CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-183 Valuetypes supporting local interfaces are local types? CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-182 #pragma version issue CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-181 Servant deactivation callback? CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-180 DynUnion incomplete CORBA 2.4 CORBA 2.4.2 Resolved closed
CORBA24-179 Format of RMI Hashed Format repid CORBA 2.4 CORBA 2.4.2 Resolved closed
CORBA24-132 Use of the type ComponentHome CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-131 USING Components::Enumeration CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-128 Implementation of get_component CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-129 New IDL keywords CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-127 CORBA IR METAMODEL CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-126 Is the ccm_home method shown in Table 8-1 a typo? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-123 Do EJB-mapped attributes go to the ComponentDefault interface? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-124 What's the return type of CCM mappings of EJB finder and creator methods? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-125 How is CCMHome::get_home_def mapped to EJB operations? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-121 CCM Issue: How are standard EJB exceptions mapped into the CCM View CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-120 Should Components::Enumeration be an IDL interface or an IDL abstract value CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-118 Components Issues - Interface Repository ptc/99-10-03 CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-122 CCM Issue: Is CCMObject::remove intended to be available to the CCM client? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-119 CCM Issue: Is a home needed? CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-117 Components Issues - Chapter 61 ptc/99-10-04 CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-116 implementing import for C++ CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-171 wchar alignment in GIOP 1.2 CORBA 2.4 CORBA 2.4.2 Resolved closed
CORBA24-170 Is padding necessary for empty Reply body? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-168 Small optimization for the GIOP header CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-169 GIOP _get_domain_managers ambiguous CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-167 interop issue: CodeSets service context in GIOP 1.0 request CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-166 Version and byte order changes when fragmenting messages (interop) CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-163 selected_profile_index origin CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-165 Issue 2 -- resulting from UK comment UK-5: CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-162 Absence of Wide Character Code Set CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-164 Issue 1 -- resulting from Japanese comment JPN-009E: CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-156 Valuetype in anys. Unmarshaling problem? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-140 GIOP encoding of nil Abstract Interface is unspecified CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-139 .Passing the interface repository ID of the method in IIOP CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-137 TAG_ENDPOINT_ID_POSITION and TAG_LOCATION_POLICY CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-138 Chunked GIOP marshalling for variable-length types CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-133 Compacting GIOP messages by using indirections CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-134 Compacting GIOP Messages by using templates CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-135 Compacting GIOP Requests by hashing down operation names CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-136 Optimization of LOCATION_FORWARD replies CORBA 2.2 CORBA 2.4.2 Resolved closed

Issues Descriptions

Conflict between POA & Exceptions spec for OBJECT_NOT_EXIST

  • Legacy Issue Number: 3919
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    There is a conflict between the specification of the OBJECT_NOT_EXIST
    exception and its use in the POA spec. The exception definition says
    that OBJECT_NOT_EXIST means that an object has gone away forever, and
    that clients should tidy up references to it. However, the POA spec
    requires an ORB to raise this exception in cases where the object may
    not have gone away for ever.

    In particular, 11.2.6 (in the 5 May 2.4 Draft) requires an ORB to raise
    OBJECT_NOT_EXIST if request comes in for a child POA that is not active
    and was not activated by the application's POA Activator. While this
    may mean that the object has gone away for ever, it doesn't always
    mean that. For example:

    1) If the server admin has stuffed port number allocations, a server
    may accidentally get requests for POAs that it doesn't know about.

    2) If the server has been incorrectly (re-)built one of its "static"
    child POAs might not be activate.

    3) If the server is buggy and / or its persistent state is flakey,
    it may temporarily fail to dynamically activate a child POA.

    In each case, the problem MAY be one that can be fixed, allowing the
    missing POA to reappear in a few minutes. It is therefore inappropriate
    for the ORB to be telling the client that the Object has gone away for
    ever.

    For what it is worth, I think the ORB should raise another exception,
    say OBJ_ADAPTER, in the default case. It might raise OBJECT_NOT_EXIST
    if it (somehow) tracks the lifecycle of transient and / or persistent
    POAs, or if the application code tells it the POA no longer exists.
    Note: I'm not suggesting that an ORB be required to support such things.

    The other alternative is to change the definition of OBJECT_NOT_EXIST
    to remove the implication that the object has gone away forever and
    the suggestion that clients should throw away references to the object.
    [I think that's wrong though ...]

  • Reported: CORBA 2.3.1 — Thu, 28 Sep 2000 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4.2
  • Disposition Summary:

    Close no change

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

Definition of TRANSIENT minor code 1 confusing

  • Legacy Issue Number: 4036
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    >From CORBA 2.4, Table 4-3: TRANSIENT minor code 1 is described as:

    "Request discarded due to resource exhaustion in POA."

    However, section 11.3.2.1 states that minor code 1 is used when the
    POAManager is in the DISCARDING state.

    I think it would be better to reword this description as:

    "Request discarded because POAManager is in DISCARDING state (e.g.
    server lacks resources to complete request.)"

  • Reported: CORBA 2.4.1 — Thu, 9 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Make it so

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

IDL format for RepositoryId

  • Legacy Issue Number: 4035
  • Status: closed  
  • Source: UBS ( Karsten Starr)
  • Summary:

    Following statement in CORBA V2.3 (06/1999),
    P10-39, Chapter 10.6.1, OMG IDL Format concerning
    the OMG IDL format for Repository IDs:

    >> The RepositoryId consists of three components, separated by
    colons, (":")

    The first component is the format name, "IDL."

    The second component is a list of identifiers, separated by
    "/" characters.

    These identifiers are arbitrarily long sequences of alpha-
    betic, digit, underscore ("_"), hyphen ("-"), and period (".")
    characters. Typically, the first identifier is a unique prefix,
    and the rest are OMG IDL Identifiers that make up the scoped
    name of the definition. <<

    There are two issues here:

    • Firstly I propose to change >>"IDL."<< into >>"IDL".<<
    • Furthermore, I propose be more specific on the definition
      of the Repository Id. The above definition does not
      exclude a RepositoryId in the following style (which
      in my opinion does not make sense and effects inter-
      operability between ORBs): "IDL:/A/B:1.0"
      A regular expression could clarifiy this issue:
  • Reported: CORBA 2.4.1 — Thu, 9 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Incorporate changes and close issue.

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

Valuetypes supporting local interfaces are local types?

  • Legacy Issue Number: 4031
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    The semantics for local interfaces states:

    A valuetype may support a local interface.

    This brings up two questions.
    1. Can it support multiple? In addition to a unconstrained non abstract
    interface?
    2. Does it then become a local type (I think not, I think it becomes a
    local type only when it contains state that is a local type)

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

    No Data Available

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

#pragma version issue

  • Legacy Issue Number: 4016
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    In the CORBA 2.4 spec, chapter 10, the definition of #pragma ID has
    been modified so that later re-declarations of the same ID for a type
    are permitted. Before, it was explicitly an error to use #pragma ID
    for a type more than once, even if the same IDs were given.

    The section of #pragma version has not been updated. This means that
    handling of the two similar pragmas is now inconsistent:

    interface A {};
    #pragma ID A "LOCAL:foo"
    #pragma ID A "LOCAL:foo" // OK in 2.4, error in 2.3

    interface B {};
    #pragma version B 3.4
    #pragma version B 3.4 // Error in 2.4 and 2.3

    Should #pragma version be updated to be consistent with #pragma ID?

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

    Incorporate changes and close issue

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

Servant deactivation callback?

  • Legacy Issue Number: 4014
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Consider a servant for a persistent object that sits in front of a database.
    Assume a simple implementation model, using RETAIN and
    USE_ACTIVE_OBJECT_MAP_ONLY.

    We have n CORBA objects with n servants, and each servant implements
    its operations by reading/writing through to the persistent store, possibly
    also caching some state and maintaining other resources, such as database
    connections or memory buffers.

    I want to implement a life cycle destroy() operation. In the body of
    destroy, I have to write something like:

    void
    Foo_impl::
    destroy() throw(CORBA::SystemException)

    { my_poa->deactivate_object(my_oid); // Cannot remove database record here or do any other // cleanup. }

    The problem is that the servant can't simply blow things away at that
    point because there may be other operations running concurrently in the
    same servant, and those operations would get awfully surprised if their
    state suddenly disappeared.

    So, I delay reclaiming resources and deleting the database record until
    the servant becomes idle. In C++, that's no problem. Eventually, the
    servant's AOM entry disappears and (at least if I use reference-counted
    servants) that triggers the destructor of the servant, and I can
    clean up in the destructor.

    However, it appears that this doesn't work for other languages because they
    may not have destructors or, like Java, make no guarantees about when
    the destructor will be called.

    The problem is that there is no way for me to find out at what
    point the servant becomes idle, so that I could clean up.

    I think we need a callback from the ORB to the server application code that
    notifies the server when a servant finally becomes idle. Otherwise, it is
    pretty much impossible to implement life cycle support in languages other
    than C++, especially for threaded servers.

  • Reported: CORBA 2.4.1 — Thu, 2 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close no change.

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

DynUnion incomplete

  • Legacy Issue Number: 4005
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    given the a DynUnion value, I want to find out whether the discriminator
    currently indicates the default case. For example:

    union u switch (long)

    { case 0: long l; case 1: char c; case 2: double d; default: float f; }

    ;

    For this union, I want to know whether the default member is active, that is,
    whether the discriminator has a value other than 0, 1, or 2.

    Finding out whether the discriminator indicates the default case is currently
    rather difficult. I have to:

    1) get the union type code
    2) collect the values of all the explicit case labels from
    the type code
    3) check if the discriminator currently has a value that is not
    one of the explicit case labels values

    It would be much nicer to add the following to DynUnion:

    interface DynUnion : DynAny

    { boolean is_set_to_default_case(); // ... }

    ;

    The is_set_to_default_case operation returns true if a union has
    an explicit default label and the discriminator value does not
    match any of the union's other case labels.

  • Reported: CORBA 2.4 — Mon, 30 Oct 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Add the is_set_to_default_member function with the functionality as described for is_set_to_default_

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

Format of RMI Hashed Format repid

  • Legacy Issue Number: 3970
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    The format of the "hash code" element of an RMI Hashed Format repid
    needs to be clarified. Section 10.6.2 gives the algorithm for computing
    the 64-bit number to be used as the hash code, but does not specify the
    on-the-wire format for this number. In contrast, the spec explicitly
    states that the 64-bit number representing the SUID is transcribed as
    a 16-digit upper-case hex string.

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

    Clarify as suggested below

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

Use of the type ComponentHome

  • Legacy Issue Number: 3645
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    1. In the document OMG ptc/99-10-04 p.69-329 there is in item 5 a use
    of the type ComponentHome, shouldn't it be CCMHome? If I do recall
    correctly, ComponentHome was used in the first versions of the
    specification proposal.

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

    You are correct. ComponentHome should be CCMHome

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

USING Components::Enumeration

  • Legacy Issue Number: 3418
  • Status: closed  
  • Source: International Business Machines ( Ignacio Silva-Lepe)
  • Summary:

    It is probably not a good idea to mandate an implementation for
    Enumeration, since there may be different options for implementing.
    For example, it may be desirable for
    performance reasons to implement a form of lazy Enumeration that does
    not carry with it every element that it can contain, but requiring
    this kind of implementation can be overkill for some
    applications. Given this, Enumeration is defined as an abstract
    valuetype and at least one concrete specialization of it is
    required. In addition, FOR INTEROPERABILITY, at least one STANDARD
    implementation must also be provided so that client stubs and server
    skeletons know how to marshal and unmarshal Enumeration values.

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

    resolution see above

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

Implementation of get_component

  • Legacy Issue Number: 3213
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    2. Implementation of get_component with separate ORB and component vendors
    Problem: A design goal of the components specification was to permit the component container to be provided by a different vendor than the ORB vendor. When this is true, how does the implementation of get_component work?

  • Reported: CPP 1.1 — Wed, 12 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    closed issue, resolved

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

New IDL keywords

  • Legacy Issue Number: 3216
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    Problem: The new IDL keywords use mixed case, rather than the lower case style used by current keywords. Should the new keywords be changed to comply with the existing style?

  • Reported: CPP 1.1 — Wed, 12 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Yes, new IDL keywords should be changed to conform to existing style guide.

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

CORBA IR METAMODEL

  • Legacy Issue Number: 3207
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    1) The isBasic Attribute needs to be removed from HomeDef to synchronize
    with the regular CORBA IR.

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

    resolved

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

Is the ccm_home method shown in Table 8-1 a typo?

  • Legacy Issue Number: 3191
  • Status: closed  
  • Source: International Business Machines ( Ignacio Silva-Lepe)
  • Summary:

    Table 8-1 shows a mapping for CCMObject::get_home. It looks like it should
    say CCMObject::get_ccm_home

    Proposal:

    Change "CCMObject::get_home" to "CCMObject::get_ccm_home" in Table 8-1.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    No Data Available

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

Do EJB-mapped attributes go to the ComponentDefault interface?

  • Legacy Issue Number: 3187
  • Status: closed  
  • Source: International Business Machines ( Ignacio Silva-Lepe)
  • Summary:

    When mapping EJB set/get methods to a CCM view, it is not clear whether the
    resulting IDL attributes belong on the ComponentDefault interface or on the
    component definition itself

    Issue:
    Set/get method pairs on the EJB remote interface map to IDL attributes, but
    do these attributes end up in the XXXDefault interface or in the XXX
    component definition? Section 8.2.1.2 of the specification seems to imply
    they belong in the XXXDefault interface, but section 5.3.2 says the
    component definition for a basic CCM "shall only contain zero or more
    attribute declarations", which suggests that attributes of a CORBA
    Component belong in the component definition. Also, the mapping in the
    other direction (EJB view of a CCM), described in 8.3.1, suggests that CCM
    attributes are always found in the component definition itself. It appears
    that both versions will work, but this point is worth clarifying.

    Proposal:
    Change 8.2.1.2 to say that all EJB set/get method pairs are mapped to IDL
    attributes on the component definition itself.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    resolved

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

What's the return type of CCM mappings of EJB finder and creator methods?

  • Legacy Issue Number: 3189
  • Status: closed  
  • Source: International Business Machines ( Ignacio Silva-Lepe)
  • Summary:

    Summary:

    8.2.1.2 of the CCM specification says that EJB finder and creator methods
    which return an RMI object reference are mapped to methods which return a
    Components::CCMObject reference. It is unclear whether the actual base
    class CCMObject is intended or whether the specific component subclass
    (e.g., Widget) is intended. The specific subclass seems more sensible,
    and is consistent with the equivalent IDL mappings shown in section 5.8.4.

    Proposal:

    Change 8.2.1.2 to make it clear that the specific subclass (e.g., Widget)
    is the return type.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Change 8.2.1.2 to make it clear that the specific subclass (e.g., Widget) is the return type

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

How is CCMHome::get_home_def mapped to EJB operations?

  • Legacy Issue Number: 3190
  • Status: closed  
  • Source: International Business Machines ( Ignacio Silva-Lepe)
  • Summary:

    Chapter 8 omits to mention how the CCMHome::get_home_def call is mapped by
    the bridge at runtime to an EJB operation.

    Issue:
    The very similar call CCMHome::get_component_def is shown as mapped to the
    EJBHome.getEJBMetaData operation, but there is no mapping shown for
    CCMHome::get_home_def. It appears that get_home_def could be also be
    implemented using the EJBHome.getEJBMetaData operation, and if necessary,
    with the help of Java introspection.

    Proposal:
    Add a line in Table 8-1 to show CCMHome::get_home_def mapped at runtime to
    EJBHome.getEJBMetaData.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Add a line in Table 8-1 to show CCMHome::get_home_def mapped at runtime to EJBHome.getEJBMetaData

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

CCM Issue: How are standard EJB exceptions mapped into the CCM View

  • Legacy Issue Number: 3182
  • Status: closed  
  • Source: International Business Machines ( Ignacio Silva-Lepe)
  • Summary:

    Chapter 8 of the spec specifies mappings between EJB operations and their
    equivalents in the CCM view, but it leaves the mappings of standard EJB
    exceptions unclear.

    Issue:
    Create methods on an EJB home interface all throw the standard
    javax.ejb.CreateException; finder methods on the EJB home interface all
    throw the javax.ejb.FinderException; and remove methods on both home and
    remote interfaces all throw the javax.ejb.RemoveException. In a few cases
    chapter 8 gives an implied mapping: for example, the FinderException on the
    findByPrimaryKey method seems to map to either the
    Components.UnknownKeyValue exception or to the Components.InvalidKey
    exception on the equivalent find_by_primary_key CCM method. Even in these
    cases the names are sometimes inappropriate. In the majority of cases,
    however, there is simply no CCM equivalent to the EJB exception, and bridge
    implementors are left to wonder whether they should attempt a non-standard
    mapping.

    Proposal:
    (a) Add the new CCM standard exceptions Components.CreationFailure,
    Components.NotFound, and Components.RemovalFailure
    (b) Add Components.CreationFailure to the raises clause of all create
    methods on implicit and explicit home interfaces
    (c) Add Components.NotFound to the raises clause of
    find_by_primary_key on implicit home interfaces, and to the raises clause
    of all finder methods on explicit home interfaces
    (d) Add Components.RemovalFailure to the raises clause on the remove
    operation on implicit home interfaces, to the CCMObject.remove operation,
    and to the CCMHome.remove_component operation
    (e) Specify in chapter 8 that the EJB Finder exception is always
    mapped to Components.CreationFailure; that the EJB CreateException is
    always mapped to Components.CreationFailure; and that the EJB
    RemoveException is always mapped to Components.RemovalFailure.
    (f) Make explicit in chapter 8 the already implied mapping bewteen the
    EJB DuplicateKeyException and the Components.DuplicateKeyValue exception

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    No Data Available

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

Should Components::Enumeration be an IDL interface or an IDL abstract value

  • Legacy Issue Number: 3099
  • Status: closed  
  • Source: International Business Machines ( Ignacio Silva-Lepe)
  • Summary:

    Summary: Section 8.2.1.2 of the spec defines Components::Enumeration as an
    IDL interface, with the implication
    that it is intended as a remote type.

    Issue: It has been noted that java.util.Enumeration is usually implemented
    as a java.io.Serializable and that making
    Components::Enumeration an IDL interface would prevent this from happening
    for collections of primary keys returned
    from EJB Homes that are mapped to CCM Homes.

    Proposal: Define Components::Enumeration as an IDL abstract valuetype.

  • Reported: CORBA 2.3.1 — Wed, 8 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Define Components::Enumeration as an IDL abstract valuetype

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

Components Issues - Interface Repository ptc/99-10-03

  • Legacy Issue Number: 3063
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    The following errors in the interface repository chapter 10 need to be fixed.

    1. In IDL for interface HomeDef on Page 52 and Page 88:
    Remove the line: readonly attribute boolean is_basic;
    2. In IDL for struct HomeDescription on Page 52 and Page 88:
    Remove the line: boolean is_basic;
    3. In section 10.5.38.1 on page 53: Remove the paragraph that begins with:
    "The is_basic attribute is TRUE if this is a basic home......."

  • Reported: CORBA 2.3.1 — Mon, 22 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Since there is no basic and extended distinction for homes as there is for components, change text a

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

CCM Issue: Is CCMObject::remove intended to be available to the CCM client?

  • Legacy Issue Number: 3183
  • Status: closed  
  • Source: International Business Machines ( Ignacio Silva-Lepe)
  • Summary:

    Section 5.12.1 of the spec can be interpreted to mean that the
    CCMObject::remove call is not intended for use by CCM clients; but this is
    inconsistent with the EJB/CCM mapping given in chapter 8.

    Issue:
    The explanation given for the CCMObject::remove call in section 5.12.1 is:
    "This operation is called when a component is about to be destroyed.
    The component
    can perform any cleanup processing required (e.g. releasing resources)
    prior to its
    destruction."
    This explanation can be interpreted to mean that the call is a private call
    from a CCM container to one of its components; if it has this internal
    purpose then it might not be
    intended for use by CCM clients wanting delete the component. However,
    table 8-1 shows that the CCM view of an EJB maps this call to the
    EJBObject.remove()
    method. This implies that the method is intended for client use as the
    EJBObject.remove() is. If so, then it also makes more sense to implement
    the
    CCMHome::remove() method in terms of the EJBObject.remove() method, rather
    than the current mapping which requires an EJB Handle.

    Proposal: (a) Change the text for remove() in 5.12.1 to say: "This
    operation is used to delete a component".
    (b) Change the mapping in table 8-1 for CCMHome::remove to use
    EJBObject.remove

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Change the text for remove() in 5.12.1 to say: "This operation is used to delete a component".

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

CCM Issue: Is a home needed?

  • Legacy Issue Number: 3066
  • Status: closed  
  • Source: Oracle ( Dan Frantz)
  • Summary:

    Summary: The CCM FTF IDL chapter does not state whether a home must be
    declared for a component. A home must have a component, but must a
    component have a home?

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

    A component must have a home

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

Components Issues - Chapter 61 ptc/99-10-04

  • Legacy Issue Number: 3060
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    The following errors in the component model chapter 61 need to be fixed as
    follows to align the IDL in the text with the final IDL published in
    Appendix A (orbos/99-08-08).
    1. In IDL on page 46, section 61.6.3 add a “;” after expected_event_type.
    2. In IDL on page 43, section 61.5.3 replace
    ConnectionList get_connections (in FeatureName name)
    raises (InvalidName);
    with
    ConnectedDescriptions get_connections (in FeatureName name)
    raises (InvalidName);
    3. In IDL on page 68, section 61.10.1.2 replace
    valuetype ConfigValue

    { FeatureName name; any value; }

    ;
    with
    valuetype ConfigValue

    { public FeatureName name; public any value; }

    ;

  • Reported: CORBA 2.3.1 — Mon, 22 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    resolved

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

implementing import for C++

  • Legacy Issue Number: 2973
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    I'm concerned that for C++, implementing "import" as currently specified in
    the Components spec will be extremely difficult.

    Imagine how you might implement this: your IDL compiler generates a C++
    header file for all imported name scopes and creates #include directives
    for these files in the C++ code generated for the main IDL file. The main
    problem is that importable name scopes are modules, interfaces, valuetypes,
    structures, unions, and exceptions. To import an exception, for example,
    the import mechanism would have to keep a dependency graph for that
    exception type and make sure that all dependencies are generated into the
    header file so the C++ compilation won't fail. This seems way too complex,
    and I don't see the value of being able to import individual structs and such.

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

    Remove structure, union and exception from the list of name scopes (and repository ids) that can be

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

wchar alignment in GIOP 1.2

  • Legacy Issue Number: 4007
  • Status: closed  
  • Source: Borland Software Corporation ( Vishy Kasar)
  • Summary:

    I have a question on the octet alignment requirement for wchar as
    mentioned in Table 15-1 of CORBA 2.3. In 15.3.1.6 the spec states that

    "For GIOP version 1.2, wchar is encoded as an unsigned binary octet
    value followed by the octet sequence representing the encoded value of
    the wchar. The initial octet contains a count of the number of elements
    in the sequence and the elements of the sequence of octets represent the
    wchar, using the negotiated wide character encoding"

    If this is a variable length octet sequence anyway, specifying an octet
    alignment for this does not make sense. Our assumption is that alignment
    is specified only for GIOP 1.1 style wchars and is irrelevant for
    GIOP 1.2 style wchars. I am looking for confirmation of that assumption.

    If that is a valid assumption, shall we change the table 15.1 third row
    first column entry to state "wchar (in GIOP 1.1)" instead of "wchar"?

    If that is not a valid assumption, what are we aligning here? The length
    byte? The elements of octet sequence? What is the benefit of any
    aligning in this case?

  • Reported: CORBA 2.4 — Tue, 31 Oct 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close with revision

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

Is padding necessary for empty Reply body?

  • Legacy Issue Number: 3792
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The Interop RTF added text that explicitly states that padding for a
    Request body in GIOP 1.2 is not necessary if the body is empty. No
    equivalent text was added for empty GIOP 1.2 Reply bodies.

  • Reported: CPP 1.1 — Fri, 25 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Agree to add equivalent text for reply bodies.

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

Small optimization for the GIOP header

  • Legacy Issue Number: 3708
  • Status: closed  
  • Source: University of California, Irvine ( Carlos O'Ryan)
  • Summary:

    I think I found a possible (very minor) optimization for the
    GIOP 1.3 spec, but maybe I'm missing something in GIOP 1.2

    The new <target> field on the RequestHeader_1_2 structure is
    always aligned to a 4 byte boundary, the reserved[3] field ensures
    that. Consequently the discriminant for the TargetAddress union
    does not end on a 4 byte boundary, but will require 2 bytes of padding
    following it, since all the union values in this case start on 4 byte
    boundaries.

    IMHO, using just 1 byte for the reserved[] field, would have
    resulted in more natural alignments. Did I get something wrong here?
    Is this something likely to be fixed in GIOP 1.3?

  • Reported: CPP 1.1 — Fri, 16 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this issue as too much of a change for this RTF, and add it to the GIOP wish list for future p

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

GIOP _get_domain_managers ambiguous

  • Legacy Issue Number: 3787
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In GIOP, the _get_domain_managers operation name is used to indicate
    an invocation of the get_domain_managers pseudo operation. OTOH, it is
    also used if an attribute domain_managers is accessed, as it would
    appear in

    interface I

    { readonly attribute long domain_managers; }

    ;

  • Reported: CPP 1.1 — Fri, 18 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Changing the object reference operation on the wire to _domain_managers fixes the problem stated.

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

interop issue: CodeSets service context in GIOP 1.0 request

  • Legacy Issue Number: 3681
  • Status: closed  
  • Source: Xerox ( Bill Janssen)
  • Summary:

    Well, a new Java release is upon us, and with it comes a new CORBA
    implementation. I'm trying Java 2 SE 1.3 CORBA clients against an ILU
    2.0beta1 CosNaming server, and we find that the Java ORB cannot
    reliably connect to the server. Why not? First, we must analyze the
    IOR provided by the ILU service:

    IOR:000000000000002849444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578743A312E300000000002000000000000002F0001000000000016776174736F6E2E706172632E7865726F782E636F6D00270F0000000B4E616D6553657276696365000000000100000024000100000000000100000001000000140001001800010001000000000001010000000000

    If we look at this (those who've received it un-truncated) we find that it advertises the following:

    _IIOP_ParseCDR: byte order BigEndian, repository id <IDL:omg.org/CosNaming/NamingContext:1.0>, 2 profiles
    _IIOP_ParseCDR: profile 1 is 47 bytes, tag 0 (INTERNET), BigEndian byte order
    _IIOP_ParseCDR: profile 2 is 36 bytes, tag 1 (MULTIPLE COMPONENT), BigEndian byte order
    (iiop.c:parse_IIOP_Profile): bo=BigEndian, version=1.0, hostname=watson.parc.xerox.com, port=9999, object_key=<NameService>
    (iiop.c:parse_IIOP_Profile): encoded object key is <NameService>
    (iiop.c:parse_IIOP_Profile): non-native cinfo is <iiop_1_0_1_NameService@tcp_watson.parc.xerox.com_9999>
    (iiop.c:parse_MultiComponent_Profile): profile contains 1 component
    (iiop.c:parse_MultiComponent_Profile): component 1 of type 1, 20 bytes
    (iiop.c:parse_MultiComponent_Profile): native codeset for SHORT CHARACTER is 00010001, with 0 converters
    (iiop.c:parse_MultiComponent_Profile): native codeset for CHARACTER is 00010100, with 0 converters

    That is, there's a vanilla Internet profile (bo=BigEndian,
    version=1.0, hostname=watson.parc.xerox.com, port=9999,
    object_key=<NameService>), plus a Multicomponent profile, noting that
    the ILU ORB's native codesets are Latin-1 and UCS-2.

    OK, great. Now we get the first message from the Java ORB:

    0000 47 49 4f 50 01 00 00 00 00 00 01 00 GIOP........
    0000 00 00 00 02 00 00 00 01 00 00 00 0c 00 00 00 00 ................
    0010 00 01 00 20 00 01 01 00 00 00 00 06 00 00 00 90 ... ............
    0020 00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e .......(IDL:omg.
    0030 6f 72 67 2f 53 65 6e 64 69 6e 67 43 6f 6e 74 65 org/SendingConte
    0040 78 74 2f 43 6f 64 65 42 61 73 65 3a 31 2e 30 00 xt/CodeBase:1.0.
    0050 00 00 00 01 00 00 00 00 00 00 00 54 00 01 01 00 ...........T....
    0060 00 00 00 0c 31 33 2e 31 2e 31 30 33 2e 36 38 00 ....13.1.103.68.
    0070 0e e9 00 00 00 00 00 18 af ab ca fe 00 00 00 02 ................
    0080 67 d5 93 95 00 00 00 08 00 00 00 00 00 00 00 00 g...............
    0090 00 00 00 01 00 00 00 01 00 00 00 14 00 00 00 00 ................
    00a0 00 01 00 20 00 00 00 00 00 01 01 00 00 00 00 00 ... ............
    00b0 00 00 00 05 01 00 00 00 00 00 00 07 53 79 6e 65 ............Syne
    00c0 72 67 79 00 00 00 00 06 5f 69 73 5f 61 00 00 00 rgy....._is_a...
    00d0 00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e .......(IDL:omg.
    00e0 6f 72 67 2f 43 6f 73 4e 61 6d 69 6e 67 2f 4e 61 org/CosNaming/Na
    00f0 6d 69 6e 67 43 6f 6e 74 65 78 74 3a 31 2e 30 00 mingContext:1.0.

    Note that we are seeing a CodeSets service context, even though the
    request is GIOP 1.0. The service context specifies a TCS-C of ASCII,
    and a TCS-W of UCS-2.

    The question is, what should the server do with it?

    First of all, there seems to be no way in which the algorithm in
    section 13.2.7.6 can result in the TCS-C specified in the service
    context. So perhaps this bug should be detected and signalled back to
    the sending ORB. How? Using CODESET_INCOMPATIBLE might make sense,
    but that really doesn't flag the bug in the client-side implementation
    of the codesets determination algorithm. Perhaps a straight
    COMM_FAILURE would be better. Opinions?

    Secondly, since this is GIOP 1.0, the client could reasonably ignore
    the service context, and go ahead with using its default codeset
    (Latin-1). However, to do so risks comm failure down the line, as
    ASCII (the TCS-C assumed by the client) does not permit many Latin-1
    characters. It seems better to flag this situation up front.

  • Reported: CPP 1.1 — Wed, 5 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    close with revision. See below

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

Version and byte order changes when fragmenting messages (interop)

  • Legacy Issue Number: 3680
  • Status: closed  
  • Source: ICL ( Chris Wood)
  • Summary:

    It's occoured to me that according to the spec it's allowable for
    a message to be fragmented and have second and subsequent
    fragments change the version fields.

    Having the version change while in the middle of reading a
    wstring could cause problems, the CDR encoding of version 1.1
    strings is always two bytes longer than the corresponding 1.2
    encoding, if the version changed while in the middle of reading
    the wstring the length field would be out by two.

    Secondly if request IDs are per-protocol rather than
    per-connection (as aired in issue 3438) then the request ids of
    the fragments could interfere.

    I think an extra phrase should be added to the spec with regards
    to fragmentation, similar to the one regarding byte order:

    The version of fragments must match the version of the initial message that
    the fragment extends.

  • Reported: CPP 1.1 — Fri, 16 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close without revision since the spec was already clarified to state this.

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

selected_profile_index origin

  • Legacy Issue Number: 3622
  • Status: closed  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    Since the index numbering of sequences is a language mapping specific issue, the origin of the selected_profile_index within the IORAddressingInfo must be specified. I assume a zero origin is meant.

    Proposed Resolution:
    Add the following sentence to the description of IORAddressingInfo (in section 15.4.2.1 of the 25 March CORBA 2.4 preliminary draft): "The first profile has an index of zero."

  • Reported: CPP 1.1 — Thu, 18 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Accept proposed solution.

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

Issue 2 -- resulting from UK comment UK-5:

  • Legacy Issue Number: 3624
  • Status: closed  
  • Source: Object Management Group ( Henry Lowe)
  • Summary:

    The UK believes the footnote to section 13.6.2, page 13-16, of CORBA
    2.3.1 (this is clause 5.6.2 with the footnote appearing on page 13 of
    DIS 19500-2) does not make sense, especially the phrase "... except
    ones that make such profiles...". The meaning of this footnote needs
    to be clarified with revised text.

  • Reported: CPP 1.1 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close without revision.

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

Absence of Wide Character Code Set

  • Legacy Issue Number: 3576
  • Status: closed  
  • Source: Anonymous
  • Summary:

    CORBA is inconsistent on how to deal with the lack wide character code set
    information in an IOR and the codes set service context.

    When a server receives a service context without a wide character code set
    specified, then it is supposed to raise BAD_PARAM when it receives wide
    characters data from the client.

    However a client is supposed to raise INV_OBJREF if the IOR is missing
    from the server's native wchar code set . In CORBA 2.3, section13.7.2.6,
    "Code Set Negotiation", it says, "... a server that supports interfaces
    that
    use wide character data is required to specify its native wchar code set;
    if
    one is not specified, then the client-side ORB raises exception
    INV_OBJREF."

    This requires a client to know whether a server supports interfaces that
    use
    wide character data at the time the client receives an IOR. To determine
    this when the first IOR is received is a burdensome task. The client orb
    would be forced to apply an exhaustive examination, such scanning all of
    the
    server's IDL bindings or the contents of the IFR looking for wchar types.
    Additionally the client may need to determine if some Any might flow
    containing wchar data.

    I propose that the client's behavior be changed to match the server's. If
    any wide character data is encountered and the server's IOR was missing
    the native wchar code set, (which would cause the wide character
    transmission
    code set to not be negotiated), the client should raise BAD_PARAM.

    This will allow common marshal and demarshal code to be independent of
    whether it is running as a client or server. It also allows users to not
    configure
    wide character code sets if they know they aren't using them.

  • Reported: CPP 1.1 — Fri, 21 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    The check should be able to be done at invoke time by the client orb

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

Issue 1 -- resulting from Japanese comment JPN-009E:

  • Legacy Issue Number: 3623
  • Status: closed  
  • Source: Object Management Group ( Henry Lowe)
  • Summary:

    The Japanese would like to clarify the first sentence of the first
    paragraph of section 15.5.2, page 15-46, of CORBA 2.3.1 (this
    is clause 6.4.2 of DIS 19500-2, page 70) by adding the phrase
    "if Bi-Directional GIOP is not used" to the end of the sentence.
    The resulting sentence would read "Only the client (connection
    originator) may send Request, LocateRequest, and CancelRequest
    messages if Bi-Directional GIOP is not used."

    Is there any reason not to add this phrase now that Bi-Directional
    is in the OMG specification?

  • Reported: CPP 1.1 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Agree that this was an editorial oversight in corba 2.3.

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

Valuetype in anys. Unmarshaling problem?

  • Legacy Issue Number: 3434
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    There seems to be a problem with valuetypes contained in anys.

    Consider the following:
    valuetype A

    { A a; }

    ;

    valuetype B : A

    { private long long x; }

    ;

    If an instance w/ the following structure:

    A { a = {B { x = {<value>}}}}

    is inserted into an any and the any is received by an event service. Given that
    the event service has no type information of the B encoded inside of A, the
    event service has no way of knowing how big A.a (an instance of B) is and how
    many bytes it needs to read (unless it contacts an IR)

    Am I missing something here?

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

    Close this issue and place it into the GIOP wish list for future enhancements to GIOP.

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

GIOP encoding of nil Abstract Interface is unspecified

  • Legacy Issue Number: 2333
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 15.3.7 of 98-12-04 discusses the encoding of abstract
    interfaces, but neglects to mention how to encode an abstract
    interface whose value is nil.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    see above

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

.Passing the interface repository ID of the method in IIOP

  • Legacy Issue Number: 2031
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If we had a repository ID on the wire with every request, such errors could
    > be caught. In addition, it would make it substantially easier to build
    > tools such as IIOP packet tracers – right now, it is next to impossible
    > to dump the parameter values of IIOP requests because the packet tracer
    > has no way of figuring out what the type of the target object is.

    This could be added to IIOP in a reasonably non-invasive way, too. We
    could add a service context to the request which would carry the
    repository ID of the interface in which the method was defined

  • Reported: CORBA 2.2 — Mon, 5 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

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

TAG_ENDPOINT_ID_POSITION and TAG_LOCATION_POLICY

  • Legacy Issue Number: 1303
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is there any particular reason that we shouldn"t allow these two
    ComponentIds in IIOP IORs? They certainly can be useful using IIOP for
    optimization of client/server interactions, and can be safely ignored by
    clients that don"t implement/understand them.

    So could we add text to the spec that states that these components are
    allowed in IIOP IORs, but the clients are free to ignore them?

  • Reported: CORBA 2.2 — Mon, 4 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

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

Chunked GIOP marshalling for variable-length types

  • Legacy Issue Number: 1677
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Following the discussion of valuetype chunking in the OBV group, I"ve
    been thinking that the arguments advanced for it really apply to all
    the other variable-length types in CORBA (sequences and strings) as
    well as to OBV value types, and wonder if we might try a small change
    to the marshalling rules.

    Currently, we marshal a string (say) by sending the length of the
    string followed by the bytes of the string. If we don"t know the
    string"s length in advance, say because we are reading it from stdin
    or a subprocess, we need to buffer it in memory and send it as one big
    thing. That"s inefficient.

  • Reported: CORBA 2.2 — Tue, 14 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

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

Compacting GIOP messages by using indirections

  • Legacy Issue Number: 1130
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Repeated strings within an encapsulation can account
    for a large percentage of the size of the encapsulation.
    Indirections are already used in the marshaling of TypeCodes
    to allow compacting of messages. This can be extended
    to also allow indirection for strings. The current
    encoding of a string is the unsigned long number of characters
    in the string, followed by the null-terminated characters
    comprising the string. If we resolve the maximum value
    for unsigned long "0xffffffff" for indirections, the
    next byte can refer to a previously marshaled string.

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close previously deferred issue as too much for RTF. Add to GIOP future version "wish list".

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

Compacting GIOP Messages by using templates

  • Legacy Issue Number: 1131
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A common server pattern is that of "factory". As a result
    of a request, a Factory returns an object reference.
    Frequently, these object references differ only by a
    small fraction of their full size. For example, object
    references may be exactly the same except for the object_key
    member of a GIOP profile and maybe the repository_id field
    of the IOR. Allowing the factory to return a more compact
    representation of the object reference would yield great
    savings in message size.
    If the server or client can establish a template for filling
    out object references (or possibly any type of data), a
    more compact on-the-wire form can be used for such object
    references once the template is established.

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

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

Compacting GIOP Requests by hashing down operation names

  • Legacy Issue Number: 1132
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: As of GIOP/IIOP 1.1, a Request identifies the operation to
    be invoked as a string. If this can be compacting to
    an integral value, savings would be possible on all
    subsequent requests. A simple solution would involve
    a service context containing "operation name to index"
    mappings.

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" st

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

Optimization of LOCATION_FORWARD replies

  • Legacy Issue Number: 1133
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: As of GIOP/IIOP 1.1, if a server wants to have a client
    use some locally hashed down object_key in future requests
    for an object, it must require one of the following:
    a) the client use a LocateRequest in order for the server
    to reply with a forwarded object reference that has
    a hashed down object key.
    b) respond with an OBJECT_FORWARD reply to the request,
    forcing the client to remarshal the request with the
    new target (the forwarded object reference"s key).
    With some already recommended changes to GIOP 1.1,
    such a reply will only require remarshaling the
    message header, but an extra roundtrip is still required.

    This could be avoided by addind a new service context
    to the reply that contains the forward IOR, or a new
    Reply type such as NO_EXCEPTION_AND_FORWARD that
    indicates the first request has succeeded and that
    subsequent requests can use the supplied forward IOR.

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

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