Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — Open Issues

  • Acronym: CORBA
  • Issues Count: 44
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA34-209 CORBA 3.02, page 11-25, section 11.3.6 CORBA 3.0.2 open
CORBA34-210 Section 22.2.4.6 interface RelativeRoundtripTimeoutPolicy CORBA 3.0.2 open
CORBA34-211 valuetypes and local interfaces CORBA 3.0.2 open
CORBA34-201 restriction of where a valuetype chunk can end CORBA 3.0.2 open
CORBA34-202 Bad text in 22.6 mandates Routing for sendc/sendp CORBA 3.0.2 open
CORBA34-197 Mapping from -ORBxxx to Java properties does not work for -ORBInitRef CORBA 3.0.2 open
CORBA34-198 BNF changes CORBA 3.0.2 open
CORBA34-199 rules for marshalling ValueBoxes CORBA 3.0.2 open
CORBA34-200 Problem with ServerRequestInterceptor::receive_request and DSI CORBA 3.0.2 open
CORBA34-95 LWCCM issue - Section 1.5.3 Exclusion CORBA 3.0.2 open
CORBA34-59 Section 6.4.5.26 and Section 6.4.5.30 should be moved to section 6.3 CORBA 3.0.2 open
CORBA34-60 Section 6.4.5.10 (page 6-26) CORBA 3.0.2 open
CORBA34-61 Section 6.4.5.52 (page 6-38) CORBA 3.0.2 open
CORBA34-62 CCM spec: insufficient examples of component attributes CORBA 3.0.2 open
CORBA34-64 multiple lifetime policies declaration issue CORBA 3.0.2 open
CORBA34-65 CCM IDL style inconsistency CORBA 3.0.2 open
CORBA34-56 'local executor mapping' CORBA 3.0.2 open
CORBA34-57 CCM Spec: attributes are listed in the ports section? CORBA 3.0.2 open
CORBA34-58 issue on component supporting abstract interfaces CORBA 3.0.2 open
CORBA34-53 HomeExecutorBase should have a get_servant method CORBA 3.0.2 open
CORBA34-55 portability of CCM descriptors CORBA 3.0.2 open
CORBA34-50 HomeExecutorBase should have a get_servant method CORBA 3.0.2 open
CORBA34-51 EnterpriseComponent should have a get_servant method CORBA 3.0.2 open
CORBA34-52 The association of entity component primary key and PSS key is unclear CORBA 3.0.2 open
CORBA34-31 CCMHome should have a get_components method CORBA 3.0.2 open
CORBA34-32 CCMHome should have a get_container method CORBA 3.0.2 open
CORBA34-30 Session2Context interface CORBA 3.0.2 open
CORBA34-29 HomeConfigurator should not extend CCMHome CORBA 3.0.2 open
CORBA34-27 Generic port connections CORBA 3.0.2 open
CORBA34-28 LwCCM issue - Section 1.6.8 Exclusion CORBA 3.0.2 open
CORBA34-26 LwCCM issue - Section 1.4.3.3 Exclusion CORBA 3.0.2 open
CORBA34-25 Interface Introspection CORBA 3.0.2 open
CORBA34-22 GIOP Conformance and Interceptors CORBA 3.0.2 open
CORBA34-23 Change new GIOP Negotiate Session Message to Firewall Specific CORBA 3.0.2 open
CORBA34-24 CodeSet and CSIv2 Negotitaion CORBA 3.0.2 open
CORBA34-20 page 1-20 the description of the get_connection operation CORBA 3.0.2 open
CORBA34-18 page 1-20 second bullet of the description of the disconnect operation CORBA 3.0.2 open
CORBA34-21 context interface for home implementation CORBA 3.0.2 open
CORBA34-19 page 1-20 and page 1-21 - editorial CORBA 3.0.2 open
CORBA34-17 Chapter/section: 15.4.2.2 "Request Body" CORBA 3.0.2 open
CORBA34-16 [Components] Contradiction between IDL and Interface Repository concerning CORBA 3.0.2 open
CORBA34-15 15.3.3 - codesets must be "explicitly defined" CORBA 3.0.2 open
CORBA34-14 Clarification on multi-threaded codeset negotiation CORBA 3.0.2 open
CORBA34-13 valuetype fragmentation ambiguous CORBA 3.0.2 open

Issues Descriptions

CORBA 3.02, page 11-25, section 11.3.6

  • Legacy Issue Number: 6899
  • Status: open  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    Fifth bullet near the beginning of this section states:

    Incarnations of a particular object may not overlap; that is, incarnate shall not be invoked with a particular ObjectId while, within the same POA, that ObjectId is in use as the ObjectId of an activated object or as the argument of a call to incarnate or etherealize that has not completed.

    Unfortunately, I do not see anywhere where the exception to be thrown from activate_object_with_id() for this case is specified. According to this text, if incarnate() is executing for a particular ObjectId, any calls to activate_object_with_id() should be rejected by the POA. This came up in comp.object.corba, where someone posted a question as to why Orbix 2000 throws the ObjectAlreadyActive exception for this case.

  • Reported: CORBA 3.0.2 — Mon, 12 Jan 2004 05:00 GMT
  • Updated: Mon, 18 Feb 2019 00:01 GMT

Section 22.2.4.6 interface RelativeRoundtripTimeoutPolicy

  • Legacy Issue Number: 6424
  • Status: open  
  • Source: Borland Software Corporation ( Wolfgang Haefelinger)
  • Summary:

    [..] It is used to indicate the relative amount
    of time for which a Request or its corresponding
    Reply may be delivered. After this amount of
    time, the Request is cancelled (if a response
    has not yet been received from the target) or
    the Reply is discarded (if the Request had
    already been delivered and a Reply returned from
    the target) [..]
    ---------------------------------------------------------
    Question:

    • What is the precise meaning of "Request is
      cancelled"?

    Does it mean that client ORB just gives up or
    does it mean that client tries, in kind of best
    effort semantics, to cancel request on server?

    If this cancellation fails, how will client user
    be informed about this? By a minor code in
    thrown Timeout exception?

    Is it possible to clarify this?

  • Reported: CORBA 3.0.2 — Wed, 29 Oct 2003 05:00 GMT
  • Updated: Mon, 18 Feb 2019 00:01 GMT

valuetypes and local interfaces

  • Legacy Issue Number: 6318
  • Status: open  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    The spec appears silent as to whether valuetypes are allowed to support local interfaces. Table 3-10, for example, says nothing at all about local interfaces.

    There's a couple ways to look at this. First, valuetypes are not CORBA objects. Servants for local interfaces are direct CORBA object instances, i.e., the "local" declaration on an interface effectively removes the distinction between a CORBA object and its servant. If a valuetype were used as a servant for a local object, then the valuetype would itself also be a CORBA object. By this analysis, valuetypes should not be allowed to support local interfaces.

    Another way to look at it is that the valuetype should just inherit the local interface's operations and attributes without having any subtype/subclass relationship with the base local interface. This would be a rather pointless approach to take, is there would be no possibility of using the valuetype polymorphically with respect to the base local interface.

  • Reported: CORBA 3.0.2 — Thu, 16 Oct 2003 04:00 GMT
  • Updated: Mon, 18 Feb 2019 00:01 GMT

restriction of where a valuetype chunk can end

  • Legacy Issue Number: 5892
  • Status: open  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    There is a small issue with the restriction of where a valuetype chunk can end. The spec says

    "The data may be split into multiple chunks at arbitrary points except within primitive CDR types, arrays of primitive types, strings, and wstrings, or between the tag and offset of indirections. It is never necessary to end a chunk within one of these types as the length of these types is known before starting to marshal them so they can be added to the length of the currently open chunk."

    However, in the case of array of wchar, the length is not known before starting to marshal, since each char (in GIOP 1.2 and 1.3) is marshalled as a (sort-of) sequence of octets. I think it should be legal to end a valuetype chunk in the middle of an array of char.

  • Reported: CORBA 3.0.2 — Wed, 26 Mar 2003 05:00 GMT
  • Updated: Mon, 18 Feb 2019 00:01 GMT

Bad text in 22.6 mandates Routing for sendc/sendp

  • Legacy Issue Number: 5856
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There is a sentence in the first paragraph of 22.6 that should be fixed:

    "The implementation of these methods must generate a method invocation
    as described in Section 22.14, Message Routing, on page 22-50."

    However, 22.2.5.3 allows asynchronous invocations to be delivered via
    synchronous protocols if the RoutingPolicy is ROUTE_NONE.

    This sentence should be changed to:

    "The implementation of these methods may generate a method invocation as
    described in Section 22.14, Message Routing, on page 22-50, depending
    on the effective RoutingPolicy for the invocation."

  • Reported: CORBA 3.0.2 — Tue, 11 Feb 2003 05:00 GMT
  • Updated: Mon, 18 Feb 2019 00:01 GMT

Mapping from -ORBxxx to Java properties does not work for -ORBInitRef

  • Legacy Issue Number: 6007
  • Status: open  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The CORBA 3.0 spec adds the following note in Section 4.5.1: ORB Initialization.

    "Whenever an ORB_init argument of the form -ORBxxx is specified, it is understood that the argument may be represented in different ways in different languages. For example, in Java -ORBxxx is equivalent to a property named org.omg.CORBA.ORBxxx."

    The approach stated in the above note does not work for -ORBInitRef. For example, if you have
    -ORBInitRef NameService=URL,
    you cannot translate the above arguments into a property named "org.omg.CORBA.ORBInitRef" because there can be only one property of this name and there may be many different services. This issue was slightly cover by Issue 3643 (java-rtf), which was not resolved. This issue becomes obvious and important because the note added in the CORBA 3.0 spec.

    Proposed solution: Arguments like "-ORBInitRef id=url" should be equivalent to a property named "org.omg.CORBA.ORBInitRef.id" with value "url".

  • Reported: CORBA 3.0.2 — Sat, 19 Jul 2003 04:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

BNF changes

  • Legacy Issue Number: 5952
  • Status: open  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    BTW I think the twiddle is incomplete because it is not reflected
    in the BNF for Identifier. I think it is better if the BNF always
    reflects the ultimate specification of a language's lexical
    definition. Otherwise compiler writers are apt to miss the
    subtleties.
    I'll propose some BNF changes if others agree

  • Reported: CORBA 3.0.2 — Wed, 25 Jun 2003 04:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

rules for marshalling ValueBoxes

  • Legacy Issue Number: 5899
  • Status: open  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    The GIOP specification does not say anything at all about the rules for marshalling ValueBoxes.

    I believe the expected format is to marshal ValueBoxes as if they were a normal Value with a single member, and that they follow the normal rules about indirections and chunking. The spec should clearly state this.

  • Reported: CORBA 3.0.2 — Wed, 16 Apr 2003 04:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

Problem with ServerRequestInterceptor::receive_request and DSI

  • Legacy Issue Number: 5895
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    21.3.9.2 states:

    "In the DSI model, since the parameters are first available when the user code calls arguments, receive_request is called from within arguments. It is possible that arguments is not called in the DSI model. The target may call set_exception before calling arguments. The ORB shall guarantee that receive_request is called once, either through arguments or through set_exception."

    The problem here, is that the DSI servant has already been invoked at this point, and the DSI implementation will be unaware that the server interceptor may have cancelled the invocation via raising a system exception or ForwardRequest user exception. So the DSI implementation will carry on, creating all sorts of wonderful havoc as it continues to interact with the ServerRequest PO.

    Any vendors want to comment on what their PI implementation does now?

    Proposed fix:

    First, we should define a new system exception minor code that the servant implementation can detect so that it can clean up and get out of the way as expeditiously as possible when raised by arguments or set_exception. Perhaps a minor code for OBJ_ADAPTER? Should there be two minor codes, to distinguish a system exception from ForwardRequest as the reason for cancelling the invocation?

    Second, we need some more text either in chapter 8 or 21 that states that any calls by the DSI implementation to ServerRequest::set_result or ServerRequest::set_exception will be ignored (or perhaps reraise the exception defined in the previous paragraph) if ServerRequestInterceptor::receive_request raises an exception.

  • Reported: CORBA 3.0.2 — Wed, 2 Apr 2003 05:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

LWCCM issue - Section 1.5.3 Exclusion

  • Key: CORBA34-95
  • Legacy Issue Number: 6254
  • Status: open  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    On page 11: The Normative Impact "Disable get_connections, get_all_receptacles, get_named_receptacles operations in the Receptacles interface" does not match the Document Impact: "Section 1.5.3: remove". Removal of section 1.5.3 removes the Receptacles interface in it entirety, including the description of the generic connect and disconnect operations, which are referred to by comment in the previous item. The Document Impact needs to be narrowed.

  • Reported: CORBA 3.0.2 — Tue, 16 Sep 2003 04:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

Section 6.4.5.26 and Section 6.4.5.30 should be moved to section 6.3

  • Key: CORBA34-59
  • Legacy Issue Number: 5903
  • Status: open  
  • Source: Tech-X ( Nanbor Wang)
  • Summary:

    To maintain a consistent style and to provide a detailed
    description in an XML element's first appearance, Section 6.4.5.26
    and Section 6.4.5.30 should be moved under Section 6.3 and changed
    to referring them back to the corresponding subsections like
    Section 6.4.5.29 does.

  • Reported: CORBA 3.0.2 — Fri, 18 Apr 2003 04:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

Section 6.4.5.10 (page 6-26)

  • Key: CORBA34-60
  • Legacy Issue Number: 5902
  • Status: open  
  • Source: Tech-X ( Nanbor Wang)
  • Summary:

    Section 6.4.5.10 (page 6-26): one of the child elements of the
    "containermanagedpersistence" element is "psstransactionpolicy" where
    it should have been "psstransaction" instead (see Section 6.4.5.40
    on page 6-34 and Section 7.2 on page 7-6 and 7-7).

  • Reported: CORBA 3.0.2 — Fri, 18 Apr 2003 04:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

Section 6.4.5.52 (page 6-38)

  • Key: CORBA34-61
  • Legacy Issue Number: 5900
  • Status: open  
  • Source: Tech-X ( Nanbor Wang)
  • Summary:

    1. Section 6.4.5.52 (page 6-38): It says the the "storagehome" element
    is a child element of "segment" where it should really say it is a
    child element of "containermanagedpersistence" instead.

  • Reported: CORBA 3.0.2 — Fri, 18 Apr 2003 04:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

CCM spec: insufficient examples of component attributes

  • Key: CORBA34-62
  • Legacy Issue Number: 5898
  • Status: open  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

    In OMG document formal/02-06-65, in section "1.3.3 Component Body", there
    is this text:

    "Declarations for facets, receptacles, event sources, event sinks,
    and attributes all map onto operations on the component's equivalent
    interface. These declarations and their meanings are described in
    detail below."

    In the following sections, I see facets, receptacles, event sources,
    and event sinks described, but I see no mention of attributes.
    It would be usefult to have an example of attributes in an appropriate
    place, as outlined by section 1.3.3.

    In section "1.10 Configuration with Attributes", I see that configurators
    are described, but I see no example of using attributes directly
    to configure a component.

    It would be very useful to include a small example to illustrate
    how to configure a component directly by using attributes.

    Diego Sevilla Ruiz <dsevilla@ditec.um.es> gave this
    C++ example on the CCM mailing list ( http://moriarty.dif.um.es/mailman/listinfo/ccm ):

    ======================================================

    component Whatever

    { attribute long cacheMaxKb; }

    ;

    home WhateverHome manages Whatever
    {
    };

    // C++
    WhateverHome_var weh = // obtain ref
    Whatever_var we = weh->create();

    we->cacheMaxKb(200);

    we->configuration_complete();

    ======================================================

    I don't suggest that this example be used verbatim,
    but a similar example would be useful to have in the
    CCM spec.

  • Reported: CORBA 3.0.2 — Thu, 10 Apr 2003 04:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

multiple lifetime policies declaration issue

  • Key: CORBA34-64
  • Legacy Issue Number: 5870
  • Status: open  
  • Source: INRIA ( Nawel Sabri)
  • Summary:

    In section 4.2.5 of the CCM spec formal/02-06-65, it is said that "Servant lifetime policies may be defined for each segment within a component", but there is no way to do it. Lifetime policy is declared in the CCD descriptor of the component, as an attribute of the "servant" XML element, and is implicitly applied on all the segments of the component(when it is segmented) !

    Suggested resolution: to leave the servant element as it is, expressing a DEFAULT lifetime policy, and to add the same servant element as an optional child of the segment element. This will specify the lifetime policy of the segment and override the defautl one. DTD has to be changed as follows :

    <!ELEMENT segment
    ( segmentmember+
    , containermanagedpersistence?
    , extension*
    >
    <!ATTLIST segment
    name CDATA #REQUIRED
    segmenttag CDATA #REQUIRED >

    becomes:

    <!ELEMENT segment
    ( segmentmember+
    , servant?
    , containermanagedpersistence?
    , extension*
    >
    <!ATTLIST segment
    name CDATA #REQUIRED
    segmenttag CDATA #REQUIRED >

  • Reported: CORBA 3.0.2 — Tue, 25 Feb 2003 05:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

CCM IDL style inconsistency

  • Key: CORBA34-65
  • Legacy Issue Number: 5858
  • Status: open  
  • Source: Anonymous
  • Summary:
    • document : formal/02-06-65
    • chapter : 1.5.2.4
    • text in question :

    module Components
    {
    valuetype Cookie

    { private CORBA::OctetSeq cookieValue; }

    ;
    };

    • Issues :

    1. Naming style used in this definition violates rules defined in
    "OMG IDL Style Guide" (ab/98-06-03).

    2. Naming style used in this definition is inconsistent with other parts
    of the CCM IDL, for example:

    module Components
    {
    valuetype PortDescription

    { public FeatureName name; public CORBA::RepositoryId type_id; }

    ;

    valuetype FacetDescription : PortDescription

    { public Object facet_ref; }

    ;
    }

    • suggested resolution : replace `cookieValue' with `cookie_value'
  • Reported: CORBA 3.0.2 — Wed, 12 Feb 2003 05:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

'local executor mapping'

  • Key: CORBA34-56
  • Legacy Issue Number: 5937
  • Status: open  
  • Source: Anonymous
  • Summary:

    @@ It seems to me that generating 'local executor mapping' for supported
    by a component interfaces is not needed. Even though spec doesn't say
    directly that it's needed or not there are plenty of examples where it is
    shown generated.

    @@ According to the spec the following IDL is valid

    interface I;
    component C

    { provides I i; };


    while this is not:


    interface I;
    component C
    { uses I i; };


    Any reason for that?


    @@ According to the spec Home cannot be forward-declared. Any reason
    for that?



    @@ The following CIDL is legal according to the spec:


    interface I;
    component C
    { provides I i; }

    ;

    home H manages C
    {
    };

    composition session Impl
    {
    home executor H_Exec

    { implements H; manages C_Exec; };
    };


    However there is no way to generate valid local executor mapping for this
    CIDL. The resolution would be to require all forward-declared interfaces
    used by component's provides declarations to be defined before composition
    for this component is seen. I.e. the following CIDL would be a corrected
    version:


    interface I;
    component C
    { provides I i; };


    home H manages C
    {
    };


    interface I {};


    composition session Impl
    {
    home executor H_Exec
    { implements H; manages C_Exec; }

    ;
    };

    @@ The following legal according to the spec IDL:

    module M
    {
    module Components
    {
    struct EnterpriseComponent {};
    };

    component C {};
    };

    would result in local executor mapping that looks something like this:

    module M
    {
    module Components
    {
    struct EnterpriseComponent {};
    };

    component C {};
    };

    module M
    {
    local interface C : Components::EnterpriseComponent {};
    };

    which is illegal IDL. The resolution would be to require names like
    Components::EnterpriseComponent to be fully qualified e.g.
    ::Components::EnterpriseComponent.

  • Reported: CORBA 3.0.2 — Wed, 7 May 2003 04:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

CCM Spec: attributes are listed in the ports section?

  • Key: CORBA34-57
  • Legacy Issue Number: 5918
  • Status: open  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

    In section 1.1.2 of the CCM specification:

    1.1.2 Ports
    ===========
    ..... The component model supports four basic kinds of ports:

    • Facets
    • Receptacles
    • Event sources
    • Event sinks
    • Attributes

    Well, that list includes five things, not four.

    So, is an attribute considered a port or not?

    The wording in this section needs to be clarified in the CCM
    specification, because it is not clear if an attribute
    is a port or not.

  • Reported: CORBA 3.0.2 — Mon, 28 Apr 2003 04:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

issue on component supporting abstract interfaces

  • Key: CORBA34-58
  • Legacy Issue Number: 5910
  • Status: open  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    The following information is sent in order for the specification to
    clearly state if components and local interfaces can support abstract
    interfaces (the specification is confusing on this point).

    CORBA 3.0.1 does not explicitely states if a component can support an
    abstract interface, thus it can be considered that it is possible. If so
    a big problem arises as local interfaces inheriting abstract ones is
    confusing in the specification.

    In addition, it is neither explicitely stated that provides and uses
    declarations can or cannot be of types defined through abstract
    interfaces. It does not seem to make sense for a port to be an abstract
    type. Facets will never be used by value, and an operation cannot
    (should not) return the reference of a facet or a valuetype (which would
    be in favor of provides to be defined using abstract interfaces).

      • Problem

    Consider the following definitions which are correct regarding
    formal/02-12-06:

    /* omg idl3 */

    abstract interface I

    { void foo () ; } ;


    component C supports I {
    } ;


    The mapping to OMG IDL2 of these definitions is not correct right now as
    they become:


    /* omg idl2 */


    abstract interface I { void foo () ; }

    ;

    interface C : Components::CCMObject, I { } ;

    local interface CCM_C : I { } ;

    According to formal/02-12-06, the last line may not be correct. Local
    interfaces may not inherit abstract interfaces (section 10.5.28). (I use
    may as it is confusing and can lead to various understanding of the
    spec.)

      • Potential solutions:

    1. State in the CORBA 3.0.1 that components cannot support abstract
    interfaces. In favor: Could ne considered as a minor change. Against: a
    component reference cannot be returned by an operation that can return
    an object by value or by reference. This solution looks cleaner that the
    second one from a software engineering point of view.

    2. Clearly state that components and local interfaces can support
    abstract interfaces. This use may be surprising from a software
    engineering point of view, but may be important for some users. This
    bring back the debate "quality vs powerfulness".

    In any case, I think it should be clearly stated if local interfaces may
    or may not inherit abstract ones.

  • Reported: CORBA 3.0.2 — Wed, 23 Apr 2003 04:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

HomeExecutorBase should have a get_servant method

  • Key: CORBA34-53
  • Legacy Issue Number: 6673
  • Status: open  
  • Source: National Lab. on Distributed Processing of P.R.China ( Deng Bo)
  • Summary:

    The HomeExecutorBase should have a get_servant method. When creating component or facet reference of service or session component, the first step is creating the object reference and associating its PortableServer::ObjectId with servant. Currently, the container manages executor, but the HomeExecutorBase interface does not provide a mechanism to get servant. The method would be very useful as it means the container can use executor to get servant, which is not possible now.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-40

    module Components { local interface HomeExecutorBase {}; };

    with

    module Components { local interface HomeExecutorBase

    { Servant get_servant() raises (CCMException); }

    ; };

    and add the operation description

    get_servant

    The get_servant operation returns a reference to the servant.

  • Reported: CORBA 3.0.2 — Thu, 4 Dec 2003 05:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

portability of CCM descriptors

  • Key: CORBA34-55
  • Legacy Issue Number: 6286
  • Status: open  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Sylvain Leblanc)
  • Summary:

    Identifier (FPI).

    These FPIs are required for the CAD, CSD, CCD and CPF DTDs.

    Proposed resolution:

    Adds the CCM DTDs on the OMG web site and adds the following text in the specification:

    • section 6.3, before subsection 6.3.1 :

    The CORBA Software Descriptor must refer to the DTD using the following statement: <!DOCTYPE softpkg PUBLIC "-//OMG//DTD CORBA Software Descriptor 3.0//EN" "http://www.omg.org/dtd/softpkg_3_0.dtd" />

    • section 6.4, before subsection 6.4.1 :

    The CORBA Component Descriptor must refer to the DTD using the following statement: <!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "http://www.omg.org/dtd/corbacomponent_3_0.dtd" />

    • section 6.4.4:

    replace

    <!DOCTYPE corbacomponent SYSTEM "corbacomponen.tdtd">

    with

    <!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "http://www.omg.org/dtd/corbacomponent_3_0.dtd" />

    • section 6.7, before subsection 6.7.1 :

    The Component Assembly Descriptor must refer to the DTD using the following statement: <!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "http://www.omg.org/dtd/componentassembly_3_0.dtd" />

    • section 6.7.1:

    replace

    <!DOCTYPE componentassembly SYSTEM "componentassembly.dtd">

    with

    <!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "http://www.omg.org/dtd/componentassembly_3_0.dtd" />

    • section 6.8, before subsection 6.8.1 :

    The Component Property File must refer to the DTD using the following statement: <!DOCTYPE properties PUBLIC "-//OMG//DTD Component Property File 3.0//EN" "http://www.omg.org/dtd/properties_3_0.dtd" />

  • Reported: CORBA 3.0.2 — Wed, 1 Oct 2003 04:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

HomeExecutorBase should have a get_servant method

  • Key: CORBA34-50
  • Legacy Issue Number: 6689
  • Status: open  
  • Source: Anonymous
  • Summary:

    This question is similar to the first one. When creating component or
    facet reference of service or session component, the first step is
    creating the object reference and associating its
    PortableServer::ObjectId with servant. Currently, the container manages
    executor, but the HomeExecutorBase interface does not provide a
    mechanism to get servant. The method would be very useful as it means
    the container can use executor to get servant, which is not possible now.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-40

    module Components {
    local interface HomeExecutorBase {};
    };

    with

    module Components {
    local interface HomeExecutorBase

    { Servant get_servant() raises (CCMException); }

    ;
    };

    and add the operation description

    get_servant

    The get_servant operation returns a reference to the servant.

  • Reported: CORBA 3.0.2 — Fri, 5 Dec 2003 05:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

EnterpriseComponent should have a get_servant method

  • Key: CORBA34-51
  • Legacy Issue Number: 6688
  • Status: open  
  • Source: Anonymous
  • Summary:

    When creating component or facet reference of service or session
    component, the first step is creating the object reference and
    associating its PortableServer::ObjectId with servant. Currently, the
    container manages executor, but the EnterpriseComponent interface does
    not provide a mechanism to get servant. The method would be very useful
    as it means the container can use executor to get servant, which is not
    possible now.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-39

    module Components {
    local interface EnterpriseComponent {};
    };

    with

    module Components {
    local interface EnterpriseComponent

    { Servant get_servant() raises (CCMException); }

    ;
    };

    and add the operation description

    get_servant

    The get_servant operation returns a reference to the servant.

  • Reported: CORBA 3.0.2 — Fri, 5 Dec 2003 05:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

The association of entity component primary key and PSS key is unclear

  • Key: CORBA34-52
  • Legacy Issue Number: 6684
  • Status: open  
  • Source: National Lab, Distributed Process, China ( Deng Bo)
  • Summary:

    Issue: The association of entity component primary key and PSS key is unclear. There is only one attribute as the primary key in the CCM entity component, PSS has no primary key. An entity can be identified uniquely by the PSS key, but currently PSS permits several keys, and each PSS key can be composed of several attributes. Consequently, it is difficult to establish association between entity component primary key and PSS key, and the create and find methods can not to be mapped to the corresponding methods of PSS.

  • Reported: CORBA 3.0.2 — Sat, 6 Dec 2003 05:00 GMT
  • Updated: Mon, 18 Feb 2019 00:00 GMT

CCMHome should have a get_components method

  • Key: CORBA34-31
  • Legacy Issue Number: 6438
  • Status: open  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    The CCMHome interface does not provide a mechanism for obtaining references to all CCMObjects that the home has created (those that have not been removed). The lack of a method to get all the components created by a home is inconsistent with other sections of the CCM model (specifically the deployment module APIs). Furthermore, this method would be very useful as it would provide a mechanism for querying a Container for all existent components.

    Resolution:

    Replace the following text in formal/02-06-05 on page 1-41

    interface CCMHome

    { CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); }

    ;

    with

    typedef sequence<CCMObject> CCMObjects;

    interface CCMHome

    { CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); CCMObjects get_components(); }

    ;

    and add the operation description

    get_components

    The get_components operation returns a sequence of all existent CCMObject references (i.e. those that have not been removed) created by this CCMHome.

  • Reported: CORBA 3.0.2 — Wed, 5 Nov 2003 05:00 GMT
  • Updated: Sun, 17 Feb 2019 23:56 GMT

CCMHome should have a get_container method

  • Key: CORBA34-32
  • Legacy Issue Number: 6001
  • Status: open  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    The CCMHome interface does not provide a mechanism for locating the container that created a home. The lack of a method to get a home's container is inconsistent with the rest of the CCM model. Furthermore, this method would be very useful as it would provide a means to navigate from a component to its ServerActivator, which is currently not possible.

    Resolution:

    Replace the following text in formal/02-06-05 on page 1-41

    interface CCMHome

    { CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); }

    ;

    with

    interface CCMHome

    { CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); Container get_container(); }

    ;

    and add the operation description

    get_container

    The get_container operation returns a reference to the Container object that created this CCMHome

  • Reported: CORBA 3.0.2 — Thu, 17 Jul 2003 04:00 GMT
  • Updated: Sun, 17 Feb 2019 23:56 GMT

Session2Context interface

  • Key: CORBA34-30
  • Legacy Issue Number: 5909
  • Status: open  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    The Session2Context interface allows developers to create an object reference from an octet sequence (object id). The the Entity2Context allows developers to create an object reference from a ComponentId. Neither the Session2Context nor the the Entity2Context allows the developer to infer the octet sequence or ComponentId that is associated with an operation invocation on a component. In other words, a developer may use a context to create multiple references that are subsequently invoked by a client. When the client invokes an operation on the reference the component code will be required to satisfy the operation invocation (either through the monolithic or the locator language mapping strategy). There is no information, however, as to which of the created references is being invoked by a client. To resolve the ambiguity the component developer must be able to use the context to provide the current octet sequence or ComponentId corresponding to the reference that is currently being invoked.

    Resolution:

    Replace the following text in formal/02-06-05 on page 4-37

    local interface Session2Context : SessionContext, CCM2Context

    { Object create_ref (in CORBA::RepositoryId repid); Object create_ref_from_oid ( in PortableServer::ObjectIdCORBA::OctetSeq oid, in CORBA::RepositoryId repid); PortableServer::ObjectId CORBA::OctetSeq get_oid_from_ref (in Object objref) raises (IllegalState, BadComponentReference); }

    ;

    with

    local interface Session2Context : SessionContext, CCM2Context

    { Object create_ref (in CORBA::RepositoryId repid); Object create_ref_from_oid ( in PortableServer::ObjectIdCORBA::OctetSeq oid, in CORBA::RepositoryId repid); PortableServer::ObjectId CORBA::OctetSeq get_oid_from_ref (in Object objref) raises (IllegalState, BadComponentReference); CORBA::OctetSeq get_current_oid () raises (IllegalState); }

    ;

    and add the operation description

    get_current_oid

    The get_current_oid operation is used by the component to extract the oid
    associated with the current operation invocation. This operation must be called
    within an operation invocation. If not, the IllegalState exception shall be raised.

    Also, replace the following text in formal/02-06-05 on page 4-44

    local interface Entity2Context : EntityContext, CCM2Context

    { ComponentId get_component_id () raises (IllegalState); ComponentId create_component_id ( in FacetId target_facet, in SegmentId target_segment, in SegmentDescrSeq seq_descrs); ComponentId create_monolithic_component_id ( in FacetId target_facet, in StateIdValue sid); Object create_ref_from_cid ( in CORBA::RepositoryId repid, in ComponentId cid); ComponentId get_cid_from_ref ( in Object objref) raises (BadComponentReference); }

    ;

    with

    local interface Entity2Context : EntityContext, CCM2Context

    { ComponentId get_component_id () raises (IllegalState); ComponentId create_component_id ( in FacetId target_facet, in SegmentId target_segment, in SegmentDescrSeq seq_descrs); ComponentId create_monolithic_component_id ( in FacetId target_facet, in StateIdValue sid); Object create_ref_from_cid ( in CORBA::RepositoryId repid, in ComponentId cid); ComponentId get_cid_from_ref ( in Object objref) raises (BadComponentReference); ComponentId get_current_cid () raises (IllegalState); }

    ;

    and add the operation description

    get_current_cid

    The get_current_cid operation is used by a persistent component to retrieve the
    ComponentId associated with the current operation invocation. This operation must be called
    within an operation invocation. If not, the IllegalState exception shall be raised.

  • Reported: CORBA 3.0.2 — Tue, 22 Apr 2003 04:00 GMT
  • Updated: Sun, 17 Feb 2019 23:56 GMT

HomeConfigurator should not extend CCMHome

  • Key: CORBA34-29
  • Legacy Issue Number: 5769
  • Status: open  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    Document formal/02-06-05 on page 1-49 states the following:

    "The implementation of a component type's home object may optionally support the
    HomeConfiguration interface. The HomeConfiguration interface is derived from
    Components::CCMHome. In general, the HomeConfiguration interface is
    intended for use by an agent deploying a component implementation into a container,
    or an agent deploying an assembly."

    The first statement does not offer a clear interpretation when considering the language mapping for homes. If the implementation of a component type's home optionally supports HomeConfigurator how is this information defined in IDL? Should the component type's home definition support HomeConfiguration? This would seem to be the proper interpretation but that leads to problems in the language mapping of the defined home. In section 3.3.3.6 on page 3-45

    Home Explicit Executor Interface

    The home explicit executor callback interface is defined by the following rules:

    1. For each home <home name>, a local explicit executor interface with the same
    name as the home, but with a prefix of "CCM_" and a postfix of "Explicit" is
    defined.

    2. The explicit executor interface contains all attributes and operations declared by the
    home.

    3. If the home has a base with a name of <base name>, the explicit executor
    interface inherits CCM_<base name>Explicit. If the home does not have a base,
    the explicit executor interface inherits Components::HomeExecutorBase.

    4. If the home has supported interfaces, they are inherited by the explicit executor
    interface.

    5. Additional operations are added to the explicit executor interface for factories and
    finders, see below.

    Item 4 would imply that the home explicit executor must include operations defined in both HomeConfigurator and CCMHome since HomeConfigurator extends CCMHome. This is clearly not the intended behavior of the home explicit executor since it specifically excludes any direct inheritance of CCMHome.

    Resolution

    The inheritance of CCMHome by HomeConfiguration should be removed since it is implied that every home will extend CCMHome and home definitions in IDL would then be able to explicitly support HomeConfiguration without the extra baggage of the CCMHome interface. Furthermore, the language mapping does not properly handle a component home that supports HomeConfiguration (if it extends CCMHome) since the component executor would include all CCMHome operations. The language mapping would work fine if HomeConfiguration did not extend CCMHome.

    Replace text in formal/02-06-05 on page 1-49

    The implementation of a component type's home object may optionally support the
    HomeConfiguration interface. The HomeConfiguration interface is derived from
    Components::CCMHome. In general, the HomeConfiguration interface is
    intended for use by an agent deploying a component implementation into a container,
    or an agent deploying an assembly.

    with

    The implementation of a component type's home object may optionally support the
    HomeConfiguration interface. In general, the HomeConfiguration interface is
    intended for use by an agent deploying a component implementation into a container,
    or an agent deploying an assembly.

    Replace IDL in formal/02-06-05 on page 1-49

    module Components {
    interface HomeConfiguration : CCMHome

    { void set_configurator (in Configurator cfg); void set_configuration_values ( in ConfigValues config); void complete_component_configuration (in boolean b); void disable_home_configuration(); };
    };


    with


    module Components {
    interface HomeConfiguration { void set_configurator (in Configurator cfg); void set_configuration_values ( in ConfigValues config); void complete_component_configuration (in boolean b); void disable_home_configuration(); }

    ;
    };

  • Reported: CORBA 3.0.2 — Mon, 2 Dec 2002 05:00 GMT
  • Updated: Sun, 17 Feb 2019 23:56 GMT

Generic port connections

  • Key: CORBA34-27
  • Legacy Issue Number: 5852
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    I propose to introduce generic operations that allow
    interconnecting ports regardless of their type. This
    would ease generic programming.

    The first part of the proposal is to allow generic
    usage of the "connect" and "disconnect" operations
    that are (currently) in the Receptacles interface,
    i.e. to extend the functionality to not only work
    on receptacles, but also on event source ports
    (emits and publishes keywords).

    The names "connect" and "disconnect" are appropriate
    for any kind of port, and their signatures are the
    same as "subscribe" and "unsubscribe" in the Events
    interface.

    The second part of the proposal is to introduce a
    new operation "get_port" into the CCMObject interface.
    This operation would take a FeatureName parameter and
    return the object reference associated with that
    facet or event sink.

    So I propose the following steps:

    1.) Allow connect, disconnect and get_connections to
    operate on event source ports, and introduce a
    get_port operation.
    This change would be backwards compatible.

    2.) Move connect, disconnect and get_connections from
    the now inappropriate Receptacles interface into
    the CCMObject interface. This step might cause
    minor, easily fixable breakage for software that
    widens an object reference to Receptacles instead
    of CCMObject. (I don't think any such software
    exists, it's more of a theoretical issue.)

    3.) Discourage, then remove the "subscribe" and
    "unsubscribe" operations in the Events interface.
    They don't offer any more type safety than connect
    and disconnect.

    I believe that these changes would also be of interest
    for slimming down CCM for the Lightweight CCM RFP, and
    in light of the Streams for CCM RFP (which will likely
    add another port type that needs interconnecting).

    This change does not have any impact on component
    implementations. The change to CCM implementations
    (ORBs) is neglegible (I would expect a day to make
    these changes in MicoCCM, another day to test them).

    If there is general agreement on this issue, I will
    draft the text updates.

  • Reported: CORBA 3.0.2 — Thu, 6 Feb 2003 05:00 GMT
  • Updated: Sun, 17 Feb 2019 23:55 GMT

LwCCM issue - Section 1.6.8 Exclusion

  • Key: CORBA34-28
  • Legacy Issue Number: 7028
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    While reviewing Victor's issue on section 1.5.3, I noticed
    that a similar problem exists with respect to the Events
    interface.

    While the normative exclusion "disable get_all_consumers
    [...]" (8th row of section 10.3) retains the generic
    get_consumer, subscribe, unsubscribe, connect_consumer
    and disconnect_consumer operations, removing section 1.6.8
    would remove the entire Events interface.

    Proposed resolution:

    In section 10.3, in the "Document Impact" column of the
    8th row, replace the text

    Section 1.6.8: remove

    with

    Section 1.6.8: remove these operations from the Events
    interface. Also remove the ConsumerDescription,
    EmitterDescription, SubscriberDescription and
    PublisherDescription types.

  • Reported: CORBA 3.0.2 — Wed, 25 Feb 2004 05:00 GMT
  • Updated: Sun, 17 Feb 2019 23:55 GMT

LwCCM issue - Section 1.4.3.3 Exclusion

  • Key: CORBA34-26
  • Legacy Issue Number: 7027
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    While reviewing Victor's issue on section 1.5.3, I noticed
    that a similar problem exists with respect to the Navigation
    interface.

    While the normative exclusion "disable get_all_facets, get_
    named_facets, same_component operations in Navigation
    interface" retains the generic provide_facet operation,
    removing section 1.4.3.3 would remove the entire Navigation
    interface.

    On the other hand, the still-present section 1.4.3.4 references
    the disabled operations.

    Proposed resolution:

    In section 10.3, in the "Document Impact" column of the second
    row, replace the text

    1.4.3.3: remove

    with

    1.4.3.3: remove these operations from the Navigation
    interface. Also remove the PortDescription, FacetDescription
    and FacetDescriptions types.

    1.4.3.4: remove

  • Reported: CORBA 3.0.2 — Wed, 25 Feb 2004 05:00 GMT
  • Updated: Sun, 17 Feb 2019 23:55 GMT

Interface Introspection

  • Key: CORBA34-25
  • Legacy Issue Number: 6391
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    Inspired by a recent paper by Doug Schmidt and Steve Vinoski
    and the resulting newsgroup discussion on comp.object.corba,
    I have a feature request to introduce a better reflection
    mechanism into CORBA.

    At the moment, there is the CORBA::Object::get_interface()
    operation to access a matching InterfaceDef entry in an
    Interface Repository. Since an Interface Repository is
    seldomly deployed, using this operation is pretty much
    futile and will either return a nil reference or throw
    an exception.

    Therefore, I propose to add a new get_interface_def()
    operation to the Object interface that returns a FullInter-
    faceDef structure, as defined by the Interface Repository.
    This structure contains all that a dynamic client (such as
    the ones proposed by Schmidt&Vinoski, or software like
    CorbaScript or Combat) needs to know about an interface.

    A new _interface_def pseudo-operation then needs to be added
    to GIOP. This could probably be done without a version change,
    as no marshalling changes or new messages are involved, it's
    just another operation.

    On the server side, the IDL compiler would generate a suitable
    implementation as part of the skeleton. This implementation
    could just contain a binary representation of the FullInterface-
    Description structure (just like a "precompiled" TypeCode) that
    is dumped to the GIOP stream. (So that you don't need the
    Interface Repository IDL around.)

    Proposed resolution:

    In chapter 4.3, "Object Reference Operations," add the following
    operation to the Object interface:

    module CORBA {
    interface Object

    { // PIDL ... other operations ... FullInterfaceDescription get_interface_def (); }

    ;
    };

    Add the following explanation to 4.3.1, "Determining the Object
    Interface"

    4.3.1.2 get_interface_def

    FullInterfaceDescription get_interface_def ();

    The get_interface_def operation returns a data structure
    describing the most derived type of the object addressed by
    the reference. The FullInterfaceDescription structure includes
    descriptions of all the operations and attributes in the
    transitive closure of the inheritance graph of the interface
    being described. See the Interface Repository chapter for the
    contents of the data structure. Note that if an Interface
    Repository is not available, object references contained in
    this structure may be nil or inaccessible.

    In chapter 15.4.2, "Request Message", update the text that
    reads

    In the case of CORBA::Object operations that are defined in
    the CORBA Core (Section 4.2, "Object Reference Operations,"
    on page 4-12) and that correspond to GIOP request messages,
    the operation names are _interface, _is_a, _non_existent,
    _domain_managers and _component.

    to read

    In the case of CORBA::Object operations that are defined in
    the CORBA Core (Section 4.2, "Object Reference Operations,"
    on page 4-12) and that correspond to GIOP request messages,
    the operation names are _interface, _is_a, _non_existent,
    _domain_managers, _component or _interface_def.

    In the C++ language mapping, section 1.37.1, "Mapping of
    PortableServer::Servant", add the following operation to
    class ServantBase:

    namespace PortableServer { // C++
    class ServantBase

    { ... other operations ... virtual CORBA::FullInterfaceDescription_ptr _get_interface_def (); }

    ;
    }

    Update the paragraph that reads,

    ServantBase provides default implementations of the
    _get_interface, _is_a and _non_existent object reference
    operations [...]

    to read

    ServantBase provides default implementations of the
    _get_interface, _is_a, _non_existent and _get_interface_def
    object reference operations [...]

    Add a new paragraph,

    For static skeletons, the default implementation of the
    _get_interface_def function returns information about the
    interface associated with the skeleton class. For dynamic
    skeletons, the default implementation uses the
    _get_interface function to determine its return value.

    Other language mappings might need similar updates.

    By the way, since FullInterfaceDescription is only used as
    a return value, only a pointer to FullInterfaceDescription
    is needed. Therefore, you don't need the full Interface
    Repository interface descriptions but only a pointer to an
    incomplete type.

    On the client side, you only need to pull in the Interface
    Repository IDL if you are actually calling _get_interface_def.

    On the server side, the skeleton can do some ORB-dependent
    magic to push a precompiled binary data structure into the
    result.

  • Reported: CORBA 3.0.2 — Mon, 27 Oct 2003 05:00 GMT
  • Updated: Sun, 17 Feb 2019 23:55 GMT

GIOP Conformance and Interceptors

  • Key: CORBA34-22
  • Legacy Issue Number: 6314
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    GIOP Conformance and Interceptor don't play well together.

    GIOP minor version conformance mandates two things.

    1. That standard service contexts that are considered optional
    can be ignored should the implementation not understand them.

    2. That certain service contexts get processed according to the
    specification of where they are defined.

    This requirement works well for GIOP 1.2 where a lot of them are optional,
    since (1) will apply. An implementation can claim 1.2 conformance and not
    process any of them.

    However, 1.3 and upcoming 1.4 will mandate the processing of them
    according to their specification. In many cases, this means that some
    default response may be required, which means that a GIOP 1.3, or later
    engine must have a "default" response for these service contexts.

    In an ORB that uses interceptors and has a generic GIOP messaging engine
    there is no way for the engine to "know" when or not to process a
    particular service context. It requires strict processing by the GIOP
    engine, or it requires "default" interceptors to be installed to maintain
    the level of conformance.

    However, interceptors have no way of "declaring" which service contexts
    they handle, and whether they they are overriding already installed
    (default) interceptors for processing those particular service contexts.

    For example, an non-transactional ORB that is GIOP 1.2 compliant must
    process the Transaction Service Context by raising a
    TRANSACTION_UNAVAILABLE exception, because by default the ORB is in the
    OTS_NOT_CONNECTED state. It cannot be ignored to comply with GIOP 1.2 (but
    by certain in implementations it ALWAYS is). A default interceptor is
    needed in the ORB implementation to do this. However, for an ORB
    configuration that wants to process this, there is no way for an
    interceptor to "override" default processing.

  • Reported: CORBA 3.0.2 — Wed, 8 Oct 2003 04:00 GMT
  • Updated: Sun, 17 Feb 2019 23:54 GMT

Change new GIOP Negotiate Session Message to Firewall Specific

  • Key: CORBA34-23
  • Legacy Issue Number: 6285
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Here is a small proposal for GIOP 1.4 with Firewall and Bidirectional. We
    would get rid of all the weird nasty service contexts and make it
    simplistic. The FireWall messages are only allowed before any other GIOP
    messages. BiDir messages can happen at any time according to their
    protocol.

    What do you think? Asside from some problems I see with BiDir
    offer/challenge/response correlation, it is essentially equivalent to the
    solution proposed in the adopted spec.

    module GIOP {
    enum MsgType_1_4

    { Request, Reply, CancelRequest, LocateRequest, LocateReply, CloseConnection, MessageError, Fragment, // GIOP 1.1 addition // GIOP 1.4 additions FirewallPathRequest, // 8 FirewallPathRepsonse, // 9 BiDirOffer, // 10 BiDirChallenge, // 11 BiDirResponse // 12 }

    ;

    // Firewall Traversal GIOP 1.4

    struct FirewallSpec

    { boolean is_intelligent; IOP::TaggedComponentSeq endpoints; }

    ;
    typedef sequence<FirewallSpec> FirewallPath;

    struct FirewallPathRequestHeader

    { unsigned long host_index; FirewallPath path; }

    ;
    // No body follows.

    enum FirewallPathResponseStatusType

    { NO_EXCEPTION, SYSTEM_EXCEPTION }

    ;

    struct FirewallPathResponseHeader

    { FirewallPathResponseStatusType status; boolean connection_complete; }

    ;
    // Marshalled body immediately follows

    // Bidirectional GIOP 1.4

    // To keep this file uncomplicated we can introduce the
    // headers and put the marshalled bodies in a separate BiDir module
    // Due due some issue about the challege/response protocol for this,
    // there may be a need of an offer_id to correlate them.

    struct BiDirOfferHeader

    { unsigned long offer_id; };
    // Marshalled body immediately follows.


    struct BiDirChallengeHeader { unsigned long offer_id; }

    ;
    // Marshalled body immediately follows.

    struct BiDirResponseHeader

    { unsigned long offer_id; }

    ;
    // Marshalled body immediately follows.
    };

  • Reported: CORBA 3.0.2 — Thu, 2 Oct 2003 04:00 GMT
  • Updated: Sun, 17 Feb 2019 23:54 GMT

CodeSet and CSIv2 Negotitaion

  • Key: CORBA34-24
  • Legacy Issue Number: 6283
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    I believe that we send CSIv2 stuff in a GIOP Request until a corresponding
    GIOP reply has been containing corresponding CSIv2 context ids is sent.

    For Codeset, I think the policy is to send the service context in each
    GIOP request until a corresponding GIOP Reply is received, thereby saying
    that the "negotiation" is completed and excepted (otherwise an exception
    will be raised.

    We should probably look at the fact that multiple NSReq messages can be
    sent, and there are no corresponding reply messages depending on the
    service contexts.

    I think that these messages should be intercepted since they are
    delivering service contexts.

  • Reported: CORBA 3.0.2 — Thu, 2 Oct 2003 04:00 GMT
  • Updated: Sun, 17 Feb 2019 23:54 GMT

page 1-20 the description of the get_connection operation

  • Key: CORBA34-20
  • Legacy Issue Number: 5944
  • Status: open  
  • Source: Fraunhofer FOKUS ( Tom Ritter)
  • Summary:

    page 1-20 the description of the get_connection operation refers to a ConnectionDescription struct. In fact it is a ConnectionDescription valuetype

  • Reported: CORBA 3.0.2 — Thu, 29 May 2003 04:00 GMT
  • Updated: Sun, 17 Feb 2019 23:53 GMT

page 1-20 second bullet of the description of the disconnect operation

  • Key: CORBA34-18
  • Legacy Issue Number: 5943
  • Status: open  
  • Source: Fraunhofer FOKUS ( Tom Ritter)
  • Summary:

    I found some minor editorial issues in the spec (referring to the document 02-06-65).

    • page 1-20 second bullet of the description of the disconnect operation. An 'and' is missing. This bullet should look like: "If the receptacle is a simplex receptacle and there is no current connection, then the NoConnection exception is raised."
  • Reported: CORBA 3.0.2 — Thu, 29 May 2003 04:00 GMT
  • Updated: Sun, 17 Feb 2019 23:53 GMT

context interface for home implementation

  • Key: CORBA34-21
  • Legacy Issue Number: 5936
  • Status: open  
  • Source: Fraunhofer FOKUS ( Tom Ritter)
  • Summary:

    The home interface could have freely defined operations or can support an
    interface with such operations. A home context interface may help to implement
    such operations. E.g. a home implementation needs this context interface to
    determine its own object reference.

    suggestion:

    Add a home context interface that is similar to the component context interface.
    Add a set_context operation at the HomeExecutorBase interface.

  • Reported: CORBA 3.0.2 — Wed, 7 May 2003 04:00 GMT
  • Updated: Sun, 17 Feb 2019 23:53 GMT

page 1-20 and page 1-21 - editorial

  • Key: CORBA34-19
  • Legacy Issue Number: 5945
  • Status: open  
  • Source: Fraunhofer FOKUS ( Tom Ritter)
  • Summary:

    -page 1-20 and page 1-21 the names of the operations get_all_receptacles get_named_receptacles are written with italic font. This seems to be a mistake.

  • Reported: CORBA 3.0.2 — Thu, 29 May 2003 04:00 GMT
  • Updated: Sun, 17 Feb 2019 23:53 GMT

Chapter/section: 15.4.2.2 "Request Body"

  • Key: CORBA34-17
  • Legacy Issue Number: 6287
  • Status: open  
  • Source: 2AB ( Carol Burt)
  • Summary:

    Suppose you are sending a request (GIOP 1.2 or 1.3) and the request will
    be fragmented into two segments. The first segment is a Request message
    that has the GIOP Header and part of the Request Header. The second
    segment is a Fragment message that has a GIOP Header, a Fragment Header,
    and the body is the remainder of the Request Header and the Request Body.
    Section 15.4.2.2 of CORBA 3.0 states that the Request Body (in a Request
    Message) should always be aligned on an 8 octet boundary.

    My question is, in the above scenario, where the Request Body begins in
    the Fragment message, should the Request Body be aligned on an 8 octet
    boundary or not? I have not found anything in the specification that
    explicitly says what to do.

  • Reported: CORBA 3.0.2 — Wed, 1 Oct 2003 04:00 GMT
  • Updated: Sun, 17 Feb 2019 23:51 GMT

[Components] Contradiction between IDL and Interface Repository concerning

  • Key: CORBA34-16
  • Legacy Issue Number: 6671
  • Status: open  
  • Source: Humboldt-Universitaet ( Bertram Neubauer)
  • Summary:

    According to the IDL language it is allowed to define a facet/receptacle on a component with type of Object. The text says:

    A facet is declared with the following syntax:
    (120) <provides_dcl> ::= “provides” <interface_type> <identifier>
    (121) <interface_type> ::= <scoped_name>

    “Object”
    The interface type shall be either the keyword Object, or a scoped name that denotes
    a previously-declared interface type which is not a component interface, ...

    In contradiction to that the Interface Repository element for a component, the ComponentDef, does only allow the creation of facets/receptacles with type of InterfaceDef. The according operations are:

    // write interface
    ProvidesDef create_provides (
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    in InterfaceDef interface_type
    );
    UsesDef create_uses (
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    in InterfaceDef interface_type,
    in boolean is_multiple
    );

    Thus the ComponentDef can not be used to create a facet/receptacle that is of type Object, since Object is no InterfaceDef but a PrimitiveDef.
    One solution would be to use IDLType instead of InterfaceDef since PrimitiveDef and InterfaceDef inherit from that interface. My proposal is to change the Interface Repository IDL in the following way.

    1) replace in ComponentDef:

    // write interface
    ProvidesDef create_provides (
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    in IDLType interface_type
    );
    UsesDef create_uses (
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    in IDLType interface_type,
    in boolean is_multiple
    );

    2) replace ProvidesDef, ProvidesDecsription, UsesDef, UsesDescription with

    interface ProvidesDef : Contained

    { // read interface readonly attribute IDLType interface_type; }

    ;

    struct ProvidesDescription

    { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; IDLType interface_type; }

    ;

    interface UsesDef : Contained

    { // read interface readonly attribute IDLType interface_type; readonly attribute boolean is_multiple; }

    ;

    struct UsesDescription

    { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; IDLType interface_type; boolean is_multiple; }

    ;

  • Reported: CORBA 3.0.2 — Wed, 3 Dec 2003 05:00 GMT
  • Updated: Sun, 17 Feb 2019 23:50 GMT

15.3.3 - codesets must be "explicitly defined"

  • Key: CORBA34-15
  • Legacy Issue Number: 6050
  • Status: open  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    For codesets in encapsulations we have:

    15.3.3 - codesets must be "explicitly defined"

    Issue 4824 - "it is an error for a Service Context to depend on information that is not contained within the encapsulation to determine the codeset used within it"

    But in 13.8 there is no prescribed way of "explicitly defining" the codeset.

    Please, please can we simply define that the fallbacks in 13.10.2.6 apply everywhere that the codeset is not known (whether negotiated or not) and be done with it.

    Another alternative would be to add codeset parameters to the encode() and decode() functions of 13.8.

  • Reported: CORBA 3.0.2 — Tue, 26 Aug 2003 04:00 GMT
  • Updated: Sun, 17 Feb 2019 23:50 GMT

Clarification on multi-threaded codeset negotiation

  • Key: CORBA34-14
  • Legacy Issue Number: 5880
  • Status: open  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    We recently ran into a problem with a foreign Vendor's ORB and it appears the spec is unclear on this issue.

    The problem occurs when a multi-threaded client is connecting to a server. The spec says (13.10.2.6):

    "Codeset negotiation is not performed on a per-request basis, but only when a client
    initially connects to a server. All text data communicated on a connection are encoded
    as defined by the TCSs selected when the connection is established."

    but is silent on what is supposed to happen if the client has multiple threads all trying to connect at the same time. The issue is that priority inversion can occur - either because the client sends out a request without the negotiated codeset before the one with the negotiated codeset, or because the server processes the request without the negotiated codeset before the one with the negotiated codeset (even if the latter was sent first). The problem we encountered was the latter.

    There are two possible approaches to solving this:

    a) Require the server to serialize connection establishment requests until the codeset (and other connection information) is negotiated. This requires that the client impose appropriate ordering on connection requests.

    b) Require that the client keep sending codeset (and other connection information) until it is sure that the server has received the information (by getting a reply back). This works ok unless you are exclusively using oneways. In this instance you have to keep sending codeset information forever (somewhat costly, and very costly for codebase information).

    CSIv2 (26.2.2.3) explicitly calls out (b) but I prefer (a). Do we have any guidance on what is supposed to happen?

  • Reported: CORBA 3.0.2 — Tue, 11 Mar 2003 05:00 GMT
  • Updated: Sun, 17 Feb 2019 23:50 GMT

valuetype fragmentation ambiguous

  • Key: CORBA34-13
  • Legacy Issue Number: 5941
  • Status: open  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    Although I now think I know the intent of the spec, its is ambiguous if not plain wrong with respect to valuetype fragmentation.

    In particular 15.3.4.6:

    Bullet 1 says:

    "End tags, chunk size tags, and value tags are encoded using non-overlapping ranges
    so that the unmarshaling code can tell after reading each chunk whether:
    • another chunk follows (positive tag).
    • one or multiple value types are ending at a given point in the stream (negative
    tag).
    • a nested value follows (special large positive tag)."

    Bullet 3 says:

    "• For the purposes of chunking, values encoded as indirections or null are treated as
    non-value data."

    And the pseudo-BNF says:

    "(1) <value> ::= <value_tag> [ <codebase_URL> ]
    [ <type_info> ] <state>

    <value_ref>
    (2) <value_ref> ::= <indirection_tag> <indirection>
    <null_tag>
    (3) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
    (4) <type_info> ::= <rep_ids>
    <repository_id>
    (5) <state> ::= <octets>
    <value_data>* [ <end_tag> ]
    (6) <value_data> ::= <value_chunk>
    <value>"

    Now clearly the implication of bullet 1 is that an indirection or null must appear inside a chunk in a chunked encoding, otherwise you would be able to see the value 0 or -1 after a chunk and the -1 in particular could mean an end tag or an indirection. However the possible implication of bullet 3 and the BNF (note the use of "value data") is that nulls and indirections are values and thus must appear outside of chunks. Clearly the former interpretation is the correct one otherwise anarchy ensues.

    So I propose that we change the 3rd bullet to say:

    "For the purposes of chunking, values encoded as indirections or null are treated as
    if they were not values and therefore must always appear inside a chunk when a chunked encoding is in effect."

    and then change the BNF to say:

    "(1) <value> ::= <concrete_value> | <value_ref>
    (2) <concrete_value> ::= <value_tag> [ <codebase_URL> ]
    [ <type_info> ] <state>
    (3) <value_ref> ::= <indirection_tag> <indirection> | <null_tag>
    (4) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
    (5) <type_info> ::= <rep_ids> | <repository_id>
    (6) <state> ::= <octets> |<value_data>* [ <end_tag> ]
    (7) <value_data> ::= <value_chunk> | <concrete_value>"

    etc

  • Reported: CORBA 3.0.2 — Fri, 23 May 2003 04:00 GMT
  • Updated: Sun, 17 Feb 2019 23:50 GMT