Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — All Issues

  • Acronym: CORBA
  • Issues Count: 56
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA34-301 Server Authentication CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-300 Bidirectional Policy insufficient for persistent objects CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-299 Discrepancy in the changes proposed to CSIIOP and CSI modules CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-302 Negotiation Session message is unwieldy CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-303 Negotiate Session Message Orientation CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-285 Interplay of Contexts allowed in NegotiateSession messages too ill-defined CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-286 Firewall Issue: Random BiDirIds can't be used for persistent POAs CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-290 Implications about BiDirIds CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-289 Firewall issue - Number of BiDirIds in a BiDirOffer CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-293 CodeSet issue (05) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-284 What BiDirIds shall be sent over what bidirectional connections? CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-291 paragraph limits use of BiDirOfferContext CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-292 Negotiate Session Message Issues CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-287 Firewall Issue: Connection over which BiDir offers are sent is unspecified CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-288 Firewall Issue: Response to failed BiDir challenge is unclear CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-294 CodeSet issue (04) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-296 CodeSet issue (02) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-295 CodeSet issue (03) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-297 CodeSet issue (01) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-298 GIOP version 2.0 issue CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-275 use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-276 Bi-directional connections considered volatile at connection acceptor side CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-278 How many BI_DIR_GIOP_OFFER service contexts are allowed CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-277 Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-279 connection_complete field of the FirewallPathRespContext is under specified CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-281 Targets of Export and Offer Policies incompletely specified CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-280 Expected behavior of a non-conformant implementation CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-282 Processing of NegotiateSession messages at various stages of connection set CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-283 Firewall FTF Issue: No ene-to-end security for firewall traversal CORBA 2.5 CORBA 3.4 Deferred closed
CORBA26-99 Include GIOP over Bluetooth into Wireless CORBA 1.1 CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-98 TypeCode interface issue CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-97 Valuetype initialzers need exceptions CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-96 New core issue: need UNKNOWN reply status CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-95 Syntax error in CORBA IDL CORBA 2.5 CORBA 2.6 Resolved closed
ZIOP-81 Issue for components: No meta model for CIDL ? CORBA 2.5 ZIOP 1.0 Resolved closed
CORBA26-81 minor IDL changes required in CCM API CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-80 Little problem with introspection API CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-79 CCM: Meaning of "exposed" scopes unclear. CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-78 CCM: import and re-opening of modules CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-76 CCM: Isolated scope tokens CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-77 CCM: Definition of import declaration unclear CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-75 Issue for Components: Missing language mapping CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-94 Changing VSCID prefix to 24 bits CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-10 section 7.1.1 claims to define the "NVList structure", but doesn't CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-8 IDL for ORB::resolve_initial_references CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-6 the IDL include directive should introduce declarations into the namespace CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-7 set_length operation of the DynSequence interface CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-9 Implied IDL for interfaces in modules CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-5 DynUnion operations CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-3 Chapter 11, section 11.3.8.19 (WrongPolicy)" CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-4 Problem with IDL Context interface CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-2 Support for is_a for local interfaces CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-1 Section 11.3.8.16 - ambiguity CORBA 2.5 CORBA 2.6 Resolved closed
CORBA3-37 CORBA 2.5 and Portable Interceptors mismerged CORBA 2.5 CORBA 3.0.2 Resolved closed
CORBA3-38 Alignment for empty sequence? CORBA 2.5 CORBA 3.0.2 Resolved closed
CORBA3-36 Detecting Recursion in Other Interceptors CORBA 2.5 CORBA 3.0.2 Resolved closed

Issues Descriptions

Server Authentication

  • Legacy Issue Number: 6312
  • Status: closed  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    As I understood it, the Firewall Traversal specification was to use new
    CSIv2 Compound Identity types to give the target server the complex
    principal composed of the client and the authenticating firewall traversal
    path. The server was to be authenticated to the client in much the same
    way. This functionality appears to be missing in the specification. It is
    easily fixed by returning a CSIv2 IdentityTokenSeq from a successful
    firewall negotiation, specifying the backwards firewall authentication
    trail from the server to the client.

  • Reported: CORBA 2.5 — Tue, 7 Oct 2003 04: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: Mon, 30 Mar 2020 19:47 GMT

Bidirectional Policy insufficient for persistent objects

  • Legacy Issue Number: 6313
  • Status: closed  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    The BidirectionalPolicy insufficient for persistent objects.

    The BidirectinoalExport Policy is a POA policy and it only has two values
    of ALLOW and DENY. If it is ALLOW, then a TAG_BI_DIR_GIOP componenet
    should be placed in the IOR. It is stated that the ORB must generate a
    random identifier when the POA is created. However, that will not work for
    persistent objects in which the BiDirectional Offer must remain constant.

    Also, there is no default specified if this policy is not placed on a POA,
    and no default for the RootPOA.

  • Reported: CORBA 2.5 — Thu, 9 Oct 2003 04: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: Mon, 30 Mar 2020 19:47 GMT

Discrepancy in the changes proposed to CSIIOP and CSI modules

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

    There seems to be a discrepancy in the changes proposed to CSIIOP and CSI modules. The draft document has identical changes to both. I think the intent of the Errata was to have only one, just switch them from CSIIOP to CSI. However, Brian's convience document doesn't show the change. Now, the draft document ptc/2004-01-01 that we are voting on has both. What to do? Should that be represented by another document, namely CSI, with it's changes, just like 2004-01-02 is? Cheers, -Polar

    Yeah, I see the problem. Yet another consequence of the adopted spec changing existing spec without calling out the change in the section meant to identify changes to existing specs. So it looks like the fix involves: 1. Section 1.9.2 and 1.9.3 in ptc/04-01-01 [henceforth referred to as document A] should disappear. 2. The first half of section of document A starting from the second para of the section and upto and including the last but one paragraph on page 1-20, should be appended to Section 24.2.5 "Identity Token Format" of Chapter 24 of Core with the title (that is the CSIv2 Chapter)[henceforth referred to as document B]. Also append a row to table 24-2 with info about ITTCompundToken. 3. The IDL in section 1.9.3 of document A should be merged properly into the IDL for the CSI module that appears in section 24.9.2 document B. 4. The addition to CSIIOP IDL as it appears in Section 1.5.2 of document A should be merged appropriately into the IDL for CSIIOP in section 24.9.3 of document B. 5. In document B insert a section 24.5.1.6 "TAG_IIOP_SEC_TRANS" with a two liner explanation of what this tag is together with the IDL for it from section 1.5.2 of document A. I'd suggest that we file this as an issue and resolve it in the FTF roughly along the lines suggested above.

  • Reported: CORBA 2.5 — Fri, 19 Mar 2004 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: Mon, 30 Mar 2020 19:47 GMT

Negotiation Session message is unwieldy

  • Legacy Issue Number: 6311
  • Status: closed  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    The Negotiate Session message is unwieldy in that if it is used to send
    service contexts, there are no general ways to govern its use other than
    by special rules, all of which special cases are not accounted for in the
    specification.

    For example, when do you sent Bidirectional service contexts as ooposed to
    firewall contexts? Can you send transaction contexts? Codesets? Codebase?
    CSIv2? Can you send BiDir service contexts while firewall contexts are
    being processed?

  • Reported: CORBA 2.5 — Tue, 7 Oct 2003 04: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: Mon, 30 Mar 2020 19:47 GMT

Negotiate Session Message Orientation

  • Legacy Issue Number: 6284
  • Status: closed  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    The NegotiateSession message is a single typed GIOP message that is sent
    between both Client and Server to negotiation service contexts, and
    further to initiate and negotiate bidirectional GIOP.

    Having a single message is problematic in that a connection, once
    negotiated bidirectional may have different requirements for such things
    like Codesets, etc. Getting a NegotiateSession message after a
    bidrectional set up, the endpoints will have difficulty discerning the
    orientation of the NegotiateSession message.

    At the very least NegotateSession messages should have an orientation,
    much like the GIOP Request and Reply messages do.

    I'm not so sure they must be correlated with a "request id", but different
    message types would help. I would suggest two messages,
    NegotiateSessionRequest and NegotiateSessionReply to maintain the
    client-server orientation, respectively.

  • Reported: CORBA 2.5 — Thu, 2 Oct 2003 04: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: Mon, 30 Mar 2020 19:47 GMT

Interplay of Contexts allowed in NegotiateSession messages too ill-defined

  • Legacy Issue Number: 7311
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP document allows all of the contexts that can be found in a GIOP query or response message to be also allowed in a NegotiateSession message. However, the interplay among these contexts is undefined. An example is the use in NegotiateSession messages of both CodeSet negotiation and BiDir connection setup. What can be used in what order is not defined.

    RECOMMENDATION:
    Only bi-directional GIOP and firewall contexts may be used in a NegotiateSession message in this version of GIOP. The contexts are the following:

    · BI_DIR_GIOP_OFFER
    · BI_DIR_GIOP_CHALLENGE
    · BI_DIR_GIOP_RESPONSE
    · BI_DIR_GIOP_ACCEPT
    · FIREWALL_PATH
    · FIREWALL_PATH_RESP

    Further contexts may be added to new versions of the BiDir GIOP spec as their interplay with the existing set and the order of their use is carefully analyzed and documented. This effectively limits the scope of the problem to the bidir protocol and use by the firewall. The order and stage of processing the above contexts is discussed in another Firewall issue.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

Firewall Issue: Random BiDirIds can't be used for persistent POAs

  • Legacy Issue Number: 7310
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP document specifies that all BiDirIds must be randomly generated. However, persistent POAs must use the same BiDirId across sessions since they are stored in the IOR.

    RECOMMENDATION:
    A new policy is created (BiDirIdGenerationPolicy) that contains two fields:
    field 1, the ID generation method, will take the value 'RANDOM' or the value 'REPEATABLE'
    field 2, the ID type, will take the value 'STRONG' or the value 'WEAK'

    The random generation method is adequately documented. The repeatable method will always generate the same BiDirId for a given POA. This effectively makes the ID a constant, but without the concern for storage. It also results in the end-user not having to deal with BiDirIds - they are handled entirely by the infrastructure.

    The values for the ID type indicate whether the type of BiDirId generated is strong or weak.

    This policy is placed on the client ORB and/or the POA in question.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

Implications about BiDirIds

  • Legacy Issue Number: 7225
  • Status: closed  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    I'll use the following example to explain the implications that I derive from my understanding about the spec. I hope that it makes sense to you. If I'm wrong, please let me know.

    Suppose I set up a client that has some POAs with BI_DIR_EXPORT policy ALLOW. The client wants to invoke a server that accepts bi-directional GIOP. This invocation will cause callbacks to a few objects on the client using bi-directional GIOP. The server is not allowed to create new connections to the client.

    In the code of my client application, I can simply use the following statement to invoke the target object. And I would expect that the target object will call back some of the objects on the client ORB during this invocation.

    obj = ...; // target
    obj.invoke_target(...);

    In order for the above scenario to work, I derive the following implications from the spec.

    1. This invocation requires the target to call back on some of the objects on the client ORB. Because the client ORB has no knowledge about what objects might be called back, the client ORB has to ensure that the BiDirIds on all of its POAs that have EXPORT policy ALLOW must be available at the server side.

    This conclusion also implies that the client ORB may have to track what BiDirIds that have been sent (and accepted) over every connection that allows bi-directional GIOP in order to figure out what BiDirIds have not yet been sent, assuming that you don't want to send all BiDirIds in every request. Furthermore, when someone creates a new POA with the EXPORT policy ALLOW later on the client ORB, the next new invocation on each bi-directional connection will also have to transmit the BiDirId for this new POA to the server side.

    2. When the server receives a GIOP Request with BI_DIR_GIOP_OFFER service context, the server cannot dispatch the request to the target object implementation until this connection becomes bi-directional. Why? If the server dispatches the request before this connection becomes bi-directional, this request may fail because the target is not able to call back objects on the client ORB. In the case of Strong BiDirIds, the server may even have to send CHALLENGE and wait for RESPONSE before the server can dispatch the request.

    If we put both implications together in the case of Strong BiDirIds, when someone creates a new POA with EXPORT policy ALLOW on a client ORB, a longer delay will be expected in the next request on every bi-directional connection because the server has to verify the BiDirId of this new POA no matter whether this new BiDirId will be used for callbacks on that connection or not. To me this overhead is not acceptable if it is the only way to implement bi-directional GIOP according to the spec. I hope the spec can be written in a way that allows efficient implementation, though efficiency is not always a concern for everyone.

  • Reported: CORBA 2.5 — Thu, 8 Apr 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

Firewall issue - Number of BiDirIds in a BiDirOffer

  • Legacy Issue Number: 7307
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP document does not specify which BiDirIds and how many of them are sent in a BI_DIR_GIOP_OFFER.

    RECOMMENDATION:
    All unoffered BiDirIds are supplied in a BI_DIR_GIOP_OFFER.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

CodeSet issue (05)

  • Legacy Issue Number: 7201
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Does Codeset come before/with/after BiDir negotiation?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 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: Mon, 30 Mar 2020 19:47 GMT

What BiDirIds shall be sent over what bidirectional connections?

  • Legacy Issue Number: 7312
  • Status: closed  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The new BiDir spec is not clean about what BiDirIds shall be send to what connections. Because the BidirectionalOfferPolicy is either ALLOW or DENY, the only way to make bi-directional GIOP possible is to send all BiDirIds on an ORB to every connection that is used by an object reference that has effective BidirectionalOfferPolicy ALLOW. Besides, when a new POA with BidirectionalExportPolicy ALLOW is created, the BiDirId of this new POA must be transmitted to the server side of every existing bi-directional connections (before or in the next request).

    The above implication derived from the spec is very inefficient. Consider an ORB with n bi-directional connections and m BiDirIds. The communication overhead for sending these BiDirIds is (m * n), while, in the ideal case, the communication overhead for sending BiDirIds is (c * n) where c is the average number of BiDirIds needed on each bi-directional connection. This ideal case can be easily achieved by allowing the BidirectionalOfferPolicy to specify a list of POAs whose BiDirIds shall be transmitted.

    Proposed resolution:
    1. Extend the choices of the value field of the BidirectionalOfferPolicy:
    ALLOW_ALL – same as ALLOW now, but the implication shall be explicitely stated in the spec
    ALLOW_LISTED – a list of POAs being provided in the policy
    DENY – same as it now
    2. Add a field to the policy to allow a sequence of POAs being specified.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

paragraph limits use of BiDirOfferContext

  • Legacy Issue Number: 7224
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The second paragraph on page 15-60 of the revised GIOP chapter only allows a BiDirOfferContext to be sent to a server if the ORB-level policy permits it:

    "If the client ORB policy permits bi-directional use of a connection, a Request or
    NegotiateSession (see MARS/04-01-01) message can be sent to the server that
    contains a BI_DIR_GIOP_OFFER IOP::ServiceContext structure in the header that
    indicates that this GIOP connection is bi-directional. The BiDirOfferContext
    indicates to the server that the objects with the supplied BiDirIds are available for
    invocation over that connection. To determine whether an ORB may support bidirectional
    GIOP, the BidirectionalOfferPolicy has been defined (see Section 15.9,
    "Bi-directional GIOP policy," on page 65)."

    This, however, contradicts the rest of the document, which allows the ORB-level policy to be overriden at the object level. ("A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden
    for specific object references received by the client ORB." - Section 15-9, page 15-66).

    Additionally, the first sentence of the above paragraph is worded in such a way that it defines a connection as bidirectional before it has accepted as such by a server.

    Finally, a spurious reference to the submission document is included in the first sentence ("see MARS/04-01-01").

    RECOMMENDATION:
    Rephrase the paragraph as follows:

    If the effective BidirectionalOfferPolicy of an object in the client is set to ALLOW, a Request or NegotiateSession message that contains a BI_DIR_GIOP_OFFER IOP::ServiceContext structure in the header can be sent to the server, offering bi-directional use of the connection. The BiDirOfferContext indicates to the server that the objects with the supplied BiDirIds are available for invocation over that connection. To determine if bidirectional GIOP may be supported, the BidirectionalOfferPolicy has been defined (see Section 15.9, "Bi-directional GIOP policy," on page 65).

  • Reported: CORBA 2.5 — Tue, 6 Apr 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

Negotiate Session Message Issues

  • Legacy Issue Number: 7202
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    If a service context negotiation fails by way of the NegotiateSession
    message in either direction. how does the sender (client or servers side)
    get an indication back to the sender?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 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: Mon, 30 Mar 2020 19:47 GMT

Firewall Issue: Connection over which BiDir offers are sent is unspecified

  • Legacy Issue Number: 7309
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP document does not specify the connections over which a BI_DIR_GIOP_OFFER should be sent.

    RECOMMENDATION:
    A BI_DIR_GIOP_OFFER will be sent over all existing bi-directional connections. If there are none, then a new connection will be established and its bidirectionality initiated.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

Firewall Issue: Response to failed BiDir challenge is unclear

  • Legacy Issue Number: 7308
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The actions that result from the failure of a BiDir challenge are unclear.

    RECOMMENDATION:
    The client has proven itself untrustworthy. A BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is returned to the client and all bi-directional connections to the client are closed.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

CodeSet issue (04)

  • Legacy Issue Number: 7200
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Can Codeset come before/with Firewall Traversal in Negotiate Session
    meesages?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 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: Mon, 30 Mar 2020 19:47 GMT

CodeSet issue (02)

  • Legacy Issue Number: 7198
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Does Codeset get negotiated in only the other direction?
    If so, will that happen in Negotiate Session meesages orRequest Messages?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 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: Mon, 30 Mar 2020 19:47 GMT

CodeSet issue (03)

  • Legacy Issue Number: 7199
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    On a connection in which BiDir is negotiated, but no Codeset
    is negotiated, will the reverse direction be able to negotiate
    code set?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 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: Mon, 30 Mar 2020 19:47 GMT

CodeSet issue (01)

  • Legacy Issue Number: 7197
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Does the CodeSet get negotiated in Negotiate Session?
    If so, does Codeset continue to get negotiated in Requests?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 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: Mon, 30 Mar 2020 19:47 GMT

GIOP version 2.0 issue

  • Legacy Issue Number: 7168
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    The following paragraph raises an interesting issue. If we follow this to the letter

    • since it says that the new version of GIOP is not backward compatible with the
      earlier versions of GIOP, it implicitly appears to make this new GIOP version a
      new "major" version of GIOP. Clearly we need to figure out a way to avoid doing
      this, since creating GIOP version 2.0 in this way raises all sorts of other issues.

    From the second paragraph on page 1-30 of the Firewall Final Adopted Spec (ptc/04-04-01):

    This document supercedes the previously adopted CORBA firewall specification. In
    addition, the changes to bi-directional GIOP, specified in Chapter 15, supercede the
    adopted specification for bi-directional GIOP. These specifications are not backwards
    compatible with the previous specifications and they are intended to make it possible
    to create a functional protocol for the interoperation of ORBs and firewalls.

  • Reported: CORBA 2.5 — Fri, 19 Mar 2004 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: Mon, 30 Mar 2020 19:47 GMT

use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous

  • Legacy Issue Number: 7353
  • Status: closed  
  • Source: Real-Time Innovations ( Dave Stringer)
  • Summary:

    ptc/04-04-06 section 15.9.1 (top of page 15-67) states:
    When the server receives a BI_DIR_GIOP_OFFER context it must send back a
    BI_DIR_GIOP_ACCEPT context in both the strong and weak identification cases.

    What happens if an ACCEPT service context is not returned? Either immediately
    or ever?

    Can a connection initiator, having sent an OFFER SC, send any further GIOP
    messages over that connection prior to receiving the ACCEPT SC?

    Should a connection initiator, having sent an OFFER SC but not having received
    an ACCEPT SC, accept a Request (i.e in the reverse direction) on that connection?
    a) for an object whose POA's BiDirId has been offered and accepted?
    b) for an object whose POA's BiDirId has been offered but a corresponding
    ACCEPT has not yet been received?
    c) for an object whose POA's BiDirId has been offered and accepted only over a
    different connection (to that over which the Request arrives)?
    d) for an object whose POA has a BiDirId but it hasn't yet been offered?
    e) for any object (e.g. one whose POA doesn't have a BiDirId)?

    If an OFFER SC is sent on a Request message, can the corresponding ACCEPT
    SC be carried on any GIOP message from the connection acceptor?
    a) the associated Response
    b) a Response not associated with the Request
    c) a NegotiateSession message
    d) a Request message for an object whose POA's BiDirId has already been
    negotiated

    If an OFFER SC is sent on a NegotiateSession message, can the corresponding
    ACCEPT SC come piggy-backed on any GIOP message (that can carry SCs) or
    must it come over a NegotiateSession message?

    If two POAs (with EXPORT policy) are created and their BiDirIds are sent separately
    in OFFER SCs on separate messages over a given connection, is a subsequently
    received ACCEPT SC deemed to relate to one or to both of the offered BiDirIds?

    Since I assume that a connection is effectively promoted to BiDir once the first
    ACCEPT SC (indicating no error) is received. What is the point of insisting that
    the connection acceptor "must" send additional ACCEPT SC?

    In fact, even wthout any ACCEPT(no error) SCs, the occurrence of a GIOP Request
    message from the connection acceptor would imply that the connection acceptor
    has accepted the BiDirId. It would seem that the ACCEPT(no error variant) SC is
    completely superfluous.

    Given the ambiguities in the protocol, it seems likely that an implementation may
    find the real-world interactions to have broken its model of the protocol. What should
    a GIOP protocol machine do in such a situation?

    If the connection initiator deems that the OFFER-ACCEPT protocol has gone wrong
    should it be required to close the connection?

    As there is no correlation between OFFER SCs and ACCEPT SCs, on a given
    connection, does an ACCEPT (indicating an error) imply that the connection is
    in an indeterminate state and should be closed?

    If a connection is to be closed due to an error in the OFFER-ACCEPT protocol do
    the normal rules regarding outstanding invocations apply? Do they apply for both
    directions?

  • Reported: CORBA 2.5 — Thu, 13 May 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

Bi-directional connections considered volatile at connection acceptor side

  • Legacy Issue Number: 7352
  • Status: closed  
  • Source: Syracuse University ( C. Joncheng Kuo)
  • Summary:

    This issue was mentioned by Dave Stringer. I now file it as an issue.

    When a bi-directional connection is established between a connection initiator and a connection acceptor, the connection acceptor may have to consider this bi-directional connection is volatile, i.e., the connection acceptor may lose (and is not able to resume) its capability of making invocations on such a connection anytime. For example, the connection may be lost due to network problems or the client may close a connection due to an idle time-out. These situations are not a problem for uni-directional GIOP because the ORB who wants to make an invocation can always initiate a new connection when the old connection is not available.

    This problem may be less serious when bi-directional communication occurs only during the period of an invocation from the connection initiator. In other words, if the connection is lost and results in the failure of bi-directional "callback", the connection initiator may retry, effectively resuming the bi-directional connection.

    On the other hand, for the use case in which a connection initiator "registers" an object reference to the connection acceptor, there is no guarantee that "callbacks" from the connection acceptor to the connection initiator will eventually succeed, assuming the network is not always down.

    If this issue is a limitation that cannot be solved easily, we should spell it out in the spec.

  • Reported: CORBA 2.5 — Tue, 11 May 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

How many BI_DIR_GIOP_OFFER service contexts are allowed

  • Legacy Issue Number: 7318
  • Status: closed  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The Bidirectional GIOP spec does not specify how many BI_DIR_GIOP_OFFER service contexts are allowed in a NegotiateSession or Request.

    If only one such service context is allowed, it shall be stated clearly. Besides, because each BI_DIR_GIOP_OFFER service context can contain only either strong or weak BiDirIds (but not both), if there are both strong and weak BiDirIds on the ORB, the ORB has to use at least two GIOP messages to send them all.

    If we allow multiple BI_DIR_GIOP_OFFER service contexts in one message, we'll have a problem in matching BI_DIR_GIOP_ACCEPT service contexts to these offers because there is no sequencing on offers and accepts.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY

  • Legacy Issue Number: 7351
  • Status: closed  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    Part of this issue has been surfaced in the discussions over the mail list. I now file it as an issue.

    The Bi-directional GIOP spec says, "An object reference with a BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional
    connection." Satisfying this policy requirement does not close some potential limitation and ambiguity when other policies or policy instances are around.

    For example, at the connection initiator side, we may have two object references one of which has BidirectionalOfferPolicy of DENY and the other has BidirectionalOfferPolicy of ALLOW. If these two object references point to the same server, according to spec, we need two connections to the server: one is bi-directional and one is not. However, having a non-bi-directional connection doesn't mean much. For invocations on the object reference with the DENY policy, the server side can always callback using the other bi-directional connection.

    There is an argument (by Brian Niebuhr) saying that it's not realistic to both trust and not trust the same server. However, in practice, it's not always possible to tell whether two object references point to the same server or not. Furthermore, the client may decide whether or not to trust the server of an object reference depending on reasons other than the information about the server. For example, the client may decide to use BidirectionalOfferPolicy of ALLOW or DENY according to the source of an object reference.

    On the other hand, at the connection acceptor side, things become a little more interesting. For an object reference with BidirectionalAcceptPolicy of ALLOW and effective BidirectionalOfferPolicy of DENY (e.g., the default policy on that ORB), what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has offered as bi-directional." However, shall we let the BidirectionalOfferPolicy of DENY prohibits the use of such a bi-directional connection? Or shall we allow the use of such a bi-directional connection because it's in the "reverse" direction?

  • Reported: CORBA 2.5 — Tue, 11 May 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

connection_complete field of the FirewallPathRespContext is under specified

  • Legacy Issue Number: 7317
  • Status: closed  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The connection_complete field of the FirewallPathRespContext is under specified.

    The fourth paragraph (including IDL) from the end of Section 1.5.4, Firewall Service Context, says,

    “Once the connection has been established, the last intelligent firewall in the FirewallPath sends a FIREWALL_PATH_RESP service context in another NegotiateSession message.”

    However, the last paragraph of this section says that, when the connection is not completely established, a FIREWALL_PATH_RESP service context with the connection_complete field of false is sent.

    Furthermore, when the connection_complete field is false, the spec does not explain what are the situations that may cause incomplete connection establishment and what the client shall do for “further processing”. Shall the FIREWALL_PATH_RESP service context also contains information indicating what the client shall do?

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

Targets of Export and Offer Policies incompletely specified

  • Legacy Issue Number: 7315
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The target (ORB, POA, object, thread) of the Export and Offer policies and the side of the connection involved is incompletely specified.

    RECOMMENDATION:
    Define the two sides of a connection as the connection 'Initiator' and connection 'Acceptor'. The usual terms of 'client' (Initiator) and 'server' (Acceptor) become confusing in a bi-directional situation. Given those terms for each side, specify that the Export and Offer policies are used on the Initiator side. Specify that the Export policy may be applied to the ORB, the POA and/or to the thread. Specify that the Offer policy can be applied to the Initiator ORB, to a reference in the Initiator for an object in the Acceptor, or to a thread in the Initiator ORB.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

Expected behavior of a non-conformant implementation

  • Legacy Issue Number: 7316
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    It is not defined what happens if a non-conformant implementation receives a BiDir offer.

    RECOMMENDATION:
    State that a non-conformant implementation need not do anything - it may simply ignore the offer.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

Processing of NegotiateSession messages at various stages of connection set

  • Legacy Issue Number: 7314
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP Document discusses three stages of connection setup, but it is unclear when each stage begins and when it ends. It is also unclear what NegotiateSession or Firewall activity can take place in each stage and what the order of processing may be.

    RECOMMENDATION:
    Rewrite the relevant portions of the document to specify the following (excerpted without edit from Brian Niebuhr's discussion of NegotiateSession contexts and the stages of setup):

    "...during connection setup, only firewall contexts can be in the negotiate session message, NOTHING ELSE. After the connection is setup, there is a period before the first request or locate request where we can do session setup items. I think that in that period, only Bidir contexts can be sent, NOTHING ELSE. The first request or locate request indicates the connection_established period. Again, during that period I think only the Bidir contexts should be legal. This makes things very simple. There are no conflicts between firewall and bidir, and nothing else can go in a negotiate session message."

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

Firewall FTF Issue: No ene-to-end security for firewall traversal

  • Legacy Issue Number: 7313
  • Status: closed  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The title of Section 1.7, End-to-End Secure Connection, is misleading. There is no end-to-end security in the firewall traversal spec. All security mechanisms described in this spec are essentially mechanisms between a client, firewalls, and a server, not end-to-end. Thus, it is susceptible to the man-in-the-middle attack.

    I'm saying we should fix the problem, but the title of this section and the caption of Figure 1-4 is certainly misleading. Besids, if the firewall traversal scheme described in the spec is actually susceptible to the man-in-the-middle attack, we may want to consider stating it somewhere in the spec rather than making people have a wrong impression that it is secure

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04: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: Mon, 30 Mar 2020 19:47 GMT

Include GIOP over Bluetooth into Wireless CORBA 1.1

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

    Include GIOP over Bluetooth into Wireless CORBA 1.1

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

    see below

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

TypeCode interface issue

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

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

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

    No Data Available

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

Valuetype initialzers need exceptions

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

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

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

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

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

    Specfic text changes:

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

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

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

    instead of:

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

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

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

    instead of:

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

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

    Accept the proposed change based on discussion above

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

New core issue: need UNKNOWN reply status

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

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

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

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

    Revised text:

    In section 21.3.12.10, add after PortableInterceptor::TRANSPORT_RETRY:

    PortableInterceptor::UNKNOWN

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

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

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

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

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

    const ReplyStatus UNKNOWN = 5;

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

    No Data Available

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

Syntax error in CORBA IDL

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

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

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

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

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

    see below

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

Issue for components: No meta model for CIDL ?

  • Key: ZIOP-81
  • Legacy Issue Number: 4575
  • Status: closed  
  • Source: Humboldt-Universitaet ( Harald Boehme)
  • Summary:

    There is no meta model for the CIDL language from orbos/99-07-01 in
    orbos/99-07-02.

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

    see below

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

minor IDL changes required in CCM API

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

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

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

    valuetype FacetDescription : PortDescription

    { public Object facet; }

    ;

    should be replaced by

    valuetype FacetDescription : PortDescription

    { public Object facet_ref; }

    ;

    because 'facet' is a CIDL keyword.

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

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

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

    ;

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

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

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

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

    ;

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

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

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

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

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

    get_oid_from_ref (in Object ref)

    should be replaced by

    get_oid_from_ref (in Object objref)

    because 'ref' is a PSDL keyword.

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

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

    get_cid_from_ref (in Object ref)

    should be replaced by

    get_cid_from_ref (in Object objref)

    because 'ref' is a PSDL keyword.

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

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

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

    should be read as

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

    because 'ref' is a PSDL keyword.

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

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

    should be read as

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

    because 'ref' is a PSDL keyword.

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

    Accept the previous required changes.

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

Little problem with introspection API

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

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

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

    see below

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

CCM: Meaning of "exposed" scopes unclear.

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

    ccm/01-08-04 says

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

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

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

    and the following import statement

    import X::Y;

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

    module X{
    interface another_interface{};
    };

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

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

    see below

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

CCM: import and re-opening of modules

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

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

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

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

    and the import statements

    import A;
    import B;

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

    module Y{
    interface another_interface{};
    };

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

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

    import A;

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

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

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

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

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

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

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

    See issue 4577.

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

CCM: Isolated scope tokens

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

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

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

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

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

    see below

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

CCM: Definition of import declaration unclear

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

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

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

    module A {
    module B {
    interface C {
    struct S

    {long a;}

    ;
    };
    };
    };

    Now consider the import statement

    import A::B;

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

    It is unclear whether in this context, the definition

    interface D : C {};

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

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

    interface D : B::C {};

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

    Furthermore, the text could be understand to mean that

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

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

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

    see below

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

Issue for Components: Missing language mapping

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

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

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

    see below

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

Changing VSCID prefix to 24 bits

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

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

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

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

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

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

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

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

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

    see below

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

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

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

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

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

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

    see below

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

IDL for ORB::resolve_initial_references

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

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

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

    close, no change

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

the IDL include directive should introduce declarations into the namespace

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

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

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

    close, no change

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

set_length operation of the DynSequence interface

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

    The set_length operation of the DynSequence interface is defined as:

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

    in the IDL but is defined as:

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

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

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

    see below

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

Implied IDL for interfaces in modules

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

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

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

    module Stock {
    interface StockManager

    { ... }

    ;
    };

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

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

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

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

    see below

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

DynUnion operations

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

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

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

    see below

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

Chapter 11, section 11.3.8.19 (WrongPolicy)"

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

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

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

    see above

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

Problem with IDL Context interface

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

    a few problems with IDL contexts:

    1) On page 4-32, with have:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    11) For get_values(), it says:

    The NO_MEMORY exception is raised if dynamic memory allocation fails.

    This sentence is utterly redundant.

    12) For get_values(), we have:

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

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

    13) For get_values(), we have:

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

    However, for create_child(), we have:

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

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

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

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

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

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

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

    So, what happens if I have

    interface I

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

    ;

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

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

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

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

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

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

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

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

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

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

Support for is_a for local interfaces

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

    Proposal: Section 3.7.6.1: Change the bullet that says

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

    to:

    • The get_interface, get_domain_managers, get_policy,
      get_client_policy, set_policy_overrides, get_policy_overrides, and
      validate_connection pseudo-operations, and any DII support
      pseudo-operations,
      may result in a NO_IMPLEMENT system exception with minor code 3 when
      invoked on a reference to a local object.
  • Reported: CORBA 2.5 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    Reflect this fact as follows

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

Section 11.3.8.16 - ambiguity

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

    My issue is the ambiguity surrounding the following statement:

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

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

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

    No Data Available

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

CORBA 2.5 and Portable Interceptors mismerged

  • Key: CORBA3-37
  • Legacy Issue Number: 4585
  • Status: closed  
  • Source: Vanderbilt University ( Ossama Othman)
  • Summary:

    The new Portable Interceptor chapter in the CORBA 2.5 specification
    has apparently been mismerged. Section 13.8 "Coder/Decoder
    Interfaces," the Codec related interfaces added to the "IOP" module,
    should supercede those in the deprecated "IOP_N" module that is listed
    in section 21.10 "Portable Interceptor IDL."

    Suggested changes include:

    • Remove the IOP_N module from Section 21.10 "Portable Interceptor
      IDL."
    • Change all instances of "IOP_N" to "IOP." In particular, methods
      listed in sections 21.3.13 (ClientRequestInfo IDL) and 21.10 refer
      to the "IOP_N" module. The following methods in section 21.10 must
      be updated:

    module PortableInterceptor {

    // ...
    local interface ClientRequestInfo

    { // ... IOP_N::TaggedComponent get_effective_component (...) IOP_N::TaggedComponentSeq get_effective_components (...) // ... }

    ;
    // ...

    local interface ORBInitInfo

    { readonly attribute IOP_N::CodecFactory codec_factory; }

    ;

    };

  • Reported: CORBA 2.5 — Mon, 1 Oct 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fixed in CORBA 3.0 (ptc/02-01-14). Close no change

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

Alignment for empty sequence?

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

    struct X

    { long long_1; sequence<double> double_seq; long long_2; }

    ;

    The question is, how should things be padded if double_seq is empty?
    (Assume that we are starting at byte offset 0 for marshaling this structure.)

    Approach taken by ORB 1:

    • long_1 is aligned on a four-byte boundary (offset 0).
    • The length of double_seq is aligned on a four-byte boundary,
      immediately following long_1 (offset 4).
    • long_2 is aligned on a four-byte boundary. Because double_seq is
      empty, this means that long_2 immediately follows the length of
      double_seq on the wire, so long_2 begins at offset 8 and the total
      number of bytes for the struct is 12.

    Approach taken by ORB 2:

    • long_1 is aligned on a four-byte boundary (offset 0).
    • The length of double_seq is aligned on a four-byte boundary,
      immediately following long_1 (offset 4).
    • Now four bytes of padding are inserted because the sequence element
      type is double, so the next data item is expected to start on
      an eight-byte boundary.
    • long_2 is aligned on that eight-byte boundary, so long_2 begins at
      offset 12 and the total number of bytes for the struct is 16.

    The spec isn't clear on what should happen:

    Sequences are encoded as an unsigned long value, followed by the
    elements of the sequence. The initial unsigned lon gcontains the
    number of elements in the sequence. The elements of the sequence
    are encoded as specified for their type.

    >From this, I cannot infer unambiguously which interpretation is correct.

    Both approaches seem reasonable. (Personally, I have a slight preference
    toward approach 2 because it's more consistent: after consuming the sequence,
    the next data item will always start on an 8-byte boundary, which is more
    consistent than approach 1, because the padding rules don't depend on the
    length of the sequence at run time.)

    I suspect that the best way to resolve this might be to take a majority vote
    in line with the behavior of current implementations. And, of course,
    the question now is what do we do with the GIOP version? We probably should
    increment it, but I don't see what that would achieve for already existing
    implementations, sigh...

  • Reported: CORBA 2.5 — Tue, 30 Oct 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, no change necessary

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

Detecting Recursion in Other Interceptors

  • Key: CORBA3-36
  • Legacy Issue Number: 4554
  • Status: closed  
  • Source: International Business Machines ( Tim Baldwin)
  • Summary:

    We have identified a requirement where the interceptors for one service
    need to be able to detect recursive invocations made by some other
    interceptor during the processing of a request. As far as we have been
    able to determine there is no way to achieve this using the
    Request-scope/Thread-scope Current mechanism described in the spec.

    It is probably easiest to explain this using a specific example. Start
    with some form of "transaction" service that registers client-side
    interceptors so it can detect all new request invocations and add service
    contexts that perform some form of "begin transaction" processing at the
    server. This transaction service must only perform this "begin
    transaction" once per application-level request, so it allocates a
    PICurrent slot and performs the processing described in section 21.4.4.2 to
    ensure that any recursive calls it makes itself will form part of the same
    transaction and not begin a new one.

    However a problem now occurs if we introduce some other service, say a
    "security" service that has its own interceptors registered. The order in
    which these two service's interceptors run can affect what happens, but
    since interceptor ordering is undefined assume that the security
    interceptor runs first.

    An application makes a request on its own thread A. The send_request
    interceptors start to run on thread B and the security interceptor runs
    first, at this point both the RSC and TSC slots for the transaction service
    are empty. The security interceptor makes a recursive request so the
    send_request interceptors run again on a new thread C. The security
    interceptor runs again and this time doesn't recurse so the transaction
    interceptor now runs on thread C. At this point it finds its RSC slot
    empty so does a "begin transaction" and sets its TSC for thread C. We've
    now finished interceptors on thread C and return to thread B and invoke
    send_request for the transaction service. Once again it finds its RSC slot
    empty and will try to "begin transaction" again. Now we have a problem as
    we have issued two "begin transactions" for the same application request.

    In fact it as actually the second of those two "begin transactions" that we
    really want to do, as that represents the true start of the application's
    transaction. The first one (caused by the recursive call in the other
    interceptor) is at best redundant and wasteful and at worst wrong and
    problematic.

    Does anyone have any comments on this problem?

  • Reported: CORBA 2.5 — Tue, 4 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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