Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — All Issues

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

Issues Descriptions

What is the RSC when using a PersistentPoller

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

    What is the RSC when
    > using a PersistentPoller? Since it is a valuetype that can be passed
    > from one process to another, the RSC obviously can't be the same in the
    > other process as at the original invocation point.
    >
    > Anybody have any bright ideas for this one? Should it be empty? A copy
    > of the TSC at the poll point? Change MessageRouting:PersistentRequest
    > to have an attribute that provides access to a copy of the RSC, and
    > PersistentRequestRouter::create_persistent_request to have the RSC as an
    > "in" argument?

  • Reported: CORBA 3.0.1 — Mon, 25 Nov 2002 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

Type code creation

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

    The core spec says in section 4.11.3:

    Typecode creation operations that take name as an argument shall check that
    the name
    is a valid IDL name or is a null string.

    This is oxymoronic: we are talking about IDL here; IDL does not have the
    concept of
    a null string. If anything, we can say "empty string".

    Looking at this bit of spec, it would appear that a call such as

    orb->create_interface_tc(someRepId, 0);

    is legal. But that doesn't make sense because it's illegal to pass null
    pointers
    across IDL interfaces in C++ (or null references as strings in Java).

  • Reported: CORBA 3.0.1 — Sun, 1 Dec 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fix as suggested

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

Unfortunate CDR Encapsulation of ASN.1 Encodings

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

    Document: Chapter 24 Corba, CSIv2

    There is a misinterpretation in the current JDK implementations as to the
    interpretation of the word of "encapsulation" in the CSIv2 specification
    in relation to the encoding of the fields within the CSI Identity Token.

    The issue is that the JDK and already certified implementations have
    performed a CDR encapsulation of the byte arrays within the Identity
    Token. This CDR encapsulation is not needed as the the Identity Token is
    already a CDR encapsulation, so further CDR encapsulating the byte array
    containing the ASN.1 encodings is inefficient.

    We can suggest that current implementations do not generate CDR
    encapsulation for these fields, yet accept them to be compatible with
    misaligned implementations.

    Proposed Fix:

    Remove the word "encapsulation" before "octet stream" from the rows of the
    table 24-2 "Identity Token Types".

    Remove the word "encapsulation" in the paragraph in section 24.2.3
    "Authorization Token Format".

    Remove the word "encapsulated" in the comments in the IDL section for the
    definition of the X509CertifcateChain.

    Remove the sentence "The two-part SEQUENCE is encapsulated in an octet
    stream." in the IDL definition for "const AuthorizationElementType
    X509AttributeCertChain".

    Add paragraph to section 24.2.5 "Identity Token Formats".

    The identity token for ITTPrincipalName, ITTDistinguishedName,
    ITTX509CertChain should contain their respective ASN.1 encodings of the
    name directly. However, the token may contain a CDR encapsulation of the
    octet stream that contains the ASN.1 encoding of the name. The TSS shall
    distinguish the difference by the first octet of the field. The values of
    0x00 or 0x01 shall indicate that the field contains a CDR encapsulation.
    Any other value indicates the field for these identity token types
    contains the ASN.1 encoded value. For instance, the ASN.1 encoding for
    ITTPrincipalName starts with 0x04, and ITTDistinguishedName and
    ITTX509CertChain each start with 0x30. The TSS shall accept both the CDR
    encapsulation form and the direct ASN.1 encoding for these identity token
    types.

  • Reported: CORBA 3.0.1 — Tue, 19 Nov 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Indeed a severe interoperability problem. Fix as suggested.

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

add a ClientInterceptor then create_POA() in the post_init() method?

  • Key: CORBA3-95
  • Legacy Issue Number: 5764
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Isit possible to add a ClientInterceptor then create_POA() in the
    post_init()
    method? It seems that the ClientInterceptor is not called after that. Do
    you know the
    reason why?

    My Investigation:
    If the post_init method in SampleClientLoader.C creates the new POA
    using create_POA method, the client side PI will not be called. Even if
    an ORB-mediated call is made from within post_init(), ServerInterceptor
    is called beyond the scope of post_init(). Moreover, even if an
    ORB-mediated call is made from within post_init() in VisiBroker for
    Java, ClientInterceptor and ServerInterceptor are called beyond the
    scope of post_init(). However, in Visibroker for C++, the
    ClientInterceptor of VBC is not called. Please see the attachments for
    the difference in results of VBC & VBJ. A testcase is also attached.

    Any comments will be greatly appreciated.

  • Reported: CORBA 3.0.1 — Mon, 18 Nov 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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