CORBA 2.6 NO IDEA Avatar
  1. OMG Issue

CORBA26 — 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

    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