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

>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

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

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.

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

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