Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA34-305 BiDir GIOP Policy Clarification CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-304 MAIN_THREAD_MODEL questions CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-177 Avoiding RSC/TSC copy on server side CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-178 Implications of any/valuetype marshalling CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-179 How does an ORB implement Object::get_policy for PI defined policies? CORBA 2.4.1 CORBA 3.4 Deferred 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
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-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
CORBA25-45 Null termination of strings CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-13 Introduction of identifiers CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-12 Type redefinition in derived interface CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-11 PortableServer::ObjectId CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-10 core issue: unchecked narrow CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-14 ForwardRequest from normal operations CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-3 POAManager::deactivate should not mandate ORB::shutdown implementation CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-2 POAManager::deactivate does not specify behavior for "reject" CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-6 CORBA::ORB::object_to_string() raising INV_OBJREF or BAD_PARAM CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-5 ServantLocator preinvoke/ postinvoke semantics CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-4 Minor code 2 description for OBJECT_NOT_EXIST not consistent w/ use CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-9 Container::lookup() ordering requirements CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-8 Section 2.1.7 of CORBA 2.3 and 2.4 CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-7 Legal IDL? CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA3-26 Clarify that each interception point executes in a distinct logical thread CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA3-25 Stateful boolean causes all CSI mechanisms to operate the same way. CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA3-24 ORB::shutdown vs. ORB::destroy CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA3-23 Encodings of Sequences of Certificates are not standard. CORBA 2.4.1 CORBA 3.0.2 Resolved closed

Issues Descriptions

BiDir GIOP Policy Clarification

  • Legacy Issue Number: 4115
  • Status: closed  
  • Source: Network Associates ( Brian Niebuhr)
  • Summary:

    I am a little confused as to the scope of the BiDirPolicy in the 2.4.1
    specification. Is the BiDirPolicy a POA policy, an ORB policy, or both? In
    section 15.8 paragraph 5 on page 15-55, the specification states:

    "If the client ORB policy permits bi-directional use
    of a connection, a Request message should contain an IOP::ServiceContext
    structure in its Request header, which indicates that this GIOP connection
    is bi-directional."

    but then in section 15.9 paragraph 4 on page 15-59, the specification
    states:

    "In the absence of a BidirectionalPolicy being passed in the
    PortableServer::POA::create_POA operation, a POA will assume a policy value
    of
    NORMAL."

    but then again in the next sentence the specification states:

    "A client and a server ORB must each have a BidirectionalPolicy with a value
    of
    BOTH for bi-directional communication to take place."

    Could someone clarify for me what the intent for the scope of the policy was
    here, and what the rationale behind that decision was? We are currently
    reviewing how to use/fix BiDirIIOP in our submission to the firewall RFP,
    and I would like to understand the issues regarding the scope of the BiDir
    policy.

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

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

MAIN_THREAD_MODEL questions

  • Legacy Issue Number: 4155
  • Status: closed  
  • Source: Borland Software Corporation ( Andy Cutright)
  • Summary:

    i have a few questions about the POA ThreadPolicy type
    MAIN_THREAD_MODEL.

    first, the 2.4.1 spec (00-11-03), sec 4.2.3.2 , 'perform_work' states,
    "If called by the main thread, this operation performs an
    implementation-defined unit of work; otherwise it does nothing."

    how is a distinguished main thread supposed to be reliably determined?
    i'm not sure we really need to define this. i'd think what we're trying
    to say is that the thread that calls perform_work() is the thread that
    will be used to do the work, and it is up to the application to make
    sure this happens. in section 4.2.3.3, the spec states,
    "For maximum portability an application should call either run or
    perform_work on its main thread."

    to me it seems the intent is to let the application determine what the
    'main thread' is.

    second, what happens if an application calls both run & perform_work?
    and what happens if the application calls run from multiple threads? it
    isn't really clear what the difference in request handling with regard
    to the thread used is between run() & perform_work().

    right now the spec seems to imply through the use of the message loop
    example in section 4.2.3.2 that perform_work is really intended to be
    used to handle situations where a single thread must be used for all
    application activity. now add to that the note on pg 11-12 about using
    the main thread model:
    "Note - Not all environments have such a special requirement. If
    not, while requests will be processessed sequentially, they may not all
    be processed on the same thread."

    my interpretation is that ORB::run would be used in cases where you
    simply want the POAs to be accessed sequentially, but the application
    doesn't care about which thread the implementation uses, but you would
    need to call perform_work to specifically hand the application defined
    main thread to process requests.

    my suggestion (finally ;^) is that we should state perform_work should
    be called, on whichever thread the application likes, if it wants to
    hand a specific thread to the ORB to do work. otherwise, calling
    ORB::run from any thread simply means the implementation is free to
    handle requests for servants associated with main thread model POAs on
    whatever thread the implementation may choose (including a new one), in
    keeping
    with the requirement that the requests be processed on each POA's
    servants sequentially..

    one more question: does it make sense to state that a callback type of
    architecture won't work when using this threading model?

  • Reported: CORBA 2.4.1 — Wed, 17 Jan 2001 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Avoiding RSC/TSC copy on server side

  • Legacy Issue Number: 4169
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    During the interceptor FTF we changed the server-side threading
    requirements such that all server-side points run in the same thread
    as the ServantManager and servant except receive_request_service_contexts.

    We attempted to update 21.4.4.4 "Request Scope vs Thread Scope"
    accordingly but knew we screwed the picture and wording up. So we
    punted to the RTF.

    The main problem with the current wording is that is forces a copy of
    of TSC/RSC before the servant manager and then receive_request are
    called. This is necessary because 21.4.4.5 item 5 says: "The
    receive_request points may modify the RSC, but this no longer affects
    the TSC."

    The only way to make RSC identical to TSC in receive_request with
    respect to reading but also have them be independent with respect to
    writing is to make a copy (which could be optimized to copy-on-write,
    but why?).

    I suggest we just state they are equivalent after
    receive_request_service_contexts.

    Here is a proposed revision to ptc/00-08-06 along these lines.

    Comments?
    Harold

    21.4.4.4 Request Scope vs Thread Scope

    ... On the server-side, the request scope PICurrent is attached to
    the ServerRequestInfo and follows the request processing. It is
    logically equivalent to the thread scope PICurrent after the list of
    receive_request_service_contexts interception points are processed.

    21.4.4.5 Flow of PICurrent between Scopes

    5. The ORB logically makes the RSC equivalent to the server-side TSC
    after the receive_request_service_contexts points are processed and
    before the servant manager is called. This TSC is within the context
    for both the receive_request points, the invocation of the servant
    manager, and the invocation of the target operation.

    The receive_request points are called. These points have access to the
    RSC. Modifying the RSC at this point makes corresponding
    modifications on the TSC. Since these points execute in the same
    thread as the target operation invocation, these points may modify the
    server-side TSC which makes corresponding modifications on the RSC.

    6. After the receive_request points are called, control transfers to
    the server threads which may also read and write this server-side TSC.
    Any modifications to the TSC makes corresponding modifications on the
    RSC.

    7. <No change>

    8. <DELETE THIS ITEM>

    9. The send interception points have access to the RSC (and the
    equivalent TSC) from which they may populate the reply service context
    list. After the invocation result is sent back to the client, the
    server-side RSC is logically destroyed.

    ...

    The picture would also need updating, but let's agree on wording first.

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

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Implications of any/valuetype marshalling

  • Legacy Issue Number: 4137
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    RE: CCM chapters document [orbrev] 99-10-04, section 61.6.2, page 61-45.
    The document citation indicates that the integrity of the valuetype –
    that is, the received marshalled state – is to be preserved in an
    ORB-mediated operation, even if that valuetype cannot be unmarshalled,
    either partially (truncated) or at all. If this value is then passed to
    another operation, the original marshalled state is to be transmitted.
    This preserves the transmitted object in its entirety, regardless of
    local implementation concerns. This is obviously necessary for bridges
    or event processing, such as through the notification service.

    So the question arises, what happens if you have a partial (truncated)
    unmarshall and the recipient application changes the local state of the
    valuetype through its attributes or local operations? How can/will you
    even know the state was changed? Do you ignore the changes and send the
    originally received marshalled stream, send only the new valuetype even
    though it is a truncation of the original, or "merge" the new values for
    the unmarshalled part followed by the original appended data for the
    truncated part? Should this third option be possible through an
    explicit ORB call – that is, the application is responsible to identify
    the change in state to the ORB? I assume that the semantics of
    "truncatable" must come to include the understanding that data in the
    truncatable portions may not be contextually dependent on the inherited
    parent of the valuetype.

    As a further question, is there a reason why this semantic
    interpretation should not be extended to be a general requirement rather
    than only with respect to transmission of anys? My experience has found
    that passing anys tends to be expensive and is avoided where it can be.
    A more general interpretation permits transmission of a comprehensive
    data structure among intermediate agents that only use (unmarshall) the
    information they need.

  • Reported: CORBA 2.4.1 — Fri, 5 Jan 2001 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How does an ORB implement Object::get_policy for PI defined policies?

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

    The description for Object::get_policy (in the Core, section 4.3.7.1)
    states:

    "The get_policy operation returns the policy object of the specified
    type (see Policy Object on page 4-32), which applies to this object. It
    returns the effective Policy for the object reference. The effective
    Policy is the one that would be used if a request were made."

    For a policy defined by PI, I don't see anyway for the ORB to implement
    this operation correctly, since there isn't any way for it to know how
    to properly resolve any client override policies with the policy
    information stored in the IOR.

    When a invocation is actually in process, the ClientRequestInterceptor
    can use the information available in the ClientRequestInfo interface to
    get the client override and the IOR policy data and do the correct
    resolution before continuing with the request. However,
    Object::get_policy() needs to do the same type of thing, but it has no
    invocation context to do it in.

    I think the same problem also applies to the implementation of
    ClientRequestInfo::get_request_policy().

    I think we need a new interception point to do this work. Something
    like:

    local interface PolicyInterceptor

    { any determine_effective_policy(in PolicyInfo pi); }

    ;

    local interface PolicyInfo

    { readonly attribute Object target; readonly attribute Object effective_target; readonly attribute IOP::TaggedProfile effective_profile; IOR::TaggedComponent get_effective_component (in IOP::ComponentId id); IOP_N::TaggedComponentSeq get_effective_components (in IOP::ComponentId id); }

    ;

    If this turns out to be an acceptable solution, then we should also
    change ClientRequestInfo to:

    local interface ClientRequestInfo : RequestInfo, PolicyInfo

    { ... }

    ;

    and remove the redundant operations.

  • Reported: CORBA 2.4.1 — Sat, 18 Nov 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 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

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

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

Null termination of strings

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

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

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

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

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

    Proposed Resolution:

    Change the above sentence in section 15.3.2.7 to:

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

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

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

    To close with clarification revision

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

Introduction of identifiers

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

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

    module Inner1

    { typedef string S1; }

    ;

    module Inner2

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

    ;

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

    module Inner2

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

    ;

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

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

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

    Close no change

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

Type redefinition in derived interface

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

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

    interface B

    { typedef string S; }

    ;
    interface D : B

    { typedef long S; }

    ;

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

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

    Proposed resolution:

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

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

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

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

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

    ;
    };

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

    Make the suggested change clarifying the inheritance case

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

PortableServer::ObjectId

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

    I propose that ObjectId be changed from:

    typedef sequence<octet> ObjectId;

    to:

    typedef CORBA::OctetSeq ObjectId;

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

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

    Incorporate changes and close issue

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

core issue: unchecked narrow

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

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

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

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

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

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

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

    Incorporate changes and close issue

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

ForwardRequest from normal operations

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

    interface Foo

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

    ;

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

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

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

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

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

    Incorporate change and close issue

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

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

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

    Section 11.3.2.6 has a paragraph that states:

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

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

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

    Right, make it so

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

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

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

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

    The spec states in section 11.3.2.6, paragraph 1.

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

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

    Proposal:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    see above, Close issue, already fixed

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

ServantLocator preinvoke/ postinvoke semantics

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

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

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

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

    Clarify the expected behavior if preinvoke raises an exception

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

Minor code 2 description for OBJECT_NOT_EXIST not consistent w/ use

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

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

    POAManager::incarnate failed to create POA.

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

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

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

    A - Section 11.2.6, paragraph 2

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

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

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

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

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

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

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

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

    incorporate change and close issue

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

Container::lookup() ordering requirements

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

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

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

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

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

Section 2.1.7 of CORBA 2.3 and 2.4

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

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

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

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

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

    incorporate change and close issue

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

Legal IDL?

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

    Is the following legal IDL?

    module M
    {
    abstract interface I

    { string s(); }

    ;

    valuetype V supports I

    { private string s; }

    ;
    };

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

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

    see below

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

Clarify that each interception point executes in a distinct logical thread

  • Key: CORBA3-26
  • Legacy Issue Number: 4173
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    To me the key word is "EACH" - in other words values set via
    PICurrent.set_slot in send_request are visible to other interceptors in
    that point and go into the RSC of client interceptors serving any
    requests made from within the interceptor(s). However, the TSC for
    receive_reply (etc) would have a clean PICurrent since it runs in its
    own logical thread.

    We should clarify this.

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

    Clarify as shown below

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

Stateful boolean causes all CSI mechanisms to operate the same way.

  • Key: CORBA3-25
  • Legacy Issue Number: 4167
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    The stateful boolean of the CSIIOP::CompoundSecMech forces all CSI
    mechanisms to behave the same way with respect to state retention. This is
    problematic and makes mechanisms parametric on the POA they are
    supporting. The retention of state is actually a function of an
    established transport, not a POA.

    Discussion:

    In the architecture (OMA) POA's are the 'owners' of object references.
    Therefore, the state retention boolean must be set there, as there is only
    one CompundSecMecList per object reference.

    You may have cases where multiple CSI mechanisms must support one POA.

    These mechanisms may span POA's as they may be defaults for many POA's. If
    state retention is parameterized on the particular mechanism, then
    negotiating the state retention for each mechanism becomes easier to
    handle, as the state retention algorithm is mechanism specific. Therefore,
    that mechanism may operate independently of knowing the POA.

    This makes the TSS mechanisms to be able to work independently of the POA
    policy.

    Also, for another reason, CSI state retention is based on the established
    transport, which has nothing to do with a POA, therefore it is part of the
    CSI mechanism over which the transport it is working.

    I think the purpose for the "stateful" boolean was ill conceived. It was
    thought of by some as a deficiency in your implementation and you needed
    to provide a single boolean so one could RED FLAG a security service
    "inferior" in some sense.

    The fact is that state retention can be inefficient in some cases. State
    retention is actually parameter that is a function of the mechanism over a
    particular transport mechanism. One may want to use mechanisms that retain
    their state where one makes lots of invocations over a single transport
    (long live connections). (State retention is a function of transport).
    Short lived connections need not incur the overhead.

    Proposed Solution:

    Move the stateful field, as follows:

    module CSIIOP {
    // type used in the body of a TAG_CSI_SEC_MECH_LIST component to describe a
    // compound mechanism

    struct CompoundSecMech

    { AssociationOptions target_requires; IOP::TaggedComponent transport_mech; AS_ContextSec as_context_mech; SAS_ContextSec sas_context_mech; boolean stateful; }

    ;

    // type corresponding to the body of a TAG_CSI_SEC_MECH_LIST component

    struct CompoundSecMechList

    { sequence <CompoundSecMech> mechanism_list; }

    ;

    };

  • Reported: CORBA 2.4.1 — Mon, 22 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    CLOSE NO CHANGE

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

ORB::shutdown vs. ORB::destroy

  • Key: CORBA3-24
  • Legacy Issue Number: 4164
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    The CORBA 2.3 spec says under ORB shutdown:

    Once an ORB has shutdown, only object reference management
    operations(duplicate, release and is_nil) may be invoked on the ORB or
    any object reference obtained from it. An application may also invoke
    the destroy operation on the ORB itself. Invoking any other operation
    will raise the BAD_INV_ORDER system exception with the OMG minor code 4.

    This implies that calling ORB::shutdown also terminates the client
    side processing. I think that this wrong. I believe that ORB::shutdown
    should terminate server side processing. ORB::destroy should terminate
    the client side processing.

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

    close no change

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

Encodings of Sequences of Certificates are not standard.

  • Key: CORBA3-23
  • Legacy Issue Number: 4156
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Explicit ASN.1 definitions of a sequence of certificates make a single
    ASN.1 object out of the certificates. This approach is not what most
    systems use today.

    Discussion:

    The CSI::ITTX509CertChain and the CSI::X509AttributeCertChain both
    stipulate that the encodings of these "chains" be a single ASN.1 encoded
    object. Sequences of certificates usually come in the form of a byte
    stream of either ASN.1 DER encoded objects, or PEM encoded objects, (i.e.
    Base64 encodings wrapped with "---BEGIN CERTIFICATE--", "---END
    CERTIFICATE---" lines). It would be ideal to be able to handle both of
    kinds these sequences, since many toolkits work this way already.

    Tool kits that are provided in OpenSSL and Java, namely,
    java.security.cert.CertificateFactory will not be able to handle the
    encoding brought forth by the CSIv2 specification. However, the toolkits
    will be able to handle a stream sequence of ASN.1 or even PEM encoded
    objects, i.e. without the ASN.1 SEQUENCE wrapper.

    Proposed Solution:

    Eliminate the ASN.1 definitions in the specification, namely para 50 that
    defines ASN.1 syntax for a certificate chain (i.e. "CertificateChain"),
    and para 33 thru 34 for the corresponding one that fits the
    AttributeCertificate(i.e. AttributeCertChain and VerifyingChain).

    Furthermore, I believe, that the definition of CSI:ITTX509CertChain be
    eliminated in favor of a single OID that forms a GSS_NT_ExportedName type,
    in which it's name component is simply a non-empty sequence of
    certificates (in any form), as well as creating an OID that stipulates a
    supported name type is a DN, ASN.1 encoded or string form.

  • Reported: CORBA 2.4.1 — Thu, 18 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The proposed change is backward incompatible. Close no change

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