Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — Closed Issues

  • Acronym: CORBA
  • Issues Count: 7
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

insufficient examples of component attributes

  • Key: CORBA3-133
  • Legacy Issue Number: 5906
  • Status: closed  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

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

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

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

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

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

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

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

    component Whatever

    { attribute long cacheMaxKb; }

    ;

    home WhateverHome manages Whatever
    {
    };

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

    we->cacheMaxKb(200);

    we->configuration_complete();

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

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

  • Reported: CORBA 3.0.2 — Thu, 10 Apr 2003 04:00 GMT
  • Disposition: Duplicate or Merged — CORBA 3.0.3
  • Disposition Summary:

    duplicate of issue 5898

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Error in Chapter 21 of CORBA 3.0

  • Key: CORBA3-131
  • Legacy Issue Number: 6912
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    there is a serious error in Chapter 21 in both the CORBA 3.0 specification and the 3.1 drafts. The ORT final adopted specification (ptc/01-08-31 mentioned above) does NOT contain the methods ObjectReferenceFactory::equals an ObjectReferenceFactory::make_profiles. These methods were first added in the ORT FTF in issue 4476, then removed after further discussion in issue 4478. The final adopted specification reflects this, but somehow the incorrect text was incorporated into the official CORBA 3.0 specification. Unfortunately I only noticed this recently

  • Reported: CORBA 3.0.2 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    issue closed editorially

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

Creating IORs

  • Key: CORBA3-128
  • Legacy Issue Number: 4478
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    > // ulgy conversion to objectref: we should think about
    > // creating utilities for IOR<->objref conversion

    I meant to raise that second issue (the ugly IOR to ObjRef conversion).
    It is too painful and I think we should address it. I can think of a few
    possible solutions.

    1. have make object just return profiles, so the ORB can do the
    conversion internally.
    2. Add a method on the ORT to provide this functionality
    3. Add a separate CODEC interface to manufacture IORs from Profiles
    (IORFactory, rir etc)

  • Reported: CORBA 2.4.2 — Tue, 14 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    Undo the resolution of issue 4476 and close 4478 no change

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

There is no way to modify a POA's ORT and append to it

  • Key: CORBA3-127
  • Legacy Issue Number: 4476
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    If I wish to register an ORF (ObjectReferenceFactory) as the current
    factory, there is no way for it to append to the current template. In
    other words, an updated factory can only replace the original but not
    say add another profile to the one the given POA would generate w/ the
    adapter template.

    As an inverse, there is no way for a POA to require or even request an
    ORF to include profiles that it deems fit.

    Proposal:

    Add a parameter to make_object

    Object make_object( in string repositoryId, in ObjectId id,
    ObjectReferenceTemplate template);

    Add the following methods to ObjectReferenceTemplate

    abstract valuetype ObjectReferenceTemplate : ObjectReferenceFactory

    { readonly attribute ServerId server_id ; readonly attribute ORBId orb_id ; readonly attribute AdapterName adapter_name; ProfileSeq getProfiles(in string repositoryId, in ObjectId id); ComponentSeq getComponents(in IOP::ProfileId profile_id); }

    ;

    where ProfileSeq is defined as

    module IOP

    { typedef sequence <TaggedProfile> ProfileSeq; typedef sequence <TaggedComponent> ComponentSeq; }

    Add the following sections:

    21.5.3.8 getProfiles

    This returns the set of profiles that the POA would have generated using
    its default template. This can optionally be included in the generated
    IOR.
    [ED: This is independent of make_object, because make_object returns an
    object reference from which profiles would have to be extracted for
    inclusion]

    21.5.3.9 getComponents
    This returns set of components that would have been include in the
    profile with the id profile_id and allows the factory to choose to
    include those in the profiles that it generates.

  • Reported: CORBA 2.4.2 — Sun, 12 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    see above

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

Interoperability of ObjectReferenceTemplate and Factory.

  • Key: CORBA3-126
  • Legacy Issue Number: 4445
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    Nothing in the specs (I think the submission does say this somewhere)
    say that the valuetypes defined in this spec and implemented by the ORB
    vendor are not expected to be transmitted across different ORB
    implementations.

    Proposal:

    Add paragraph to 51.5.3.1:

    Concrete definitions and implementations of ObjectReferenceTemplate and
    ObjectReferenceFactory are ORB implementation specific and are not
    defined as they are not expected to be exchanged between ORB
    implementations.

  • Reported: CORBA 2.4.2 — Thu, 2 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    Add a clarification to the specification

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

Object Adapter name problem in ORT

  • Key: CORBA3-125
  • Legacy Issue Number: 4440
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    The adopted specification for the Object Reference Template is
    ptc/01-04-03. This specification introduces adapter names for
    object adapters. Adapter names are needed in the definition of the
    ObjectReferenceTemplate abstract valuetype. An AdapterName is
    simply a sequence of strings that is used to identify an
    instance of an object adapter.

    In the case of the POA, the spec defines the AdapterName as follows
    in section 21.5.2.1:

    In the case of the POA, the adapter name shall be the sequence
    of names starting with the root POA that is required to reach
    the POA using the find_POA call. The name of the root POA is
    the empty sequence.

    Also, in section 21.3.14.6:

    The adapter_name attribute defines a name for the object adapter that
    services requestws for the invoked object. In the case of the POA,
    the adapter_name is the sequence of names from the root PAO to the POA
    that services the request. The root POA is not named in this sequence.

    The problem here is that the POA occupies the entire name space of
    possible adapter names, so an ORB that supports other proprietary
    object adapters cannot unambiguously identify instances of other
    object adapter through ServerRequestInfo.adapter_name.

  • Reported: CORBA 2.4.2 — Mon, 30 Jul 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    Update the specification so that the Object Adapter ID of the root POA is

    { "RootPOA" }
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Overriding POA policies

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

    it appears to be impossible to portably attach OTS policies
    to POAs with the machinery that is currently in place. We need a fix for
    that, otherwise OTS ends up getting hamstrung...

  • Reported: CPP 1.1 — Mon, 15 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    close no change

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