The question is about 99-07-41.pdf, as far as I know the latest C++ mapping specification. "1.41.5 Any Class" prescribes "Boolean operator>>=(const Any&, const char*&);" for unbounded strings, and "1.16.3 Extraction from any" says that unbounded strings are extracted by value. This seems to be contradictory: I seem to remember that const char* cannot be delete'd, though I don't find it in ISO/IEC 14882:1998(E). But, regardless of anything imposed by C++, the current mapping precludes a safe technique like (safe as in exception-proof): >> String_var theString; if(!(theAny>>=theString.out()))

<< I therefore propose that the mapping be changed to "Boolean operator>>=(const Any&, char*&);". This seems to work all right on my implementation (RayORB), for gcc 3.2 (MS VC++ 6.0 doesn't seem to care one way or the other, but I suppose that is wrong, although I'm not entirely sure).

I recently got a query from a customer. Basically, they have a CORBA system
that interfaces to some legacy library. Lots of structures are being passed
back and forth, many of which contain strings; these need to be passed
as char * or as std::string, depending on where they go.

So, the customer defined conversion functions that correctly copied a
std::string or char * into and out of a string member (using string_dup()
or whatever, as appropriate). The problem is that they have to use
an undefined type name as the type of the parameter. For example:

void copy(const std::string & from, CORBA::string_mgr & to);

Of course, "string_mgr" is a mapping-internal type name and therefore the
code is non-portable.

I don't see an easy work-around that would be within the current mapping.
I could use a function that accepts a reference to a struct instead of
the string inside the struct, but that then means that I need a different
function for each structure type. Or I can write macros that are specific
to each ORB to handle it (but that is truly ugly and breaks if the vendor
decides to tinker with the internals of their mapping).

One way around it all would be to require a typedef to be generated for
string members. For example:

// IDL
struct Foo

;

// C++

namespace CORBA {
// ...
class string_mgr

; // Mapping-internal class

typedef string_mgr string_member; // New standard name
};

struct Foo

;

This would allow me to portably pass a string member to a function because
the mapping would guarantee the existence of a type named "string_member"
(or whatever name we can settle on).

void copy(const std::string & from, CORBA::string_member & to);

(Depending on the mapping implementation, there may be similar issues for
other types, such as references or arrays. If there are such mappings,
we'd need typedefs for those too.)

Basically, wherever a type name that is internal to the mapping can appear,
we end up with this kind of problem – I can't pass a value of that type
because I don't know the type name. I'd like to fix that, if possible.

rejected

In the first para of section 1.3.1, we still have a sentence about
the deprecated Ref names for object references. Those have been deprecated
for a long time now.

Proposal:

Remove the sentence beginning with "For historical reasons, the
type ARef..."

see below

In CORBA C++ 2.4 and before, the exception specification of generated
POA skeleton member functions is CORBA::SystemException plus the mapped C++
class for exceptions specified in the raise expression of the corresponding
IDL operation [see CORBA C++ 2.4 paragraph 23.27].
As a result, a servant programmer needs to convert any exception other than
those in the exception specification to one in the exception specification
– else the C++ runtime will call std::unexpected() if an unexpected
exception is thrown.

This makes exception handling on the server-side quite painful:
for example if a servant programmer calls operator new(), s/he's supposed
to catch std::bad_alloc and convert it to CORBA::NO_MEMORY. Similarly,
if s/he uses any of the ISO C++ libraries, s/he's supposed to convert the
std::exception objects raised by the library into CORBA::SystemExceptions,
or user-defined IDL exceptions.

Given that C++ compilers provide more and more features of ISO C++,
in particular the standard libraries, this is a real world issue!

Proposal
========

Add std::exception in the exception specification of generated
POA-skeleton member functions. The POA (or POA skeleton) implementation
is responsible to perform the following conversions:
std::bad_alloc to CORBA::NO_MEMORY
other std::exception to CORBA::UNKNOWN (see 3.17.1.1 in CORBA 2.3 core)

Source-code backward-compatibility
----------------------------------
I propose to make exception specifications in generated skeletons a bit
less restrictive than they were in CORBA C++ 2.4 (and before).
C++ servants written with the CORBA C++ 2.4 (and before) mapping do not
require any change – their exception specifications will be more
restrictive than required by the new mapping, which is perfectly correct.

Interoperability
----------------
It does not affect interoperability: only CORBA exceptions go on the
wire. An ORB-mediated operation can only raise a CORBA::SystemException
or a user-defined IDL exception.

Alternative Mapping for C++ Dialects
------------------------------------
Unfortunately, not all C++ compilers comply (or almost comply) with
ISO C+. With such a "C+ compiler", the ORB/POA implementation will
behave as in CORBA C++ 2.4 (i.e. no std::exception is the exception
specification). Or maybe we can allow the ORB/POA to add an
implementation-dependent class in the generated exception
specifications?

Portable user-written servants will simply include
CORBA::SystemException (or something more restrictive) in their
exception specifications.

see below

Details: This section (entitled 1.16.10 The Any Class) refers the reader to the full definition of the Any class. However, it provides the page number and section heading of itself – it is self referential.

Suggested Correction: The reference should refer to the section on page 1-150 (entitled 1.41.5 The Any Class)

see below

About two or three years ago, we decided to deprecate the read-only
nature of in params on the server side, and out params and return values
on the client side.

The second-last para of 1.13.2 still contains a remnant that we forgot
to clean up back then:

As with other out and return values, out and return sequences must
not be assigned to by the caller without first copying them.

I would suggest to modify this sentence to read:

For a sequence passed to an operation as an in parameter, the
operation must not assign to the sequence if its release flag
is false and the sequence has variable-length elements.

For a sequence passed to a client as an out parameter or return
value, the client must not assign to the sequence if its
release flag is false and the sequence has variable-length elements.

This captures more correctly the intent and the semantics of the release
flag (because assigning to a sequence with the release flag set to true
is perfectly OK).

see below

the spec talks about backward compatibility with the C mapping in a number
of places:

• 1.1.14
• at the beginning of 1.7
• in the footnote on page 1-29
• at the end of 1.10
• at the end of 1.12
• at the beginning of 1.13.3
• at the end of 1.16.10
• at the end of 1.20
• at the end of 1.23
• at the beginning of 1.26
• 1.31.3
• 1.42.1

Binary compatibility with the C mapping has never existed and never will.

Proposal: Remove all mention of the C mapping from the above places.

Remove all mention of the C mapping from the above places.

formal/99-07-41 in section 1.36.3 includes the following code:

---------------- cut here ----------------
class ServantBase_var {
public:

~ServantBase_var ()

catch (...)
{
}
}
---------------- cut here ----------------

Event better would be to add some throw spec to _remove_ref()
and _add_ref(). The spec is, as far as I can tell, silent in this
respect, thus those operations can throw anything. This is
unfortunate because it makes it harder to write exception-safe code,
both for application developers and ORB implementors alike.

see below

The third bullet of 1.17.9 states that a POA skeleton class is generated
for valuetypes that support interfaces, but is silent about whether a
_tie template is also generated.

Proposal:

Add the following to the end of the third bullet in 1.17.9:

"No tie skeleton class is generated for the valuetype because the tie
for the inherited class can be used instead."

duplicate of issue 3328 close issue

The definition for Exception in the current spec is:

// C++
class Exception

;

Why aren't _rep_id() and _name() pure virtual?

rejected

The current requirement that the default implementations of _add_ref
and _remove_ref in ServantBase do nothing creates several problems:

1. The text in the C++ mapping that states that _remove_ref
must be called on a servant means nothing unless the ref
counting mix-in was used by the servant author.

2. The intended semantics of _var types as "smart pointers"
is upheld only if the servant author goes to the extra
step of using the ref counting mix-in.

3. In many places the C++ mapping explicitly or implicitly
states that _var types will recover memory for the application
developer:

1.3.1:

Client code frequently will use the object reference
variable type (A_var) because a variable will
automatically release its object reference when it is
deallocated or when assigned a new object reference.

1.3.6:

When a _var is passed as an out parameter, any
previous value it refers to must be implicitly
released.

In addition, there are many places in the C++ mapping where
the specification of _var types for arrays, structs, strings,
sequences, type Any, type codes, value types, value boxes,
value factories, etc. guarantees that the memory will be
reclaimed when the _var goes out of scope. This makes it
easy for users to believe that all _var types will release
storage for the objects that point to.

Benefits of Proposed Resolution:

Users can depend on ORB's to manage servant memory by default
rather than by exception.

Specification text that promises or implies automatic memory
reclamation need not change.

Existing user code will still compile.

Resolution:
Revised Text:

Replace the text in section 1.36.1 beginning with the sentence:

Servant instances may implement reference counting to prevent
themselves from being destroyed while the application is
still using them.

and section 1.36.2 in its entirety with:

Servant instances may implement reference counting to prevent
themselves from being destroyed while the application is still
using them. Servant reference counting is performed using the
_add_ref and _remove_ref functions declared in ServantBase. The
default implementations of _add_ref and _remove_ref supplied by
ServantBase provide true reference counting. An instance of a
servant class derived from ServantBase initially has a reference
count of one. Invoking _add_ref on the servant instance
increases its reference count by one. Invoking _remove_ref on
the servant instance decreases its reference count by one; if the
resulting reference count equals zero, _remove_ref invokes delete
on its this pointer in order to destroy the servant. For ORBs
that operate in multi-threaded environments, the implementations
of _add_ref and _remove_ref that the ServantBase class provides
shall be thread-safe.

ServantBase supports copy construction and the default assignment
operation. Copy construction always sets the reference count of
the new servant instance to one. The default assignment
implementation merely returns *this and does not affect the
reference count.

For servants that require that servants are not reference
counted, these functions are virtual and thus may be overridden
by derived servant classes. A default mix-in class is also
provided to remove the reference counting in the PortableServer
namespace; please see Section 1.36.2, "Servant No Reference
Counting Mix-In," on page 1-??? for more details. Details
concerning POA and application responsibilities with respect to
reference counting can be found in Section 1.36.4, "Servant
Memory Management Considerations," on page 1-???.

Note that for applications that depended on the the
RefCountServantBase provided in previous revisions of this
specification ORBs must provide a default implementation of this
mix-in class in the PortableServer namespace that essentially
does nothing:

// C++
namespace PortableServer
{
class RefCountServantBase : public virtual ServantBase

;

}

1.36.2 Servant No Reference Counting Mix-In

The PortableServer namespace also provides a standard servant
mix-in class to remove the reference counting:

// C++
namespace PortableServer
{
class NoRefCountServantBase : public virtual ServantBase
{
public:
~NoRefCountServantBase();
virtual void _add_ref() {}
virtual void _remove_ref() {}
protected:
NoRefCountServantBase() {}
NoRefCountServantBase(const NoRefCountServantBase&) {}
NoRefCountServantBase& operator=(const NoRefCountServantBase&);
private:
// ...other implementation details...
};
}

The NoRefCountServantBase mix-in class overrides the inherited
_add_ref and _remove_ref functions it inherits from ServantBase,
in order to override and remove the default reference counting in
ServantBase.

see below

CORBA::Fixed should have a to_string() member function to allow an
explicit conversion to a string. Otherwise the only way to get a string
version of the information in a fixed is via a string stream, which can
be awkward.

namespace CORBA {
class Fixed

;
}

The caller of Fixed::to_string() must deallocate the return value by
calling CORBA::string_free or assigning it to a String_var.

No Data Available

Why is it that String_var contains the following?

operator char *();

The mapping never passes strings as a char *. The only parameter
passing signatures are const char * for in params, char * & for inout params,
and String_out for out params.

It seems that this operator is redundant?

The only reason I can think of for it having been added are sloppy signatures
(such as old implementations of strcpy or some such, which sometimes used
char * instead of const char *). However, wouldn't it be better to remove
operator char *() from String_var and force a cast for such broken function
signatures?

Remove operator char*() from class String_var.

Page 1-153, section 1.41.2:

String_var has:

operator char*();
operator const char*() const;

What is missing here is:

operator char*&();

Without that, a String_var cannot be passed as an inout param.

Add operator char*&() to class String_var.

Currently there is Any extraction with widening to Object, and
AbstractBase.
It seems useful to also have one that widens to ValueBase.

duplicate of issue 3092...closed

page 1-23 says:

The T* constructor creates a T_var that, when destroyed, will delete
the storage pointed to by the T* parameter. The parameter to this
constructor should never be a null pointer. Compliant implementations
are not required to detect null pointers passed to this constructor.

So, I can't explicitly initialize with null:

T_var tv = 0;

This seems strange, seeing that the default constructor does initialize
with null.

Also, the spec doesn't say anything about assignment. Is the following legal?

T_var tv = ...;
tv = 0;

I don't understand the restriction. What's the motivation for
disallowing this? Especially for String_var, the prohibition against null
null seems rather draconian. For example, I may be using a temporary local
String_var for exception safety and then, at some point, decide to
assign null to it to force an early deallocation of the string instead
of having to create a separate scope to achieve this.

At any rate, we should clarify so that, whatever the eventual decision is,
the text for the assignment operator agrees with the text for the constructor.

see below

Question: do I need to deallocate the string returned by Exception::_name()
and Exception::_rep_id() or not? The spec doesn't say...

Given that these are PIDL, and that the return value is const char *
(rather than non-const char *), I'd say that I shouldn't have to deallocate
the return value. But I think we should clarify this in the spec.

Also, the Exception class in section 1.41.7 doesn't show the _name and
_rep_id members, so we need to add them there.

Further, Exception doesn't show up in section 1.23 (Mapping of Pseudo
Objects). I suspect that we need to add Exception there as well and
mention the exception to the memory management rules? Another interesting
thing is that, if Exception is a pseudo object, then UserException and
everything derived from it is also a pseudo object. But, user exceptions
can't be pseudo objects. But, if they are not pseudo-objects, we can't
really make special-purpose memory managment rules. Sigh...

see below

Section 1.17.9 states that valuetypes that support a non-abstract
interface have a POA skeleton class generated for them. Is a tie
template class also supposed to be generated?

see below

The CORBA 2.3.1 specification does not cover the case of code generation
for the OBV_ class constructor for a valuetype that inherits from
another concrete valuetype:

// IDL
valuetype A

;

valuetype B : A

;

The generated OBV constructor for class B needs to take both o1 and o2
arguments, so it should look like this:

// C++
class OBV_B

;

Proposal:

Change the second paragraph of 1.17.2 to read:

"For the same reasons, a C++ OBV_ class defines a protected default
constructor, a protected constructor that takes an initializer for each
valuetype data member, and a protected default constructor. The
parameters of the constructor that takes an initializer for each member
appear in the same order as the data members appear, top to bottom, in
the IDL valuetype definition, regardless of whether they are public or
private. If the valuetype inherits from a concrete valuetype, then
parameters for the data members of the inherited valuetype appear
first. All parameters for the member initializer constructor follow the
C++ mapping parameter passing rules for in arguments of their respective
types."

see below

Section 1.17.10.3 states that type specific valuetype factories are
generated with a public destructor. This conflicts with the reference
counting requirement for factories, since it makes it easier for
application code to delete a factory that still has outstanding
references.

Proposal:

Change the text in 1.17.10.3 to make destructors for type specific
valuetype factories protected rather than public.

No Data Available

2. Valuetypes should have _var typedef inside the class to aid template
programming just like objects, structs and unions.

see below

The last C++ RTF made changes that identify specific inheritence
strategies must be used for generating code for interfaces that inherit
from abstract interfaces. The text in 1.40.3 was not updated to reflect
this, and still suggests that other strategies are possible, when they
are no longer allowed.

see below

The CORBA 2.3 C++ mapping for valueboxes (1.17.7.2) does not specify the
behavior of the constructors, assignment operator and _value modifier
method with respect to the object reference argument. These methods
clearly need to call _duplicate on their argument, since the valuebox
must manage its own memory.

Proposal:

Add the following paragraph just before the example in 1.17.7.2:

Value box classes for object reference maintain a private managed copy
of the object reference. The constructor, assignment operator and
_value modifier method for these classes call _duplicate on the object
reference argument, and the destructor calls CORBA::release on the boxed
reference.

see below

The CORBA 2.3 C++ mapping makes no mention of _out types for
valuetypes. Clearly this is needed and should be mentioned.

see below

Section 1.17.10.2, the definition of operator= for ValueFactoryBase_var
has "ValueFactoryBaseBase_var".

fixed editorially...issue closed

1. Should a session component have a way to save and restore its private state?
Problem: The current component specification provides no way for the component programmer to explicitly save and restore its private state for session components.

closed issue, no change

This section indicates that the Language Mappings are to be provided as errata. I have searched high and low in the OMG web site to find these mappings and have not found a single bit of info on them. I need these mappings to accurately design and implement the extended CCM features.

close no change

In the first versions of the CCM specification terms such as
ComponentBAse, ComponentHome, ... have been used. More recently these
terms have been changed to CCMObject, CCMHome... Shouldn't all the
interfaces of the ccm module be changed this way in order to be
homogeneous in their naming?

Why is there CCMContext (with CCM prefix) and SessionContext without
CCM prefix ?

Thus SessionComponent, EnterpriseComponent, SessionContext, ... would
become CCMSessionObject, CCMEnterpriseObject, CCMSessionContext ...

close, no change

2. Document OMG ptc/99-10-04 p.615-87. In the last paragraph of the
illustrative example, it is said that: "The implementations of
operations for navigation, executor activation, object reference
creation and management, and other mechanical functions are either
generated or supplied by the container."
Don't you think this is dangerous in a multi vendor context? Let say
a component implementation rely on the container to provide these
operations. What will happend if this component is deployed in a
container which considers that component implementations include
the generated code providing these operations? (Same feeling as in
remark 2.)

close issue, no change

Problem: Can home finders be federated?

No, HomeFinder cannot be federated. Clients can use the Naming Service instead, which is federated.

Problem: The current specification does not provide an interface for registering homes that can be used outside of the container. Should it?

close, no change

I have a number of issues with the Software Package Descriptor section of
the CCM specification (Component Spec - Volume I, orbos/99-07-01.) I have
not found answers to issues raised below in either the components-ftf
archive, or the issues list.

ISSUE - The softpkg descriptor example uses an "id" attribute, which isn't
defined in the softpkg.dtd.

>From page 10-305, 10.2.1 A softpkg Descriptor Example, CORBA Components -
orbos/99-07-01:

<idl id="IDL:M1/Bank:1.0" ><link href="ftp://x/y/Bank.idl"/></idl>

According to the softpkg.dtd, (page B-435, B.1 softpkg.dtd, CORBA Components

• orbos/99-08-05, ) the idl element is defined as follows:

<!ELEMENT idl
( link

The same definition can also found in section 10.2.2.14, The idl Element (,
page 10-311, CORBA Components - orbos/99-07-01.) There are no attributes
defined for the idl element.

see below

In chapter 69.9.1.2 Deployment Scenario on page 329 of ptc/99-10-04.pdf the
operation get_implementation() is refered as if it belongs to the
ComponentInstallation interface (called only "Installation"), but the
specification of that interface lacks it.

Duplicate, close

Dealing with the following IDL3 definition, a problem arises when
generating the IDL2 definitions (complete IDL2 mapping is enclosed at
the end of this mail).

module example {
valuetype AnEvent : Components::EventBase

;

component Producer

;

component Consumer

;
};

According to the chapter 5 of the CCM specification, the publishes
definition of the Producer component is mapped to the following
definition (excerpt).

interface Producer : Components::CCMObject

;

In the mean time, the consumes definition of the Consumer component is
mapped to the following definition.

interface Consumer : Components::CCMObject {

::example::ConsumerEventConsumers::AnEventConsumer
get_consumer_input();

};

We can see that two versions of the "AnEventConsumer" interface have
been defined in two distincts modules. Thus the following Java
lines are not correct:

example.Producer p = ...;
example.Consumer c = ...;

p.subscribe_output(c.get_consumer_input());

The Java compiler will refuse to compile the last one, producing an
error like "BadTypeCoerce". However, in the IDL3 definitions, both
components have been defined in order to be used together. (sic!)

Thus, we think that the mapping for a Consumer should not be based on
the component definitions, but on the event definition itself. It
would then avoid multiple (incompatible) definitions of the consumers.
This mapping could be defined in two distinct ways.

see below

Looking a the <Assembly> interface, a question arises. When providing
the assembly descriptor location, a logic description of the
application to deploy is provided. But, how are set the pysical hosts
to be used for the deployemnt of the logic configuration? No hooks is
provided to the deployment tool (as there are no interfaces for the
tool) in order to provide these information, and no operation is
available on the assembly interface to do so. Is there an extension of
the <Assembly> interface in order to contain this information?
Otherwise, how could the application be deployed?

Thinking about what should be provided, it is necessary to assign a
logical name contained in the assembly descriptor to a physical host
name. Maybe an extension to the assembly descriptor filled at
deployment time is the solution? The second possible choice crossing
my mind is an IDL structure (in fact sequence of structure) that could
be provided to the assembly object.

rejected

What about <i>valuetype factories</i>?

<p>In the context of a component dealing with events, the aspect of
<i>valuetype</i> factories has not been really mentionned in the spec,
especially in the deploiement process.
If I am right, dealing with <i>valuetypes</i> in a program means to
instantiate and to register a factory for this <i>valuetype</i> to the
ORB. In the context of the CCM, a component and its home is installed
into a generic container which may not know the <i>valuetype</i>.
Thus, the <i>valuetype factory</i> may have to be installed at
deployment time. </p>
<p> According
to the similarity in the <i>home</i> and <i>valuetype factory</i>
concepts, it may be a good solution to add an entry in the CORBA
Component Descriptor OSD file to define the <i>valuetype factory</i>
(which would have to be included in the component package) required by
the component as well as to define a standard name scheme for their
entry points. Here is an draft example of what it could look
like. Relationships / dependencies between components and <i>valuetype
factories</i> also have to be introduced.</p>

<!--
<softpkg>
...
<implementation id="...">
... all the environment stuff ...
<descriptor type="Event Factory">
<fileinarchive>...</fileinarchive>
</descriptor>
<code type="DLL">
<fileinarchive name="bank.dll" />
<entrypoint>createEventFactory</entrypoint>
</code>
</implementation>
...
</softpkg>
-->

<p><tt><softpkg>
<br>  ...
<br>  <implementation id="...">
<br>    ... all the environment stuff ...
<br>    <descriptor type="Event Factory">
<br>      <fileinarchive>...</fileinarchive>
<br>    </descriptor>
<br>    <code type="DLL">
<br>      <fileinarchive name="bank.dll" />
<br>      <entrypoint>createEventFactory</entrypoint>
<br>    </code>
<br>  </implementation>
<br>  ...
<br></softpkg></tt></p>

<p>The second solution could be to include the code for <i>valuetype
factory</i> creation in the <i>home</i> implementation, which mean
less specification: "The home has to install any valuetype factory
required by the component." would be enough. However, this second
approach may not be as much portable as the first one (as long as a
<i>home</i> may be portable between containers, which IMHO should be
possible).</p>

see below

he following sub-issues need to be addressed to make sure that CCM/EJB
bridge implementations are interoperable. In particular, these sub-issues
have in common that the current definition of the bridge relies on the
Java-to-IDL mapping, which in certain cases does not match the requirements
of the EJB-to-CCM mapping.

Sub-issue: METHOD NAMES IN STANDARD INTERFACES

The names for some methods defined on standard interfaces, for example
<home-name>Implicit.find_by_primary_key or <home-name>Implicit.create,
differ from the names that their EJB counterparts get mapped to under
Java-to-IDL (in the example these would be
<home-name>.findByPrimaryKey and create__keytype, respectively). When
this happens, the translation from one form of the name to the other
can happen at either the client or the server side of the bridge. FOR
INTEROPERABILITY, it is necessary to eliminate this ambiguity. Choices
for doing this include requiring the client stub to always do the
translation or requiring the server skeleton to take into account both
name forms.

The actual problem we are getting hit by here is overloaded names. Methods
like remove and create in EJBHome and user-defined EJB homes can only be
mapped to remove_XXX and create_XXX under Java-to-IDL, yet the
definitions of the corresponding methods in <home-name>Implicit are remove
and create, respectively. I can understand that these implicit home names
were defined as such because <home-name>Implicit is a standard interface
(although the fact that its name is prefixed by <home-name> is a bit
troubling) and, if for no other reason, because the XXX in create_XXX
cannot be known in general. So, if we stick to the standard names, there is
a mismatch. Notice however that I said that the mapping is done under
Java-to-IDL. Perhaps I should not say that but the CCM spec is not clear
about this and in fact it states that the create methods in an EJB home are
mapped to factory names under Java-to-IDL. So we may actually be talking
about two different issues: (1) use different mapping rules for create with
no primary key, in which case we need to ammend the spec to this effect;
(2) perform a translation, in which case we have an interoperability issue.

Sub-issue: HANDLING STANDARD EXCEPTIONS

Standard exceptions thrown by EJB methods, such as
DuplicateKeyException, have a mapping specification to IDL (under the
current Java-to-IDL specification) that does not match the exceptions
that they map to under the CCM spec (in the example this would be
DuplicateKeyValue). This requires that the bridge perform a run-time
translation of exceptions from the Java-to-IDL mapping to the CCM
mapping at either the client stub or the server skeleton. FOR
INTEROPERABILITY, it is further necessary that the location of the
translation be fixed. Early prototype implementation suggests that it
is more advantageous for the client stub to perform the translation
since otherwise the server skeleton would need to know what kind of
client it is talking to: a CCM client or an EJB client. A larger issue
that this falls under is the reconciliation of the Java-to-IDL mapping
with the EJB-to-CCM mapping. If and when the larger issue is resolved,
this issue would largely disappear.

This also falls under the Java-to-IDL mismatch. Our choices seem to be: (1)
define the standard exceptions, e.g. Components::DuplicateKeyValue, as if
they had been mapped from Java under Java-to-IDL, (2) map the exceptions
from Java under rules different from those on Java-to-IDL; (3) perform a
translation. Choice (1) may be too intrusive but it could be rationalized
with a "integration with EJB" argument. Choices (2) and (3) are similar to
the above.

Sub-issue: PASSING A PRIMARY KEY PARAMETER

A number of methods defined by standard interfaces, such as remove
defined by EJBHome, include in their signature a primary key value and
define its type to be java.lang.Object, which under RMI-IIOP is mapped
to CORBA::Any. Since the primary key is actually an object passed by
value and thus mapped to an IDL value type, a run-time translation
must be performed from the value type to Any and viceversa whenever a
method that includes a primary key is called. FOR INTEROPERABILITY, it
is necessary that the location of this translation be fixed. Choices
for doing this include requiring the client stub to always do the
translation or requiring the server skeleton to take into account both
a value or an Any that could possibly be coming from any given
client. In additon, if a primary key is returned it may be more
advantageous for the client to perform this translation, since the
server skeleton may not know what form the client is expecting.

Here again the problem is that, under Java-to-IDL, java.lang.Object gets
mapped to ::java::lang::Object (not CORBA::Any actually, as per the actual
Java-to-IDL I am looking at) for methods like EJBHome.remove, whereas the
key is expected to be passed as a value type. So the choices seem to be:
(1) use rules other than those in Java-to-IDL for the mapping or (2)
perform a translation.

see below

What exactly is meant in chapter 69.7.2.3 by component archive file? It is
not defined anywhere. Is it a software package descriptor or a software
package? At least it is not a CORBA component descriptor as shown in the
example in chapter 69.7.1. The text there is like:

<componentfile id="A">
<fileinarchive name="ca.ccd"/>
...

Is the sufix ccd right?

see below

Document orbos/99-08-13, line 9 and further, contradicts with
orbos/99-07-01,
Chapter 4.4. The production rules for typePrefix and typeId contain a
";",
where file orbos/99-08-13 omits them.

Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01,
Chapter 4.2. The production rules for import contain a ";",
where file orbos/99-08-13 omits them.

see below

The mapping between EEJB metadata and the IR is missing in the
current specification .Resolution: Define the mapping

see above, rejected

Moving existing interfaces from the CORBA module to a new IR module breaks
backward compatibility. Hence they should be moved back to the CORBA module. The
elements that are newly added can go into a new module, and interfaces
corresponding to the existing ones with the same names can be placed in the new
module, with these interfaces deriving from the existing corresponding
interfaces in the CORBA module, thus allowing all CORBA3 IR interfaces to be
accessed from a single module.

This also fixes a related problem regarding separation of the TypeCode stuff,
specifically TypeCode factory. It is broken in the current spec because certain
types used by the typecode factory were inadvertently moved to the IR module.

see below

In section 69.4.5.45, the "rights" element is mentioned, but the "rights
combinator" elemnt is not. Given a set of "rights" it is not possible to
determine how to cobine them without the "rights combinator" as specified in
CORBAsec. Suggest we add a "rights cobminator" element, consistent with the
definition of rights combinator in CORBAsec.

see below

ISSUE - What is the purpose of the "name" element as used in the
"dependency" element?

See section 10.2.2.7, The dependency Element (, page 10-308, 10.2.1 A
softpkg Descriptor Example, CORBA Components - orbos/99-07-01.) Section
10.2.2.20, The name Element, describes the name element as an optional
element of the "author" element, and is meant to identify the author. So
does the name element identify the author of the dependency, or is it used
to identify the dependency itself?

see below

When a component type is implemented, it inherits a specialized
interface for callback functions, for example SessionComponent. In
this context, why should home implementations be unspecialized? Using
a specific home type, deployment could be improved when performed in a
multi-actor context. As the cooperation between containers and homes
is unspecified, using multi-actors components seems unreachable. One
particular aspect is how the container <Context> interface si provided
to the component instance. Using a well defined specialized home
interface would solve this problem easily. Thus, avoiding the use of
wrappers for example which are another solution, but far more complex.
Such an interface should be defined for each component type category.

As an example the following interface could be a basis for session
component homes. (there must be other operations to add here, but I
have not foudn them yet.)

interface SessionCCMHome : CCMHome

;

rejected

7. Where is HomeExecutorBase interface defined? I only saw it used in
the packaging and deployment model. If it is a standard interface
which is returned (how could it be non standard), shouldn't it be
defined somewhere? (Same remark for ExecutorSegmentBase
interfaces. It may be defined in the last Components.idl, but I did
not find one more recent than orbos/99-08-13.)

See the resolution for issue 4574.

6. In example p.615-86, shouldn't myToonImpl extends ToonSessionImpl
(presented in the previous pages) instead of ToonImpl (which is not
defined)? The same classname is used in pages 96-98, but it seems
correct in this case.

see below

5. Even if it is only an example, p.615-85 ToonTownImpl implements
ExecutorSegmentBase, shouldn't it be HomeExecutorBase?

see below

4. Why does not CCMHome include the operation create_component() ? I
understand that a component created by a home with keys should not
offer this interface, however according to the exemple in the spec
Container operation install_home() returns a CCMHome, thus how
could a component be created in this context? Does it imply that
you know if the home is keyless or not, thus narrowing it before
use? Don't you find strange to have the remove operation but not a
default create in the CCMHome interface?

rejected

3. Why isn't the operation <string get_implementation(in string iuuid)>
defined in the interface ComponentInstallation while being used in
ptc/99-10-04 p.69-329 item 9? (Where Installation should be
replaced by ComponentInstallation don't you think?) Moreover, this
operation is required for an Assembly to find the location of a
component implementation in order to load it in a container.

see below

1) Some concepts from the CORBA metamodel (component, facet, receptacle,
event publishing/emission/consumption) are also in P/D metamodel but the
definitions from the CORBA metamodel are not directly reused.

Recommendation: Analyze where reuse is appropriate and adjust the P/D
metamodel accordingly.

2) The P/D metamodel has the notion of files (e.g. configuration property
files and some other files) where some metadata are stored. The hand-coded
DTDs treat these files as types in their own right, i.e. they conceptualize
them as files, and some of the other types point to the file types. This
is approach is mimicked in the metamodel. However, it might not make sense
in the metamodel because, in a repository context, you are referencing
other information in the repository and not necessarily a file. The way
the metamodel is now, when something references one of these files you lose
the metadata trail. The file metaclass itself does not have structural
features pointing to metaclasses that define the contents of the file. You
have to go elsewhere (i.e. to the property file Package) to get that
metadata and there is no reference to the property file Package.

Recommendation: It might make more sense for references to the file
metaclass to instead reference the top level element of the property file
Package so that you can "follow the metadata trail." If someone wants to
break out the properties metadata in a file, then the generated DTD should
allow that, i.e. the part that needs to go into a properties file should be
able to be self-contained without external references.

rejected, See issue 4575.

ISSUE - The description of the "implementation" element explains the
"variation" attribute, but the attribute is not part of the definition.

>From page 10-32, CORBA Components - orbos/99-07-01: "The variation attribute
is used to indicate a variation from a normal implementation." But the
definition of the implementation attribute list only lists the "id"
attribute. The variation attribute is not part of the definition as given in
softpkg.dtd either (, page B-419, B.1 softpkg.dtd, CORBA Components -
orbos/99-08-05.)

see below

In ptc/99-10-04, the production 104

<readonly_attr_declarator >::=
<simple_declarator> [ <raises_expr> ]

see below

The draft component specification (ptc/99-10-04) explains that CIDL is
a superset of IDL. This is a derivation from the specification
voted-on in the PTC (orbos/99-07-01), which specified that CIDL is a
superset of PSDL.

Also, declaring CIDL not to be a superset of PSDL means that the
<catalog_use_dcl>, <abstract_storage_home_binding> etc become
meaningless, as they refer to entities from PSDL.

Proposed Resolution: Declare CIDL to be a superset of PSDL.

See issue 3065.

Question: Is it legal to send the same codeset context more than once
on the same connection?

The spec says:

Codeset negotiation is not performed on a per-request basis,
but only when a client initially connects to a server.

These words suggest that the codeset must be sent on the first request,
but don't say whether it's OK to send it more than once.

I would like to have clarification, and also a loose interpretation. Here
is why:

A multithreaded client starts talking to a new object from
multiple threads more or less simultaneously. If the codeset
info must be sent only on the first request and is illegal on
subsequent requests, we end up with rather complex locking
logic in the connection management layer of the ORB. In effect,
each request is no longer a stand-alone and context-free thing;
instead, how to send a specific request now depends on what
other threads may have done in the past.

That's not very nice (even though it can be implemented) because
it needlessly complicates things.

So, I would like to change things such that it is legal to send the
codeset context even if it was sent previously on the same connection.
When that happens, the server should simply and silently ignore all
but the first context (even if the subsequent contexts have different
codeset information from earlier ones). That way, requests remain
context-free. [ Yet again, we see a sterling demonstration that attaching
semantics to the duration of a connection was a very bad idea, especially
in a model that is connectionless ]

Further, it seems pointless to send codeset info at all unless the client
actually uses an operation that involves a wchar or wstring parameter.
So, I think it would make sense to relax things such that the codeset
need not be sent until the first request is made that requires sending it.

see above

I set out reading ptc/2000-04-05 to answer a question: how could a
client interceptor for the OTS implement the proper behavior for the DII
get_response or get_next_response operations that require the
WrongTransaction to be raised if the current thread is not properly
associated with the same transaction as the request.

I wasn't able to answer this question authoritatively, because there is
nothing in the Portable Interceptors Chapter that indicates the proper
time sequencing of when the client side request interceptor operations
are invoked in relation to the use of the DII (or the AMI_ messaging
interfaces either.)

By inference, it appears to me that the only way to allow an OTS client
request interceptor to exhibit the proper semantics is for the ORB to
not make calls to receive_

when the response is
received from the protocol stack, but instead to make them when
get_response or get_next_response is called by the application.

This paragraph in 21.3.7.2:

"Asynchronous requests are simply two separate requests. The first
request receives no reply. The second receives a normal reply. So the
normal (no exceptions) flow is: first request - send_request followed by
receive_other; second request - send_request followed by receive_reply."

is also not particularly useful, since it doesn't give any indication
how the interceptor can distinguish the "first request" from the "second
request".

So, to sum up, the PI chapter needs explicit information showing the
time sequencing of when the request interceptor operations are invoked
in relationship to a static call, a DII call, and AMI_ calls.

see above

When using the pollable sets, pollers are registered with
PollableSet::add_pollable() and retrieved using
PollableSet::get_ready_pollable(). As pollers are valuetypes they are passed by
copy, thus portable applications must assume that get_ready_pollable() returns
a different poller instance than the one passed to add_pollable(). Thus, with
non-TII, currently there is no portable way to find out how requests
(represented by the pollers returned from sendp) and replies (represented by
the pollers returned from get_ready_pollable ) correlate.

Consider the following IDL:

module Stock
{
interface Quoter

};

and a client that does a 1000 invocations in the style

poller = quoter->sendp_get_quote(portfolio[i].stock_name);
poll_set->add_pollable(poller);

Now, the client could retrieve the 1000 replies in the order:

while(poll_set->number_left() > 0)

;

But how can the client find out which returned quote belongs to which
stock_name?

Possible resolutions:
---------------------
(a) Reconsider the introduction of a correlation id on pollers which can be
used to compare if two pollers are referring to the same request/reply.

(b) Based on the fact that pollable set is locality-constrained and that
valuetypes support sharing semantics (see CORBA 2.3, 5.2.4.2 Sharing
Semantics), it could be required that PollableSet::get_ready_pollable() returns
a pointer to the same valuetype instance as the one passed as argument of
PollableSet::add_pollable().

(c) Close without action, i.e. has to be solved at the application level, e.g.
in our example the application would have to solve this by changing get_quote to

long get_quote(in string stock_name, out string stock_name);

Discussion:
-----------
(c) contradicts with the CORBA Messaging Philosophy that AMI is a mere
client-side issue and that in principle any existing target can be called
asynchronously.

(b) means that we would have two different polling-related correlation
mechanisms:

• one for correlating requests and replies in different processes based on the
  PersistentRequest objref
• one for correlating requests and replies in the same process based on poller
  pointers

(a) means that a generic correlation mechanism is defined that covers both:
intra- and inter-process correlation. This was variant (a) of issue 2803 in the
latest vote. It failed with 5 NO : 4 YES : 3 ABSTAIN.

I could work out two straw men for (a) and (b) for the next vote, or much
better, we could try to discuss this before the next vote and just work out a
straw man for the variant that has better acceptance.

close no change

There is currently no way to register a value factory from an ORB
initializer.

see above.

looking at the POA IDL, I get the impression that it was written at a time
where the use of multiple ORBs in a process wasn't anticipated. With
the advent of messaging, OTS, QoS policies, etc, it is more and more common
for one application to use several ORBs simultaneously.

When writing code, it becomes an endless pain dealing with multiple ORBs.
That's because I have to endlessly pass the ORB around in my program, just
so I can do things like call object_to_string() or string_to_object(), etc.

I think it would be really useful to have an ORB() accessor on the POA
interface:

interface POA

;

The accessor would return the ORB for this POA. Doing this would eliminate
most of the cases in my code where I have to pass the ORB around. For
example, in a servant, I can call _default_POA(), and then call ORB() to
get at the ORB.

Adding the operation would cause any compatibility problems, I believe.

Opinions?

see above

This problem comes from the fact that RoutingPolicy is actually a range: min and max. Basically, Messaging defines this range of Routing QoS:

ROUTE_NONE(0) ---> ROUTE_FORWARD(1) ---> ROUTE_STORE_AND_FORWARD(2)

You can set your min and max to any of the values, with the caveat that min must be <= max. The issue that concerns us is when the min is ROUTE_NONE(0) and the max is either ROUTE_FORWARD(1) or ROUTE_STORE_AND_FORWARD(2).

If you look at the Messaging spec (orbos/98-05-06) in section 5.3.5.3, it says:

"If, for example, the min is ROUTE_NONE and the max is ROUTE_FORWARD, the Routing protocol will normally be used but a direct connection may be used if available."

Of course, we've left in "usually" just to make sure we could screw up OTS for you

Reading the text in section 3.3 makes me believe that an issue should really be raised in the Messaging-RTF to clarify this. Here's what I BELIEVE the results would be for all of the combinations.

min maxresultconfidence ----------- ---------- -------------------- ROUTE_NONEROUTE_NONEDirect Call100% ROUTE_NONEROUTE_FORWARDTII if possible50% direct if not ROUTE_NONEROUTE_STORE_AND_FORWARDTII if possible50% direct if not ROUTE_FORWARDROUTE_FORWARDTII Only100% ROUTE_FORWARDROUTE_STORE_AND_FORWARDTII Only100% ROUTE_STORE_AND_FORWARDROUTE_STORE_AND_FORWARDTII Only100%

Obviously, the problem is with cases #2 and #3.

How should an ORB determine which to use: what priority is given to each of the RoutingType values?

close no change

Minor codes specifications are missing in all the places where the
specifications states that a system exception is to be raised. The minor
codes need to be specifiedto complete the specification of exceptional
beahivior.

see above

I am in the process of implementing Portable Interceptors within a C++
ORB,
and I would like to raise an issue for resolution regarding the semantics
of the
"register_initial_reference()" function, particularly with respect to the
memory
management of the object being registered.

The interface for this function is as follows:

void register_initial_reference (
ObjectId id,
Object_ptr obj
);

Within the Portable Interceptors specification, there is really no
information about
how the memory for the object should be managed. For example, does the
caller of
"register_initial_reference()" pass ownership of the object to the ORB, or
not?
Also, does the caller of "resolve_initial_references()" gain ownership of
the object
which is returned, or not?

Here is my proposed resolution:

The fact that the "obj" parameter is a CORBA::Object implies that it is a
reference-counted
object. Therefore, it would make sense that when
"register_initial_reference()" is called, the
ORB performs a "_duplicate()" on the object to increment its reference
count (the ORB would
then hold its own reference count). The caller of
"register_initial_reference()" can decide
whether to call "release()" or retain its own reference count.

Later, when "resolve_initial_references()" is called, the ORB would call
"_duplicate()" on the
object prior to returning it to the caller, thereby giving the caller its
own reference count.
The caller would then need to call "release()" when it is finished with
the object.

When the ORB is deleted, it must clean up the lookup table of registered
objects. To do this,
it simply calls "release()" on each one, and if no one else holds a
reference count, then
the object is simply deleted.

I would like the hear other people's thoughts on this, particularly those
who have done or are
working on a C++ implementation of PI.

see above

(All document refs to ptc/00-04-05)

Sec. 4.3.7.1 (Object::get_policy) talks about "the Policy as specified in
the IOR". Policies get translated to IOR components, but AFAIK there's no
general way that a component can be unscrambled to give a Policy. This
suggests that we need another interception point, effectively the inverse of
the existing IORInterceptor (sec. 21.5), that allows an IOR component to be
converted into a Policy on the client side.

I suggest something like:

local interface ReceiveIORInterceptor : Interceptor

;

local interface ReceiveIORInfo

;

and an extra operation add_receive_ior_interceptor in ORBInitInfo.

ReceiveIORInterceptor::establish_policies provides the opportunity for an
interceptor to turn IOR components back into Policies, using the
interceptor's Policy Factories directly or indirectly via
ORB::create_policy.

The ORB will call this method on all registered ReceiveIORInterceptor
objects during or before the first call of Object::get_policy (we needn't be
more specific - this would allow eager calls on unmarshalling or lazy calls
within Object::get_policy).

see above

Portable interceptor implementations need access to the ORB. The presumed
place to put the ORB would be on ORBInitInfo since at least one
implementation needs the ORB at initialization time. Is that sufficient?
Or is it also needed in RequestInfo and IORInfo? My guess is that having
ORB only on ORBInitInfo is sufficient. All interceptors begin here. If
the ORB is needed at other points, the implementations can assure that it
is available where it's needed.

Since ORB is PIDL and we don't want to pollute the interceptor interfaces
with PIDL, we have to create IDL access to the ORB, but that's another
issue.

This issue is a restatement of issue 3403. Merge with issue 3403 and close this issue

Portable interceptor implementations need access to the ORB. In order to
accomplish this, the ORB must be defined in IDL There are four
possibilities that have been opined:

1. Define the ORB as "native ORB;"

This puts the ORB into the IDL namespace. However, the ORB is still
described in PIDL. This doesn't really help us to remove PIDL, some folks
feel this is a misuse of native, but it would be sufficient for the
requirements of PI.

2. Define an IDL wrapper for the ORB, call it proxyORB for now.

proxyORB would contain exactly the same items that the PIDL ORB does, only
defined in pure IDL. Advantages: this is a migration step toward getting
rid of ORB PIDL if we encourage folks to use proxyORB rather than ORB.
Disadvantages: dual maintenance; lots of work - too much for this FTF?; I
don't think we know all the ramifications; where do you get a proxyORB?
from the ORB?

3. Make the leap and redefine ORB in IDL now.

This option is similar to option 2, but the IDL is not a wrapper, it's the
real ORB. Advantages: no dual maintenance; we get rid of ORB PIDL right
now. Disadvantages: BIG step - too big for this FTF?; lots of work; I
don't think we know all the ramifications.

4. Make the ORB a primitive type like TypeCode.

This seems to be generally undesired. It requires all compilers to change.
Unless someone really likes this approach, I don't think we should even
consider it.

Resolve this issue simultaneously with 3772 and close it as soon as 3772 is resolved and closed

How are the routing policies e.g.ImmediateSuspend, LimitedPing, UnlimitedPing,
etc. created. It is not clear that these can be created using the standard
create_policy operation since these policies are valuetypes that support the
CORBA::Policy interface.

Also what are the Policy Type tag values for these policies?

close no change

object_to_string and string_to_object are missing on ORBInitInfo.

Resolve in conjunction with 3772 and close this issue when 3772 is resolved

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

The text in section 9.2.3 / page 9-71 describing the
arguments attribute to ORBInitInfo could use some
more precise wording. It reads:

"This attribute contains the arguments passed to ORB_init.
They may or may not contain the ORB's arguments."

I take this to mean that any ORB_init arguments that
applied to the ORB instance being created may not be
present. All other strings passed to ORB_init will be
present so initialisation strings can be passed to
the interceptors through ORB_init.

With the current text it is possible to think that
you may not get any of the arguments to ORB_init.

see above

Section 15.4.5, page 15-39:

LocateRequest messages may be sent from a client to a server to
determine the following regarding a specified object reference:

• whether the object reference is valid

In the absence of a definition for how to judge a reference "valid", this
is a meaningless statement.

close with revision

ORBs should be required to reject IORs that do not contain any profile that the ORB can use

accomodated by proposed change from Issue 3234.

Part 2: Should an ORB be allowed to drop non-standard profiles (as it is allowed
to, indeed almost encouraged to do in GIOP/IIOP 1.2) even though it is not faced
with any resource contraints. Moreover, when it is faced with resource
contraints should it be required to follow a specific sequence in determining
what profiles to drop.

The proposed resolution defines two possible IOR conformance classes for every ORB interoperability

Since the index numbering of sequences is a language mapping specific issue, the origin of the selected_profile_index within the IORAddressingInfo must be specified. I assume a zero origin is meant.

Proposed Resolution:
Add the following sentence to the description of IORAddressingInfo (in section 15.4.2.1 of the 25 March CORBA 2.4 preliminary draft): "The first profile has an index of zero."

Accept proposed solution.

CORBA is inconsistent on how to deal with the lack wide character code set
information in an IOR and the codes set service context.

When a server receives a service context without a wide character code set
specified, then it is supposed to raise BAD_PARAM when it receives wide
characters data from the client.

However a client is supposed to raise INV_OBJREF if the IOR is missing
from the server's native wchar code set . In CORBA 2.3, section13.7.2.6,
"Code Set Negotiation", it says, "... a server that supports interfaces
that
use wide character data is required to specify its native wchar code set;
if
one is not specified, then the client-side ORB raises exception
INV_OBJREF."

This requires a client to know whether a server supports interfaces that
use
wide character data at the time the client receives an IOR. To determine
this when the first IOR is received is a burdensome task. The client orb
would be forced to apply an exhaustive examination, such scanning all of
the
server's IDL bindings or the contents of the IFR looking for wchar types.
Additionally the client may need to determine if some Any might flow
containing wchar data.

I propose that the client's behavior be changed to match the server's. If
any wide character data is encountered and the server's IOR was missing
the native wchar code set, (which would cause the wide character
transmission
code set to not be negotiated), the client should raise BAD_PARAM.

This will allow common marshal and demarshal code to be independent of
whether it is running as a client or server. It also allows users to not
configure
wide character code sets if they know they aren't using them.

The check should be able to be done at invoke time by the client orb

Why does it make sense at all to allow an ORB to throw an exception if it finds
a service context it does not "understand"? This is not very helpful for
interoperability. Would a sending ORB have to handle this exception and resend
the same request without context to allow to interoperate with an ORB throwing
BAD_PARAM in this case? If an unknown service context is sent with a reply, the
receiving ORB would throw BAD_PARAM at the caller (even if it got a valid
reply). The originator of the service context wouldn't even know.

To close with Issue 3561 resolution to eliminate option of throwing exception

In document ptc/00-03-02 on page 13-30 in the last bullet on that page it says: "If a system
exception is raised , it shall be BAD_PARAM with an OMG standard minor code of 1".

This cannot be right because the OMG standard minor code of 1 for BAD_PARAM is assigned to "failure
to register, unregister or lookup value factory."

I recommend that we change this minor code to a new one that is properly allocated with the
associated text that reads something like: "Service context not understood". I am still wondering
though why BAD_PARAM is the correct exception to raise. Wouldn't BAD_CONTEXT be more appropriate?

In any case we have to change the minor code, even if we cannot make up our minds about which
exception.

resolved and closed

Page 15-50 of 2.3.1:

ORBs that suport only version 1.1. or 1.2 IIOP profiles must
ignore, but preserve, any data in the profile that occurs
after the components member.

A 1.2 ORB is obliged to ignore, but preserve, any information that follows
the components member in 1_1 profile body. I think the cost of implementing
this is quite high. What follows after the components member is not in
a separate encapsulation. So, an ORB that receives an IOR that indeed has
data after the components member doesn't understand anything about that data
and therefore must treat it as a blob of bits.

However, the IOR might be little-endian and the receiving ORB might be
big-endian. When the receiving ORB wants to send the IOR back out, it
can't send it as a big-endian IOR because it can't know how to byte-swap
the data that follows the components member. That means that a big-endian
ORB is obliged to remarshal the IOR back as a little-endian IOR.
That's inconvenient, to say the least.

I don't think it makes sense to require an ORB to preserve something that
is not encapsulated, simply because the cost of doing this is high.
(The ORB has to keep a copy of the marshaled profile around because of
the trailing bit it doesn't understand.)

Close with revision

Section 15.3.4, page 15-18:

The encoding used for indirection is the same as that used for
recursive TypeCodes (i.e., a 0xffffffff indirection marker
followed by a long offset (in units of octets) from the beginning
of the long offset).

[...]

Indirections may refer to any preceding location in the GIOP
message, including previous fragments if fragmentation is used.
This includes any previously marshaled parameters.

The beginning of the section ("is the same as that used for recursive
TypeCodes") is in conflict with what appears at the end ("refer to any
preceding location in the GIOP message [...]. This includes any previously
marshaled parameters.")

This is incorrect because the indirection for type codes does not permit
indirections that span type code boundaries (page 15-27):

The indirection applies only to TypeCodes nested within
some "top-level" TypeCode. Indirected TypeCodes are not
"freestanding," but only exist inside some other encoded TypeCode.

I would suggest to rephrase the first part of what is on page 15-18
to avoid saying that the indirection is the same as for type codes
because that's simply not the case.

close with revision

a chunk can be followed by:

1. a new chunk (starting with its size tag)
(1 <= chunk_size_tag < 0x7fffff00
2. a new value (value_tag | 0 | value_ref)
(0x7fffff00 <= value_tag <= 0x7fffffff)
(valueref = 0xffffffff)
3. an end tag
(0x80000000 <= end_tag <= 0xffffffff)

A value indirection and a "top-level" end tag, both have the same tag (0xffffffff).
Consequently, the 0xffffffff tag marks the end of the current value but it is not clear whether or not a new value (indirection) has started.

An example where this situation occurs is a ring buffer that is chunked encoded.

to close with revision

When the response_flags text was added for GIOP 1.2 Request processing,
the old text for the GIOP 1.0 and 1.1 response_expected field was
removed. Thus, the current documentation no longer completely describes
the GIOP 1.0 and 1.1 protocols.

to close with revision

I have a question on how can ORB vendor support profile with ID
TAG_MULTIPLE_COMPONENTS? The spec 2.3/13.6.2 says single profile holds
enough information to drive a complete invocation. Let us say we have an
IOR with one profile and the ID is TAG_MULTIPLE_COMPONENTS. As per
13.6.2.2, the profile body in this case contains a
MultipleComponentProfile. Let us again assume that there is only one
TaggedComponent with component id of TAG_CODE_SETS and its component
data.

What we have here is a legal profile with no end point information. What
can a ORB do with such a profile? Is there any thing broken here or did
I just misinterpret the spec completely?

Close with no revision

I believe that, at some point, we decided that it is legal to send
request for different GIOP versions over the same connection. Could someone
please confirm or deny? (My memory is a bit hazy on the details.)

At any rate, careful scrutiny of the spec does not reveal any words that would
either state that separate connections must be used for different GIOP versions
or that they can share a single connection. A definite statement is required
either way.

Assuming that different GIOP versions can indeed coexist on the same
connection, we get an interesting problem: for GIOP 1.0 and 1.1, the spec
disallows a client to send a CloseConnection message; for GIOP 1.2, it
requires the client to send a CloseConnection message. This begs the question:
if different GIOP versions can coexist on the same connection, it becomes
impossible to achieve orderly connection shutdown. Sending a CloseConnection
message is illegal for GIOP 1.0 and 1.1, whereas it is required for
GIOP 1.2... So, what's the client to do if multiple GIOP versions are used
over the same connection?

To close with revision

There seems to be a problem with valuetypes contained in anys.

Consider the following:
valuetype A

;

valuetype B : A

;

If an instance w/ the following structure:

A { a = {B { x = {<value>}}}}

is inserted into an any and the any is received by an event service. Given that
the event service has no type information of the B encoded inside of A, the
event service has no way of knowing how big A.a (an instance of B) is and how
many bytes it needs to read (unless it contacts an IR)

Am I missing something here?

Close this issue and place it into the GIOP wish list for future enhancements to GIOP.

Although this is a Java-specific issue, I suspect it will have to be
decided in interop, therefore I'd like this to be an interop issue. I've
cc'ed java-rtf since I'm sure they'll be interested.

System exceptions only have: minor code, completion status. Java
exceptions all have a reason string as well. This is a potentially
significant bit of info that is not getting transferred across the wire in
Java ORB implementations. Our rmi over iiop customers expect this
information.

Our suggested solution is to create another service context for a system
exception reason string. When a system exception occurs, on a Java server,
the ORB places the reason string into this service context on the reply
message. On a Java client, the ORB checks for and extracts this string and
uses it when creating the system exception instance which is propagated to
the application code. If the service context doesn't exist, the Java ORB
just does what it does today. Any other client bindings may ignore this
service context.

Java bindings do not need to change for this proposal.

To be more precise (sorta), we need three things:
1. A new service context ID

const ServiceId SystemExceptionReason = TBD;

2. The context data associated with this ID is a CDR encapsulation of a
string.
3. Some verbage somewhere describing this.

closed/resolved

Section 15.3.4.5 contains an inconsistency in the description of how end tags
for valuetypes are written. Consider the case where an unchunked value (V)
contains a chunked value (CV1). Should the end tag for CV1 contain a nesting
depth of -2 or -1?

The following sentence in the spec seems to imply that the correct value is -2:

> The end tag is a negative long whose value is the negation of the absolute
> nesting depth of the value type ending at this point in the CDR stream.

However the spec also says:

> The outermost value type will always be terminated by an end tag with a
> value of -1.

which is not true if the end tag for CV1 is written as -2, since no end tag
with a -1 value will be written.

Proposed resolution:

Delete the second above sentence from the spec.

Close with revision using alternative A above.

The valuetype encoding "grammar" in 15.3.4.7 is wrong. The rule for
<state> should be:

<state> ::= <octets> |<value_data>* [ <end_tag> ]

to allow for valuetypes with no state and therefore no value chunks.

-

to close with revised text

Looking at formal/99-10-07, 15.3.2.8 which describes marshaling of fixed
types I ran into a question. The section doesn't mention how to indicate
the scale of the written decimal.

My understanding is that the TypeCode of kind fixed, which gets written
before the value, indicates the maximum number of digits and the maximum
scale, not what is currently contained in the number. To describe the
current scale I would expect that a decimal point gets written to the
stream, just like the decimals into the half-octets as described in
15.3.2.8.

Close with no Interop Revision

It is unclear in the spec when reply messages are allowed when a fragmented
send message is sent.

It is possible to know that a system exception will occour before the last
fragment in a message is recieved, for example the request can be
demultiplexed to discover the object does not exist, or the appropriate
service contexts are not present.

It should be legal to send a reply containing anything but a NO_EXCEPTION or
USER_EXCEPTION before the last fragment is recieved.

close without revision

1. In the document OMG ptc/99-10-04 p.69-329 there is in item 5 a use
of the type ComponentHome, shouldn't it be CCMHome? If I do recall
correctly, ComponentHome was used in the first versions of the
specification proposal.

You are correct. ComponentHome should be CCMHome

It is probably not a good idea to mandate an implementation for
Enumeration, since there may be different options for implementing.
For example, it may be desirable for
performance reasons to implement a form of lazy Enumeration that does
not carry with it every element that it can contain, but requiring
this kind of implementation can be overkill for some
applications. Given this, Enumeration is defined as an abstract
valuetype and at least one concrete specialization of it is
required. In addition, FOR INTEROPERABILITY, at least one STANDARD
implementation must also be provided so that client stubs and server
skeletons know how to marshal and unmarshal Enumeration values.

resolution see above

every ORB I know of implements the various destroy() operations on
local objects (such as policies or DynAny) as a no-op and destroys the local
object on the final call to release() instead. Yet, the spec still requires
programmers to call destroy(). The problem with this is that programmers
can easily end up writing non-portable code without any visible problem.
Then, when code is moved to another ORB, it is conceivable that it will
leak objects.

This isn't very pretty. I think we should get rid of the destroy() calls
on local objects (possibly with the exception of the ORB object, although
the entire shutdown issue for that is quite a mess anyway). It doesn't
make sense to require the programmer to make a destroy() call for something
that naturally can be reference counted.

When the interfaces identified in section 11.1.5 are updated to be local interfaces, any destroy() o

Problem: The new IDL keywords use mixed case, rather than the lower case style used by current keywords. Should the new keywords be changed to comply with the existing style?

Yes, new IDL keywords should be changed to conform to existing style guide.

2. Implementation of get_component with separate ORB and component vendors
Problem: A design goal of the components specification was to permit the component container to be provided by a different vendor than the ORB vendor. When this is true, how does the implementation of get_component work?

closed issue, resolved

1) The isBasic Attribute needs to be removed from HomeDef to synchronize
with the regular CORBA IR.

resolved

Table 8-1 shows a mapping for CCMObject::get_home. It looks like it should
say CCMObject::get_ccm_home

Proposal:

Change "CCMObject::get_home" to "CCMObject::get_ccm_home" in Table 8-1.

No Data Available

Chapter 8 omits to mention how the CCMHome::get_home_def call is mapped by
the bridge at runtime to an EJB operation.

Issue:
The very similar call CCMHome::get_component_def is shown as mapped to the
EJBHome.getEJBMetaData operation, but there is no mapping shown for
CCMHome::get_home_def. It appears that get_home_def could be also be
implemented using the EJBHome.getEJBMetaData operation, and if necessary,
with the help of Java introspection.

Proposal:
Add a line in Table 8-1 to show CCMHome::get_home_def mapped at runtime to
EJBHome.getEJBMetaData.

Add a line in Table 8-1 to show CCMHome::get_home_def mapped at runtime to EJBHome.getEJBMetaData