Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 2238 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 2238.

Report 2238 Actions

    Problem Report Number 2238
    Submitter's Classification Specification problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0627
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard CORBA
    Certification Program The Open Brand certification program
    Test Suite VSORB version 1.0.1
    Test Identification All/All/All -
    Problem Summary PG4O.00002 We request an Interpretation to be made on the use of an Environment parameter as part of our ORB's C++ mapping. Currently the VSORB test suite flags this as an error. We believe that it is compliant...
    Problem Text
    We request an Interpretation to be made on the use of an Environment
    parameter as part of our ORB's C++ mapping. Currently the VSORB test suite
    flags this as an error. We believe that it is compliant with the CORBA
    2.1 standard.

    We believe that the Environment parameter should be accepted by the test
    suite for the following reasons:

    1. The use of the Environment parameter is required for environments which
    do not support exception handling.
    2. The CORBA 2.1 specification does not preclude the use of any number of
    additional defaulted parameters as part of the C++ mapping.
    3. We wish to maintain backward compatibility for existing customers,
    many of whom are using the Environment parameter.
    Test Output
    Numerous compiler error messages

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    We recommend this request be refused.

    While we appreciate there is an installed base issue for some
    ORB vendors in transitioning to a CORBA-conforming ORB implementation
    this seems a vendor-specific issue. As such it should be addressed as
    part of the conformance transition strategy of these vendor(s) involved
    rather than within the CORBA branding program.

    Given the incompatibility between the two exception mappings at the
    application level this also seems the only position CORBA branding
    can accomodate on this issue without significantly compromising
    its goal of having portable CORBA applications.

    Additional Comments

    The CORBA IDL to C++ mapping is predicated on the C++ Annotated Reference
    Manual which requires, among other things, compiler support for native
    exception handling. The spec also discusses alternative mappings
    for use with C++ compilers which do not support some ARM requirements.

    One of these alternative mappings is an approach for mapping IDL to
    C++ compilers that do not support native exception handling. This alternative
    mapping adds an additional parameter to C++ method signatures mapped
    from IDL and has the ORB return exception information in this parameter,
    named Environment.

    VSORB tests for compliance to the CORBA IDL to C++ mapping and not for
    compliance to any alternative mappings. An ARM-compliant C++ compiler
    (supporting native exceptions) is a prerequisite for testing. The
    presence of Environment parameter is not allowed to be visible
    in the language binding used for branding.

    To the best of our knowledge the submitter's implementation will use native
    exception handling if it is available but also always includes the
    Environment parameter in its method signatures and returns expection
    information in it. That is, it provides method signatures based on the
    alternative non-expection mapping even in an environment where it is
    providing exception information through C++ exceptions as per the base
    mapping.

    We believe this behavior is non-conforming. In terms of the three rationales
    provided in the IR.

    1) Support for non-exception environments

    We consider this an enhancement request and hence out of scope.

    The policy that VSORB tests only the C++ native exception handling mapping
    has been in place since the inception of the project, and was specified
    in all the materials (Test Spec, User Manuals, etc) reviewed by the ORB
    vendors involved in the the X/Open VSORB Test Suite Development Group.
    In its September 1997 meeting the TDG (including representatives of the
    submitter) discussed this at length and reaffirmed, per the minutes
    of this meeting:

    o the C++ complier used for testing must supply native exception
    handling and the test suite will verify the ORB's C++ mapping is
    that which the spec defines for use with such a dialect

    Altering this policy has substantial cost implications and needs to be
    resolved as a business issue, not a spec interpretation.

    2) The spec allows the Environment parameter in all mappings

    We disagree with this on technical grounds.

    This is a different issue than (1) - rather than asking VSORB to
    test the alternative mapping it suggests the Environment parameter
    should be allowed to be provided in method signatures even in
    the mapping which uses native exception handling.

    We do not believe the CORBA specification in fact allows
    this behavior as conforming. Section 18.19 for instance clearly
    states that C++ exceptions are used for passing exception information,
    not Environment parameters, unless native exception handling is
    unavailable.

    Further, the exception mapping and the alternative mapping are not source
    code compatible and supporting both would preclude application portability
    across branded systems. In fact we do not see how a portable C++
    application could be written if the optional provision of the Environment
    parameter by an ORB and its use by an application were to be allowed in
    the base C++ mapping.

    3) Backward compatability.

    We consider this to be out of scope.

    An ORB vendor is likely to have products with some degree of non-compliance
    in its installed base and be faced with transitioning users to its compliant
    products. VSORB and the CORBA branding program accomodate this as they
    leave vendors free to have additional modes of operation for other
    behavior as long as they offer strictly conforming behavior for VSORB
    to test. How this is implemented is however beyond the scope of VSORB
    and CORBA branding which provides a vendor-neutral validation of CORBA
    conformance, leaving to vendors the decision how best to achieve a
    transition to meeting these requirements. Here for example the
    submitter could have offer an second alternative C++ binding including
    the Environment parameter or employ ifdefs to accomodate their current
    implementation without needing to impact the base mapping that is
    required for branding.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    It appears that the request for Interpretation has some validity. That
    the behavoir desired is within the current specification.

    The Open Group recognises that there is no error in the operation
    of the tests. However, in reading the appropriate sections from
    the CORBA 2.1 standard, there does not appear to be any specific
    text that precludes the behavoir desired in this interpretation.

    The Open Group does, however, recognise that the use of the Environment
    parameter will mean that the portability of applications across multiple
    environments will be impacted and this needs to be considered in
    responding to the interpretation.

    If this behavoir is seen as permissible, then it would be beneficial if
    RTF also make a statement on the long term validity of such a behavior,
    and/or the desire to require implementors to use Native C++ Exception
    Handling.

    Post review
    -----------
    The implementation has been deemed to be conformant and this has been
    reflected in a workaround provided to the customer to enable the
    large number of tests which previously failed to give the correct
    result. This will be reflected in a formal release due early September.
    This interpretation request is therefore refused and the customer should
    run the authorised workaround.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    The decision of the voting members of this group is that the ORB in
    question does conform to the specification.

    The concensus was that server-side operation signatures in CORBA 2.1 are
    not specified, and therefore are not subject to conformance. Since the
    parameter is defaulted on the client side, the presence or absence of the
    additional parameter doesn't affect client code portability.

    It should be noted that the addition of the POA specification in the next
    version of the product standard will change this situation, as it does
    precisely specify server-side operation signatures. Therefore C++ Native
    Exception handling will need to be used in this situation.


    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion
    This request is refused.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority