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

;

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.

duplicate of issue 5898

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

issue closed editorially

> // 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)

Undo the resolution of issue 4476 and close 4478 no change

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

;

where ProfileSeq is defined as

module IOP

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.

see above

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.

Add a clarification to the specification

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.

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

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...

close no change