As per the discussion in the Interop RTF meeting in Mesa, it was decided to
split up 2457 into two parts as follows:

Part 1: What should an ORB do when it does not find any profile in an IOR that
it is able to use? This should usually not happen in a CORBA interoperability
compliant ORB, but the possibility should be covered in the spec anyway.

to close with agreed resolution

Chapter 13 (formal/99-07-17) is missing specification of minor codes for many
the standard system exceptions that are specified to be raised under various
circumstances.

correct the erroneous minor codes and add ones where missing in chaps 13 and 15. Leave the resolutio

Also, 13.6.2.2 claims "ORB services are assigned component identifiers
in a namespace that is distinct from the the profile identifiers".
What is the significance of this statement?

duplicate

Summary: Suppose I am using a 2.3 ORB and receive a type code from a 2.2 ORB without
a repository ID. What am I supposed to do if I want to send that type
code somewhere else? (This could happen for an event channel, for example.)

In this case, we need to add the case for empty repository ID string implies that a repositoryID is

Summary: With GIOP 1.2, we added LOCATE_FORWARD_PERM to the protocol, which
permanently replaces an IOR with a different one. I believe we shouldn"t
have done this because it creates an internal inconsistency. The
Object::hash() operation requires that the hash value for a reference
must be immutable during its life time. (Unfortunately, "life time" isn"t
well-defined.)

resolved

Summary: the spec makes no statement as to the legality of the following constant
definitions:

const long C1 = 3.14;
const short C2 = 1.0;
const unsigned long C3 = -1;
const char C4 = 10;
const char C5 = 500;
const long C6 = 999999;
const short C7 = C6;
const octet C8 = 1000;
const short C9 = C5;
const short C10 = 100 * 100 * 100;

I"m sure that there are lots of others I haven"t thought of, but you get
the idea...

There are certainly lots of holes in the spec, with respect to both the
legal types of the RHS and rules for overflow/underflow and mixed-type
arithmetic. Looks like this will require a major cleanup...

There is a conflict between the specification of the OBJECT_NOT_EXIST
exception and its use in the POA spec. The exception definition says
that OBJECT_NOT_EXIST means that an object has gone away forever, and
that clients should tidy up references to it. However, the POA spec
requires an ORB to raise this exception in cases where the object may
not have gone away for ever.

In particular, 11.2.6 (in the 5 May 2.4 Draft) requires an ORB to raise
OBJECT_NOT_EXIST if request comes in for a child POA that is not active
and was not activated by the application's POA Activator. While this
may mean that the object has gone away for ever, it doesn't always
mean that. For example:

1) If the server admin has stuffed port number allocations, a server
may accidentally get requests for POAs that it doesn't know about.

2) If the server has been incorrectly (re-)built one of its "static"
child POAs might not be activate.

3) If the server is buggy and / or its persistent state is flakey,
it may temporarily fail to dynamically activate a child POA.

In each case, the problem MAY be one that can be fixed, allowing the
missing POA to reappear in a few minutes. It is therefore inappropriate
for the ORB to be telling the client that the Object has gone away for
ever.

For what it is worth, I think the ORB should raise another exception,
say OBJ_ADAPTER, in the default case. It might raise OBJECT_NOT_EXIST
if it (somehow) tracks the lifecycle of transient and / or persistent
POAs, or if the application code tells it the POA no longer exists.
Note: I'm not suggesting that an ORB be required to support such things.

The other alternative is to change the definition of OBJECT_NOT_EXIST
to remove the implication that the object has gone away forever and
the suggestion that clients should throw away references to the object.
[I think that's wrong though ...]

Close no change

Summary: Many changes between CORBA 2.2 and CORBA 2.3 are not changebarred. Some
examples from the POA chapter (docs/formal/99-07-15.pdf):

• Page 11-20: added PortableServer::POAManager::get_state() method.
• Page 11-28: change in the TRANSIENT lifespan policy"s semantics
  (from "cannot outlive the process" to "cannot outlive the POA instance")
• Page 11-35: change in PortableServer::POA::set_servant_manager()
  semantics wrt multiple invocations

I wonder which other tidbits I"ve overlooked so far. Is there a complete
list of changes (such as a CVS log) anywhere?

Page 11-47, reference_to_servant, uses "Wrongpolicy". That should be
"WrongPolicy".

Duplicate of 3634.

ection 11.3.8.4 of the 2.3 spec states: "After all descendant POAs have
been destroyed and their servants etherealized, the POA continues to
process requests until there are no requests executing in the POA."

does that mean new requests are rejected or that new requests for that
POA are processed?

also, if a parent POA is being destroyed, once a descendant has been
destroyed, can an adapter activator be called for the descendant during
this period? in the same paragraph, the spec says "After destruction has
become apparent, the POA may be recreated .. via an Adapter Activator".
should the request block, or can it be rejected?

closed no change

Core issue #1: The Core should explicitly state that valuetype
parameters are copied for collocated interface invocations.

Merge with issue 3364 and close this issue

Are the names of valuetype initializers introduced into the
scope of a derived valuetype? I'm proposing that they are
not introduced. The implication is that derived valuetypes
are free to reuse the names of base type initializers.

Proposed resolution:

Change the last sentence of the first paragraph in 3.8.1.5:

"The names of the initializers are part of the name scope of
the value type, but are not part of the name scope of derived
valuetypes."

Same as Issue 3305, Therefore same resolution as 3305

DynValue is missing support for null valuetypes. There is no
way to determine whether a DynValue represents a null valuetype,
nor is there any way to dynamically construct an Any containing
a null valuetype.

Proposed resolution:

Add the following operations to the DynValue interface:

boolean is_null();
void set_to_null();
void set_to_value();

And replace the description of the interface with the following text:

The DynValue interface can represent both null and non-null
valuetypes. For a DynValue representing a non-null valuetype, the
DynValue's components comprise the public and private members of
the valuetype, including those inherited from concrete base valuetypes,
in the order of definition. A DynValue representing a null valuetype
has no components and a current position of -1.

boolean is_null();

The is_null operation returns TRUE if the DynValue represents
a null valuetype.

void set_to_null();

The set_to_null operation changes the representation of a DynValue
to a null valuetype. Specifically, the current components of the DynValue
are destroyed, component_count returns zero and the current position is
set to -1.

void set_to_value();

The set_to_value operation changes the representation of a DynValue
to a non-null valuetype. The state of the DynValue is initialized
exactly as if create_dyn_any_from_type_code had been invoked.
The set_to_value operation has no effect when invoked on a DynValue
representing a non-null valuetype.

The remaining operations of the DynValue interface have equivalent
semantics to DynStruct. When invoked on a DynValue representing a
null valuetype, get_members and get_members_as_dyn_any return an empty
sequence.

Merge with 3135 and provide resolution as part of 3135

Summary: This is an issue with the Portable Object Adapter:

If a POA configured with a ServantLocator receives a LocateRequest, what
is the expected behavior? A ServantLocator expects to receive an operation
name as a parameter to preinvoke() and postinvoke(), but there is no
operation name in a LocateRequest.

We could just return a true response to the LocateRequest and not involve
the ServantLocator. That might mislead the sender though. If the sender
received a true response and then sent a message they might get an
OBJECT_NOT_EXIST exception back.

We could pass an operation name like "_locate" to the manager. That would
let the manager know that a location request was being processed, and the
underscore would signify that it is an internal message since it"s not a
_get or _set.

Add a subsection to section 11.3.6 specifying "_locate" and its usage.

Summary: Section states that the deactivate_object() operation doesn"t wait for etherialize operation to complete before it returns. This is impossible to implement in single-threaded ORB

No Data Available

>From CORBA 2.4, Table 4-3: TRANSIENT minor code 1 is described as:

"Request discarded due to resource exhaustion in POA."

However, section 11.3.2.1 states that minor code 1 is used when the
POAManager is in the DISCARDING state.

I think it would be better to reword this description as:

"Request discarded because POAManager is in DISCARDING state (e.g.
server lacks resources to complete request.)"

Make it so

Following statement in CORBA V2.3 (06/1999),
P10-39, Chapter 10.6.1, OMG IDL Format concerning
the OMG IDL format for Repository IDs:

>> The RepositoryId consists of three components, separated by
colons, (":")

The first component is the format name, "IDL."

The second component is a list of identifiers, separated by
"/" characters.

These identifiers are arbitrarily long sequences of alpha-
betic, digit, underscore ("_"), hyphen ("-"), and period (".")
characters. Typically, the first identifier is a unique prefix,
and the rest are OMG IDL Identifiers that make up the scoped
name of the definition. <<

There are two issues here:

• Firstly I propose to change >>"IDL."<< into >>"IDL".<<
• Furthermore, I propose be more specific on the definition
  of the Repository Id. The above definition does not
  exclude a RepositoryId in the following style (which
  in my opinion does not make sense and effects inter-
  operability between ORBs): "IDL:/A/B:1.0"
  A regular expression could clarifiy this issue:

Incorporate changes and close issue.

The semantics for local interfaces states:

A valuetype may support a local interface.

This brings up two questions.
1. Can it support multiple? In addition to a unconstrained non abstract
interface?
2. Does it then become a local type (I think not, I think it becomes a
local type only when it contains state that is a local type)

No Data Available

given the a DynUnion value, I want to find out whether the discriminator
currently indicates the default case. For example:

union u switch (long)

;

For this union, I want to know whether the default member is active, that is,
whether the discriminator has a value other than 0, 1, or 2.

Finding out whether the discriminator indicates the default case is currently
rather difficult. I have to:

1) get the union type code
2) collect the values of all the explicit case labels from
the type code
3) check if the discriminator currently has a value that is not
one of the explicit case labels values

It would be much nicer to add the following to DynUnion:

interface DynUnion : DynAny

;

The is_set_to_default_case operation returns true if a union has
an explicit default label and the discriminator value does not
match any of the union's other case labels.

Add the is_set_to_default_member function with the functionality as described for is_set_to_default_

In the CORBA 2.4 spec, chapter 10, the definition of #pragma ID has
been modified so that later re-declarations of the same ID for a type
are permitted. Before, it was explicitly an error to use #pragma ID
for a type more than once, even if the same IDs were given.

The section of #pragma version has not been updated. This means that
handling of the two similar pragmas is now inconsistent:

interface A {};
#pragma ID A "LOCAL:foo"
#pragma ID A "LOCAL:foo" // OK in 2.4, error in 2.3

interface B {};
#pragma version B 3.4
#pragma version B 3.4 // Error in 2.4 and 2.3

Should #pragma version be updated to be consistent with #pragma ID?

Incorporate changes and close issue

Consider a servant for a persistent object that sits in front of a database.
Assume a simple implementation model, using RETAIN and
USE_ACTIVE_OBJECT_MAP_ONLY.

We have n CORBA objects with n servants, and each servant implements
its operations by reading/writing through to the persistent store, possibly
also caching some state and maintaining other resources, such as database
connections or memory buffers.

I want to implement a life cycle destroy() operation. In the body of
destroy, I have to write something like:

void
Foo_impl::
destroy() throw(CORBA::SystemException)

The problem is that the servant can't simply blow things away at that
point because there may be other operations running concurrently in the
same servant, and those operations would get awfully surprised if their
state suddenly disappeared.

So, I delay reclaiming resources and deleting the database record until
the servant becomes idle. In C++, that's no problem. Eventually, the
servant's AOM entry disappears and (at least if I use reference-counted
servants) that triggers the destructor of the servant, and I can
clean up in the destructor.

However, it appears that this doesn't work for other languages because they
may not have destructors or, like Java, make no guarantees about when
the destructor will be called.

The problem is that there is no way for me to find out at what
point the servant becomes idle, so that I could clean up.

I think we need a callback from the ORB to the server application code that
notifies the server when a servant finally becomes idle. Otherwise, it is
pretty much impossible to implement life cycle support in languages other
than C++, especially for threaded servers.

Close no change.

The format of the "hash code" element of an RMI Hashed Format repid
needs to be clarified. Section 10.6.2 gives the algorithm for computing
the 64-bit number to be used as the hash code, but does not specify the
on-the-wire format for this number. In contrast, the spec explicitly
states that the 64-bit number representing the SUID is transcribed as
a 16-digit upper-case hex string.

Clarify as suggested below

Page 11-47, reference_to_servant, uses "Wrongpolicy". That should be
"WrongPolicy".

Editorial, fixed editorially in 2.4

Pages 11-30 (twice), 11-31 (three times), and 11-52 (once) mention
the OBJECT_ADAPTER exception. That's wrong – it should be OBJ_ADAPTER.

Editorial, fixed editorially in 2.4

Section 4.3.7.1 refers to a get_client_policy operation, but it is not
defined anywhere in the CORBA specification.

temporary bug....fixed, and issue closed

Page 7-9 of 2.3.1 shows

boolean poll_response(in Request req);

However, on page 7-5, we have:

boolean poll_response();

The version on page 7-5 is the correct one because poll_response() is
an operation on Request.

Proposal:

Change the signature on page 7-9 to read:

boolean poll_response();

closed issue...editorial

This system exception is listed in the notification specification but
does not exist in CORBA 2.3 (nor CORBA 2.0 AFAIK).

closed issue, available in current draft

The components spec permits attributes to raise user exceptions, to
bring them in line with operations. That's a really nice idea, but
raises yet another versioning problem. In particular, no new IDL that
uses an attribute with a raises clause can be compiled by an older IDL
compiler. (Simply deleting the raises clause and then compiling with
an older compiler is risky at best – marshaling code won't in general
expect to get a user exception in reply to accessing an attribute...)

withdrawn by submitter

I was wondering if anyone can explain the rationale for adding the field
'is_abstract' to the CORBA::InterfaceDescription and
CORBA::InterfaceDef::FullInterfaceDescription struct types in the CORBA
2.3 Interface Repository specification. (I do know about abstract interfaces,
I am really looking for the rationale for breaking backwards compabitility).

Basically, a CORBA 2.3 client using stubs compiled from the latest IDL cannot
interoperate using IIOP with the Interface Repository of a pre-CORBA 2.3 ORB,
because virtually any client of the IR will want to obtain a
FullInterfaceDescription from an InterfaceDef, and a pre-CORBA 2.3 ORB will
not marshal the 'is_abstract' field for the description struct, thereby the
CORBA 2.3 client will fail to unmarshal the struct.

flagged as urgent....resolved

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

Table 13-1 is missing a row:

Feature Version 1.0 Version 1.1 Version 1.2
-----------------------------------------------------------
Valuetypes and yes
Abstract
Interfaces

add table row as suggested.

Description: Instruction for marshalling of null values is missing (in

ptc/99-03-07). Issues include:

• The null_tag token is included in the grammar, but it's purpose is
  described nowhere. If this is the intended encoding of any null value,
  how are the typing semantics of values to be maintained? For example,
  which type-specific factory is to be used to create the null value to
  be
  passed to the servant? How are the truncation semantics to be
  preserved?
• There is a statement in 15.3.4.5 that "[t]he tag value 0 is reserved
  for future use". Does this refer to null_tag? (Note that there seems to
  be
  inconsistent use of "tag" within the text.) If so, how are null values
  to be marshalled? The grammar doesn't seem to allow for zero length
  value_data.

to close with revision

In the current 2.3 spec section 15.3.3 on Encapsulation
states in the last paragraph:
"Note that this gaurantees a four-octet alignment of the
start of all encapsulated data within GIOP messages and
nested encapsulations(2)"

There's a foot note on the bottom of the page stating:
(2) "Accordingly, in cases where encapsulated data holds
data with natural alignment of greater than four
octets, some processors may need to copy the octet
data before removing it from the encapsulation. The
GIOP protocol itself does not require encapsulation
of such data"

Here's the problem, the latest revisions have added support
for a "[unsigned] long long" being the discriminator type
within a union and therefore the encapsulated information
for a tk_union TypeCode could have alignment needs of eight,
not four.

The footnote needs to be revised to indicate that copying
could be necessary for some type code indirections or at
least the sentence stating that "GIOP problem itself..."
should be removed/revised. Of course we could try to
remove support for "long long" discriminators....

Some of the interoperability testing we've been doing
indicates that all but one vendor who supports long long
discriminator types are not doing things correctly...

to close with revision

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

CORBA 2.3, section 15.4.3.2 - Reply Body - states:

"A vendor (or group of vendors) wishing to define a specific set of system
exception minor codes should obtain a unique VMCID from the OMG, and then
define up to 4096 minor codes for each system exception."

Section 3.17 - Standard Exceptions - states:

"Within a vendor assigned space, the assignment of values to minor codes is
left to the vendor."

The first dictates that minor code numbers are in the space of each
Standard Exception. Ie, the true # of minor codes is (4096 times
#-of-Standard-Exceptions). But the second implies that vendors can
allocate their minor codes however they wish.

So which is it? The first mandate (if you read it as a mandate) or the
second freedom?

Take proposed resolution from Core RTF discussion in issue Archive

Summary: If we had a repository ID on the wire with every request, such errors could
> be caught. In addition, it would make it substantially easier to build
> tools such as IIOP packet tracers – right now, it is next to impossible
> to dump the parameter values of IIOP requests because the packet tracer
> has no way of figuring out what the type of the target object is.

This could be added to IIOP in a reasonably non-invasive way, too. We
could add a service context to the request which would carry the
repository ID of the interface in which the method was defined

Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

Summary: Following the discussion of valuetype chunking in the OBV group, I"ve
been thinking that the arguments advanced for it really apply to all
the other variable-length types in CORBA (sequences and strings) as
well as to OBV value types, and wonder if we might try a small change
to the marshalling rules.

Currently, we marshal a string (say) by sending the length of the
string followed by the bytes of the string. If we don"t know the
string"s length in advance, say because we are reading it from stdin
or a subprocess, we need to buffer it in memory and send it as one big
thing. That"s inefficient.

Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

Summary: Is there any particular reason that we shouldn"t allow these two
ComponentIds in IIOP IORs? They certainly can be useful using IIOP for
optimization of client/server interactions, and can be safely ignored by
clients that don"t implement/understand them.

So could we add text to the spec that states that these components are
allowed in IIOP IORs, but the clients are free to ignore them?

Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

Summary: As of GIOP/IIOP 1.1, if a server wants to have a client
use some locally hashed down object_key in future requests
for an object, it must require one of the following:
a) the client use a LocateRequest in order for the server
to reply with a forwarded object reference that has
a hashed down object key.
b) respond with an OBJECT_FORWARD reply to the request,
forcing the client to remarshal the request with the
new target (the forwarded object reference"s key).
With some already recommended changes to GIOP 1.1,
such a reply will only require remarshaling the
message header, but an extra roundtrip is still required.

This could be avoided by addind a new service context
to the reply that contains the forward IOR, or a new
Reply type such as NO_EXCEPTION_AND_FORWARD that
indicates the first request has succeeded and that
subsequent requests can use the supplied forward IOR.

Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

Summary: As of GIOP/IIOP 1.1, a Request identifies the operation to
be invoked as a string. If this can be compacting to
an integral value, savings would be possible on all
subsequent requests. A simple solution would involve
a service context containing "operation name to index"
mappings.

Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" st

Summary: Section 15.3.7 of 98-12-04 discusses the encoding of abstract
interfaces, but neglects to mention how to encode an abstract
interface whose value is nil.

see above

Summary: A common server pattern is that of "factory". As a result
of a request, a Factory returns an object reference.
Frequently, these object references differ only by a
small fraction of their full size. For example, object
references may be exactly the same except for the object_key
member of a GIOP profile and maybe the repository_id field
of the IOR. Allowing the factory to return a more compact
representation of the object reference would yield great
savings in message size.
If the server or client can establish a template for filling
out object references (or possibly any type of data), a
more compact on-the-wire form can be used for such object
references once the template is established.

Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

Summary: Repeated strings within an encapsulation can account
for a large percentage of the size of the encapsulation.
Indirections are already used in the marshaling of TypeCodes
to allow compacting of messages. This can be extended
to also allow indirection for strings. The current
encoding of a string is the unsigned long number of characters
in the string, followed by the null-terminated characters
comprising the string. If we resolve the maximum value
for unsigned long "0xffffffff" for indirections, the
next byte can refer to a previously marshaled string.

Close previously deferred issue as too much for RTF. Add to GIOP future version "wish list".

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

Summary:

8.2.1.2 of the CCM specification says that EJB finder and creator methods
which return an RMI object reference are mapped to methods which return a
Components::CCMObject reference. It is unclear whether the actual base
class CCMObject is intended or whether the specific component subclass
(e.g., Widget) is intended. The specific subclass seems more sensible,
and is consistent with the equivalent IDL mappings shown in section 5.8.4.

Proposal:

Change 8.2.1.2 to make it clear that the specific subclass (e.g., Widget)
is the return type.

Change 8.2.1.2 to make it clear that the specific subclass (e.g., Widget) is the return type

When mapping EJB set/get methods to a CCM view, it is not clear whether the
resulting IDL attributes belong on the ComponentDefault interface or on the
component definition itself

Issue:
Set/get method pairs on the EJB remote interface map to IDL attributes, but
do these attributes end up in the XXXDefault interface or in the XXX
component definition? Section 8.2.1.2 of the specification seems to imply
they belong in the XXXDefault interface, but section 5.3.2 says the
component definition for a basic CCM "shall only contain zero or more
attribute declarations", which suggests that attributes of a CORBA
Component belong in the component definition. Also, the mapping in the
other direction (EJB view of a CCM), described in 8.3.1, suggests that CCM
attributes are always found in the component definition itself. It appears
that both versions will work, but this point is worth clarifying.

Proposal:
Change 8.2.1.2 to say that all EJB set/get method pairs are mapped to IDL
attributes on the component definition itself.

resolved

Section 5.12.1 of the spec can be interpreted to mean that the
CCMObject::remove call is not intended for use by CCM clients; but this is
inconsistent with the EJB/CCM mapping given in chapter 8.

Issue:
The explanation given for the CCMObject::remove call in section 5.12.1 is:
"This operation is called when a component is about to be destroyed.
The component
can perform any cleanup processing required (e.g. releasing resources)
prior to its
destruction."
This explanation can be interpreted to mean that the call is a private call
from a CCM container to one of its components; if it has this internal
purpose then it might not be
intended for use by CCM clients wanting delete the component. However,
table 8-1 shows that the CCM view of an EJB maps this call to the
EJBObject.remove()
method. This implies that the method is intended for client use as the
EJBObject.remove() is. If so, then it also makes more sense to implement
the
CCMHome::remove() method in terms of the EJBObject.remove() method, rather
than the current mapping which requires an EJB Handle.

Proposal: (a) Change the text for remove() in 5.12.1 to say: "This
operation is used to delete a component".
(b) Change the mapping in table 8-1 for CCMHome::remove to use
EJBObject.remove

Change the text for remove() in 5.12.1 to say: "This operation is used to delete a component".

I think I found a possible (very minor) optimization for the
GIOP 1.3 spec, but maybe I'm missing something in GIOP 1.2

The new <target> field on the RequestHeader_1_2 structure is
always aligned to a 4 byte boundary, the reserved[3] field ensures
that. Consequently the discriminant for the TargetAddress union
does not end on a 4 byte boundary, but will require 2 bytes of padding
following it, since all the union values in this case start on 4 byte
boundaries.

IMHO, using just 1 byte for the reserved[] field, would have
resulted in more natural alignments. Did I get something wrong here?
Is this something likely to be fixed in GIOP 1.3?

Close this issue as too much of a change for this RTF, and add it to the GIOP wish list for future p

Well, a new Java release is upon us, and with it comes a new CORBA
implementation. I'm trying Java 2 SE 1.3 CORBA clients against an ILU
2.0beta1 CosNaming server, and we find that the Java ORB cannot
reliably connect to the server. Why not? First, we must analyze the
IOR provided by the ILU service:

IOR:000000000000002849444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578743A312E300000000002000000000000002F0001000000000016776174736F6E2E706172632E7865726F782E636F6D00270F0000000B4E616D6553657276696365000000000100000024000100000000000100000001000000140001001800010001000000000001010000000000

If we look at this (those who've received it un-truncated) we find that it advertises the following:

_IIOP_ParseCDR: byte order BigEndian, repository id <IDL:omg.org/CosNaming/NamingContext:1.0>, 2 profiles
_IIOP_ParseCDR: profile 1 is 47 bytes, tag 0 (INTERNET), BigEndian byte order
_IIOP_ParseCDR: profile 2 is 36 bytes, tag 1 (MULTIPLE COMPONENT), BigEndian byte order
(iiop.c:parse_IIOP_Profile): bo=BigEndian, version=1.0, hostname=watson.parc.xerox.com, port=9999, object_key=<NameService>
(iiop.c:parse_IIOP_Profile): encoded object key is <NameService>
(iiop.c:parse_IIOP_Profile): non-native cinfo is <iiop_1_0_1_NameService@tcp_watson.parc.xerox.com_9999>
(iiop.c:parse_MultiComponent_Profile): profile contains 1 component
(iiop.c:parse_MultiComponent_Profile): component 1 of type 1, 20 bytes
(iiop.c:parse_MultiComponent_Profile): native codeset for SHORT CHARACTER is 00010001, with 0 converters
(iiop.c:parse_MultiComponent_Profile): native codeset for CHARACTER is 00010100, with 0 converters

That is, there's a vanilla Internet profile (bo=BigEndian,
version=1.0, hostname=watson.parc.xerox.com, port=9999,
object_key=<NameService>), plus a Multicomponent profile, noting that
the ILU ORB's native codesets are Latin-1 and UCS-2.

OK, great. Now we get the first message from the Java ORB:

0000 47 49 4f 50 01 00 00 00 00 00 01 00 GIOP........
0000 00 00 00 02 00 00 00 01 00 00 00 0c 00 00 00 00 ................
0010 00 01 00 20 00 01 01 00 00 00 00 06 00 00 00 90 ... ............
0020 00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e .......(IDL:omg.
0030 6f 72 67 2f 53 65 6e 64 69 6e 67 43 6f 6e 74 65 org/SendingConte
0040 78 74 2f 43 6f 64 65 42 61 73 65 3a 31 2e 30 00 xt/CodeBase:1.0.
0050 00 00 00 01 00 00 00 00 00 00 00 54 00 01 01 00 ...........T....
0060 00 00 00 0c 31 33 2e 31 2e 31 30 33 2e 36 38 00 ....13.1.103.68.
0070 0e e9 00 00 00 00 00 18 af ab ca fe 00 00 00 02 ................
0080 67 d5 93 95 00 00 00 08 00 00 00 00 00 00 00 00 g...............
0090 00 00 00 01 00 00 00 01 00 00 00 14 00 00 00 00 ................
00a0 00 01 00 20 00 00 00 00 00 01 01 00 00 00 00 00 ... ............
00b0 00 00 00 05 01 00 00 00 00 00 00 07 53 79 6e 65 ............Syne
00c0 72 67 79 00 00 00 00 06 5f 69 73 5f 61 00 00 00 rgy....._is_a...
00d0 00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e .......(IDL:omg.
00e0 6f 72 67 2f 43 6f 73 4e 61 6d 69 6e 67 2f 4e 61 org/CosNaming/Na
00f0 6d 69 6e 67 43 6f 6e 74 65 78 74 3a 31 2e 30 00 mingContext:1.0.

Note that we are seeing a CodeSets service context, even though the
request is GIOP 1.0. The service context specifies a TCS-C of ASCII,
and a TCS-W of UCS-2.

The question is, what should the server do with it?

First of all, there seems to be no way in which the algorithm in
section 13.2.7.6 can result in the TCS-C specified in the service
context. So perhaps this bug should be detected and signalled back to
the sending ORB. How? Using CODESET_INCOMPATIBLE might make sense,
but that really doesn't flag the bug in the client-side implementation
of the codesets determination algorithm. Perhaps a straight
COMM_FAILURE would be better. Opinions?

Secondly, since this is GIOP 1.0, the client could reasonably ignore
the service context, and go ahead with using its default codeset
(Latin-1). However, to do so risks comm failure down the line, as
ASCII (the TCS-C assumed by the client) does not permit many Latin-1
characters. It seems better to flag this situation up front.

close with revision. See below

It's occoured to me that according to the spec it's allowable for
a message to be fragmented and have second and subsequent
fragments change the version fields.

Having the version change while in the middle of reading a
wstring could cause problems, the CDR encoding of version 1.1
strings is always two bytes longer than the corresponding 1.2
encoding, if the version changed while in the middle of reading
the wstring the length field would be out by two.

Secondly if request IDs are per-protocol rather than
per-connection (as aired in issue 3438) then the request ids of
the fragments could interfere.

I think an extra phrase should be added to the spec with regards
to fragmentation, similar to the one regarding byte order:

The version of fragments must match the version of the initial message that
the fragment extends.

Close without revision since the spec was already clarified to state this.

The UK believes the footnote to section 13.6.2, page 13-16, of CORBA
2.3.1 (this is clause 5.6.2 with the footnote appearing on page 13 of
DIS 19500-2) does not make sense, especially the phrase "... except
ones that make such profiles...". The meaning of this footnote needs
to be clarified with revised text.

Close without revision.

The Japanese would like to clarify the first sentence of the first
paragraph of section 15.5.2, page 15-46, of CORBA 2.3.1 (this
is clause 6.4.2 of DIS 19500-2, page 70) by adding the phrase
"if Bi-Directional GIOP is not used" to the end of the sentence.
The resulting sentence would read "Only the client (connection
originator) may send Request, LocateRequest, and CancelRequest
messages if Bi-Directional GIOP is not used."

Is there any reason not to add this phrase now that Bi-Directional
is in the OMG specification?

Agree that this was an editorial oversight in corba 2.3.

I have a question on the octet alignment requirement for wchar as
mentioned in Table 15-1 of CORBA 2.3. In 15.3.1.6 the spec states that

"For GIOP version 1.2, wchar is encoded as an unsigned binary octet
value followed by the octet sequence representing the encoded value of
the wchar. The initial octet contains a count of the number of elements
in the sequence and the elements of the sequence of octets represent the
wchar, using the negotiated wide character encoding"

If this is a variable length octet sequence anyway, specifying an octet
alignment for this does not make sense. Our assumption is that alignment
is specified only for GIOP 1.1 style wchars and is irrelevant for
GIOP 1.2 style wchars. I am looking for confirmation of that assumption.

If that is a valid assumption, shall we change the table 15.1 third row
first column entry to state "wchar (in GIOP 1.1)" instead of "wchar"?

If that is not a valid assumption, what are we aligning here? The length
byte? The elements of octet sequence? What is the benefit of any
aligning in this case?

Close with revision

The Interop RTF added text that explicitly states that padding for a
Request body in GIOP 1.2 is not necessary if the body is empty. No
equivalent text was added for empty GIOP 1.2 Reply bodies.

Agree to add equivalent text for reply bodies.

In GIOP, the _get_domain_managers operation name is used to indicate
an invocation of the get_domain_managers pseudo operation. OTOH, it is
also used if an attribute domain_managers is accessed, as it would
appear in

interface I

;

Changing the object reference operation on the wire to _domain_managers fixes the problem stated.

Chapter 8 of the spec specifies mappings between EJB operations and their
equivalents in the CCM view, but it leaves the mappings of standard EJB
exceptions unclear.

Issue:
Create methods on an EJB home interface all throw the standard
javax.ejb.CreateException; finder methods on the EJB home interface all
throw the javax.ejb.FinderException; and remove methods on both home and
remote interfaces all throw the javax.ejb.RemoveException. In a few cases
chapter 8 gives an implied mapping: for example, the FinderException on the
findByPrimaryKey method seems to map to either the
Components.UnknownKeyValue exception or to the Components.InvalidKey
exception on the equivalent find_by_primary_key CCM method. Even in these
cases the names are sometimes inappropriate. In the majority of cases,
however, there is simply no CCM equivalent to the EJB exception, and bridge
implementors are left to wonder whether they should attempt a non-standard
mapping.

Proposal:
(a) Add the new CCM standard exceptions Components.CreationFailure,
Components.NotFound, and Components.RemovalFailure
(b) Add Components.CreationFailure to the raises clause of all create
methods on implicit and explicit home interfaces
(c) Add Components.NotFound to the raises clause of
find_by_primary_key on implicit home interfaces, and to the raises clause
of all finder methods on explicit home interfaces
(d) Add Components.RemovalFailure to the raises clause on the remove
operation on implicit home interfaces, to the CCMObject.remove operation,
and to the CCMHome.remove_component operation
(e) Specify in chapter 8 that the EJB Finder exception is always
mapped to Components.CreationFailure; that the EJB CreateException is
always mapped to Components.CreationFailure; and that the EJB
RemoveException is always mapped to Components.RemovalFailure.
(f) Make explicit in chapter 8 the already implied mapping bewteen the
EJB DuplicateKeyException and the Components.DuplicateKeyValue exception

No Data Available

Summary: Section 8.2.1.2 of the spec defines Components::Enumeration as an
IDL interface, with the implication
that it is intended as a remote type.

Issue: It has been noted that java.util.Enumeration is usually implemented
as a java.io.Serializable and that making
Components::Enumeration an IDL interface would prevent this from happening
for collections of primary keys returned
from EJB Homes that are mapped to CCM Homes.

Proposal: Define Components::Enumeration as an IDL abstract valuetype.

Define Components::Enumeration as an IDL abstract valuetype

Summary: The CCM FTF IDL chapter does not state whether a home must be
declared for a component. A home must have a component, but must a
component have a home?

A component must have a home

The following errors in the interface repository chapter 10 need to be fixed.

1. In IDL for interface HomeDef on Page 52 and Page 88:
Remove the line: readonly attribute boolean is_basic;
2. In IDL for struct HomeDescription on Page 52 and Page 88:
Remove the line: boolean is_basic;
3. In section 10.5.38.1 on page 53: Remove the paragraph that begins with:
"The is_basic attribute is TRUE if this is a basic home......."

Since there is no basic and extended distinction for homes as there is for components, change text a

The following errors in the component model chapter 61 need to be fixed as
follows to align the IDL in the text with the final IDL published in
Appendix A (orbos/99-08-08).
1. In IDL on page 46, section 61.6.3 add a “;” after expected_event_type.
2. In IDL on page 43, section 61.5.3 replace
ConnectionList get_connections (in FeatureName name)
raises (InvalidName);
with
ConnectedDescriptions get_connections (in FeatureName name)
raises (InvalidName);
3. In IDL on page 68, section 61.10.1.2 replace
valuetype ConfigValue

;
with
valuetype ConfigValue

;

resolved

I'm concerned that for C++, implementing "import" as currently specified in
the Components spec will be extremely difficult.

Imagine how you might implement this: your IDL compiler generates a C++
header file for all imported name scopes and creates #include directives
for these files in the C++ code generated for the main IDL file. The main
problem is that importable name scopes are modules, interfaces, valuetypes,
structures, unions, and exceptions. To import an exception, for example,
the import mechanism would have to keep a dependency graph for that
exception type and make sure that all dependencies are generated into the
header file so the C++ compilation won't fail. This seems way too complex,
and I don't see the value of being able to import individual structs and such.

Remove structure, union and exception from the list of name scopes (and repository ids) that can be

Summary: the current spec doesn"t list policy objects as locality constrained.
This seems rather strange. In particular, at the time I create policy objects,
there is no POA that could be responsible for them, and I have no way
to associate a policy object with a particular POA.
Of course, this raises the question of whether references to policy objects
are persistent or transient, whether I can pass them to another address
space, whether requests on them are single-threaded or not, etc, etc.

Close, no change (for 2.4).

Summary: something about locality-constrained objects... The spec says that LC objects
are local, so I cannot pass reference to another process or use
object_to_string with them. There are no other restrictions so, by
implication, LC objects can do everything a normal object can do. In paricular,
I can invoke operations on LC objects via the DII, I get preinvoke and
postinvoke calls from a servant locator, and the reference for an LC object
and its servant have independent life cycles.

This seems rather strange.

close, no change

Summary: Here"s an interesting question. How do you prevent the externalization of
an l-c object? The user can create a reference to the l-c object before
the l-c object has been bound to the POA itself. This means that the
reference can be externalized, and calls could presumably come into
the POA for this l-c object. What should the result of this call be?
OBJECT_NOT_EXIST?

issue closed, no change

Given the IDL below, is the third case (labeled "Nested Recursive
Case") legal in CORBA 2.3.x? (I understand that the answers to my questions
may change in 2.4: I am interested in possible flaws in 2.3 at the moment).
If it is legal, I have some concerns listed after the IDL:

//IDL
module recurse
{
//Recursive Struct: This is legal
struct TestStruct1

;
// Nested Struct: This is legal
struct TestStruct2 {
struct TestStruct3

twoMember;
};
// Nested Recursive Case: IS THIS LEGAL?
struct One {
struct Two

oneMember;
};
};

1) If this IDL is loaded into an IFR, and the type() method of the StructDef
for ::recurse::One::Two is called, what should happen? I can think of at
least three interpretations of the spec (in particular, section 10.5) :

a) type() should fail since the TypeCode for Two is not valid
outside of the definition of One. If this is the case, what should it
throw? (the natural result of many implementations would be MARSHAL, but
that seems wrong)

b) type() should succeed and should include a complete, valid
TypeCode of the form:

//BEGIN TYPECODE//
Struct_tc(Two)
MemberList
StructMember
twoMember,
TypeCode: Struct_tc(One)
MemberList
StructMember
oneMember,
TypeCode: Recursive_tc("IDL:recurse/One/Two:1.0")
//END TYPECODE//

c) type() should succeed and should include a complete, valid
TypeCode of the form:

//BEGIN TYPECODE//
Struct_tc(Two)
MemberList
StructMember
twoMember,
TypeCode: Struct_tc(One)
MemberList
StructMember
oneMember,
TypeCode: Struct_tc(Two)
MemberList
StructMember
twoMember,
TypeCode: Recursive_tc("IDL:recurse/One:1.0")
//END TYPECODE//

2) Similarly, what should the behavior be when the type() method on the
generated structs (or their Helper classes in Java) are called? In
particular, at what point is the ORB responsible for "embedding" the
recursive TypeCode in its enclosing TypeCode as specified by section 10.7.3
"Creating TypeCodes"?

For example, given the following code (in Java, but applied to other
languages):

TypeCode recursiveTC = orb.create_recursive_tc("IDL:recurse/One:1.0");

org.omg.CORBA.StructMember[] members = new
org.omg.CORBA.StructMember[1];
members[0] = new org.omg.CORBA.StructMember("twoMember",
_orb().create_sequence_tc(0, recursiveTC), null);
/1/ TypeCode twoType = _orb().create_struct_tc(id(), "Two", members);

members = new org.omg.CORBA.StructMember[1];
members[0] = new org.omg.CORBA.StructMember("oneMember", twoType,
null);
/2/ TypeCode oneType = _orb().create_struct_tc(id(), "One", members);

If 1 attempted to resolve the recursive TC, it would fail.
If 2 attempted to resolve the recursive TC, it would succeed, but would
have to traverse all of twoType's members to see if there was a recursive TC
in there.

Any other thoughts on this issue would be appreciated.

Close no change with explanation as above.

1. The phrase "the only recursion permitted for constructed types with the exception of value types" is confusing: a) valuetypes are not constructed types b) the definition of a valuetype may indeed be recursive, but then so can interfaces - why are these not mentioned? Are you trying to say something specific with regard to valuetypes?

2. The cross reference in the first example should be 3.10.7 not 3.10.3.

3. Why does the second paragraph on page 3-38 insist that a forward declared definition must follow "in the same source file"? While this is sensible I do not see the point in enforcing it (there is a separate rule about repository IDs which has a bearing). I couldn't find a statement requiring completion of forward interface and valuetype declarations to compare with - I have always assumed these must be satisfied too.

Incorporate changes and close issue

The org.omg.CORBA.DataInputStream and
org.omg.CORBA.DataOutputStream do not define read_fixed() and
write_fixed() methods. To enable custom marshalling/unmarshalling
of the fixed data types, these methods should be added to the
above classes.

Incorporate changes and close issue.

The IDL grammar does not allow valuetype initializers to be declared
as raising user exceptions, which seems like a potentially useful thing
to do. Was this possibility considered and rejected for some reason?