Issues for CORBA Core Revision Task Force discussion list

To comment on any of these issues, send email to orb_revision@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 1: Recusive Type Definitions (orb_revision)

Click here for this issue's archive.
Nature: uncategorized
Severity:
Summary:

Summary: What does "semantically constrained" mean in section 3.8.2 under the discussion of recursive type specifications.

Resolution: closed issue, resolved
Revised Text: Replace the 2 sentences "Although it is.."template type." with "although the IDL syntax allows the generation of recursive constructed type specificationsthe only recursion permitted for constructed types is through the use of the sequence template type.
Actions taken:
May 16, 1996: Issue received
March 25, 1997: closed issue

Discussion:

Issue 2: Inheritance of describe_contents() (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Where does the OperationDef interface inherit the describe_contents() operation from.

Resolution: close issue, resolved
Revised Text:
Actions taken:
May 16, 1996: Issue received
February 26, 1998: closed issue

Discussion:

Issue 14: IFR: union elements associated with case labels (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: A union element associated with N case labels manifests in the IFR as N distinct UnionMembers. Is this intended?

Resolution: resolved, close issue
Revised Text:
Actions taken:
May 16, 1996: Received issue
February 26, 1998: closed issue

Discussion:

Issue 66: Whether unions carry exact discriminant information (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: It is uncertain whether or not the explicit value used to discriminate between various arms of a union is information which is required to be supported.

Resolution: resolved, close issue
Revised Text: Value of aunion type includes the exact value of the discriminator. Move this requirement to Chapter 1, since it is a requirement on the type model, not on IDL
Actions taken:
August 5, 1996: Received issue
March 25, 1997: Closed issue

Discussion:

Issue 68: Missing info about the semantics of ORB_init and OA_init (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The text associated with ORB_init and OA_init does not specify what is done with the argv parameter that requires it to be inout.

Resolution: Incorporate change in 2.3a and close issue.
Revised Text: Add the following paragraph immediately following the next to last paragraph
Actions taken:
August 13, 1996: Received issue
February 22, 1999: closed issue

Discussion:

Issue 73: Do typecodes need literal constant representations in all mappings? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Section 6.7 of the CORBA 2 spec constrains the representation of typecodes such that typecode "literals" can be placed in C include files. Is this meant?

Resolution: The offending paragraph, which is now the para 3 of section 10.7, seems to not clearly state anythi
Revised Text: Remove para 3 of section 10.7 Close in 2.3a after incorporating change.
Actions taken:
August 13, 1996: Received issue
February 22, 1999: closed issue

Discussion:

Issue 76: CORBA::InterfaceDef name collision (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: CORBA::InterfaceDef defines an operation "is_a", although there is already an "is_a" operation defined in CORBA::Object. Section 3.6 on page 3-17 says this is not allowed.

Resolution: close issue, resolved
Revised Text:
Actions taken:
August 13, 1996: Received issue
February 26, 1998: closed issue

Discussion:

Issue 85: Interface Repository Error Handling (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The IR specification specifies what operations are an error, but does not specify how this error is returned. The specification does not define any exceptions.

Resolution: Superceded by Issue 778
Revised Text: Close issue with annotation that it is now being handled in 778
Actions taken:
August 15, 1996: Received issue
February 22, 1999: closed issue

Discussion:

Issue 86: lookup() questions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Does the lookup() function also lookup in the base interfaces if used on an InterfaceDef? If so, what if it is is more than one interface? Can the search_name argument be a scoped name?

Resolution: resolved, close issue
Revised Text:
Actions taken:
August 15, 1996: Received issue
February 26, 1998: closed issue

Discussion:

Issue 87: Exception as explicit parameter (orb_revision)

Click here for this issue's archive.
Nature: Interpretation
Severity: Serious
Summary:

Summary: Is it permissible to declare an exception as an explicit parameter?

Resolution: resolved, close issue
Revised Text: An exception declaration is not a type declaration, according to the grammar, so it cannot be a parameter type.This has already been entered as a C++ issue. Issue closed.
Actions taken:
August 18, 1996: Received issue
December 12, 1996: closed issue

Discussion:

Issue 88: Request reuse (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Can a Request pseudo object be invoked multiple times?

Resolution: resolved, close issue
Revised Text: Add following sentence to 4.2.3:"The behavior is undefined if the Request pseudo-object has already been used with a previous call to invoke(), send(), or send_multiple_requests." There is no way for portable application to reuse a Request Pseudo-Object
Actions taken:
August 20, 1996: Received issue
June 20, 1997: closed issue

Discussion:

Issue 90: Ambiguity in DII and DSI (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: For the DII, what value if any can be placed into the Any in the NamedValue corresponding to an OUT parameter? Must it be NULL, or is it legal to include a storage pointer? Also for DSI.

Resolution: resolved, close issue
Revised Text: Add a new para after fourth para in 4.1.1, as follows, with the word "argument" and the word "namedValue" in bold:"For out parameters, applications can set the argument member of the NamedValue structure to a value that includes either a NULL or a non-NU
Actions taken:
August 22, 1996: Received issue
June 20, 1997: closed issue

Discussion:

Issue 97: Usage of standard exceptions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Is there a difference between standard/system exception? Can an implementation raise both? Is raising a standard exception the recommended way to handle errors while setting an attribute?

Resolution: resolved, close issue
Revised Text: A new sentence was added to the end of the first paragraph in 3.1.15 and also to the unnumbered section "Exception" in 12.3.4. Find additional sentences in the corresponding archive file.
Actions taken:
September 6, 1996: Received issue
June 20, 1997: closed issue

Discussion:

Issue 116: Typecodes for recursive sequences (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: In the interface for the create_recursive_sequence_tc ORB method, is this just a matter of creating a TypeCode with these two fields, or is there a parameter missing?

Resolution: No parameter is missing. you just create a TypeCode with TCKind set to tk_sequence and content type
Revised Text: Replace the text in section 8.7.3 that says:
Actions taken:
September 13, 1996: Received issue
February 23, 1999: closed issue

Discussion:

Issue 117: Unqualified names in scopes (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: CORBA says "Once an unqualified name is used in a scope, it cannot be redefined", but my IDL compiler allows it. Is it legal?

Resolution: no change to spec., close issue
Revised Text: No change to spec. It"s not legal for a conforming IDL compiler to permit redefinition of unqualified name after it has been used in the same scope
Actions taken:
September 23, 1996: Received issue
March 25, 1997: Closed issue

Discussion:

Issue 127: _is_a with CORBA::Object as input parameter (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: What should _is_a() return when invoking it with an input parameter designating CORBA::Object?

Resolution: closed with revised text
Revised Text: Section 7.2.4, 2nd paragraph: The is_a() shall always return TRUE when invoked with an input parameter designating a CORBA:Object ...No change to the specification
Actions taken:
September 23, 1996: Received issue
March 25, 1997: Closed issue

Discussion:

Issue 128: ServerRequest::op_def() (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: What is the purpose of the ServerRequest::op_def method? It is not described in the Chap. 5 discussion of ServerRequest or in 18.4.1.

Resolution: close issue, no change
Revised Text:
Actions taken:
September 23, 1996: Received issue
February 23, 1999: closed issue

Discussion:

Issue 129: DSI and oneway operations (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: After calling a Dynamic Invocation Routine, how can the ORB know whether to send a response back to the client (i.e., whether the operation was "oneway")?

Resolution: The ORB uses protocol information (i.e. from GIOP response_expected) to make this decision.
Revised Text: Close no change in 2.3a with explanation as above.
Actions taken:
September 23, 1996: Received issue
February 22, 1999: closed issue

Discussion:

Issue 130: Unions with enum as discriminator type (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: How is it possible in IDL to specify a union with an enum discriminator type?

Resolution: no change necessary, close issue
Revised Text: No change to spec. All conforming IDL compilers shall permit use of enum types as discriminators for union types
Actions taken:
September 23, 1996: Received issue
March 25, 1997: Closed issue

Discussion:

Issue 132: Scope of standard exceptions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Page 3-35 doesn"t really say that the list of standard exceptions belong to the CORBA module, although 3.12 seems to clarify.

Resolution: resolved, close issue
Revised Text: Section 3.12 requires that conforming IDL compilers behave as if the standard system exceptions were defined in module CORBA. ?? issue for CORE RTF: Should IDL text in 3.15.1 be bracketed by "module CORBA {"and"}"?
Actions taken:
September 23, 1996: Received issue
March 25, 1997: Closed issue

Discussion:

Issue 133: Repository IDs (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: I would expect a lookup on IDL:/CORBA/Object:1.0 to return an InterfaceDef. It would seem more logical if Object was represented by a "default" InterfaceDef in the repository.

Resolution: resolved, close issue
Revised Text:
Actions taken:
September 23, 1996: Received issue
February 26, 1998: closed issue

Discussion:

Issue 137: Do simple/anonymous types have repository IDs? (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity:
Summary:

Summary: Do simple types like "long" have specified repository IDs? ("IDL:CORBA/long:1.0") How about anonymous types, like "sequence <long, 10>"?

Resolution: clarified, close issue
Revised Text: Clarification
Actions taken:
September 26, 1996: Received issue
January 6, 1997: closed issue

Discussion:

Issue 156: Apparent error in CORBA 2.0 Interoperability (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: in 13.5.6 "The DCE ESIOP", "Location Policy Component" there is for module IOP a list of 4 "const octet statements.. The BNF appears to suggest that this is invalid.

Resolution: issue closed, no change
Revised Text:
Actions taken:
October 8, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 233: Pseudo-IDL identifiers differ by case only (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity: LOW
Summary:

Summary: IDL identifiers in chapter 4 differ by case only [Ch 17 CORBA2.0] Some of the identifiers used in the IDL in Ch 4 differ only by case, which is not legal in IDL.

Resolution:
Revised Text: Reassign issue to orb_revision, because it affects the DII chapter. The defect is still present in the 2.3 draft. For example, on page 7-5, we have: void create_request( // ... out Request request, // newly created request // ... ); This is only pseudo-IDL, but we might as well fix it.
Actions taken:
October 14, 1996: received issue
June 13, 2000: moved to orb_revision
October 30, 2000: closed issue

Discussion:

Issue 283: Similar structure to IR::Identifier (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: There is no such type as IR::Identifier? It should really say CORBA::Identifier. Are ServiceTypeNames limited to characters allowed in IDL Identifier and also case sensitive?

Resolution: resolved in 2.2
Revised Text:
Actions taken:
October 19, 1996: received issue
February 23, 1999: moved to orb_revision
February 26, 1999: closed issue

Discussion:

 closed issue

Issue 300: Recursive sequence TypeCodes (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Are they a new TypeCode kind (tk_kind) or are they of the tk_sequence TypeCode kind/

Resolution: subsumed by issue 116, close issue.
Revised Text:
Actions taken:
October 29, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 306: Portability and the #include directive (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: #include has same definition that C and C++ programmers are used to.HP treats #include at global scope as merely introducing declarations. This idea needs closer examination

Resolution: close no change in 2.4
Revised Text:
Actions taken:
November 23, 1996: received issue
August 12, 1999: close dissue

Discussion:

Issue 380: Interface for managing interceptors is missing (orb_revision)

Click here for this issue's archive.
Nature: Bug
Severity: Critical
Summary:

Summary: List of interceptors to be called during request and order in which interceptor will be called: Needs to be resolved by Alec Thomas but shouls also be moved to ORB RFT

Resolution: close no change
Revised Text:
Actions taken:
November 18, 1996: received issue
April 17, 1998: moved from secrev to orb_revision
August 12, 1999: closed issue

Discussion:

This is now subject of an RFP that has been issued, and is beyond the scope of an RTF

Issue 384: CORBA2.0, 1.2.2 Paragraph 2 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para points to C Language Binding chapter and the DII for info on dynamic invocation of objects. It implies that DII is only available in C. Text should pobably be more clear

Resolution: resolved, close issue
Revised Text: Change the parenthesis in the second paragraph of 1.2.2 (top of page 1-3)to read:"(Refer to the Dynamic Invocation Interface chapter for descriptions of these request forms)."
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 385: 1.2.2 Requests Paragraph last - editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Change "Descriptions of the values and exceptions...." to "For descriptions of the values and exceptions..."

Resolution: resolved, close issue
Revised Text: Changed
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 386: 2.1 Structure of an Object Request Broker (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Paragraph 1, editorial:  Change "....up the "request." to "....up the request."

Resolution: resolved, close issue
Revised Text: Changed
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 387: 2.5 Structure of an Object Adapter (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Paragraph 2, editorial:  Change " registration of implementations" to "Registration of implementations"

Resolution: resolved, close issue
Revised Text: Changed
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 388: 3.9 Exception Declaration (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para 2, editorial: Change "...(as specified by the <member> in its declaration." to "...(as specified by the <member> in its declaration)."

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 389: 3.10.3 Raises Expressions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para last, comment: We understand why standard exceptions may not be listed on a raises expression, but it would make IDL definition of interface more complete if permitted.

Resolution: resolved, close issue
Revised Text: No change to spec. Conforming IDL source files shall not include system exceptions in raises expressions. Conforming IDL compilers may accept non-conforming IDL source files.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 390: 3.10.3 Raises Expressions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: It would make iDL definition of an interface much more complete if they were permitted. X/Open would like OMG to consider permitting listing of Standard Exceptions in raises clauses.

Resolution: Duplicate of issue # 389...closed
Revised Text:
Actions taken:
November 26, 1996: received issue
December 6, 1996: closed issue, duplicate of issue 389

Discussion:

Issue 391: 3.15.2 Object Non-Existence, Para 1, editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Change "This standard system exception" to "The OBJECT_NOT_EXIST exception", to make explicit which exception is being discussed

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 392: 4.1 Overview, Paragraph 3, editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Dynamic Invocation Interface is a proper name, and should be capitalized and italicized

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 393: 4.1.1 Common Data Structures, Paragraph 6, comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The usage of len could easily lead to a situation where it was inconsistent with TypeCode through erronous usage. WOuld be great if standard System exception was available for this case.

Resolution: Close no change in 2.3a
Revised Text:
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 394: 4.1.2 Memory usage, Para 1, editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: There is an extra space between the table reference "Table 21" and the period

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 395: 4.1.3 Return Status and Exceptions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: X/Open recommends that the specification is being modified to require DII functions to return a Status as an unsigned long. Implementations without return value return value:non-conforming

Resolution: closed issue, resolved
Revised Text:
Actions taken:
November 26, 1996: received issue
March 1, 1999: closed issue

Discussion:

Issue 396: 4.2.1 create_request Paragraph 8 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: This paragraph should be deleted, since it is not useful for an application programmer.

Resolution: issue closed, no change
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 397: 4.2.2 add_arg Paragraph 5-comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: X/Open believes there is no need to use different wording. They don"t believe that it is useful to indicate that mixing of methods might be allowed someday

Resolution: In Section 5.2.2 Para 5 Rev 2.2 remove the word "currently" from the last sentence
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 398: 4.2.3 invoke (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Paragraph 1 - editorial : The leading "c" in create_request is not boldface

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 399: 4.6 Context Object Operations, Para 2 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Spec reads " Property names are stored preserving their case, however names cannot differ simply by their case." This sentence should be deleted.

Resolution: Propose to apply resolution as above and close issue in 2.3
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 400: 4.3.1 sen3 - comment 23 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: X/Open recommends that this para is being reworded to require that applications call get_response after a send. Spec could also be modified to detect errors if response is not required

Resolution: close issue, no change
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 401: 4.3.3 get_response (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para 0 - editorial: Add a line containing ");" to the PIDL for get_response, to match the PIDL given in section 4.2.

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 402: 4.6.2 set_on_value Paragraph 2 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Text reads:"Currently, only string values are supported by the context object." Sentence should be deleted, since PIDL requires that a string be the value provided

Resolution: Propose apply resolution to rev 2.3 and close issue
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 403: 4.6.3 set_values (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: See comment on set_value in issue # 402

Resolution: Propose apply resolution to rev 2.3 and close issue
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 404: 4.6.4 get_values Paragraph 2 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The error to be returned must be specified.. Since a status is not required to be returned, it"s incorrect to say that error is returned.  Exception is raised.

Resolution: add text to sections 5.6.4, 5.6.5 and 5.6.7 stating what exceptions are raised under what condition
Revised Text: Section 5,6,4 get_values
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 405: 4.6.4 get_values Paragraph 4 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Text indicates that "Value scope names are implementation-specific." Items not necessary for portable development of applications are unspecified,undefined.

Resolution: Remove paragraph 4. Does not add any value to the spec.
Revised Text: Incorporate change proposed above and close
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 406: 4.6.4 get_values Paragraph 5 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Text reads " If the specified scope name is not found, an exception is returned." Error to be indicated must be specified. See objection for Paragraph 2.

Resolution: See resolution of 404
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 407: 4.6.5 delete_values Paragraph 1 - editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Change "value(s) values" to "value(s)

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 408: 4.6.5 delete_values Paragraph 3 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: This paragraph indicates that an exception is returned. See objection for 4.6.4 get_values Paragraph 2

Resolution: see resolution of 404
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 409: 4.6.7 delete Paragraph 4 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The exception to be returned is not specified. See objection for 4.6.4 get_values Paragraph 2.

Resolution: see resolution of 404
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 410: 5.2 Explicit Request State: ServerRequest Pseudo Object (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para 4: editorial   Change "..OMG IDL for operation.." to "..OMG IDL for the operation...:.

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 411: 5.3.2 Registering Dynamic Implementation Routines Para 1- comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Paragraph starts off by explaining that previous versions of CORBA weren"t complete. Not necessary to belabor this point. It"s not clear whether or not this lack has been repaired.

Resolution: This is fixed by the new DSI text from the Portability FP
Revised Text:
Actions taken:
November 26, 1996: received issue
June 20, 1997: closed issue

Discussion:

Issue 417: 6.3.1 Managing Interface Repositories (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Paragraph 1 - editorial: Change the reference to "get_interface" to the appropriate type-face

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 418: 6.4.3 Interface Objects Paragrapg 1 - editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Numbered bullet list following this para is formatted poorly. Text items  should be alligned and offset from the numbers in a consistent way

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 419: 6.4.3 Interface Objects Paragraph 2 - editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Change "...not by modify..." to "...not by modifying..."

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 420: 6.4.3 Interface Objects Paragraph 3 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Final Para describes the types of support interfaces that might be available in some implementations. These are not interesting for portable application develpoment.

Resolution: no change necessary, issue closed
Revised Text:
Actions taken:
November 26, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 421: 6.5.2 IRObject Paragraph 3 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Write Interface description indicates that it is error to invoke destroy on a Repository or PrimitiveDef. Should state that behavior is undefined.

Resolution: close issue, resolved
Revised Text:
Actions taken:
November 26, 1996: received issue
February 26, 1998: closed issue

Discussion:

Issue 422: 6.5.3 Contained Paragraph 2 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para indicates that IRs are not required to support simultaneous containment of multiple versions of the same named object. Required that IRs are able to handle multiple versions of objects

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 26, 1996: received issue
February 26, 1998: closed issue

Discussion:

Issue 423: 6.5.3 Contained - Paragraph 7 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: This initial Para of the Write Interface section indicates that an error is returned if an object with specified ID attribute already exists. Error should be specified.

Resolution: Close with annotation as above.
Revised Text:
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 424: 6.5.3 Contained Paragraph 10 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para indicates that name attribute is changed to new_name, and version attribute is changed to new_version. If name already exists and IR doesn"t support versioning=error. What error?

Resolution: Subsumed by 778 . Closed with that annotation
Revised Text:
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 425: 6.5.4 Container Paragraph 2 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: It"s not clear what lookup operation returns when it is successful. We can tell from the IDL, but it should be explicitly defined. We think it returns object reference to scoped name.

Resolution: no change required, close issue
Revised Text:
Actions taken:
November 26, 1996: received issue
February 26, 1998: closed issue

Discussion:

Issue 426: 6.5.4 Container Paragraph 5 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para descibes exclude_inherited argumentto the content operation. Format is poor, it"s not clear what the default setting for this argument might be (if any).

Resolution: no change required, close issue
Revised Text:
Actions taken:
November 26, 1996: received issue
February 26, 1998: closed issue

Discussion:

Issue 427: 6.5.4 Container Paragraph 6 - editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para starts the description of the arguments for the lookup_name operation. It should stand out more instead of being intended in such a way that it looks like part of previous item"s description.

Resolution: changed, close issue
Revised Text: Changed. make layout conform to other sections, and fix confusing indentation
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue
February 26, 1998: closed issue

Discussion:

 closed issue

Issue 428: 6.5.4 Container Paragraph 8 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: What other values of levels_to_search are legal? What happens if values other than those described are used?Is an exception raised? If so, what exception?

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 26, 1996: received issue
February 26, 1998: closed issue

Discussion:

Issue 429: 6.5.4 Container Paragraph 10 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: This para and para 4 both describe a limiy_type argument. These should be described in the same way since they appear to have the same semantics

Resolution: Incorporate resolution and close issue.
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 430: 6.5.4 Container Paragraph 11 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Same as issue # 429 with respect to 6.5.4 Container Paragraph 5.

Resolution: Incorporate resolution and close issue.
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 431: 6.5.4 Container Paragraph 12 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para refers to the describe operation. This operation is part of the parent interface from which container interface is inherited.There should be a pointer to the parent interface

Resolution: Close no change
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 432: 6.5.4 Container Paragraph 15 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para describes create_<type> operations. It indicates that there are errors returned under differing circumstances. Possible errors should be defined.

Resolution: Superceded by 778
Revised Text: Close with annotation that it is now being handled as part of 778.
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 433: 6.5.4 Container Last Paragraph - editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The trailing period is missing.

Resolution: changed, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 434: 6.5.6. Repository Paragraph 2 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para indicates that there may be more than 1 interface Repository in any given environment. How can portable application determine this, and how can it determine what the requirements are?

Resolution: the application should use either the naming or trading service to determine which IR to use.
Revised Text:
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed, no change to 2.3a

Discussion:

Issue 435: 6.5.6 Repository Paragraph 4 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: This Para refers to a PrimitiveDef. There should be a pointer to where this is defined.

Resolution: In section 8.5.6 second para under Read Interface, add a cross reference to section 8.5.13 where Pr
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 436: 6.5.6 Repository Paragraph 4 - editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The mention of the kind attribute should be bold-face

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 437: 6.5.8 ConstantDef Interface Paragraph 2 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: There should be a pointer to the list of simple types.

Resolution: Replace the phrase "simple type( ..... )" by the phrase "primitive types allowed in a constant decl
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 438: 6.5.10 StructDef Last paragraph - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para indicates that the type member is ignored and that it should be set to TC_void. If it is ignored, why should it be set to anything?

Resolution: Remove the phrase "is ignored" from the last sentence of section 8.5.9 rev 2.2
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 439: 6.5.11 UnionDef Last Paragraph - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: This Para indicates that the type member is ignored and that it should be set to TC_void. If it is ignored, why should it be set to anything?

Resolution: Incorporate resolution and close issue
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 440: 6.5.20 AttributeDef Paragraph 2 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: What does the describe operation return for this interface?

Resolution: Add the sentence "The describe operation for an AttributeDef object returns an AttributeDescription
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 441: 6.5.22 InterfaceDef Paragraph 6 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: This Para indicates that the base_interface attribute can return an error if there are name conflicts. What error is returned?

Resolution: Subsumed by 778
Revised Text:
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 442: 6.5.22 InterfaceDef Paragraphs 7 and 8 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: These paras indicate that an error is returned if the ID already exists in the repository. What is the error and what happens of the IR supports versioning?

Resolution: Superceded by 778
Revised Text:
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 443: 6.6.1 OMG IDL Format Paragraph 5 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The semantics of minor version number changes should be a requirement on conforming applications (objects).

Resolution: That"s what the sections appears to say. close issue, no change
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 444: 6.6.4 Pragma Directives for RepositoryId Para 1 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Conforming compilers should ignore pragmas that are not defined. in this spec, and that they do not explicitly support. Portable applications should only use pragmas defined in this spec.

Resolution: The proposal in the summary is unreasonably restrictive, and would disallow use of other pragmas i
Revised Text: Append the following sentences to Para 1 of section 8.6.4
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 445: 6.7 TypeCodes Paragraph 3 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: It"s better to say "However, TypeCode "literals" shall have a representation such that they can be placed in C include files."

Resolution: Offending sentence removed in the resolution of issue 73. This is the same as issue 73
Revised Text:
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 446: 6.7.1 The TypeCode Interface All Paragraphs - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: PIDL for this interface describes the exceptions that might be raised, but the text doesn"t define the conditions when all of those exceptions might occur. This must be addressed.

Resolution: Fixed in 2.2 close no change.
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 447: 6.7.1 The Type Code Interface Paragraph 4 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Last sentence: It"s not clear under which conditions this is permitted. It"s permitted when a structure,union,enumeration or alias typecode wasn"t obtained from Interface Repository.

Resolution: Fixed in 2.2 close no change
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 448: 6.7.2 TypeCode Constants Last Paragraph - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para indicates that form of TypeCode constants might be implementation specific.Does that mean the contents of the TypeCode implementation as opposed to signature of programmer?

Resolution: Offending language has been removed in Revision 2.3
Revised Text: Close no change in 2.3a
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 449: 7.1 Converting Object References to Strings Para 3 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: it"s not clear from this whether the string generated by object_to_string is portable accross ORBs or among clients. Please add text clarifying portability of generated string.

Resolution: resolved, close issue
Revised Text: For all conforming ORBs, if obj is a valid reference to an object then string_to_object(object_to_string(obj)) will return a valid reference to same object if two operations are performed on same ORB. For all conforming ORBs supporting IOP this remains t
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 450: 7.2.1 Determining the Object Implementation and Interface (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para 1-comment: These interfaces are very important parts of ORB interface. Their semantics are very unclear. What exceptions are they permitted to raise? Expand on this definition.

Resolution: resolved, close issue
Revised Text: add a new paragraph at the beginning of 7.2.1, as follows:"Note: The get_implementation() operation is deprecated in this version of the specification, and will be removed in a future version of the specification."
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 451: 7.2.4 Equivalence Checking Operation Paragraph 3 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Concept of "type safe narrow" isn"t really described. What"s it"s importance, announcement mechanism, and whether it can be portably relied on by programmers. Where"s more info in spec??

Resolution: resolved, close issue
Revised Text: section 7.2.4, 3rd para: No change to this paragraph - it is non-normative. Replace "string" with "RepositoryID" in PIDL above
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 452: 7.2.5 Probing for Object Non-Existence Paragraph 2 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para describes implementation strategies that ORB implementors might use to ensure ORBS remain synchronized about presence of objects.Info really appropriate for this spec?

Resolution: no change required, close issue
Revised Text: No change. This text is clearly non-normative.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 453: 7.4 ORB Initialization Last Paragraph - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: X/Open would like to see either the provision for a system default ORB or an interface that application could use to get list of available ORBs from which to choose.

Resolution: No change to the specification. The existing spec supports a default ORB
Revised Text: No change to the specification. The existing spec supports a default ORB
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 454: 7.4 ORB Initialization Last Paragraph - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Unacceptable to say that "calling the ORB_init function multiple times for the same ORB may be required where an ORB is implemented as a shared library."

Resolution: defer to portability
Revised Text: Intend od 2nd sentence is that some applications because of their thread structures, may have to call ORB_init() more than once in order to ensure that it is called at least once. This is a non-normative explanation of 1st sentence. Defer to Portability
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 455: 8.1 Role of the Basic Object Adapter Para 1 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Last sentence: Seems like an odd thing to say. All X/Open specs only guarantee that they are correct if system is configured correctly. Not a big deal

Resolution: resolved, close issue
Revised Text: The BOA will be replaced in a future version of the specification
Actions taken:
November 26, 1996: received issue
June 20, 1997: closed issue

Discussion:

Issue 457: CORBA::Bounds and CORBA::TypeCode::Bounds (orb_revision)

Click here for this issue's archive.
Nature: Bug
Severity: Critical
Summary:

Summary: Does Bounds have data members or not? At what scope should Bounds be defined? Given that Bounds exception is also used by Request interface, I suspect what is meant is CORBA::Bounds

Resolution: no change to spec., close issue
Revised Text: No change to the specification. There are 2 definitions of Bounds: CORBA::Bounds and CORBA::typeCode::Bounds. Neither has data members
Actions taken:
November 13, 1996: received issue
December 11, 1996: closed issue

Discussion:

Issue 458: IDL grammar (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: There is an inconsistency between the IDL grammar as defined in chapter 3 of CORBA2.0 spec and an IDL example from same chapter(Example p. 3-16..rule 71 and rule 36 specify different

Resolution: resolved, close issue
Revised Text: Find the resolution in the corresponding archives file
Actions taken:
December 5, 1996: received issue
June 20, 1997: closed issue

Discussion:

Issue 459: CORE spec reference (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: CORE contains specific language binding information which should be in a language binding chapter or in a new appendix

Resolution: Such information now exists only in the way of examples of what a particular piece of pseudo-IDL me
Revised Text: Close no change in 2.3a
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 464: DII operations "get_response and get_next_response (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Both operations permit the flag CORBA::RESP_NO_WAIT to be set. How is is invoker being informed that there is no response available? Incorrect to use exception.

Resolution: resolved, closed issue
Revised Text: The CORBA 2.2 revision changed the mapping for some DII operations and invalidated the C mapping for deferred synchronous DII. It may have done the same for other languages that followed the C mapping rather than the C++ mapping. This is both a language mapping issue and a Core issue because of the well-known mess in the PIDL for Request. Since the text for the C mapping is in the DII chapter (that is, Core), until that mess is cleaned up, it appears that orb_revision is the place to deal with the faulty C mapping. The problem is that the original (pre-2.2) PIDL for CORBA::Request had the operation Status get_response( in Flags invoke_flags); If the RESP_NO_WAIT flag is set, return is immediate, even if the response is not complete. Since "Status" was allowed to be mapped as a "long" (in CORBA 2.1 and before), the return value could be used to determine whether the response was ready by those implementations that cared. With CORBA 2.2, "Status" was replaced by "void", making it impossible to determine whether the response completed. Exactly the same situation is true for the mapping of operation get_next_response, for which no PIDL was ever given, only very disparate language mappings. The C++ mapping didn't use the Status approach. Its mapping added (among others) operations CORBA::Request::poll_response and CORBA::ORB::poll_next_response and redefined Request::get_response. The same was true for Smalltalk. We propose a similar approach to repair the C mapping. This does nothing to move the C, C++, and Smalltalk mappings out of the chapter, as they should be, but it at least makes the C mapping valid. Adding "poll_response" to the Request pseudo-object doesn't heal the disconnect between the PIDL and the language mappings -- obviously more needs to be done to get to a cleaner spec -- but at least a valid C language mapping would be restored. Revised Text: All references are to draft CORBA 2.3 (15-Nov-98). 1. Section 7.2 Request Operations, change the get_response operation and add the poll_response operation to the IDL at the end: void get_response () raises (WrongTransaction); boolean poll_response(); 2. Before 7.3.3, insert a section and renumber the following: 7.3.x poll_response /* C */ CORBA_boolean CORBA_Request_poll_response ( CORBA_Request, CORBA_Environment *); poll_response determines whether the request has completed. A TRUE return indicates that it has; FALSE indicates it has not. Return is immediate, whether the response has completed or not. Values in the request are not changed. 3. Change the current 7.3.3 "get_response" to the following, except leave the last paragraph as is. //PIDL void get_response () raises (WrongTransaction); get_response returns the result of a request. | If get_response is called before the request has | completed, it blocks until the request has | completed. Upon return, the out parameters and return values defined in the Request are set appropriately and they may be treated as if the Request invoke operation had been used to perform the request. 4. In the current 7.3.4 "get_next_response" a. Change the C mapping code to the following: /* C */ CORBA_boolean CORBA_poll_next_response ( CORBA_Environment *); void CORBA_get_next_response ( CORBA_Request *req, CORBA_Environment *env ); b. After the Smalltalk mapping, add the following paragraph. poll_next_response determines whether any request has completed. A TRUE return indicates that it has; FALSE indicates it has not. Return is immediate, whether any response has completed or not. c. Remove the two paragraphs beginning with: "If the RESP_NO_WAIT flag..." "The following response flag is defined ..."
Actions taken:
December 18, 1996: received issue
March 5, 1999: moved from c-rev-wg to orb_revisiojn

Discussion:

Issue 499: Internationalization (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: New Idl types have been introduced to cover non-ISO code sets.Sec 5.4.1 indicates that where "generic strings" are required in a spec "wstring"should be used. Place holder in naming spec: Istring

Resolution: not interpretable, closed
Revised Text:
Actions taken:
February 12, 1997: received issue
February 12, 1997: issue logged
February 23, 1999: moved to orb_revision
February 26, 1999: closed issue

Discussion:

 moved to orb_revision

Issue 542: Interface Repository (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: In the Interface Repository spec, StructDef,UnionDef, and ExceptionDef should be derived from Container,since types can be defined within structs,unions,and exceptions according to IDL gram

Resolution: resolved, close issue
Revised Text: In section 6.5.10 add a sentence to the end of the first paragraph:"It can contain structs, unions, and enums." and change the IDL declaration (see corresponding archive file)
Actions taken:
April 15, 1997: received issue
June 20, 1997: closed issue

Discussion:

Issue 545: Enums and enumerators (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Sec 3.13 says enumerators don"t create a nested scope.Implication: 2 differnt enum types within same module can"t have same enumerator names. Flag following example as an error

Resolution: issue closed, no change
Revised Text:
Actions taken:
April 10, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 551: Object::is_a (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Some ORBs are sloppy about existence. One ORB used raises INV_OBJREV whenever object doesn"t exist, even when server can be reached. Behavior is compliant..tighten spec here.

Resolution: close no change in 2.4
Revised Text:
Actions taken:
April 22, 1997: received issue
February 23, 1999: moved to orb_revision

Discussion:

Issue 556: OTS 1.1 specification changes (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: OTS 1.1 spec doesn"t clearly say which module defines the TRANSACTION_REQUIRED, TRANSACTION_ROLLEDBACK, INVALID_TRANSACTION WRONG_TRANSACTION exceptions.

Resolution: resolved close issue
Revised Text: Add 3 lines to the end of 3.15.1 as follows: exception TRANSACTION_REQUIRED ex_body; exception TRANSACTION_ROLLEDBACK ex_body; exception INVALID_TRANSACTION ex_body. Add a new section 3.15.3, as follows: <find new section in corresponding archive file>
Actions taken:
April 28, 1997: received issue
June 20, 1997: closed issue

Discussion:

Issue 557: WRONG_TRANSACTION (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: OTS 1.1 spec (page 10-17 and 10-18) is not clear whether the WRONG_TRANSACTION exception is intended to be a system exception or a user exception

Resolution: issue resolved, see revised text
Revised Text: Add a new paragraph at the end of 4.1 as follows. --> Find new paragraph in corresponding archives file
Actions taken:
April 28, 1997: received issue
June 20, 1997: closed issue

Discussion:

Issue 563: Object terminal missing from IDL grammar (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Given the current IDL grammar, there is no way to parse any IDL containing the keyword "Object". It never appears in the grammar as a terminal symbol.

Resolution: resolved, closed in "97
Revised Text: Append a line to production (31) and (32) <base_type_spec>, as follows:"| <object_type>", and insert a new production between (31) and (32), as follows"(31a) <object_type> ::="Object"". also, append sentence to second para of 3.2.4 (see corresponding arc
Actions taken:
May 1, 1997: received issue
June 20, 1997: closed issue

Discussion:

Issue 564: Description of constant expression semantics is unclear (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary:

Resolution: resolved, closed issue
Revised Text: replace 3rd para of 3.7.2 with the following (find full text in the corresponding archive file)
Actions taken:
May 1, 1997: received issue
June 20, 1997: closed issue

Discussion:

Issue 565: Terminology consistency (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: What terminology should the core settle on? Interface inheritance with use of subtype/supertype? What about immediate and transitive versions of relationships?

Resolution: resolved closed issue
Revised Text: This issue is being addressed by the ORMSC in its revision of the OMA. When they complete the revision a new issue if necessary will be filed to bring the Core Chapters 1 and 2 in line with the new OMA. For now nothing should be done in this regard to the Core chapters pending the completion of the OMA revision
Actions taken:
May 20, 1997: received issue
August 12, 1999: closed issue

Discussion:

Issue 566: OMG IDL prefix pragma (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: All standard OMG IDL including the CORE and all services have implicit #pragma prefix "omg.org". Make sure this appears intext of ALL IDL that is specified, particular in CORBAServices

Resolution: closed issue
Revised Text: Fixed by IOP 1.1
Actions taken:
May 22, 1997: received issue
June 20, 1997: closed issue

Discussion:

Issue 567: Scope and use of prefix pragma in IDL-style repository IDs (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: There is confusion about effect of "prefix" pragma evident in the Interface Repository chapter. Whole notion of prefix should be explained more fully in section 6.6.1

Resolution: Clarifying language has been incorporated in section 10.6.5.2 (old section 8.6.5.2) in Rev 2.3 adeq
Revised Text: Close no change in 2.3a
Actions taken:
May 12, 1997: received issue
February 22, 1999: closed issue

Discussion:

Issue 568: inherit vs. include (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Ther is sense in which an interface "includes" operations it inherits from its base interface.Does it also "include" types, constants, and exceptions?

Resolution: close issue with annotation fixed in Rev 2.2+
Revised Text:
Actions taken:
May 21, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 569: What exactly is a request (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: One may expect it to be a reply or response.Reading chapters 1,4,5 makes clear that it is the entirety of an invocation of an operation, including request and response. Change possible soon?

Resolution: Clarify the sense in which the term Request is used in section 1.2.2
Revised Text: Replace the second sentence of the first paragraph of section 1.2.2 by: "The term Request is broadly used to refer to the entire sequence of causally related events that transpires between a client intiating it and the last event causally associated with that initiation, e.g. the client receives the final response associated with that Request from the server, or the server carries out the associated operation in case of a oneway request, or the sequence of events associated with the Request terminates in a failure of some sort. The initiation of a Request is an event."
Actions taken:
May 20, 1997: received issue
August 12, 1999: closed issue

Discussion:

Issue 570: "service"~~operation or interface? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Does a service consist of  single operation, or a collection of related operations, exceptions, types, and constants?

Resolution: Cleaning up the use of the word service throughout the document does not seem to be an achievable g
Revised Text: 1. In section 1.2.5 append the following phrase to the first sentence:
Actions taken:
May 20, 1997: received issue
February 22, 1999: closed issue

Discussion:

Issue 571: Question about IDL grammar (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Is it a mistake, in IDL grammar as given in CORBA 2.0, revised July 1996, that <octet_type> is not one of <const_type>s?

Resolution: subsumed by issue 725
Revised Text:
Actions taken:
May 6, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 588: limited-length strings (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Limited-length strings are missing from enumeration in section 1.2.4. Were they intended to go in "Basic Types" or the "Constructed types" section?

Resolution: Incorporate change in 2.3a and close issue
Revised Text: � A string type, which consists of a variable-length array of characters
Actions taken:
May 29, 1997: received issue
February 22, 1999: closed issue

Discussion:

Issue 595: Section 16.7: only C++ mapping defines string_free and string_dup (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Only the C++ mapping defines string_free and string_dup. Why are these methods not present in other language mappings? If they are generally applicable they should be added to the IDL

Resolution: They are C++ language specific helper functions, that is why they are in the C++ mapping section. T
Revised Text:
Actions taken:
July 9, 1997: recived issue
February 23, 1999: issue closed, no change

Discussion:

Issue 596: request() should be added to IDL (section 17.13.2) (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The Object C++ mapping has an _request() method that is not in the IDL. This method should be added to the IDL

Resolution: The Object::_request operation is an artifact of the C++ mapping and not generally applicable to ot
Revised Text:
Actions taken:
July 9, 1997: received issue
February 23, 1999: closed, no change

Discussion:

Issue 597: Sequence parameter specified is ignored (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Why does mapping ignore the sequence parameter specified in the IDL for the initialization service and split this single parameter into 2 separate ones in the mapping?

Resolution: That is an artificat of C/C++ historical usage and is not a core issue. In general language mapping
Revised Text: Close no change in 2.3a
Actions taken:
July 9, 1997: received issue
February 22, 1999: closed issue

Discussion:

Issue 598: sec 17.7.1: IDL for interface request doesn"t match C++ mapping (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The IDL for interface Request does not match the C++ mapping. There are a series od add_arg methods in the mapping that should be added to the IDL.

Resolution: Language mappings are allowed to have custom mappings for pseudo-interfaces.
Revised Text: Close no change in 2.3a
Actions taken:
July 9, 1997: received issue
February 22, 1999: closed issue

Discussion:

Issue 604: Section 7.2: get_implementation function (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Why does Object have a get_implementation function instead of a readonly implementation attribute? (likewise for get_interface)

Resolution: closed issue, no change
Revised Text:
Actions taken:
July 9, 1997: received issue
February 23, 1999: closed issue, no change

Discussion:

Issue 607: No defined value for OBJECT_NIL (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Section 7.2.3: reference is made to OBJECT_NIL but there is no defined value for this. A value must be explicitly defined and typed

Resolution: resolved, close issue
Revised Text:
Actions taken:
July 9, 1997: received issue
February 26, 1998: closed issue

Discussion:

Issue 609: TCKind enum should be updated (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Section 6.8: TCKind enum should be updated to include adopted IDL type extensions as follows: tk_longlong, tk_longdouble, tk_wstring, tk_wchar. Update DefinitionKind and PrimitiveKind enum

Resolution: Close, fixed in 2.2
Revised Text:
Actions taken:
July 9, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 610: create_exception() is declared outside any interface scope (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Section 6.8: The create_exception() methos is declared outside any interface scope. It seems logical to move it to Container Interface along with other create_XXX() methods

Resolution: Fixed in 2.2
Revised Text:
Actions taken:
July 9, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 611: Syntax for basic types must be updated (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Section 3.8.1: The syntax for basic types must be updated to include the adopted IDL type extensions.

Resolution: Fixed in 2.2
Revised Text:
Actions taken:
July 9, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 623: Section 7.8: editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Section 7.8: ; is missing from definition of attribute policy_type

Resolution: Close, Fixed in 2.2
Revised Text:
Actions taken:
July 9, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 624: Section 3.7.2: take new IDL type extensions into account (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The section states that the <<and>> operands must be in the range 0 to 32. Should be changed to 0 to 64 to take new IDL type extensions into account

Resolution: Close, Fixed in 2.2
Revised Text:
Actions taken:
July 9, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 641: Do identifiers and keywords clash if they differ in case? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Section 3.2.3 and 3.2.4: It"s not said explicitly that an identifier may not differ from a keyword only in case since it differs only in case from a keyword

Resolution: Fixed in 2.2+, Close
Revised Text:
Actions taken:
July 30, 1997: received issue
June 25, 1998: closed issue
February 23, 1999: closed issue

Discussion:

 closed issue

Issue 665: TypeCode equality (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: TypeCode equality is not very well-specified or portable.

Resolution: Incorporate more complete specification as shown below:
Revised Text: In section 3.8.2 following to the paragraph describing the any type:
Actions taken:
August 11, 1997: received issue
May 12, 1998: issue moved from port-rtf to orb_revision
February 23, 1999: closed issue

Discussion:

: complete the changes that were intended in the resolution of issue 665 by adding 
the missing pieces in Chapter 15 
Revised Text: 
Page 15-23, first para following heading "Encoded Idnetifiers and Names": 

Change the para to read: 

        The Repository ID parameters in tk_objref, tk_struct, tk_union, 
        tk_enum, tk_alias, tk_except, tk_native, tk_value, tk_value_box 
        and tk_abstract_interface TypeCodes are Interface Repository 
        RepositoryId values, whose format is described in the specification 
        of the Interface Repository. For GIOP 1.2 onwards, repositoryID 
        values are mandatory. For GIOP 1.0 and 1.1, RepositoryId values are 
        required for tk_objref and tk_except TypeCodes; for tk_struct, 
        tk_union, tk_enum, and tk_alias TypeCodes RepositoryIds are 
        optional and encoded as empty strings if omitted. 

Actions taken: Send this issue with the recommendation to adopt the proposed 
resolution and revised text as above to the Interop RTF, with a strong

Issue 666: Native types with respect to typecodes, DII, DSI,Interface Reposit. (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The portability spec is silent on issue of native types with respect to typecodes, DII, DSI and Interface Repository. Issue should be addressed. (see archive for details)

Resolution: Proposed resolution is to add representation of native type in the IR. Details below as proposed by
Revised Text: Here are the proposed extensions to allow native types in the IR. Our
Actions taken:
August 11, 1997: received issue
May 12, 1998: issue moved from port-rtf to orb_revision
February 23, 1999: closed issue

Discussion:

Issue 675: Section 3.3.8.16:deactivate_object() operation (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
August 13, 1997: received issue
February 25, 1999: moved to cxx_revision
March 8, 1999: moved from cxx_revision to orb_revision
October 30, 2000: resolved

Discussion:

 moved from cxx_revision to orb_revision

Issue 719: CDR encoding of TypeCode names inconsistent with equal operation (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Should the TypeCode equal operation compare the results of name() to determine TypeCode equality? Same question for member_name()

Resolution: Duplicate of issue 665
Revised Text:
Actions taken:
September 10, 1997: received issue
September 12, 1997: closed issue

Discussion:

Issue 724: Non ASCII alphabetics in IDL identifiers (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: IDL identifiers can contain non-ASCII alphabetic characters. None of the language maappings deals with this. To fix this restrict IDL identifiers to ASCII characters, digits and underscore

Resolution: Since most of the implementation languages to which IDL is mapped do not accept non-ASCII character
Revised Text: All revisions refer to base document Rev 2.2+ i.e. Rev 2.2 as modified by ptc/98-03-03
Actions taken:
September 17, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 725: Octet and enum constants (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: IDL should permit enum and octet constants.

Resolution: The following changes add enum and octet constants to IDL:
Revised Text: Page 3-11, production 13:
Actions taken:
September 17, 1997: received issue
February 23, 1999: closed issue

Discussion:

:=

Issue 726: Figure 2-2 in CORBA 2.0 and CORBA 2.1 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: In the figure all the interfaces/skeletons/adaptors/stubs have either an Up-call or a Normal-call arrow or both with the exception of the Dynamic Skeleton which has neither

Resolution: Add an Up-Call Arrow to the Dynamic skeleton box.
Revised Text:
Actions taken:
September 18, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 727: Bug in the 2.1.spec for IDL unions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: Table 3-11 on page 3-26 shows wchar as al legal switch type for unions. The grammar on page 3-26 doesn"t have wchar as a legal switchtype. The same is true for grammar on page 3-13. Is wchar legal for union discriminator? Spec will need to be fixed

Resolution:
Revised Text:
Actions taken:
October 17, 1997: received issue
May 6, 1999: moved from idltx to core RTF
October 30, 2000: closed issue

Discussion:

Issue 749: Issue with ObjectId_to_string and string_to_ObjectId (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: Section 18.4 "illegal characters": It should be clarified what corresponds to the concept of "illegal characters". On the othe hand, do we want to specify that ObjectIds generated by the POA should not include those "illegal characters?

Resolution:
Revised Text:
Actions taken:
October 6, 1997: received issue
June 8, 1999: moved from C++ to Core RTF
October 30, 2000: closed issue

Discussion:

Issue 751: Inclusion of standard exception (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary:   The proposal is to define a new standard exception, called
   EXTERNAL_ACCESS (the name is not important) that carries
   an any value.  Another alternative may be to re-define
   the exception COMM_FAILURE so that it may carry an any in
   addition to the existing minor and completed fields.

Resolution: close no change in 2.4
Revised Text:
Actions taken:
October 6, 1997: received issue
August 12, 1999: closed issue

Discussion:

Not clear that an RTF is the right place for  adding such featurelets. This should be added as part of some appropriate submission to some RFP.

Issue 753: Inheriting exceptions in IDL (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary: When writing IDL, why is it not possible to have an exception declaration inherit from another exception? It"s possible to have an interface inherit another interface, so it seems logical to derive an exception class from an already declared exception area

Resolution: close issue with no change with the above explanation.
Revised Text:
Actions taken:
October 23, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 754: Minor bug in 2.1 spec (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Summary: The grammar mentions fixed point literals for constsnts on page 3-12. The corresponding section of the grammar on page 3-19 does not include <fixed_pt_literal> as a valid constant initializer

Resolution: incorporate changes in 2.3 and close this issue and 1066.
Revised Text: 1. Change Production 80 to remove <fixed_pt_type> as a valid parameter type:
Actions taken:
October 21, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 776: CORBA 2.1 IR Structdef typo (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: "Read Interface" section of 7.5.10: The second sentence is a typo. The StructDef as a whole can "contain" structs, unions, and enums. However, the members attribute is a CORBA IDL data type not a subtype of Container, and hence cannot "contain" anything in the sense used elsewhere in the IR spec. The sentence should be deleted

Resolution: Remove the second sentence in section 8.5.10 of Rev 2.2
Revised Text:
Actions taken:
October 30, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 777: TypedefDef issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary: Is it legal for a TypedefDef to contain another TypedefDef that is NOT mentioned in it"s "members" attribute? If not, should the IR spec explicitly forbid this?

Resolution: resolved, issue closed
Revised Text: StructDef, UnionDef, ExceptionDef, InterfaceDef, and ValueDef are derived from Container, but may only legally contain certain types of Interface Repository definitions. StructDef, UnionDef, and ExceptionDef objects may only contain StructDef, UnionDef, or EnumDef definitions. InterfaceDef and ValueDef objects may only contain TypedefDef (including definitions derived from TypedefDef), ConstantDef, and ExceptionDef definitions. Revised Text: Add the following text to the second paragraph of 10.5.4.2: Certain interfaces derived from Container may restrict the types of definitions that they may contain. Any create_<type> operation that would insert a definition that is not allowed by a Container will raise the BAD_PARAM exception with minor code 4. Add to the end of 10.5.10.2: A StructDef used as a Container may only contain StructDef, UnionDef, or EnumDef definitions. Add to the end of 10.5.11.2: A UnionDef used as a Container may only contain StructDef, UnionDef, or EnumDef definitions. Add to the end of 10.5.20.2: An ExceptionDef used as a Container may only contain StructDef, UnionDef, or EnumDef definitions. Add to the end of 10.5.23.2: An InterfaceDef used as a Container may only contain TypedefDef, (including definitions derived from TypedefDef), ConstantDef, and ExceptionDef definitions. Add to the end of 10.5.24.2: An InterfaceDef used as a Container may only contain TypedefDef, (including definitions derived from TypedefDef), ConstantDef, and ExceptionDef definitions.
Actions taken:
October 30, 1997: received issue
August 12, 1999: closed issue

Discussion:

Issue 778: Proposed IFR exceptions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: Proposed IFR exceptions raised by destroy() and move(): exception DependencyExists {};   raised by create_* and move():  exception RIDAlreadyDefined {};    exception NameALreadyDefined {};

Resolution: Incorporate changes in 2.3a and close issue.
Revised Text: 1. In Chapter 3 section 3.17.2 table of minor codes add the following rows in the BAD_PARAM group:
Actions taken:
November 7, 1997: received issue
February 22, 1999: closed issue

Discussion:

Issue 779: Containers (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: On the issue of making StructDef, UnionDef, and ExceptionDef inherit from container, would it be possible to introduce the depreciation of including anything other than members in these three types?

Resolution: This issue appears to be a rehash of the essence of Issue 777 so I recommend that we close this wit
Revised Text:
Actions taken:
November 7, 1997: received issue
August 12, 1999: closed issue

Discussion:

Issue 780: RIDs (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: The definition of IDL Repository IDs the example in the IFR chapter 7.6.6 indicates that prefixes when not set are not separated. Definition says that "typically" it is the prefix and scoped name separated with "/".

Resolution: Fixed with sepcific example in section 10.6.5.2 in Rev 2.3
Revised Text: Close no change in 2.3a
Actions taken:
November 7, 1997: received issue
February 22, 1999: closed issue

Discussion:

Issue 783: IDL types are ambiguous with inheritance (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary: What is the return type of parent(), short or long? The spec does not say whether the inherited ::y::y::z takes precedence, or whether it is ::x::z. The scope resolution rules don"t mention how to resolve such an ambiguity. The spec should be updated to state that ::x::z takes precedence (IDL example in corresponding archive "issue783")

Resolution: Close noting that this has been explained in Revised Chapter 3.
Revised Text:
Actions taken:
November 25, 1997: received issue
January 5, 1998: issue moved from C++ to ORB Revision
February 23, 1999: closed issue

Discussion:

 closed issue

Issue 797: locally constrained (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary: What is the consensus for the notation to use for interfaces to objects
 that are in the orb but not outside. We use to call them psuedo objects.
 During the last talk I got the feel that there are three options:
 
 1.	//PIDL
 2.      "psuedo" keyword placed before "interface"
 3.	//locally constrained

Resolution:
Revised Text:
Actions taken:
December 9, 1997: received issue
December 23, 1997: closed issue
December 23, 1997: moved issue to orb_revision
October 30, 2000: closed issue

Discussion:

Issue 811: union typecode (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: 1. The label value corresponding to a default label should be
 designated explicitly either as an ignored field whose size equals the
 size for the discriminator type, as some value that does not coincide
 with another label value, as reserverd for future use, or as absent
 (Table 12-2 and page 12-16, "encoding the tk_union Default Case" of
 IIOP 2.1).

Resolution:
Revised Text:
Actions taken:
December 23, 1997: received issue
December 29, 1997: closed issue

Discussion:

Issue 812: union typecode (02) (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: 2. I cannot locate where the definition of typecodes for unions with
 members with multiple labels. The natural semantics with respect to
 the member accessor operations on that typecode and the CDR
 marshalling of that typecode would seem to be that the union
 declaration is treated as if the member definition in question were
 replicated once for each label.

Resolution:
Revised Text:
Actions taken:
December 23, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 884: Appendix B lists incorrect CORBA Components IDs (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary: 1. Appendix B lists the CORBA Component IDs. This listing is
    incorrect: Proposed resolution: Change Appendix B to correspond to the
    main text.

Resolution: Proposed resolution: Change Appendix B to correspond to the
Revised Text:
Actions taken:
January 7, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 903: Ambiguity in non_existent() specification (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: There is a minor ambiguity here. Consider the case where the ORB cannot
 make a reliable determination because the client-side run-time cannot
 reach the implementation repository or the server. In that case, most
 ORBs will raise a TRANSIENT or COMM_FAILURE exception. I can read the
 above words in the spec to mean that a compliant implementation of
 non_existent is allowed to hide the exception from me and return false
 instead.
 I suggest to amend the wording such that non_existent is obliged to propagate
 any exception other than OBJECT_NOT_EXIST back to the caller.

Resolution: Sugested text below , close issue
Revised Text:
Actions taken:
January 13, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 910: #pragma processing (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 7-32, the 2.1 spec says about #pragma processing:
 An IDL compiler must either interpret these annotations
 as specified, or ignore them completely.
 I don"t think this makes sense.
 If the prefix pragma isn"t honored in one ORB, but used by another ORB,
 the repository IDs will disagree for types generated from the same
 IDL definition, but with different IDL compilers. This in turn means
 that interoperability is destroyed.

Resolution: See resolution of 999 , close issue
Revised Text:
Actions taken:
January 23, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 911: Question about typecode creation (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Consider the following operation in the ORB pseudointerface:
 
         TypeCode create_union_tc (
             in RepositoryId id,
             in Identifier name,
             in TypeCode discriminator_type,
             in UnionMemberSeq members)
 
 Suppose that in some mapping this is invoked with the given arguments,
 i.e. an id, a name, a discriminator_type, and members..
 For concreteness, suppose that the id argument has the value
 "IDL:foo/bar:1.0".
 
 There are three main cases:<<Go to issue archive>>

Resolution: Add clarification to section 10.6 that consistency of RepositoryIds with the IDL source or the IR i
Revised Text:
Actions taken:
January 21, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 912: Inheritance of Exceptions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: This is a request to add an optional extension to IDL which would
 permit an exception declaration to include a specification of the
 superexception or superexceptions for a given exception, exactly the
 same way superinterfaces may be specified when defining an interface.The advantage of this extension is that it (optionally) permits
 interface designers to organize exceptions into categories, which can
 help clarify the design of the exceptions.

Resolution: close issue, resolved
Revised Text:
Actions taken:
January 22, 1998: received issue
February 23, 1999: closed issue

Discussion:

 close issue, resolved

Issue 913: defined_in member of ModuleDescription for top-level module (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: What is the value member of what is returned by
 CORBA::Contained::describe when invoked on a CORBA::ModuleDef object
 corresponding to a top-level IDL module?

Resolution: Incorporate change in 2.3 and close issue
Revised Text:
Actions taken:
January 21, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 915: Trader constraint language and international characters (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: the trader constraint language (page 16-98, 2.1 spec) defines a
 character class "<other>". This class is used in the definition of
 what characters may appear inside a string literal (on page 16-97).
 The problem is that the definition limits the legal character values
 that may appear in a string literal. Only character positions 0x1
 to 0x7f are legal, anything else is illegal.

Resolution: Replace section B.2.3 with corresponding text from the ISO Trader standard
Revised Text: Replace section B.2.3 on page 16-97 of formal/97-12-23 by the following: "B.2.3 Character Set Issues The previous BNF has been complete up to the non-terminals <Leader>, <Follow>, <Alpha>, <Digit>, and <Other>. For a particular character set, one must define the characters which make up these character classes. Each character set which the trading service is to support must define these character classes. The character classes for the ISO Latin-1 character set are: <Leader> := <Alpha> <Follow> := <Alpha> | <Digit> | _ <Alpha> is the set of alphabetic characters(letters), as defined in ISO/IEC 14750 <Digit> is the set of digits [0-9] <Other> is the set of Latin-1 characters that are not <Alpha>, <Digit>, or <Special>"
Actions taken:
January 21, 1998: received issue
August 12, 1999: closed issue

Discussion:

Issue 916: Resetting #pragma prefix? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: the spec doesn"t say how I can reset a repository ID prefix back to nothing
 after I have set it. Consider
 
 	#pragma prefix "dstc.edu.au"
 	interface foo {};
 	#pragam prefix ""		// Attempt to reset prefix
 	interface bar {};
 
 This doesn"t work with at least one ORB I have tried.

Resolution: See resolution of issue 999 , close issue
Revised Text:
Actions taken:
January 26, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 917: Incorrect definition of "object type" (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The definition of interface and object type in the Object Model
 are imprecise, if not incorrect.  [See section 1.2.5 of the Corba 2.1
 spec (Aug 1997)]

Resolution: Clarify as follows
Revised Text:
Actions taken:
January 27, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 918: CORBA::Contained::describe() underspecified (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: The describe() operation of the CORBA::Contained interface of the
 Interface Repository is under-specified in CORBA 2.1. (section 7.5.3
 on page 7-12).  The text should add that the "kind" field of the returned
 Description struct should give the DefinitionKind for the "most derived" 
 type of the object.  Without this, the spec can be read as allowing
 describe() to return a kind of dk_Typedef, or even dk_all!

Resolution: incorporate the proposed clarification
Revised Text:
Actions taken:
January 25, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 991: Operation to add to CORBA::ORB pseudo-object (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary: The following operations should be added to the CORBA::ORB
 pseudo-object:
 
 module CORBA {
         interface ORB {
 
                 ...
                 typedef sequence<octet> SerializedData;
                 typedef unsigned long   SerializedEncoding;
 
                 const SerializedEncoding CDR_ENCODING   = 0;
 
                 SerializedData  serialize(in Any data,
                                           in SerializedEncoding how);
                 Any             unserialize(in SerializedData data,
                                             in SerializedEncoding how);
                 ...
         };
 };

Resolution: Close no change in 2.4
Revised Text:
Actions taken:
March 4, 1998: received issue
August 12, 1999: closed issue

Discussion:

This issue is very unlikely to get resolved resolved through the RTF process. It was attempted once and it failed. Some of the objections were that it is inappropriate
to add such a complete featurelet through the RTF. It is probably better added through some submission to some RFP. It is therefore proposed that this issue be
closed.

Issue 992: CORBA 2.2 - "native" and the interface repository (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary: Whilst implementing the POA I noticed that there were no extensions to
 the Interface Repository or TypeCodes to handle native types.
 
 The nett result appears to be that there is no way to express some of
 the POA interfaces in the Interface Repository. Obviously the native
 interfaces themselvse can"t be expressed, but nor can some of the IDL
 specified interfaces.
 
 e.g. ServantLocator has two operations (preinvoke and postinvoke) both
 of which have a Cookie listed as a parameter. There appears to be no way
 to generate a TypeCode for the Cookie (native) paramter and therefore no
 way to perform an InterfaceDef.create_operation to desribe either of
 preinvoke or postinvoke.

Resolution:
Revised Text:
Actions taken:
March 5, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 999: #pragma prefix issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: How does the scope of #pragma prefix interact with #include? Find details in the corresponding archive

Resolution:
Revised Text: The following text changes describe the resolution. Since vote 3 the changes to 8.6 have been added
Actions taken:
March 13, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1054: Marshalling is_equivalent (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: CORBA 2.2 GIOP does not define a way to invoke is_equivalent on an object remotely

Resolution: close no change with above explanation
Revised Text:
Actions taken:
March 13, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1066: Fixed point constant typo in 2.2 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 3.7.2 of CORBA 2.2 contains an error on page 3-20, last para:
 
 	For example, 0123.450d is considered to be fixed<5.2> and
 	3000.00 is fixed<1,-3>.
 
 This is in conflict with section 3.2.5 on page 3-9, last para:
 
 	A fixed-point decimal literal consists of an integer part, a
 	decimal point, a fraction part and d or D. [ ... ]
 	Either the integer part of the fraction part (but not both)
 	may be missing; the decimal point (but not the letter d (or D))
 	may by missing.
 
 So, it seems that the "3000.00" on page 3-20 really should be
 "3000.00d" or "3000.00D".

Resolution:
Revised Text:
Actions taken:
March 18, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1067: Wide character and wide string literals (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 3.2.5 on page 3-9, 2nd para says:
 
 	Wide character and wide string literals are specified exactly
 	like character and string literals. All character and string
 	literals, both wide and non-wide, may only be specified
 	(portably) using the characters found in the ISO 8859-1 character
 	set, that is interface, names, operation names, type names, etc., will
 	continue to be limited to the ISO 8859-1 character set.
 
 - The first part says that wide character literals and wide string literals
   are to be specified exactly like character and string literals.
 
   This seems to be impossible - if they were exactly the same, there would
   be no point in having them... At any rate, the sentence seems to
   imply that I must restrict myself to ISO Latin-1 characters in
   wide literals.
 
 - The second part then says that wide literals are restricted to 8859-1,
   but that interface names (etc.) will continue to be limited to 8859-1.
 
   Now what is that supposed to mean? Interface names have always (and
   incorrectly) been limited to 8859-1. Nothing has changed. Am I to
   imply then that the sentence was meant to suggest that wide literals
   can actually contain wide characters other than 8859-1?
 
 This paragraph simply doesn"t make sense as it stands.

Resolution:
Revised Text:
Actions taken:
March 18, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1068: Fixed point constants issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Page 3-20 of CORBA 2.2:
 
 	A fixed-point literal has the apparent number of total and
 	fractional digits, except that leading an trailing zeros are
 	factored out, including non-significant zeros before the decimal
 	point. For example, 0123.450d is considered to be fixed<5,2> and
 	3000.00 is fixed<1,-3>.
 
 Apart from the fact that 3000.00 is not a fixed point constant literal,
 I"m confused about something else...
 
 If 3000.00d is fixed<1,-3>, then 3000.0000d is also fixed<1,-3>.
 
 These rules result in
 
 	3000.00d	being		fixed<1,-3>
 BUT
 	3000.01d	being		fixed<6,2>
 
 This doesn"t seem to make sense. If I bother to write the trailing zeros,
 surely I have a reason, namely, that I mean to use that scale. In other words,
 I think that
 
 	3000.00d	should be 	fixed<6,2>
 and
 	3000.0000d 	should be	fixed<8,4>
 
 Why are fractional trailing zeros thrown away but fractional trailing
 non-zeros retained?

Resolution:
Revised Text:
Actions taken:
March 18, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1071: Type of fixed point quotients (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary: the 2.2 spec on page 3-20 defines the type of a fixed point division as:
 
 	fixed<(d1-s1+s2) + Sinf, Sinf>
 
 I"m having a problem with this: The type of the result cannot be known
 at compile-time because it depends on the actual values.
 
 This differs from the add, subtract, and multiplication operators,
 where the result type can be determined statically.
 
 There is a C++ mapping problem too. The C++ mapping uses a template
 type for fixed point, where the digits and the scale are template parameters
 (i.e. must be compile-time constants).

Resolution:
Revised Text:
Actions taken:
March 19, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1074: Typo in type code section (13.3.4) (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 13-13, CORBA 2.2:
 
 	A "simple" parameter list has a fixed number of fixed length entries,
 	or a single parameter which is has its length encoded first.
 
 This should probably be
 
 	... single parameter which has is length encoded first.

Resolution:
Revised Text:
Actions taken:
March 19, 1998: received issue
June 25, 1998: closed issue

Discussion:

Issue 1086: How to deal with object identity (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: I"m not quite sure where this should go, but there should be an explicit
 statement somewhere in the CORBA descriptions that states how to deal
 with object identity with respect to subscribe/unsubscribe schemes.
 
 The (language/CORBA/etc independent) pattern
     interface SomeSender {
         void addSomeListener( in SomeListener theListener );
         void removeSomeListener( in SomeListener theListener );
         ...
     }
 is very commonly found, and as far as I understand it (I might be wrong,
 but if so, it needs to be documented that this would be incorrect),
 SomeListener actually needs to implement a "is_identical( Object )"
 operation that would be called by the removeSomeListener() operation
 in order to find out which of the registered listeners should be removed.

Resolution:
Revised Text:
Actions taken:
March 20, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1087: IDl "module" construct - IDL files (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: It appears that the IDL concept of a module is tightly bound to
 the storage of IDL statements in files. In other words, it does not
 seem to be possible to distribute IDL statements in the same logical
 module across multiple files. Consequently, few people use the
 concept, and name collisions occur sooner or later when trying to
 integrate systems that have not been developed by only one group.

Resolution:
Revised Text:
Actions taken:
March 20, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1088: ORB_init (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Page 4-9 of CORBA 2.2:
 
 	ORBid strings other than the empty string are intended to be used
 	to uniquely identify each ORB used within the same address space
 	in a multi-ORB application.
 
 I don"t believe this is possible, mainly because the language mappings
 do not permit multiple ORB run-time libraries to be linked into the same
 address space.

Resolution:
Revised Text:
Actions taken:
March 20, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1091: Editorial issue, chapter 8 (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Summary: In the recap IDL at the end of chapter 8, there is a missing comma after
 the tk_except enumerator in the definition of TCKind.

Resolution:
Revised Text:
Actions taken:
March 21, 1998: received issue
February 23, 1999: closed issue

Discussion:

 received issue

Issue 1094: Indentation on page 4-4 (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: interface Object on page 4-4  shows:
 
 	interface Object {
 		ImplementationDef get_implementation();
 		InterfaceDef get_interface();
 		boolean is_nil();
 		Object duplicate();
 		void		release();
 		boolean			is_a(...);
 		boolean			non_existent();
 		boolean 		is_equivalent(...);
 		unsigned		long hash(...);		<======
 		// ...
 	};
 
 The first four declarations use no indentation, the fifth declaration
 uses one indentation level, and the final four declarations use a different
 indentation level. This could be tidied up a bit.

Resolution:
Revised Text:
Actions taken:
March 22, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1145: Forward declarations and inheritance (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The IDL spec explains forward declarations at the end of section 3.5.2.
 However, it does *not* make the following illegal:
 
 	interface base;			// Forward declaration
 
 	interface derived: base {	// Should be illegal
 		// ...
 	};
 
 	interface base {
 		// ...
 	};
 
 The problem here is that a forward-declared interface is used as a base
 interface before the definition for that interface has been seen.
 In the absence of further words in the spec, this is legal, but clearly,
 it should be illegal (otherwise, I can"t use a single-pass compiler).

Resolution:
Revised Text:
Actions taken:
April 16, 1998: received issue
June 25, 1998: moved from port-rtf to orb_revision
February 22, 1999: closed issue

Discussion:

Issue 1146: Semantics and standard exceptions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The spec lists the standard exceptions in section 3.15.1.
 
 However, for many of these, there are no semantics specified anywhere.
 Instead, for the majority of standard exceptions, the *only* "semantics"
 are what is in the comments in section 3.15.1.
 We badly need an explanation of which standard exception indicates what
 error condition in the spec, otherwise we"ll never get agreement on which
 exception means what...

Resolution:
Revised Text:
Actions taken:
April 16, 1998: received issue
June 25, 1998: moved from port-rtf to orb_revision
February 23, 1999: closed issue

Discussion:

Issue 1153: Domain manager related specification shortcoming(s) (01) (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 1) The specification lacks any operations for moving an object reference
 from one domain manager to another, thus making the domain manager
 abstraction less useful as a means for managing allocation of policies
 to groups of object references, the memberships of which change over a
 period of time.

Resolution: This issue is included in the mandatory requirements of the Security Domain Membership Management R
Revised Text:
Actions taken:
April 17, 1998: received issue
August 19, 1999: closed issue

Discussion:

Issue 1154: Domain Manager related specification shortcoming (02)-ConstructionPolicy (orb_revision)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Summary: 2) The associated ConstructionPolicy object does not provide any
 facility for allocating an object reference to any domain manager other
 than the domain manager to which the creator (if an object) belongs or a
 completely new domain manager.

Resolution: This issue is included in the mandatory requirements of the Security Domain Membership management R
Revised Text:
Actions taken:
April 17, 1998: received issue
August 19, 1999: closed issue

Discussion:

Issue 1155: Domain Manager related specification shortcomings (03) (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 3) There is no way at present to implement the
 Object:get_domain_managers operation in an interoperable fashion. To fix
 this it seems a new GIOP message needs to be defined to carry the
 implicit get_domain_managers operation. There of course may be other
 ways to fix this. Some of the submitters of the original security spec
 saw domain managers as replicated objects such that a replica of it was
 present in each ORB instance where there was an object belonging to that
 domain manager was instantiated, thus relegating the problem of getting
 the domain manager information to the replication mechanism. Well, the
 hoped for replication facility has not happened yet and there is no
 other way to implement this interoperably. This needs to be fixed.

Resolution: get_domain_managers operation in an interoperable fashion. To fix
Revised Text:
Actions taken:
April 17, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 1156: resolve_initial_references under-specified (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: resolve_initial_references can raise an InvalidName exception. However,
 the text in section 4.5 does not attach any semantics to that exception
 (in fact, it does not mention the exception at all).
 
 The spec needs to state explicitly *when* InvalidName should be raised.
 Presumably, the intent was that it would be raised for unknown ObjectIds,
 such as "XXXX".

Resolution: Needs no further action in Core RTF. Close this issue no change.
Revised Text:
Actions taken:
April 17, 1998: received issue
June 25, 1998: moved from port-rtf to orb_revision
August 19, 1999: closed issue

Discussion:

 This has been addressed in the submission that was accepted in response to the Interoperable Name Service RFP, and hence will be fixed in Core as
soon as that adopted spec is incorporated into Core

Issue 1160: GIOP typo, section 4.2 (page 4.4) of CORBA 2.2 (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: Section 4.2 (page 4.4) of the corba 2.2 spec defines a "non_existent" operation
 on CORBA::Object. In Section 13.4.1 (page 13-23) it sates that the operation
 name for such a request is encoded as the string "_not_existent". This latter
 string  looks like a typo, and we propose to change this (on page 13.23) to
 "_non_existent".

Resolution: :Object. In Section 13.4.1 (page 13-23) it sates that the operation
Revised Text:
Actions taken:
April 20, 1998: received issue
June 25, 1998: closed issue

Discussion:

 resolved, close issue

Issue 1164: Versioning by the back door? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: I"ve always been under the impression that CORBA does not have versioning.
 it looks like we
 actually *do* have versioning. Could someone please let me know what
 the correct interpretation should be? Has this versioning stuff sort
 of quietly snuck in via the back door?
 
 I find this section of the spec particularly stunning because a few pages
 earlier, it says about #pragma directives:
 
 	An IDL compiler must eithe rinterpret these annotations
 	as specified, or ignore them completely.
 
 So, on the one hand, we can happily ignore #pragma, and a few pages
 later, we go and add semantics to the version pragma?!

Resolution:
Revised Text:
Actions taken:
April 22, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 1241: / in prefix pragma? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: currently, #pragma prefix is completely unconstrained and can contain
 any character. This includes potentially troublesome things such as space
 and "/", or non-printing characters.
 
 I would suggest to define a syntax for #pragma prefix. In particular, I think
 that "/" should be forbidden in a prefix. This is because otherwise, given
 a repository ID, I cannot work out where the prefix ends and the scoped
 name starts. In addition, things that cannot normally be part of file names
 or identifiers should probably be forbidden as well, otherwise we could
 get problems with things like the class path in Java.

Resolution:
Revised Text:
Actions taken:
April 27, 1998: received issue
June 25, 1998: moved from port-rtf to orb_revision
February 23, 1999: closed issue

Discussion:

Issue 1315: Semantics of system exception completion_status (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The CORBA 2.2 spec says the following about completion_status:
 
 Each standard exception also includes a completion_status code which
 takes one of the values {COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE}.
 These have the following meanings:
 
 COMPLETED_YES	The object implementation has completed processing prior
 to the
 		exception being raised.
 COMPLETED_NO	The object implementation was never initiated prior to the
 exception
 		being raised.
 COMPLETED_MAYBE	The status of implementation completion is
 indeterminate.
 
 These definitions do not cover the case where the standard exception was
 raised by the object implementation itself.

Resolution:
Revised Text:
Actions taken:
May 11, 1998: received issue
October 30, 2000: closed issue

Discussion:

Issue 1394: Typos in IR IDL in spec (01) (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: The following problems appear in the 2.2 spec (98-02-23) and the IDL 
 summary extracted from it (98-03-01.idl).
 
 - Section 8.8 page 8-45: need forward declaration of ExceptionDef, i.e., 
 "interface ExceptionDef" before use on page 8-47. There are a number of 
 forward declarations in the middle of 8-45 that would seem to be the 
 logical place for it.

Resolution:
Revised Text:
Actions taken:
May 20, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1395: Typos in IR IDL in Specification (02) (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: - Section 8.8 page 8-47: need forward declarations of WstringDef and 
 FixedDef before use on page 8-48. Again, it would seem that they were 
 left out of the list of forward declarations on 8-47.

Resolution:
Revised Text:
Actions taken:
May 20, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1396: Typos in IR IDL in Specification (03) (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: - Section 8.8 page 8-48: remove incorrect "};" between "create_array" and 
 "create_fixed".

Resolution:
Revised Text:
Actions taken:
May 20, 1998: received issue
February 23, 1999: closed issue

Discussion:

 received issue

Issue 1397: Typos in IR IDL in Specification (04) (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: - Section 8.8 page 8-53: add "," after "tk_except" in definition of TCKind.

Resolution:
Revised Text: Fix and close
Actions taken:
May 20, 1998: received issue
February 23, 1999: closed issue

Discussion:

 closed issue

Issue 1398: Typos in IR IDL in Specification (050 (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: - Section 8.8 page 8-55: change "element type" to "element_type" in 
 operation create_sequence_tc.

Resolution:
Revised Text:
Actions taken:
May 20, 1998: received issue
February 23, 1999: closed issue

Discussion:

 received issue

Issue 1422: Does the DII support the standard object operations? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: There are two types of standard operations:  ones that are transmitted
 over the wire, and ones that are not.  Now it seems reasonable to
 support the over-the-wire operations via the DII, such as "is_a",
 "non_existent", "get_interface" and "get_implementation" (obsolete), but
 what about the ones that don"t go over the wire:
 
 	hash
 	is_equivalent
 	get_policy
 	get_domain_managers
 
 I would guess that the DII should not support these operations, but the
 spec does not explicitly say that.  So, should we add a statement to the
 DII part of the spec that an attempt to invoke these non-over-the-wire
 operations should raise BAD_OPERATION?

Resolution:
Revised Text:
Actions taken:
June 2, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1537: Typo in chapter 8 (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: Table 8-1 on page 3-39 of the CORBA spec contains a typo.
 "tx_fixed" should be "tk_fixed".

Resolution:
Revised Text:
Actions taken:
June 23, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 1541: Type code typos (as only one issue) (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Summary: There are a few typos in the spec for type codes.
 
 Page 8-40:
 
 	A structure with N members results in a tk_struct TypeCode with
 	2N+1 parameters.
 
 This is no longer correct. Because of the Repository ID parameter that
 was added, this is now 2N+2.
 
 Similar fixes need to be applied to the text for unions (3N+3 parameters,
 not 3N+2), enumerations (N+2 parameters instead of N+1 as implied by
 the text), and aliases (they have three parameters, not two).
 
 The text for tk_objref also needs updating, because it states that
 it has one parameter instead of two.
 
 Also, Table 7-1 for tk_objref should be updated because it is internally
 inconsistent.

Resolution:
Revised Text:
Actions taken:
June 24, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1542: Type code operations under-specified (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: On page 8-38:
 
 	Member_count [sic] returns the number of members
 	constituting the type.
 
 This is a little ambiguous and easily confused with the number of parameters.
 For clarity, I would suggest to add a sentence to make this clearer, e.g.
 "For example, the member count of a structure with three members is three."
 
 This would help to avoid confusion with parameters (if I am not careful,
 I might think the number is six, because a the three members of a structure
 are described by six parameters, or I might think that the number is nine,
 because a three-member structure has a total of nine parameters).
 
 The origin for the index to the member_name operation is never defined.
 Presumably, indexes start at zero? If so, this must be stated.

Resolution:
Revised Text:
Actions taken:
June 24, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1543: Type code parameter ordering (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: 
 the TypeCode pseudo interface makes no mention about the order of parameters
 for structured types. For example, given the IDL struct
 
 	struct MyStruct {
 		char	c_mem;
 		string	s_mem;
 	};
 
 it is legal for member_name(0) to return "s_mem" and member_name(1) to
 return "c_mem" (provided member_type(0) returns a char type code and
 member_type(1) returns a string type code).
 
 The same comments apply to unions, exceptions, and enums, where the order
 in which members are presented is not necessarily the same order as in the IDL
 definition.

Resolution:
Revised Text:
Actions taken:
June 24, 1998: received issue

Discussion:

Issue 1545: Type codes cannot describe all unions (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: Fix this by stating that member_label returns an Any containing
 a *sequence* of labels if a single member has more than label.
 
 Add a typedef to the TypeCode pseudo-IDL:
 
 	typedef sequence<any> LabelSeq;
 
 A sequence of this type would be contained in the Any returned by
 member_label() if a member has multiple labels (this avoids changing the
 signature of member_label()).
 
 For the above union, the member_count() operation would return 2, not 5.

Resolution:
Revised Text:
Actions taken:
June 24, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1585: IDL struct issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: IDL structs are specified to have "one or more" members rather than
 "zero or more".
 
 Whilst it might be argued from a stylistic point of view that an empty
 struct is of limited use, of should be avoided, there are places where
 it may be desirable to specify a placeholder struct for later expansion,
 or for machine generated code where there happens to be nothing to fill
 the struct with.
 
 I can see no compelling technical reasons for requiring that a struct
 contain at least one member, so I propose that the grammar be revised to
 alow for a struct with zero members.
 
 Such a change would not break any existing IDL.

Resolution:
Revised Text:
Actions taken:
June 26, 1998: received issue
March 1, 1999: closed issue

Discussion:

Issue 1587: name scoping issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In the course of a discussion Philippe Gautron pointed out to me that in
 ISO-C++, the scope of a class begins with its declaration, and hence a
 member or type declaration in the class  may not introduce the same name
 as that of the class, exception being constructors of the class.
 Analogous rules apply to struct and namespace. When this principle is
 extended to the case insensitivity of IDL a consequence is that
 
 	interface I {
 		void i();
 	};
 
 is illegal as is:
 
 	module M {
 		interface m {....};
 	};
 
 The basic rule is that the name of the scope, if it has one is
 implicitly inserted into the scope and hence cannot be reused for other
 purposes in that scope. Given that IDL has to be mapped to C++ this
 seems like an eminently reasonable restriction. However, I could not
 find this explicitly stated anywhere. Do y"all feel this is reasonable?
 If so, and if it is indeed not mentioned then I think we should add a
 line or two in 3.13 clarifying this?

Resolution:
Revised Text:
Actions taken:
June 26, 1998: received issue
March 1, 1999: closed issue

Discussion:

Issue 1612: Description of Wide String type (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: Null termination is a marshalling and language mapping issue and should not
 appear as part of the semantic description of the IDL type. It should be
 completely valid for a language with a native wide string type to handle the
 varying length nature of the wide string with or without use of null
 termination and certainly without exposing it to the user. Therefore, the
 description of the wide string type in 3.8.3 should not mention null
 termination. 
 
 Also the syntax should be included.

Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1622: TypeCode comparison proposal (01) (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Points 1 through 9 need to be considered as one unit.  Point 10 can be
 voted on independently, but does provide a useful capability for
 controlling the size and content of TypeCodes.
 
 Proposal:
 
 1.  Make RepositoryIds mandatory for all TypeCodes that have them. [This
 was done by the previous core RTF.  I am just reiterating it here for
 completeness.]
 
 2.  All TypeCode constants generated by the IDL compiler, as well as all
 TypeCodes returned by the Interface Repository must include alias
 TypeCodes wherever a typedef declaration appears in the original IDL
 source.
 
 3.  Each IDL programming language mapping must provide a mechanism for
 the programmer to ensure that values of the IDL any type contain the
 exact typecode desired by the programmer.
 
 4.  The name() and member_name() fields of the TypeCode are for
 documentary purposes only, and are never considered significant when
 comparing TypeCodes.
 
 5.  Define a new equivalent operation for TypeCodes:
 
 pseudo interface TypeCode {
     ...
     boolean equivalent(in TypeCode other);
     ...
 };
 
 with the following semantics:
 
 a)  If the two TypeCodes are the same primitive type (null, void, short,
 long, ushort, ulong, float, double, boolean, char, octet, any, TypeCode,
 longlong, ulonglong, longdouble, wchar) then equivalent() returns true.
 
 b)  If the two TypeCodes are string, wstring or fixed with the same
 parameters (bounds, digits or scale) then equivalent() returns true.
 
 c)  If the two TypeCodes are both arrays or both sequences, with the
 same bounds and their component types are equivalent(), then
 equivalent() returns true.
 
 d)  If the two TypeCodes are both object references, return true if the
 their RepositoryIds are the same.
 
 e)  If the two TypeCodes are both structs, exceptions, unions, enums or
 aliases, and they have the same RepositoryId, then equivalent() returns
 true.  Note in this case that member TypeCodes are not compared.
 
 f)  If either or both of the TypeCodes have an empty RepositoryId, then
 equivalent() falls back to a structural comparison, and returns true if
 all members of the two TypeCodes also are equivalent(). This case will
 only occur when interoperating with an older ORB that does not yet
 require RepositoryIds as mandatory for these TypeCodes.   Note that the
 name() and member_name() fields are not used in this comparison.
 
 g)  Otherwise, equivalent() returns false.
 
 6.  The ORB uses TypeCode::equivalent for all internal TypeCode
 comparisons, such as for supporting any (and thus DII and DSI) and
 DynAny.
 
 7.  If the programmer needs to distinguish between a type and/or
 different aliases of that type, he can call TypeCode::id() and compare
 the RepositoryIds.
 
 8.  All DynAny insert & get operations do not consider aliases as
 significant.  The type() operation however, will return the TypeCode
 with all of the aliases intact, including type() from any DynAny member
 components.  DynAny::assign() and DynAny::from_any compare the internal
 TypeCode of the DynAny with the TypeCode of its argument using
 TypeCode::equivalent() and raise Invalid if equivalent() returns false.
 
 9.  The TypeCode::equal() operation is not used internally by the ORB
 and is deprecated.

Resolution:
Revised Text:
Actions taken:
July 1, 1998: received issue
July 1, 1998: closed issue

Discussion:

Issue 1623: TypeCode comparison proposal (02) (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 10.  Define two new operations on TypeCodes:
 
 pseudo interface TypeCode {
     ...
     TypeCode    get_compact_typecode();
     TypeCode    get_canonical_typecode();
     ...
 };
 
 TypeCode::get_compact_typecode() strips out all optional name & member
 name fields.  TypeCode::get_canonical_typecode() looks up the TypeCode
 in the Interface Repository and returns the fully fleshed-out TypeCode.
 If the top level TypeCode does not contain a RepositoryId, (such as
 array and sequence TypeCodes, or TypeCodes from older ORBs), then a new
 TypeCode is constructed by calling TypeCode::get_canonical_typecode() on
 each member TypeCode of the original TypeCode.  If the Interface
 Repository is unavailable, or does not contain the information needed,
 the call raises the INTF_REPOS system exception.

Resolution:
Revised Text:
Actions taken:
July 1, 1998: received issue
July 1, 1998: closed issue

Discussion:

Issue 1665: Lifetime of ORB and validity of ORB pointe (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: In CORBA 2.2 added the ORB::shutdown operation. What operations are
 valid during the potentially lengthy shutdown process while ongoing
 operations complete? What is the validity of the ORB reference after the
 shutdown? Is the ORB destroyed? Can a new ORB be reconstituted by
 ORB_init?
 
 This issue came up during the port-rtf discussion for CORBA 2.3. It goes
 beyond considerations for the POA so it should be addressed by
 orb_revision.
 r

Resolution: Fix the problem as described below
Revised Text: 1. Change the following text to ORB::perform_work() (Section 4.11.2) after the polling loop example: Once the ORB has shutdown, work_pending() and perform_work() will raise the BAD_INV_ORDER exception. An application can detect this exception to determine when to terminate a polling loop. 2. Change the text for ORB::run() (Section 4.11.3) to: This operation provides execution resources to the ORB so that it can perform its internal functions. Single threaded ORB implementations, and some multithreaded ORB implementations, need the use of the main thread in order to function properly. For maximum portability, an application should call either run() or perform_work() on its main thread. run() may be called by multiple threads simultaneously. This operation will block until the ORB has completed the shutdown process, initiated when some thread calls shutdown(). 2. Change the text for ORB::shutdown() (Section 4.11.4) to: This operation instructs the ORB to shut down, that is, to stop processing in preparation for destruction. Shutting down the ORB causes all object adapters to be destroyed, since they cannot exist in the absence of an ORB. Shut down is complete when all ORB processing (including request processing and object deactivation or other operations associated with object adapters) has completed and the object adapters have been destroyed. In the case of the POA, this means that all object etherializations have finished and root POA has been destroyed (implying that all descendent POAs have also been destroyed). If the wait_for_completion parameter is TRUE, this operation blocks until the shut down is complete. If an application calls shutdown(TRUE) in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock. If the wait_for_completion parameter is FALSE, the shutdown may not have completed upon return. An ORB implementation may require the application to call run() or perform_work() after the shutdown(FALSE) has been called in order to complete the shutdown process. While the orb is in the process of shutting down, the ORB operates as normal, servicing incoming and outgoing requests until all requests have been completed. An implementation may impose a time limit for requests to complete while a shutdown is pending. Once an ORB has shutdown, invoking any operation on that ORB or any object reference obtained from that ORB will raise the BAD_INV_ORDER system exception with the OMG minor code 4, except for the reference management operations: duplicate(), release(), and is_nil(). 3. Add a new section (4.11.5) for the new ORB::destroy() operation: void destroy(); This operation destroys the ORB so that its resources can be reclaimed by the application. Any operation invoked on a destroyed ORB reference will raise the OBJECT_NOT_EXIST exception. Once an ORB has been destroyed, another call to ORB_init with the same ORBid will return a reference to a newly constructed ORB. If destroy() is called on an ORB that has not been shutdown, it will start the shutdown process and block until the ORB has shutdown before it destroys the ORB. If an application calls destroy() in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock. For maximum portability and to avoid resource leaks, an application should always call shutdown() and destroy() on all ORB instances before exiting. 4. Add the following entries to the minor exception code table in section 3.17.2: SYSTEM EXCEPTION MINOR CODE EXPLAINATION BAD_INV_ORDER 3 Operation would deadlock. 4 ORB has shutdown.
Actions taken:
July 10, 1998: received issue
August 19, 1999: closed issue

Discussion:

Issue 1667: Proposal on floating point fixes (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: I"m preparing a proposal to "fix" fixed point types, but I"d like to
 outline what I am thinking before I have it completed, in order to give
 people a chance to comment.
 Michi has pointed out a few issues with the fixed point constant
 grammar, but I think I can resolve those pretty easily by making changes
 so that fixed point constants are only allowed to be defined using the
 syntax:
 
 const fixed FOO = 1.2D;
 
 Some people have expressed the idea that the fixed point type
 specification is lacking sufficient semantic content, and they are
 afraid that since different languages or even implementations of
 languages might do the math differently that portability or
 interoperability is affected.  Frankly, I don"t see the problem as
 serious for the CORE RTF.  In most cases, the fixed point type is mapped
 to the native fixed point facility of the language.  If that isn"t
 sufficiently robust to support stuff like banking applications, the CORE
 RTF can"t do much to fix it anyway.
 
 For the C++ RTF:
 
 For the C++ binding, of course, things are broken.  However, I think I
 may have a solution to the problem:
 
 First, define a new class CORBA::FixedValue which is used as the results
 of all of the Fixed arithmetic operations, as well as for the type for
 fixed point constants.  FixedValue would store the digits and scale
 information dynamically.  All of the defined fixed point types would be
 convertable from/to the FixedValue type, with the DATA_CONVERSION
 exception available to signal overflow.
 
 Second, get rid of the explicit reference to a template type.  Since the
 grammar will be changed to no longer allow anonymous fixed point
 declarations (as parameter types), there is no longer a specific need to
 define the exact type name for the Fixed types, and in fact,
 implementations no longer must implement fixed as a template type.

Resolution:
Revised Text:
Actions taken:
July 13, 1998: received issue
July 15, 1998: closed issue -- resolved by issue754

Discussion:

Issue 1679: DynStruct::get_members needs exception (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: If get_members is called on a DynStruct whose members have not been
 initialized, what should it do? It can"t return any values, because there
 are none.
 
 I suggest allowing it to raise DynAny::Invalid in this case. If there are
 objections to adding a raises clause, I suggest having it raise BAD_INV_ORDER.

Resolution: incorproate changes and close issue in 2.4
Revised Text:
Actions taken:
July 14, 1998: received issue
August 19, 1999: closed issue

Discussion:

Added TypeMismatch exceptions to deal with empty exceptions. 
Added types for DynAny. Added exceptions to deal with situations where there cannot be a member or 
where the current position does not indicate a member. 
Revised Text: see ptc/99-03-02

Issue 1688: Illegal IDL in CosTime module (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The IDL in module CosTime for the compare_time and
 time_to_interval operations is illegal.  Reference
 http://www.omg.org/archives/experts/msg00890.html
 for further information.

Resolution:
Revised Text: //www.omg.org/archives/experts/msg00890.html
Actions taken:
July 16, 1998: revceived issue
February 23, 1999: closed issue

Discussion:

  All references to formal/97-12-21.pdf

Issue 1725: CosObjectIdentity::ObjectIdentifiers can"t be UUIDs? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Does anyone know why the CosObjectIdentity::ObjectIdentifier was changed
 from "typedef sequence<octet,16>" to "typedef unsigned long"? This
 happened some time ago between the 3/94 and 3/95 versions of the
 CosRelationships specification.
 
 It seems odd since the earlier version could support the 128 bit UUIDs
 used in DCE and the 128 bit GUIDs found in Microsoft but the current
 version is only one quarter the size. Also, all available literature I
 can find on the topic indicates that the 128 bit version is necessary
 for uniqueness "across space and time". In large distributed object
 environments, I don"t think the 32 bit version will cut it.

Resolution:
Revised Text:
Actions taken:
July 23, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 1728: Proposed change to IDL in section 3.10.2, page 3-32 "Parameter Declaration (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Firstly, in Section 3.10.2, "Parameter Declarations" on
 page 3-32, the last paragraph states:
 
         When an unbounded string or sequence is passed as an
         inout parameter, the returned value cannot be longer
         than the input value.
 
 This seems like an undesirable and unnecessary restriction to me.
 Is there any chance that you could remove this restriction in a
 future version of the specification? Alternatively, if there is
 a good reason for this restriction then perhaps you could document
 it in a future revision of the specification.

Resolution:
Revised Text:
Actions taken:
July 23, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 1729: Change to IDL for anonymous types (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Secondly, anonymous types are generally a pain to deal with
 for a language mapping. I know that anonymous sequences are
 a necessary evil because they are needed to define recursive
 structs and recursive unions. For example:
 
         struct node {
                 long            data;
                 sequence<node>  children;
         };
 
 However, IDL allows anonymous sequences and arrays to be used
 in other ways for which they are not essential.

Resolution:
Revised Text:
Actions taken:
July 23, 1998: received issue
October 30, 2000: closed issue

Discussion:

Issue 1753: Size of IDL char (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Summary: The IDL chapter says on page 3-24:
 
 	OMG IDL defines a char data type that is an 8-bit quantity which...
 
 This seems to imply that chars must map to an 8-bit type in the target
 language. Not all CPUs can do this. For example, on a Cray, chars are a
 32-bit type.
 
 I would suggest to remove the size requirement.

Resolution:
Revised Text:
Actions taken:
July 30, 1998: received issue
February 22, 1999: closed issue, no action in 2.3a

Discussion:

Issue 1772: Incorrect LifeCycle IDL? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 6.2 of formal/98-07-05 mentions
 
 typedef Naming::Name Key;
 
 I believe it should be CosNaming::Name instead.

Resolution:
Revised Text:
Actions taken:
August 4, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 1796: Missing orb.idl (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: It appears that during the editing for the POA changes for 2.2, Appendix A
 of the old BOA chapter was dropped without a trace. As a result, it looks
 like the definition for the orb.idl include file has disappeared.

Resolution:
Revised Text:
Actions taken:
August 11, 1998: received issue
February 22, 1999: closed issue

Discussion:

 Add the following text to Section 3.14, following the example IDL that shows

Issue 1797: Types defined in the CORBA module? (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity:
Summary:

Summary: Where am I supposed to pick up the types defined in the CORBA module,
 such as CORBA::Identifier, if I want to use them in my IDL?
 
 The (now apparently missing) orb.idl file gave me access to the
 TypeCode interface and the IFR interfaces, but mentioned nothing about
 other types defined in the CORBA module.

Resolution: :Identifier, if I want to use them in my IDL?
Revised Text:
Actions taken:
August 11, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 1802: Multiple paths to a recursive sequence typecode (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: What exactly is the story for how the TypeCodes are created?  Is there
 one call to create_recursive_sequence_tc per recursive sequence template in the
 source, or one per cycle in the type graph?  I think this is worth clarifying
 in section 8.7.3, which doesn"t seem to conceive of the possibility of multiple
 type graph cycles through the same recursive sequence type.

Resolution: This was fixed in the process of resolving issue 1928 in Core Revision 2.3a. See resolution of 1928.
Revised Text:
Actions taken:
August 12, 1998: received issue
August 19, 1999: closed issue

Discussion:

Issue 1892: Nested scopes (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: The name of an interface or a module may not be redefined within
 the immediate scope of the interface or the module. For example:
 
 module M {
 	typedef short M; // Error: M is the name of the module
 			    in the scope of which the typedef is.
 	interface I {
 		void i (in short j); // Error: i clashes with the interface name I
 	};
 };

Resolution: Incorporate changed text and close issue in 2.4
Revised Text: : (i) Editorial fixed in 2.3a (ii) extend the restriction to struct, union and exception to be consistent across the board. Revised Text: On page 3-48 of ptc/98-12-04 change the paragraph which currently reads: The name of an interface, value type, or a module may not be redefined within the immediate scope of the interface, value type, or the module. For example: To read: The name of an interface, value type, struct, union, exception or a module may not be redefined within the immediate scope of the interface, value type, struct, union, exception or the module. For example:
Actions taken:
August 27, 1998: received issue
August 19, 1999: closed issue

Discussion:

Issue 1893: page 3-47: Identifiers (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: Page 3-47:
 
 	"Identifiers for the following kinds of definitions are scoped:
 
 		- types
 		- constants
 		- enumeration values
 		- exceptions
 		- interfaces
 		- attributes
 		- operations"
 
 I"m not sure I understand the purpose of this list. In particular, what
 is meant by "are scoped"? Scoped by what? I think the intent was to state
 that if any of these identifiers appears within a nested scope, it needs
 to be unique only within that nested scope?

Resolution: Incorporate changes in 2.4 and close issue
Revised Text: Replace the following text on page 3-47, 3-48 at the beginning of section 3.15.2: An entire OMG IDL file forms a naming scope. In addition, the following kinds of definitions form nested scopes: * module * interface * valuetype * structure * union * operation * exception Identifiers for the following kinds of definitions are scoped: * types * constants * enumeration values * exceptions * interfaces * valuetype * attributes * operations An identifier can only be defined once in a scope. However, identifiers can be redefined in nested scopes. An identifier declaring a module is considered to be defined by its first occurrence in a scope. Subsequent occurrences of a module declaration within the same scope reopen the module allowing additional definitions to be added to it. By the text: Contents of an entire OMG IDL file, together with the contents of any files referenced by #include statements, forms a naming scope. Definitions that do not appear inside a scope are part of the global scope. There is only a single global scope, irrespective of the number of source files that form a specification. The following kinds of definitions form scopes: * module * interface * valuetype * struct * union * operation * exception The scope for module, interface, valuetype, struct and exception begins immediately following its opening '{' and ends immediately preceding its closing '}'. The scope of an operation begins immediately following its '(' and ends immediately preceding its closing ')'. The scope of an union begins immediately following the '(' following the keword "switch", and ends immediately preceding its closing '}'. The appearance of the declaration of any of these kinds in any scope subject to semantic validity of such declaration, opens a nested scope associated with that declaration. An identifier can only be defined once in a scope. However, identifiers can be redefined in nested scopes. An identifier declaring a module is considered to be defined by its first occurrence in a scope. Subsequent occurrences of a module declaration with the same identifier within the same scope reopens the module and hence its scope, allowing additional definitions to be added to it.
Actions taken:
August 27, 1998: received issue
August 19, 1999: closed issue

Discussion:

Issue 1928: Proposal for creating recursive TypeCodes (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: We have spent some time pondering the various issues surrounding
 recursive TypeCodes and OBV, and have come up with a proposed
 solution.  This is not a formal proposal (it does not include actual
 changes to the CORBA spec) and is intended mostly to promote
 discussion.
 
 For this discussion a recursive TypeCode is defined as a TypeCode
 which contains data members which refer to the containing type or any
 type containing the containg type.
 
 The basic problem of creating recursive TypeCodes has become more
 complex with the addition of valuetypes.  The current mechanism for
 creating TypeCodes (as adopted by the last RTF) cannot create
 TypeCodes for a large number of cases, and can be quite confusing.
 The new proposal solves the problem of creating recursive TypeCodes in
 general and would deprecate all existing mechanisms for creating
 recursive TypeCodes.

Resolution:
Revised Text:
Actions taken:
September 2, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 1944: Typo on pages 10-53, 10-55, and 10-70 (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: The create_value_tc() api and C++ example use ValueMembersSeq, but the name
 should match the ValueMemberSeq ( no "s" after Member) definition given on page
 10-33 & 10-65

Resolution:
Revised Text:
Actions taken:
September 11, 1998: received issue
September 21, 1998: closed issue

Discussion:

Issue 1950: deactivate_object page no: 9-35 (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Summary: deactivate_object page no: 9-35
 
 void deactivate_object(in Objectid oid) 
   raises (ObjectNotActive,WrongPolicy)
 
 If a servant manager is associated with the poa, ServantLocator:: etherealize will be invoked  with the oid and the servant.
 It should be ServantActivator::etherealize instead of ServantLocator:: etherealize.
 
 The Note of deactivate object it should be ServantActivator::etherealize  instead of ServantLocator:: etherealize

Resolution:
Revised Text:
Actions taken:
September 15, 1998: received issue
September 29, 1998: close issue

Discussion:

:etherealize instead of ServantLocator:: etherealize.

Issue 1967: New proposal for recursive TypeCode creation (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The basic problem of creating recursive TypeCodes has become more
 complex with the addition of valuetypes.  The current mechanism for
 creating TypeCodes (as adopted by the last RTF) cannot create
 TypeCodes for a large number of cases, and can be quite confusing.
 The new proposal solves the problem of creating recursive TypeCodes in
 general and would deprecate all existing mechanisms for creating
 recursive TypeCodes.

Resolution:
Revised Text:
Actions taken:
September 17, 1998: received issue
November 3, 1998: closed issue

Discussion:

Issue 1969: Handling of minor codes for standard exceptions underspecified (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Looking at ptc-98-08-07, I find the discussion of minor codes hopelessly
 underspecified.  The text in 3.17.2 doesn"t actually mention the OMG
 space explicitly; it should.  Also, the definition of the partitioning
 of the minor code, at the beginning of 3.17, is hopelessly vague -- what
 ``high order bits"" are used, what ``low order bits""?  What"s the
 policy for obtaining a new vendor registration?

Resolution: I believe that this issue has been adequately addressed in the 2.3a revision. So I propose that we c
Revised Text:
Actions taken:
September 23, 1998: received issue
August 19, 1999: closed issue

Discussion:

Issue 1970: set_servant_manager (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: What exception should POA::set_servant_manager raise if the wrong servant
 manager type is passed? For example, if a POA has RETAIN and I try to
 register a ServantLocator, should set_servant_manager raise WrongPolicy, or
 some system exception? With respect to set_servant_manager, the spec says
 
 "This method requires the USE_SERVANT_MANAGER policy; if not present, the
 WrongPolicy exception is raised."
 
 Because WrongPolicy is used to denote whether set_servant_manager can be
 called correctly or not, it seems like the wrong exception to also use for
 the case of passing the wrong servant manager type. May I suggest that
 BAD_PARAM be raised in that case instead?

Resolution: Incorporate change in 2.4 and close issue.
Revised Text: The OBJ_ADAPTER exception should be raised in this case. The reasoning for this is as follows: I think the cases can best be shown in a table: Policies Servent manager Arg Narrowable to Servant Activator Servent manager Arg Narrowable to Servant Locator Servent manager Arg Narrowable to Other USE_SERVENT_MANAGER & RETAIN (ok) OBJ_ADAPTER OBJ_ADAPTER USE_SERVANT_MANAGER & NON_RETAIN OBJ_ADAPTER (ok) OBJ_ADAPTER not(USE_SERVANT_MANAGER) WrongPolicy WrongPolicy WrongPolicy The columns are the cases of what type the argument to set_servant_manager can be narrowed to. It would be weird but (at least theoretically) possible for the argument to have its most derived type be ServantManager or some other derived type. That is the last column. The rows are cover relevant combinations of poa policies. In the cells are my proposals for what exception should be raised. The two cells marked (ok) are the only ones where the call works without exception. I have used OBJ_ADAPTER rather than BAD_PARAM for the reasons already discussed in the archive. Revised Text: In section 11.3.8.11 (set_servant_manager), add an additional paragraph between the first and second (last) paragraph: "If the ServantRetentionPolicy of the POA is RETAIN, then the ServantManager argument (imgr) shall support the ServantActivator interface. (E.g. in C++ imgr is narrowable to ServantActivator.) If the ServantRetentionPolicy of the POA is NON_RETAIN, then the ServantManager argument shall support the ServantLocator interface. If the argument is nil, or does not support the required interface, then the OBJ_ADAPTER exception is raised."
Actions taken:
September 24, 1998: received issue
August 19, 1999: closed issue

Discussion:

Issue 1972: Missing equality for DynAny (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Type DynAny has no equality operator. This makes it impossible
 to determine whether or not two DynAnys contain the same value, unless
 I am prepared to recursively iterate over all of a DynAny"s components
 to determine whether they are equal. This is rather inconvenient.
 
 I would suggest to add a new operation to DynAny:
 
 	boolean equal(in DynAny da);

Resolution: added comparison operator
Revised Text: see ptc/99-03-02
Actions taken:
September 30, 1998: received issue
August 19, 1999: close dissue

Discussion:

Issue 1974: DynUnion::member() (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: What does DynUnion::member() return if a union does not have a default
 case label and has no active member? A nil reference? A DynAny
 with TCKind tk_null?
 
 It"s not specified, but should be.

Resolution: incorporate change and close in 2.4
Revised Text: see ptc/99-03-02
Actions taken:
September 17, 1998: received issue
August 19, 1999: closed issue

Discussion:

 Revision of DynUnion fixes this problem

Issue 1981: Which OBV initialiser to run is under-specified (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: Detail: The 2.3 draft says:
 
   There may be any number of init declarations, as long as the signatures 
   of all the initializers declared within the same scope are unique.
 
 To me, this implies that initialiser selection is done by matching the actual call parameter types against the formal parameter types in all the initialisers, and choosing the one that applies. However (a) this isn"t said explicitly and (b) if it is the intention, it"s fairly easy to construct a case where no one initialiser is more applicable than any other. Assuming initialiser parameters are allowed to be interface types (it doesn"t say they aren"t), consider a declaration of two initialisers in the same scope with parameter interfaces A and B, then calling the initialiser with a parameter of C, an interface that inherits from both A and B. It is impossible to say that one initialiser is more or less applicable than the other. The specification should make clear what choice a compliant ORB should make.

Resolution: Incorporate changes in 2.4 and close issue
Revised Text: The solution is to eliminate the possibility of there being a question of which initializer to call in the face of polymorphism. In effect, outlawing the potential overloading implied by the current design. The proposal requires the IDL designer to specify a unique name for the initializer. The syntax is changed to be: factory <identifier> ( <in_parameter_list> ) Language mappings specify how the <identifier> is mapped to a method in the target language. Normally this would wind up being a create operation of some kind on the value factory. Changes are specified against the draft CORBA2.3a document. Revised Text: 1. In section 10.5.24 ValueDef Add a new field to Initializer struct Initializer { StructMemberSeq members; Identifier name; }; 2. Make the same change in 10.8 3. In Section 5.2.5.2 change Value instance -> Value type 4. In the example change the initializer to: factory init(in string name, in string SSN); 5. In Section 3.4 OMG IDL Grammar In production 24 <init_dcl> change "init" to "factory" <identier> 6. In Section 3.8.5 Initializers Change "init" to "factory" <identifier> Replace the 2 descriptive paragraphs by the following single paragraph: In order to ensure portability of value implementations, designers may also define the signatures of initializers (or constructors) for non abstract value types. Syntactically these look like local operation signatures except that they are prefixed with the keyword "factory", have no return type, and must use only in parameters. There may be any number of factory declarations. The names of the initializers are part of the name scope of the value type. 7. In 3.8.1.6 Value Type Example Change the initializer to "factory" init(....) 8. In Section 3.2.4 Keywords remove "init" as a keyword. add "factory" as a keyword.
Actions taken:
September 20, 1998: received issue
February 26, 1999: moved from obv-rtf to orb_revision
August 19, 1999: closed issue

Discussion:

Issue 1997: What does interface substitutability mean in CORBA? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Thanks to Joaquin Miller, a question came up in the context of the OMA
 revision work that is going on in ORMSC about what the ORB vendors think
 "substitutability" means.

Resolution:
Revised Text:
Actions taken:
September 29, 1998: received issue
October 30, 2000: closed issue

Discussion:

Issue 2000: OMG VMCID (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Well, it looks like I get to choose what OMG"s VMCID is going to be. My
 > current thoughts are to allocate 65613 as OMG"s VMCID. This will make
 > the minor code value unsigned long appear on the wire as \x00, "M",
 > \x0<e>, <E>; where <e> is the high four bits of the minor code and <E>
 > is the lower 8 bits of the minor code.

Resolution:
Revised Text:
Actions taken:
September 29, 1998: received issue
September 30, 1998: closed issue

Discussion:

 non-issue

Issue 2007: TypeCode constants for bounded strings? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: CORBA 2.2 has the following sentences near the beginning of section
 8.7.2:
 
 In the case of an unnamed, bounded string type used directly in an
 operation or attribute declaration, a TypeCode constant named
 TC_string_n, where n is the bound of the string is produced. (For
 example, "string<4> op1();" produces the constant "TC_string_4".)
 
 CORBA 2.3 is missing these sentences.

Resolution:
Revised Text:
Actions taken:
September 28, 1998: received issue

Discussion:

Issue 2034: Recursive IDL types (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The current spec is not terribly clear on how recursive IDL types are
 supposed to work.A minor problem here is that the terminating semicolon is missing following
 the closing curly brace.
 
 But more seriously, it leaves it open whether, for example, the following
 is legal:
 
 	struct foo {
 		union u switch (long) {
 		case 0:
 			sequence<foo> foo_mem;
 		case 1:
 			char c_mem;
 		} u_mem;
 
 		long l_mem;
 	};

Resolution:
Revised Text:
Actions taken:
October 5, 1998: received issue
October 30, 2000: closed issue

Discussion:

Issue 2070: InconsistentTypeCode exception in CORBA 2.3 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The current CORBA 2.3 ORB interface chapter (ptc/98-08-08) does not 
 match the resolution which was voted on for the InconsistentTypeCode
 exception (issue 1089).
 
 The proposed resolution from ptc/98-05-01 was to place the exception
 in the ORB interface with InvalidName, not in the CORBA module.
 Jishnu, could we correct this mistake by moving InconsistentTypeCode
 from the CORBA module into the ORB interface?

Resolution: Already fixed in 2.3a Draft
Revised Text:
Actions taken:
October 10, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2084: Recursive exceptions? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Is the following IDL legal?
 
 	exception e {
 		sequence<e> e_seq;
 	};
 
 The grammar permits it, so from that, I would have to conclude it"s legal.
 However, not all ORBs I"ve tried can handle this -- some accept it and it
 works, others accept it but generate bad code, and yet others won"t compile
 the IDL.

Resolution:
Revised Text:
Actions taken:
October 15, 1998: received issue
October 30, 2000: closed issue

Discussion:

Issue 2119: long double problem? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: (2.2 3-24) and (2.2 13-8)
 I"m no floating point expert, but it seems to me that these two
   definitions are inconsistent. The first implies 1 + 15 + 64 = 80
   bits of information, while the second implies 1 + 15 + 112 = 128 bits
   of information.

Resolution: No inconsistency exists as explained in the archive.
Revised Text:
Actions taken:
October 23, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2156: Exception for abstract interface inheritance (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Abstract interfaces can only inherit from other abstract interfaces,
 yet the Interface Repository chapter (98-10-08) does not define the
 behavior of an InterfaceDef object when an attempt is made to violate
 this rule.
 
 Text should be added to section 10.5.23.2 defining the behavior of
 the mutators is_abstract and base_interfaces.
 
 Since none of the BAD_PARAM minor codes really apply, it appears
 that a new one is needed.

Resolution:
Revised Text:
Actions taken:
November 2, 1998: receive dissue
October 30, 2000: closed issue

Discussion:

Issue 2162: void * in DII Chapter (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Now that we have the native type, it is time to replace those void *s in
 the DII specification PIDL and restate them in terms of native types.

Resolution: Incorporate changes in text and close issue.
Revised Text: Resolution: void * is used in four places in Chapter 7 to denote an opaque value which is interpreted in an implementation language specific way to get hold of a value to associate with a Request or an NVList. Essentially it is as if a native type were defined as follows: native OpaqueValue; and used to type those parameters. It happens so that in the C language mapping OpaqueValue maps to void *. SO it is proposed to introduce the native type OpaqueValue and state that individual language mappings map it to whetever is appropriate for that language. We should raise an issue with each language mapping RTF to revise the appropriate pieces of those chapters to align with the "native" terminology. Revised Text: 1. In IDL on top of page 7-5, insert the first line in module CORBA to read: native OpaqueValue; 2. In IDL on top of page 7-5, replace the following line: in void * value, // argument value to be added by the line: in OpaqueValue value, // argument value to be added 3. Immediately preceding section 7.2.1 insert the following paragraph: "In IDL, The native type OpaqueValue is used to identify the type of the implementation language representation of the value that is to be passed as a parameter. For example in the C language this is the C language type "void *". Each language mapping specifies what OpaqueValue maps to in that specific language". 4. In section 7.2.2 on page 7-7 in IDL for add-arg replace the line in void * value, // argument value to be added by the line in OpaqueValue value, // argument value to be added 5. On page 7-11 section 7.4 in the IDL for NVList::add-item replace the line: in void * value, // argument value to be added by the line in OpaqueValue value, // argument value to be added 6. On page 7-12 section 7.4.2 in IDL for add_item replace the line: in void * value, // argument value to be added by the line in OpaqueValue value, // argument value to be added
Actions taken:
November 3, 1998: received issue
November 3, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2200: Typo in POA (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On P. 11-52 I see:
 
    ...Assuming the POA has the USE_SERVANT_MANAGER policy and no servant
    manager is associated with a POA, any request received by the POA for
    an Object Id value not present in the Active Object Map will result
    in an OBJECT_NOT_EXIST exception.
 
 However on P. 11-9:
 
   If the POA has the USE_SERVANT_MANAGER policy, a servant manager
   has been associated with the POA so the POA will invoke incarnate or
   preinvoke on it to find a servant that may handle the request. (The
   choice of method depends on the NON_RETAIN or RETAIN policy of the
   POA.) If no servant manager has been associated with the POA, the POA
   raises the OBJ_ADAPTER system exception.

Resolution: Incorporate changes in 2.4 and close issue.
Revised Text: The issue is clearly valid - there is an inconsistency that needs to be removed. The only choice is whether to make the exception be OBJECT_NOT_EXIST or OBJ_ADAPTER. I agree with the submitter of the issue that it should be OBJ_ADAPTER. My reasoning is that error should be obviously different than the case where the servant manager is present but does not want to provide a servant. This is an internal error in the implemenation of the server, and the client ought to be able to easily tell the difference. Revised Text: In the second paragraph of 11.6.4 (first paragraph on pg 11-52), replace "OBJECT_NOT_EXIST" with "OBJ_ADAPTER".
Actions taken:
November 9, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2202: Scoping resolution for member names (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The wording of the current 2.3 spec says nothing to suggest that member names in structs are in (or
 out) of the scope of the struct.  That is, whether
 
   struct s {
     struct t {...} t;
   };
 
 is legal or illegal.

Resolution: Close this issue in 2.4 noting that the resolution of issue 1893 subsumes this issue.
Revised Text: The resolution of 1893 takes care of the problem described in this issue by precisely stating where the scope of a struct (among other constructs) begins and where it ends. In particular struct s { struct t { ... } t; }; is illegal.
Actions taken:
November 10, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2206: Need namespace for Policy Type (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: To allow vendors to define their own value added Policies, the
 PolicyType should be partitioned into spaced that can be assigned to
 vendors.  Since the PolicyType is a CORBA long, just like the system
 exception minor code, we can just reuse the VMCID for this purpose.

Resolution: resolved and closed
Revised Text: Resolution: Do it, using essentially the same space as VMCID, ensuring that the appropriate blocks of values that are reserved for experimental and OMG allocated VMCIDs and VPVIDs are honored in the allocation of either. Also point out that getting an allocation of VMCID results in the allocation of the same value as VPVID to the vendor. Take note of the following facts: (i) PolicyTypes associated with adopted standards have already been allocated in the "0" space. (ii) VMCID of 0 is used widely for experimental use (iii) The VMCID OMGVMCID is reserved for the use of OMG hence the same VPVID value should be reserved by OMG (but perhaps not used). (iv) Propose that VMCID/VPVID of 1 - \xf be reserved for OMG use. (v) Propose that \xfffff be reserved for experimental use. Revised Text: 1. Replace the following text in section 4.9.1 on page 4-21: PolicyType defines the type of Policy object. The values of PolicyTypes are allocated by OMG. New values for PolicyType should be obtained from OMG by sending mail to request@omg.org. In general the constant values that are allocated are defined in conjunction with the definition of the corresponding Policy object. by: PolicyType defines the type of Policy object. In general the constant values that are allocated are defined in conjunction with the definition of the corresponding Policy object. The values of PolicyTypes for policies that are standardized by OMG are allocated by OMG. Additionally, vendors may reserve blocks of 4096 PolicyType values identified by a 20 bit Vendor PolicyType Valueset ID (VPVID) for their own use. PolicyType which is an unsigned long consists of the 20-bit VPVID in the high order 20 bits, and the vendor assigned policy value in the low order 12 bits. The VPVIDs 0 through \xf are reserved for OMG. All values for the standard PolicyTypes are allocated within this range by OMG. Additionally, the VPVIDs \xfffff is reserved for experimental use and OMGVMCID (ref) is reserved for OMG use. These will not be allocated to anybody. Vendors can request allocation of VPVID by sending mail to tag-request@omg.org. When a VMCID (ref) is allocated to a vendor automatically the same value of VPVID is reserved for the vendor and vice versa. So once a vendor gets either a VMCID or a VPVID registered they can use that value for both their minor codes and their policy types. 2. In section 3.17 on page 3-52 of ptc/98-12-04, replace the paragraph that reads: "Within a vendor assigned space, the assignment of values to minor codes is left to each ORB implementation." by: Within a vendor assigned space, the assignment of values to minor codes is left to the vendor. Vendors may request allocation of VMCIDs by sending email to tag-request@omg.org. The VMCID 0 and \xfffff are reserved for experimental use. The VMCID OMGVMCID (re) and 1 - \xf are reserved for OMG use.
Actions taken:
November 11, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2214: create_policy specification needs to be completed (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The specification of the create_policy operation in Chapter 4 section
 4.9.2 (ptc-98-10-05, 5 November 98) is missing the following important
 elements:
 
 1. There is no specification of what is expected of someone who is
 defining a new policy type, in order to use this operation as the
 factory for policy objects of that type.
 
 2. Policy objects of wich of the PolicyTypes can be created using this
 operation in release 2.3 is not specified. Consequently, the types that
 are valid as input through the "val" parameter are unspecified also.

Resolution: Incorporate changes in 2.4 and close issue
Revised Text: Insert two new sections 4.9.5 and 4.9.6 as follows: 4.9.5 Specification of New Policy Objects When new PolicyTypes are added to CORBA specifications, the following details must be defined. It must be clearly stated which particular uses of a new policy are legal and which are not: o Specify the assigned CORBA::PolicyType and the policy's interface definition. o If the Policy can be created through CORBA::ORB::create_policy, specify the allowable values for the any argument 'val' and how they correspond to the initial state/behavior of that Policy (such as initial values of attributes). For example, if a Policy has multiple attributes and operations, it is most likely that create_policy will receive some complex data for the implementation to initialize the state of the specific policy: //IDL struct MyPolicyRange { long low; long high; }; const CORBA::PolicyType MY_POLICY_TYPE = 666; interface MyPolicy : Policy { readonly attribute long low; readonly attribute long high; }; If this samply MyPolicy can be constructed via create_policy, the specification of MyPolicy will have a statement such as: "When instances of MyPolicy are created, a value of type MyPolicyRange is passed to CORBA::ORB::create_policy and the resulting MyPolicy's attribute 'low' has the same value as the MyPolicyRange member 'low' and attribute 'high' has the same value as the myPolicyRange member 'high'. o If the Policy can be passed as an argument to POA::create_POA, specify the effects of the new policy on that POA. Specifically define incompatibilities (or inter-dependencies) with other POA policies, effects on the behavior of invocations on objects activated with the POA, and whether or not presence of the POA policy implies some IOR profile/component contents for object references created with that POA. If the POA policy implies some addition/modification to the object reference it is marked as "client-exposed" and the exact details are specified including which profiles are affected and how the effects are represented. Typically, the Messaging::TAG_POLICIES component is used to carry this information. o If the Policy can be set within a client to tune the client's behavior, specify the policy's effects on the client specifically with respect to (a) establishment of connections and reconnections for an object reference; (b) effects on marshaling of requests; (c) effects on insertion of service contexts into requests; (d) effects upon receipt of service contexts in replies. In addition, incompatibilities (or inter-dependencies) with other client-side policies are stated. For policies that cause service contexts to be added to requests, the exact details of this addition are given. o If the Policy can be used with POA creation to tune IOR contents and can also be specified (overriden) in the client, specify how to reconcile the policy's presence from both the client and server. It is strongly recommended to avoid this case! As an excercise in completeness, most POA policies can probably be extended to have some meaning in the client and vice versa, but this does not help make usable systems, it just makes them more complicated without adding really useful features. There are very few cases where a policy is really appropriate to specify in both places, and for these policies the interaction between the two must be described. o Pure client-side policies are assume to be immutable. This allows efficient processing by the runtime that can avoid re-evaluating the policy upon every invocation and instead can perform updates only when new overrides are set (or policies change due to rebind). If the newly specified policy is mutable, it must be clearly stated what happens if non-readonly attributes are set or operations are invoked that have side-effects. o For certain policy types, override operations may be disallowed. If this is the case, the policy specification must clearly state what happens if such overrides are attempted. 4.9.6. Standard Policies Table xxx below lists the standard policy types that are defined by various parts of CORBA and CORBA Services in this version of CORBA Policy Type Policy Interface Definion in section/page Uses create_policy? <OMG editing staff, complete with all current standard policies before publishing>
Actions taken:
November 16, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2218: WRONG_TRANSACTION (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: WRONG_TRANSACTION Exception
 
 	The CosTransactions module adds the WRONG_TRANSACTION exception
 	that can be raised by the ORB when returning the response to a
 	deferred synchronous request. This exception is defined in Chapter 4
 	of the Common Object Request Broker: Architecture and Specification.
 This para doesn"t state what module is to be used for
 	  WRONG_TRANSACTION. I assume what is meant is that it should be
 	  a system exception?
 
 	- I can"t find this exception in either chapter 4 or chapter 3
 	  of the 2.3 spec. Looks like it needs to be added. I don"t know
 	  why the above para refers to chapter 4 though -- it seems that
 	  this exception should be added to the list of system exceptions
 	  in chapter 3?

Resolution: issue merged with issue1963
Revised Text:
Actions taken:
November 17, 1998: received issue
November 18, 1998: issue closed, merged with issue 1963

Discussion:

Issue 2221: Core uses both "standard" and "system" exception terminology (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The core chapters (chapter 3, for example) uses both "standard" and
 "system" to describe the same class of exceptions.  Most of the core
 seems to prefer "standard", however the C++ language mapping uses
 SystemException.
 
 The core should be cleaned up to use "standard" as the normal term, and
 then state that "system" is used in some language mappings as a synonym.

Resolution:
Revised Text:
Actions taken:
November 19, 1998: received issue
October 30, 2000: closed issue

Discussion:

Issue 2223: Local operations on CORBA::Object (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Basically, people get confused about which operations on CORBA::Object
 can go remote. It"s clear from the GIOP spec that only non_existent(),
 is_a(), get_interface(), and get_domain_managers() can go on the wire.
 It follows that things like nil(), hash(), and is_equivalent() must be
 local. However, as Owen Rees pointed out, this only applies to GIOP, not
 the core, but a compliant ORB need not provide GIOP.
 
 It seems that it would be a good idea to add some clarification to the core
 to state which operations on CORBA::Object must be local and which ones
 may (but need not) go remote.

Resolution: Incorporate changes in 2.4 and close issue
Revised Text: Provide clarifying text in Chapter 4 for each of the Object operations stating which ones may go remote and which are local only. Revised Text: Change text in Chapter 4 as follows: 1. In section 4.3.1 append the sentence: "The implementation of this operation may involve contacting the ORB that implements the target object." to the last paragraph of the section. 2. In section 4.3.9, append the sentence: "The implementation of this operation may involve contacting the ORB that implements the target object." to the first paragraph of the section. 3. In section 4.3.7, append the sentence: "The implementation of this operation may involve remote invocation of an operation (e.g. DomainManager::get_domain_policy for some security policies) for some policy types." to the first paragraph of the section. 4. Add the following paragraph at the end of section 4.3 (immediately preceding section 4.3.1: "Unless otherwise stated, the operations in the IDL above do not require access to remote information."
Actions taken:
November 19, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2230: is_a underspecified (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: the description of is_a suffers from the same problem that we fixed for
 non_existent in 2.3: it is not clear what the operation should do if
 it could not make a determination due to a hard error. This means that
 the application does not know whether failure to make a determination
 returns false, or whether that will raise an exception (and false is
 returned only if the object doesn"t have the expected type).

Resolution: clarify
Revised Text: Add the following text before the last para of section 4.3.4 (add text at the top of page 4-12): Determining whether an object's type is compatible with the logical_type_id may require contacting a remote ORB or interface repository. Such an attempt may fail at either the local or the remote end. If is_a cannot make a reliable determination of type compatibility due to failure, it raises an exception in the calling application code. This enables the application to distinguish among the true, false, and indeterminate cases.
Actions taken:
December 1, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2235: uses of recursive_tc (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: According to ptc/98-10-08, 16 Oct. 98 [REVIEW], p. 10-53,
     "Once the recursive TypeCode has been properly embedded in the
       enclosing TypeCode which corresponds to the specified repository
       id, it will function as a normal TypeCode."
 
 Given the following idl:
 
     valuetype v {
         public v m0;
    };
 
 And the following C++ code to generate the typecode for v:
 
     CORBA::ORB_ptr orb = ...;
     CORBA::TypeCode_ptr tcRecursive =
 orb->create_recursive_tc("IDL:v:1.0");
     CORBA::ValueMemberSeq v_seq;
     v_seq.length(1);
     v_seq[0].type = tcRecursive;
     ...
     CORBA::TypeCode_ptr tcV = orb->create_value_tc("IDL:v:1.0", "v",
                                        VM_NONE, CORBA::TypeCode::_nil(),
 v_seq);
 
 After tcRecursive has been properly embedded, what does "tcRecursive
 functioning
 like a normal TypeCode" mean?  Does it mean that one can call on
 tcRecursive the same
 methods that are available on tcV? For example, will
 
    CORBA::Visibility vis = tcRecursive->member_visibility(0);
 
 work?

Resolution: Close no change in 2.4
Revised Text: -currently, the spec says the embedded typecode is incomplete when constructed but must function as a real typecode when embedded. This requires implementers to perform some sort of delegation for a recursive tc. - the issue proposes that even once completed, the embedded typecode raise an exception whenever it is programmatically queried. In both scenarios, ORBs must implement a special typecode (the embedded one). In one case to do delegation, in the other to raise exceptions. Both wordings of the spec (the current wording and your proposal) impose a limitation on implementations of recursive typecodes. There doesn't appear to be any pressing reason to make the embedded typecode unusable if it can just as easily (and with some additional benefits for implementors who are using reference counting) perform the delegation so the wording should remain unchanged.
Actions taken:
December 3, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2252: DynValue::get_members/set_members (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The final draft (ptc/98-10-16 - from 15-Nov-98) defines
 DynValue::get_members/set_members as:
 
 --
 struct NameValueAccess {
    FieldName id;
    Visibility access;
    any value
 };
 
 typedef sequence<NameValueAccess> NameValueAccessSeq
 
 NameValueAccessSeq get_members();
 void set_members(in NameValueAccessSeq values) raises (InvalidSeq),
 --
 
 and goes on to say "Any attempt to set or get a member which has been
 declared private in the IDL definition of the value contained in the
 dynamic any raises the exception NO_PERMISSION."

Resolution: :get_members/set_members as:
Revised Text:
Actions taken:
December 10, 1998: revceived issue

Discussion:

Issue 2254: Destruction of ORB (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: how is the ORB object destroyed? There is no ORB::destroy() operation,
 like for the POA. (With "destroy", I mean to remove it from memory
 (C++), or to allow it to be garbage collected (Java).)
 
 Is shutdown to be meant to destroy the ORB? If so, then this must be
 clarified in the specification. For example, if shutdown() destroys the
 ORB, all subsequent calls to ORB operations (via ORB references) must
 raise OBJECT_NOT_EXIST, just as it is with any other (locality
 constrained) object.
 
 If shutdown() does not destroy the ORB, but just shuts down
 communications and stops handling of further requests, then some other
 operation is needed to destroy the ORB.

Resolution:
Revised Text:
Actions taken:
December 14, 1998: receive dissue
December 14, 1998: closed issue

Discussion:

Issue 2258: OBV, value-reference substitution, Multiple Inheritance (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Hi, is it possible to pass a supporting value type by value when used as
 a interface?  It looks like this is droped from the OBV spec
 (ptc/98-10-06.pdf says when a supporting value type is used as a
 interface then an object reference will be used).

Resolution:
Revised Text:
Actions taken:
December 15, 1998: received issue
February 19, 1999: moved to orb_revision

Discussion:

Issue 2275: Sequences of recursive structs/unions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: If I have a recursive struct or union type and want to pass a sequence 
 of that type to an operation, I am completely stuck if I want to do
 this with C++. I"m not sure about other mappings, but I expect that
 Java, Ada, etc. will all suffer from the same problem.

Resolution:
Revised Text:
Actions taken:
December 21, 1998: received issue
October 30, 2000: closed issue

Discussion:

Issue 2296: Custom marshalling & AbstractBase (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The 2.3a draft defines DataOutputStream as having the following
 operation (see p. 5-12):
 
   void write_Abstract(in AbstractBase value);
 
 Yet there is no definition of the type `AbstractBase" anywhere
 in the document.

Resolution: Add AbstractBase as a native type in the CORBA module, together with explanation in Chapter 6.
Revised Text: 1. In section 6.2, add a new numbered list item 4. Renumber existing items 4 and higher to 5 and higher. The text is: "Abstract interfaces implicitly inherit from CORBA::AbstractBase. This type is defined as native. It is the responsibility of each language mapping to specify the actual programming language type that is used for this type. module CORBA { // IDL native AbstractBase; }; " 2. In Section 4.2 in the CORBA IDL, insert the line: native AbstractBase; immediately preceding the line that reads "interface NVList".
Actions taken:
January 7, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2303: POA threading policies (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The POA offers the SINGLE_THREAD_MODEL policy. It guarantees that, for
 a POA with this policy, all invocations are serialized. (The only other
 threading policy, ORB_CTRL_MODEL, allows to ORB to thread invocations as
 it sees fit.)
 
 There is a pragmatic problem here: SINGLE_THREAD_MODEL guarantees
 serialization for only a particular POA. This means that if I have a server
 that uses three POAs, all of which use SINGLE_THREAD_MODEL, invocations on
 any one of these POAs are serialized but invocations on different POAs
 can be dispatched in parallel.

Resolution:
Revised Text:
Actions taken:
January 10, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2308: POA SINGLE_THREAD_MODEL description ambiguous (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The description for the SINGLE_THREAD_MODEL policy only states that the
 POA makes all upcalls in a manner that is safe for code that is
 multi-thread-unaware.  This statement could be read to disallow
 recursive upcalls from one object implementation to another mediated by
 the same POA on a single thread.
 
 Proposed resolution:
 
 Add the following sentence to both sections 9.2.8 and 9.3.7, where the
 text defines the Single Threaded Model:
 
 A single-threaded POA will still allow recursive upcalls, where an
 object"s implementation invokes an operation on an object implemented
 using the same POA.

Resolution:
Revised Text:
Actions taken:
January 18, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2310: Missing minor code (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In the 2.3a core chapters, there is a minor code missing from page 3-58,
 table 3-13.  BAD_PARAM minor code 1 should also be raised for errors 
 trying to lookup and unregister a value factory.  Alternatively we could
 add new minor codes for these.

Resolution: Let minor code one be used for all value factory related exceptions.
Revised Text: In table 3-13 on page 3-58 change the "Explanation" field for BAD_PARAM minor code 1 to read: "failure in attempt to register, unregister or lookup value factory."
Actions taken:
January 20, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2311: Custom Marshaling clarification (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In the core 2.3a chapters, page 5-11, section 5.5.1, last paragraph needs
 to be clarified or deleted.  This paragraph originally referred to the
 "streaming policy" registration APIs that used to be specified here but
 have since been deleted.
 
 Do we still intend to allow language mappings to provide alternative 
 mechanisms for custom marshaling as well as the standard mechanism of
 having the valuetype implementation provide the CustomMarshal methods
 marshal and unmarshal?  If not, this paragraph should be deleted.  If so,
 the last part of the paragraph should be reworded, for example "... to
 support other ways for value types to implement custom marshaling".

Resolution: Incorporate change in 2.4 and close issue
Revised Text: Delete last paragraph of section 5.5.1 (the one starting "This API is guaranteed").
Actions taken:
January 20, 1999: received issue
September 16, 1999: closed issue

Discussion:

Delete last paragraph of section 5.5.1 (the one starting "This API 
is guaranteed"). 

Rationale: 

This is a hangover from a previous level of the spec (the version that 
used streaming policies) and now serves no purpose other than to confuse 
the reader.

Issue 2312: Names of Data*Stream methods (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The method names in DataInputStream and DataOutputStream have been
 chosen to match the method names in the Java portability streams.
 There is a proposal before the Java RTF to change some of the latter
 names.  If this is accepted, we should change the corresponding names 
 in Data*Stream as well.  
 
 This affects page 5-12 in the core 2.3a chapters.  write_Value should
 change to write_value and write_Abstract to write_abstract_interface.
 The corresponding read_* methods on page 5-14 should also be changed.

Resolution:
Revised Text:
Actions taken:
January 20, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2314: Supporting multiple abstract interfaces (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Valuetypes should be able to support multiple abstract interfaces but
 only a single regular interface.  See also comments number 28 and 31
 in the list of core 2.3a errata I just sent out.

Resolution: Incorporate changes in 2.4 and close issue.
Revised Text: Resolution: Make changes to allow valutypes to support multiple abstract interfaces. The current prohibition on valuetypes supporting multiple interfaces was intended to prevent the OBV spec introducing multiple interface support by the "back door." The argument went that there is not much if any difference between a valuetype supporting multiple IDL interfaces and any implementation supporting sulitple IDL interfaces. Since we had no standard way to do the latter, we should not invent a standard way to do the former but not the latter, and we should not invent a standard way to do the latter as part of adding OBV. All very logical and reasonable. This consideration does not require disallowing support of multiple abstract interfaces. These are just giving the valuetype additional type semantics, as in C++ where a class has multiple abstract base classes containing only pure virtual functions, or in Java where a class implements multiple Java (not IDL) interfaces. So there is no reason to prevent this. The reason to allow this is the Java to IDL mapping. A Java serializable class that implements multiple RMI abstract interfaces (i.e., interfaces that do not extend java.rmi.Remote but whose methods throw RemoteException) is mapped to an IDL valuetype that supports multiple IDL abstract interfaces. If the latter is prohibited, we cannot correctly support the former. Revised Text: a. Page 3.13, section 3.4, production 19. Change last line to [ "supports" <interface_name> { "," <abstract_interface_name> }* ] b. Page 3.13, section 3.4, add new production <abstract_interface_name> ::= <scoped_name> c. Make above two changes in section 3.8.1.3 on page 3-23. d. Page 3-24, section 3.8.1.3, first line. Change "and <interface_name>" to "<interface name>, and <abstract_interface_name>". e. Page 3-27, section 3.8.5, third paragraph, add "and any number of abstract interfaces" at end of sentence. f. Page 3-27, section 3.8.5, third line of fifth paragraph. Change "interfaces and abstract interface" to "interface and abstract interfaces". g. Page 3-27, table 3-10. Add new column for Abstract Interface following the column for Interface. Contents are the same as the existing column for Interface except that the entry for Stateful Value should be "supports". h. Page 3-27, table 3-10. Abstract Value inherits from Interface should be "supports single". Also add new row for Abstract Interface, with contents (Interface) (Abs Int) (Abs Val) (Stfl Val) (Box Val) no multiple no no no i. Page 6-2, add new numbered point 6 before existing point 6 (which becomes point 7): Value types may support any number of abstract interfaces, but no more than one regular interface. j. Page 10-16: Change the supported_interface parameter of the create_value method of Container to a parameter named supported_interfaces with a data type of InterfaceDefSeq. Also make this change on page 10-58. k. Page 10-19: Change supported_interface to supported_interfaces. l. Page 10-34: Change the supported_interface attribute of ValueDef to a parameter named supported_interfaces with a data type of InterfaceDefSeq. Also make this change on page 10-64. m. Page 10-35: Change the supported_interface member of ValueDescription to a member named supported_interfaces with a data type of RepositoryIdSeq. Also make this change on page 10-66. n. Page 10-36: Change the first paragraph of section 10.5.24.1 to "The supported_interfaces attribute lists the interfaces that this value type supports." o. Page 10-36: In section 10.5.24.2, change supported_interface to supported_interfaces.
Actions taken:
January 20, 1999: received issue
September 16, 1999: closed issue

Discussion:

 a. Page 3.13, section 3.4, production 19.  Change last line to

Issue 2316: Codebases with multiple URLs (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: To support JDK 1.2 correctly, the codebase support for Objects By Value
 needs to support multiple URLs rather than a single URL as at present.
 
 This affects page 5-16 in the core 2.3a chapters.  Either the signatures
 of the implementation and implementations methods need to change to:
   URLSeq implementation(in CORBA::RepositoryId x); 
   URLSeqSeq implementations(in CORBA::RepositoryIdSeq x);
 
 or we need to say that the URL string can be a blank-separated
 sequence of URLs.  This also affects the OBV grammar on page 15-19.

Resolution: Incorporate changes in 2.4 and close issue
Revised Text: It needs one or other of the following resolutions: Option A. Encode multiple URLs as a blank-separated string. This leaves the existing IDL unchanged, but requires changes to the supprting text in chapters 5 and 15 to state that a codebase URL can be multiple blank-separated URLs. Option B. Encode multiple URLs as a sequence of strings. This requires IDL changes to page 5-16 and 15-19. It is proposed that we resolve this issue using option B because: (a) Encoding multiple URLs as a sequence of strings is more natural in IDL (b) The Java to IDL mapping already does it this way. This means that the core IDL remains unchanged. However, the text and code comments should be clarified. Revised Text: On page 5-16, change the line: typedef string URL; to: typedef string URL; // blank-separated list of one or more URLs Also change the comment: // Operations to obtain a URL to the implementation code to: // Operations to obtain the location of the implementation code In the last paragraph on page 5-17, change the text: In this case, in addition to the codebase URL that is sent in the service context, each value which has a different codebase may have a codebase URL associated with it. to the text: In this case, in addition to the codebase URL(s) sent in the service context, each value which has a different codebase may have codebase URL(s) associated with it. One unrelated editorial point on this section. It is currently section 5.5.3 (part of "Custom Marshalling"). This is incorrect. It should be section 5.6 as it has nothing to do with custom marshalling. Apparently the wrong head level was used. Some changes to chapter 15 are also required. In section 15.3.4.1, first bullet, add a sentence at the end: The <codebase_URL> string is a blank-separated list of one or more URLs. In section 15.3.4.1, second last paragraph, change "codebase URL" to "codebase URL information". In section 15.3.4.2, first paragraph, change "a URL" to "codebase URL information". In section 15.3.4.3, second sentence, change "a codebase URL" to "codebase URL information". In section 15.3.4.3, third sentence, change "codebase URL" to "codebase URL information".
Actions taken:
January 20, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2318: Misleading text in section 3.2.5.2 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The second last paragraph in section 3.2.5.2 is confusing.  The
 second last sentence says (modulo typos) that since a string is a
 sequence of character literals, a sequence of \u literals can be 
 used to define a wide string literal.  
 
 This seems to me to be a non sequitur.  The conclusion does not 
 follow from the premise.  I think this sentence was supposed to say
 that since a wide string is a sequence of wide character literals,
 a sequence of \u literals can be used to define a wide string literal.

Resolution: Fix it
Revised Text: On page 3-10, second last paragraph, replace the last two sentences by the following: Since a wide string literal is defined as a sequence of wide character literals, a sequence of \u literals can be used to define a wide string literal. Attempts to set a char type to a \u defined literal or a string type to a sequence of \u literals result in an error.
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2319: Clarify meaning of no IDL initializers (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 3.8.1.5 on page 24 does not make it clear what it means to 
 have no initializers for an IDL valuetype.  The decision of the OBV 
 designers, which is reflected in the C++ and Java language mappings,
 was that this means there is no portable way to create an instance
 of the value type.  This should be clearly stated in the definition of
 IDL semantics for valuetypes, not deduced from the language mappings.

Resolution: Fix it
Revised Text: Page 3.24, section 3.8.1.5, add new paragraph after first paragraph: If no initializers are specified in IDL, the value type does not provide a portable way of creating a runtime instance of its type. There is no default initializer. This allows the definition of IDL value types which are not intended to be directly instantiated by client code.
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2320: Signature of unmarshal method is wrong (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 5-11, section 5.5.1, the signature of the unmarshal method is
 wrong.  It should return void, not ValueBase.

Resolution: Fix it
Revised Text: On page 5-11 in IDL for CustomMarshal replace the line: ValueBase unmarshal (in DataInputStream is); by the line void unmarshal (in DataInputStream is);
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2321: Errors in figure 10-2 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 10-8, the section of figure 10-2 describing the module object
 has become wrongly ordered when the green text was inserted.  It says:
 
     InterfaceDef
     ValueDef
     ValueBoxDef
     ModuleDef
 
 It should say:
 
     ModuleDef
     ValueBoxDef
     InterfaceDef

Resolution: fix the order and indentation
Revised Text: Change the figure to look like: (A) Repository (B) ConstantDef TypedefDef ExceptionDef InterfaceDef ValueDef ValueBoxDef ModuleDef (C) ConstantDef TypedefDef ExceptionDef ValueBoxDef ModuleDef InterfaceDef (D) ConstantDef TypedefDef ExceptionDef AttributeDef OperationDef ValueDef (E) ConstantDef TypedefDef ExceptionDef AttributeDef OperationDef ValueMemberDef With the following annotation in the right column against the blocks identified by letters in parens in the left margin above: (A) Each interface repository is represented by a global root repository object. (B) The Repository IR object represents the constants, typedefs, exceptions, interfaces valuetypes value boxes and modules that are defined outside the scope of a module. (C) The Module IR object represents the constants, typedefs, exceptions, interfaces, valuetypes, value boxes and other modules defined within the scope of the module. (D) An Interface IR object represents constants, typedefs, exceptions, attributes, and operations defined within or inherited by the interface. (E) A value type IR object represents constants, typedefs, exceptions, attributes, operations and members defined within or inherited by the value type.
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2322: No description for NativeDef (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 10.5.26, NativeDef, has no description of its read and write
 interfaces.  This is inconsistent with other sections.

Resolution: Provide description
Revised Text: Add the following paragraph at the end of section 10.5.26: The inherited <font>type</font> attribute is a <font>tk_native TypeCode</font> describing the native type.
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2323: is_a description is wrong (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 10-36, the "is_a" description is wrong.  "interface_id" should
 be "value_id" for consistency with the IDL.
 
 Actually, it would be more correct to name this "value_or_interface_id" 
 or just "id" since both values and interfaces can be passed to the is_a
 method of ValueDef.  This requires changing the IDL on pages 10-34 and
 10-65.

Resolution: Incorporate changes in 2.4 and close issue.
Revised Text: The parameter named value_id should changed to id to reflect the fact that it can be either and interface or a value id. Revised Text: On pages 10-34 and 10-65, change the argument name in the is_a operation from "value_id" to "id". In section 10.5.24.1 on page 10-36, in the "is_a" description, change "interface_id" to "id".
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue
September 16, 1999: closed issue

Discussion:

Issue 2325: No description for ValueBoxDef (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 10.5.25, ValueBoxDef, has no description of its read and write
 interfaces.  This is inconsistent with other sections.
 
 Proposed resolution:
 
 Add copies of sections 10.5.13.1 and 10.5.13.2 here.

Resolution: Provide description
Revised Text: Add copies of sections 10.5.13.1 and 10.5.13.2 as section 10.5.25.1 and 10.5.25.2 to this section. The second para of new section 10.5.25.1 shall read: The inherited type attribute is a tk_value_box TypeCode describing the value box.
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2327: Error in ValueDef IDL (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 10-35, the first line should be "RepositoryId supported_interface;".
 
 Also, on page 10-65, the eleventh member of FullValueDescription should be
 "RepositoryId supported_interface;" (same change).

Resolution: The resolution of this is tied to the resolution of issue 2314. So this issue is attached to and sub
Revised Text:
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2328: Text was inserted in wrong place (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 10-9, the recently added second paragraph should be moved to the
 bottom of the section.  The parapgraph preceding it and the two paragraphs
 following it refer back to numbered points 1, 2 and 3 at the bottom of 
 page 10-8, so this block of text should not be broken up.

Resolution: Make it so
Revised Text: Move the paragraph: "Analagous operations are provided for manipulating value types." to the end of the section.
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2329: RMI Repository ID missing from section 10.6 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 10.6 needs to be updated to reflect the addition of RMI
 Hashed Format RepositoryIds.

Resolution: change introductory sentence to fix this problem in section 10.6
Revised Text: In section 10.6 change the sentence that currently says: This specification defines three formats: one derived from OMG IDL names, one that uses DCE UUIDs, and another intended for short-term use, such as in a development environment. to: This specification defines four formats: one derived from OMG IDL names, one that uses OMG IDL names and Java serialization version UIDs, one that uses DCE UUIDs, and another intended for short-term use, such as in a development environment.
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2330: Error in text describing TypeCode interface (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The IDL on page 10-47 describing the TypeCode interface says that
 the member_count, member_name, and member_type operations apply to
 tk_except TypeCodes.  However, the text on page 10-49 says that
 these do not apply to exception TypeCodes.

Resolution: Fix it.
Revised Text: Page 10-49, "member_count" and "member_name" operations description, second line. After "non-boxed valuetype" add ", exception". Page 10-49, "member_type" operation description, first line. After "non-boxed valuetype" add ", exception".
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2331: Clarify text in section 15.3.7 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 15-26, last sentence of section 15.3.7, the phrase "The abstract
 encoding of value type" is not very clear.  This refers to abstract 
 interfaces, but a reader might think it refers to abstract valuetypes.

Resolution: Incorporate change in 2.4 and close issue
Revised Text: On page 15-26, last sentence of section 15.3.7 change the phrase "The abstract encoding of value type" to "The encoding of value types marshaled as abstract interfaces".
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2332: Clarifications needed in section 5.2.2 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In section 5.2.2 it states in the second paragraph that instances of
 valuetypes passed into valuetype methods are passed by reference (in a
 programming language sense).  That"s fine, but:
 
 1. This paragraph should also state that returned results are passed
    by reference.  This is necessary to ensure consistent IDL 
    valuetype semantics across different implementation languages.
 
 2. The last sentence of the following paragraph is confusing because
    it appears to contradict the statement in the second paragraph
    about reference semantics.  It says that "normal semantics for the
    programming language in question apply".  So if I have a language
    that only does pass-by-value, pass-by-value semantics would apply
    (so this says).  This cannot be correct, since it would prevent
    valuetypes from having well-defined semantics at the IDL level.

Resolution: Fix it.
Revised Text: 1. In the first sentence of the second paragraph of 5.2.2 page 5-3, change "passed into" to "passed into and returned by". 2. In the last sentence of the third paragraph, change "the normal semantics .... apply" to "programming language reference semantics apply".
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2334: Value base and the IFR (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Consider the following IDL:
 
 // IDL
 interface I
 {
     void op(in ValueBase vb);
 };
 
 How is this represented in the IFR? What is the IDLType of the vb
 parameter?
 
 I think it should be a PrimitiveDef, just as it would be the case if I
 would pass "Object" instead of "ValueBase". However, there is no
 pk_ValueBase defined. Shouldn"t this be added?

Resolution: Add value base to primitive defs.
Revised Text: (1) In section 10.5.14 page 10-25 enum declaration for PrimitiveDefs append to the list pk_ValueBase (2) Append the following sentence to the paragraph that immediately foolows the IDL referred to in (1) above: "A PrimitiveDef with kind pk_ValueBase represents the IDL type ValueBase."
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2340: Forward-Declared Interfaces (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: there just has been raging discussion on the OB list about forward-declared
 interfaces. The words we have right now are inadequate. You could argue that the
 interface is defined in the same "specification" here. However,
 current IDL compilers (if they implmement the check at all) require
 the interface to be defined in the same compilation unit as the
 forward declaration.
 
 Now, we could allow a forward-declared interface to not be defined in
 the same compilation unit, but then, I think, we would have to very
 carefully specify what sort of things I can do with the forward-declared
 interface. (If we don"t do that, we"ll make separate compilation impossible
 because the compiler doesn"t know the size of a forward-declared interface
 nor its base interfaces.)
 
 What"s the general feeling here? I think we could simple change "specification"
 to "IDL source file" and be done with it. That"s the simple way out.

Resolution:
Revised Text:
Actions taken:
January 22, 1999: receive dissue
October 30, 2000: closed issue

Discussion:

Issue 2341: Calling get_response twice? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: What if I call get_response on a request a second time, after I"ve already
 retrieved the response previously? It seems that an exception should
 be raised but the spec doesn"t say which one.
 
 Also, the spec could be interpreted right now to say that it"s OK to
 call get_response twice for the same request (because the spec says nothing
 about that). However, to me, permitting this would be silly because it would
 oblige the ORB to keep the reply around until the request object is destroyed
 or is used to initiate another request.

Resolution:
Revised Text:
Actions taken:
January 22, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2343: Grammar section 3.9.2 missing "float" rules, and other problems (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 3.9.2 has the following problems:
 
 No rules for combining floats are given, although double and long double types are mentioned.
 
 The rules for sizing intermediate forms of constant expressions that must result in an octet type
 are unspecified.
 
 The size a positive integer constant is required to have is not specified; I imagine it should be
 restricted to (at most) an "unsigned long" size, as larger sizes would not make valid array indices
 in several languages.

Resolution: Sumsume this issue in 1139, and close this issue with that annotation in 2.4.
Revised Text:
Actions taken:
January 25, 1999: received issue
September 16, 1999: closed issue

Discussion:

This issue is closely related to issue 1139, and therefore should be merged into 1139, so that the wholeissue of constant arithmetic can be dealt with in a single
consolidated resolution

Issue 2371: Issue - no PIDL, just language bindings (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In section 7.3.2 of CORBA 2.3a (ptc/98-10-07 pg 7-9) the description of
 send_multiple_requests gives the C, C++, and SmallTalk bindings for the
 operation but does not describe it in PIDL. This is inconsistent with
 the description style for other operations. It is unnecessarily biased
 towards these particular languages, and complicates the process of
 maintaining the specifications of the individual language bindings.
 
 The same comment applies to section 7.3.4 regarding get_next_response.
 In this case the language binding is in fact inconsistent with that
 published in the C++ language binding.

Resolution: Incorporate changes in 2.4 and close issue and raise new issue in C++ RTF
Revised Text: Resolution: Remove all the language mappings from the DII chapter and insert corresponding PIDL. Also update the PIDL in Chapter 4 ORB interface and make it consistent with Chapter 7. Use the ORB pseudo interface in the C++ and Java language binding chapter as the basis for this cleanup. Since this is just PIDL cleanup that simply aligns the PIDL with the way things are in the C++ and Java mappings, it has relatively little immediate impact on the most important language mappings. Even those language mappings that diverge a little from this setup are not necessarily broken, since language mappings have considerable latitude in how they map PIDL. If necessary they can eventually get aligned more closely. What is proposed involves removing C language mapping specific flag values and such from the Core chapters and requesting the C language mapping RTF to incorporate them in the C mapping chapter. Revised Text: 1. In the PIDL for the ORB interface on page 4-2, immediately following the line "interface DynValue ..." insert the lines: interface Request; // forward declaration typedef sequence <Request> RequestSeq; 2. In chapter 4 on page 4-3 in the IDL for ORB interface immediately following the get_default_context operation add the following lines of PIDL: void send_multiple_requests_oneway(in RequestSeq req); void send_multiple_requests_deferred(in RequestSeq req); boolean poll_next_response(); void get_next_response(out Request req); 3. In the third paragraph below the PIDL on page 4-7 which reads: "For a description of the create_list and create_operation_list operations, see ?List Operations? on page 7-11. The get_default_context operation is described in the section ?get_default_context? on page 7-15." Add the sentences: "send_multiple_request_oneway and send_multiple_request operations are described in the section "send_multiple_request" on page 7-9. poll_next_response and get_next_response are described in the section "get_next_response" on page 7-10." 4. In section 7.3.2 on page 7-9 remove the C, C++ and Smalltalk language mappings at the beginning of the section and place there instead the PIDL: interface Request; // forward declaration typedef sequence <Request> RequestSeq; void send_multiple_requests_oneway(in RequestSeq req); void send_multiple_requests_deferred(in RequestSeq req); 5. Remove the last four paragraphs of section 7.3.2. They belong in specific language mapping sections that happen to use the Flags, as C language does. 6. In section 7.3.4 on page 7-10 remove the C, C++ and Smalltalk language mappings at the beginning of the section and place there instead the PIDL: interface Request; // forward declaration boolean poll_next_response(); void get_next_response(out Request req) raises (WrongTransaction); Actions taken: 1. Incorporate changes in 2.4 and close issue. 2. Raise a new issue for C language mapping RTF to take the C language specific material repoved from the core chapters and incorporate them in the C chapter.
Actions taken:
February 2, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2372: Use UNICODE Character set (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Summary:  I am member of the nation using another set of accented Latin letters than is LATIN-1 standard (ISO 8859.1), namely LATIN-2. For this reason, I must comment your preference of one particular character set as an unfortunate case. I would understand, that if you would limit character set to basic Latin characters of the basic ASCII code, but preference of one national enhancements of this code brings my doubts.
  In fact, the problem is not so hot, as it may seem on the first view. I know at present no classical compiler allowing use of the national character set e.g. for the language identifiers, and the limitation of the character sets to pure Latin characters is considered by Czech (and other nation"s) programmers as no significant limitation, with exception of the comments. The same concerns CORBA identifiers used in the OMG IDL language.

Resolution: Close issue in 2.4 with no change.
Revised Text:
Actions taken:
February 2, 1999: received issue
September 16, 1999: closed issue

Discussion:

 IDL only allows ASCII characters. strings (and char) may contain characters from the Latin-1 set. The wchar and wstring type can be used for unicode
character and unicode strings. Consequently no change is required in the standards to address the concerns raised in this issue.

Issue 2377: Application Interface issue (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Summary:  During study of the ORBIX software, I analyzed structure of internal stubs generated by IDL compiler on the both client and server side of the CORBA connection. I appreciated, that for creation of the both sides are used the same constructions like Request object, not different objects Request on the client side and ServerRequest on the server side. Naturally, there was also possibility to use CORBA compliant ServerRequest object when requested, but generated stubs used "old" IONA logic. May be, there are some sophisticated reasons why OMG specification use various objects on both client and server sides which I do not know, but in general, I prefer more simple approach of IONA. Please, let application interface as simple as possible.

Resolution: This issue is adequately dealt with in the POA specification.
Revised Text:
Actions taken:
February 2, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2378: Try to define obligatory and optional parts of the CORBA specification. (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Summary:  This comment uses examples from the chapter 3, but its idea concernes style of the all specification, as a general rule.
 6)  In the version CORBA 2.2, there were introduced new features and new simple data type. I understand, that such types like long long and/or long double may be key parts for some application. On the other hand, majority of applications need not such data types, and I see no reason to introduce them as obligatory to all CORBA implementations. For this reason, try to difference various features as obligatory for any CORBA compliant implementation and other ones as optional. 
 In general, it is good idea to specify advanced features of this system to unify various its implementators, but, on the other hand, why those features are made obligatory? For this reason, try to define obligatory and optional parts of the CORBA specification.

Resolution: Close in 2.4 with no change.
Revised Text: Creating multiple conformance points will make the management of conformance problem very difficult and will make interoperability considerably more difficult thus defeating the very purpose and one of the cornerstones of the success of CORBA. The implementation of a particular application may use whatever subset it chooses but the at the interface the entire set of types must be supported.
Actions taken:
February 2, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2432: clarification and bug in InterfaceDef::FullInterfaceDescription (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The text in the interface repository specification that describes FullInterfaceDescription is ambiguous. CORBA v2.3a draft, section 10.5.23.1, page 10-22 reads:

The describe_interface operation returns a FullInterfaceDescription
describing the interface, including its operations and attributes. The
inherited describe operation for an InterfaceDef returns an
InterfaceDescription.

It does not specify whether the elements of the FullInterfaceDescription should describe only items (e.g., operations, attributes) that where defined in the interface being described, or whether they should describe items inherited from base interfaces as well. My naive, assumed rationale is that the full description is intended to improve efficiency. It should allow a dynamic client to obtain all of the information it needs to invoke any operation supported by the interface in a single request, avoiding the need to traverse the graph of base interfaces. If this is the case, then the full description should include inherited items as well, and the spec should say so. I checked our implementation (VisiBroker) and this is what it does.

My suggested remedy is to add the following words to the paragraph cited above:

"The operations and attributes fields of the FullInterfaceDescription structure include descriptions of all of the operations and attributes in the transitive closure of the inheritance graph of the interface being described."

The bug (I think) is that the FullInterfaceDescription description doesn"t include the boolean is_abstract member. The abbreviated InterfaceDescription struct has been extended with this member, and the FullInterfaceDescription should be a superset of the InterfaceDescription.

The suggested fix is to add the the following member to the InterfaceDef::FullInterfaceDescription struct:

boolean is_abstract;

Resolution: Incorporate changes in 2.4 and close issue
Revised Text: Resolution: Clarify that the FullInterfaceDescription structure includes all operations and attributes in the transitive closure of the inheritance graph. The "bug" mentioned above has already been fixed editorially. Revised Text: In section 10.5.23.1, page 10-22, append the following sentence: "The operations and attributes fields of the FullInterfaceDescription structure include descriptions of all of the operations and attributes in the transitive closure of the inheritance graph of the interface being described." to the paragraph that reads: "The describe_interface operation returns a FullInterfaceDescription describing the interface, including its operations and attributes. "
Actions taken:
February 2, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2435: Interceptors broken (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: There seems to be general consensus that the interceptor spec is
 unimplementable fantasy material. Given this, it would seem advisable to
 remove interceptors from the core.
 
 Also, there is some doubt as to whether P&P rules were followed when
 interceptors were added. My understanding is that an RTF cannot add
 new features to a spec, yet interceptors definitely seem to fall into
 that category.
 
 Given that no RFP was ever issues and that the feature is obviously broken,
 I suggest to remove the interceptor section until the outcome of the
 Portable Interceptors RFP can be added.

Resolution: Close in 2.4 with no change.
Revised Text: What is proposed in this issue is well outside the scope of what an RTF can do, i.e. an RTF cannot add new features or remove exisiting ones. It can only fix it, and if the fix requires an extremely substantial change, the fix has to be done using an RFP. Since there already is an RFP out to fix the chapter in question, it would seem inappropriate for an RTF to step in and usurp what another TF is already trying to do properly..
Actions taken:
February 4, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2436: another problem with IDL specification section 3.9.2 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The spec doesn"t say how octal and hex integral constants are treated.
 For instance, is the following line legal IDL or not:
 
   const short s = 0xFFFF;  // Valid???
 
 If the interpretation of "0xFFFF" in this context is "65535", then
 this is illegal, since the value is out of range.  If the interpretation
 is "-32768", then this assignment is valid.  The wording in this section specifies that
 each operand is converted immediately to the size of the eventual
 storage location, but fails to specify *how* that conversion is to be
 performed for hexadecimal and octal literals.

Resolution: closed issue
Revised Text:
Actions taken:
February 4, 1999: received issue
September 16, 1999: closed issue

Discussion:

Resolution: This issue is closely related to issue 1139. It therefore makes sense to subsume this issue into 1139 and thus aid in producing a single consolidated
resolution ot the constant arithmetic related stuff associated with 1139.

Issue 2442: POA Construction Policy. (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: >From what I understand of the POA document is that
 the POA or POAs are process resident, and that the servants they register
 are within their own process space, i.e. the Server.

Resolution:
Revised Text:
Actions taken:
February 5, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2444: Problems in Chapter 5 IDL (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In ptc/98-12-04 Chapter 5, page 5-14, a DataInputStream operation 
 has the signature "long long long read_long()".  It should be 
 "long long read_longlong()"
 
 Also, the spelling of W[Cc]harSeq is inconsistent between its 
 declaration and its usage on pages 5-12 to 5-14.

Resolution: Close no change in 2.4
Revised Text:
Actions taken:
February 9, 1999: received issue
September 16, 1999: closed issue, no action in 2.4

Discussion:

 These errors have been fixed editorially in Rev 2.3a and they will appear in the fixed form in the published 2.3 spec which incorporate the output of the
2.3 and 2.3a RTFs.

Issue 2446: Inheritance of value types (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Summary: There is a need for clarification regarding inheritance
 for value types. Must a value type that inherits from
 abstract bases always inherit from a "concrete"
 value? This seems to be enforced by the IDL
 grammar and the introduction of the ValueBase
 primitive type (as a concrete base in case no
 other concrete base is inherited).
 
 This seems somewhat ambiguous.

Resolution: close this issue with the note that it is resolved as part of 2490 in 2.4
Revised Text:
Actions taken:
February 9, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2447: What value type does ValueDef"s base_value() return? (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Summary: full_desc: What does a ValueDef"s base_value() operation
 return for a value type that does not inherit from
 any concrete value?
 
 I see two possible resolutions: (1) make base_value()
 return ValueDef::_nil() in this case, or (2) add a
 pk_ValueBase primitive type to PrimitiveDef and
 return that.

Resolution:
Revised Text:
Actions taken:
February 9, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2450: IR Changes in 2.3 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Jishnu has pointed out (very pointedly i might add :-) that a whole slew of 
   upwardly incompatible changes have been made to the IR.
 
   E.g. old structs that have been modified (e.g. full interface description), 
   new structs have been added, operations added to container, changed
   tckind, etc., etc.
 
   The question before us is how, if at all, to reflect this change.
 
   We came up with several options (listed in no particular order and
   with no particular recommendation.)
 
   1. Do nothing. This is the traditional approach but probably becoming
      less and less appropriate as we mature :-)
 
   2. Add a #pragma version name_of versioned_thingy major.minor 
      for every definition. (Jishnu thinks that in
      principle all the #pragma version statements could go in one place,
      say at the end of the CORBA module. [We leave it as exercise to the
      reader to work out why they have to go at the end] )
 
   3. Change the name of the enclosing module. say CORBA -> CORBA_2_3, gulp!!

Resolution: incorporate changes in 2.4 and close issue.
Revised Text: Tag all remotely accessible IR Contained's (those things that have a version attribute) in the IR specifications that have changed with the version tag 2.3. This includes not only those that have been modified themselves but in addition all those that pass any that have been modified as parameters or return values, and in general those that contain things that have changed, which pretty much boils down to all interfaces and many structs, and many enums. Also to keep things easy to remember, all new stuff that has been added in 2.3 is tagged with 2.3. These version tags enable those implementations that want to provide this information in their IR, to do so, while not forcing those that would rather not into doing so. Additionally, to maintain the sanctity of module version, it is required that whenever the content of a module is changed its version tag must be changed, which implies that once a particular version of the CORBA module is published with a specific version tag - 2.3 in this case, any changes that are proposed to the CORBA module would require the change of the version tag. The revised text keeps the actual choice of version number open for resolution by the marketing/publishing department of OMG. It however requires that a version number be assigned as directed before the standard is published. Revised Text: In the following the string <x.y> represents the version number of the published standard. The editor should replace this with the version number of the published standard. For example if the published standard is 2.3 then <x.y> should be replaced by 2.3 before publication. On the other hand if it happens to be 2.4 then <x.y> should be replaced by 2.4. (1) In section 3.14 append the following paragraph: "The version of CORBA specified in this release of the specification is version <x.y>, and this is reflected in the IDL for the CORBA module by including the following pragma version (ref pragma version): #pragma version CORBA <x.y> as the first line immediately following the very first CORBA module introduction line, which in effect associates that version number with the CORBA entry in the IR. The version number in that version pragma line must be changed whenever any changes are made to any remotely accessible parts of the CORBA module in an officially relaeased OMG standard." (2) In the IDL in section 10.8 insert a line of the form: #pragma version <name> <x.y> immediately following the line in which the <name> appears in the full declaration of the <name>. for the following module, struct, enum, union, interface, valuetype: DefinitionKind IRObject Container Contained Initializer IDLType Repository All *Def All *Description except ExceptionDescription Value* TCKind Note that in case of modules that are opened multiple times, the version pragma must appear only once, immediately following the first module declaration line for such modules.
Actions taken:
February 12, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2454: Inconsistent spellings of "policy" related identifiers: (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Summary:  I have found inconsistent spellings of "policy" related identifiers:
 
  "DomainManagersList" is used on pages 4-4 and 4-8
 
  "DomainManagerList" is used on pages 4-17,20-87,20-88,20-110
 
 Also, the operation identifer
 
  "set_policy_override" is used on pages 20-87, 20-88, 20-110
 
 However, this same operation identifier is consistently spelled as
 
  "set_policy_overrides" on pages 15-52,15-61,15-65,15-66,15-103,
 	15-104,15-105,15-106,15-108,15-109,15-111,15-199,15-218,
 	and 15-219
 
 in 98-12-03.pdf (Security Service Specification - Security Service
 	 v1.5 15 December 1998 [FINAL]
 
 So what is the "correct" spelling of these identifiers?

Resolution: Close no change in 2.4
Revised Text: DomainManagerList is correct, and all occurences of DomainManagersList in Chapter 4 is changed to DomainManagerList before publishing. Necessary changes will be made in the Security spec as required too before Security 1.5 is published. set_policy_overrides is correct. The latest version of C++ mapping reflects this in ptc/98-09-03. It should also be pointed out that set_policy_overrides pertains to an operation of the Object interface the mappings of which to individual languages munge names anyway. While it is desirable that the mappings do not munge the names in arbitrary ways, an error slipping in is not a show-stopping disaster, and it can be fixed in the next round of revision.
Actions taken:
February 17, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2456: CORBA::Object::ping ? (orb_revision)

Click here for this issue's archive.
Nature: Enhancement
Severity:
Summary:

Summary: I"d like to float the idea of adding a ping operation to CORBA::Object:
 
 	module CORBA {
 		interface Object {
 			void ping();
 			// ...
 		};
 		// ...
 	};
 
 The reason for suggesting this is that developers have a frequent need
 for this functionality. (How to determine object reachability (as opposed
 to object existence) is a FAQ).

Resolution:
Revised Text:
Actions taken:
February 18, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2487: Inconsistent Definition of Flags type (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In Section 4.3 of V2.3a specification, the typedef of Flags is "long". In
 Section 7.1.1, it is "unsigned long".

Resolution: Make it uniformly unsigned long
Revised Text: In the IDL on page 4-9 replace the line: typedef long Flags; by the line typedef unsigned long Flags
Actions taken:
February 24, 1999: received issue
June 4, 1999: closed issue

Discussion:

Issue 2490: What use is CORBA::exception_type? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: This enumeration type is defined in 3.17.1, but used no where else.  Why
 is it even there?

Resolution: incorporate changes in 2.4 and close issue.
Revised Text: Fix the grammar problems as shown below and also remove the possibility of deriving anything explicitly from ValueBase keeping in line with the way in which Object is handled. Revised Text: In section 3.4, replace productions 19 and 20 by: (19) <value_inheritance_spec> ::= [":" ["truncatable"] <value_name> {"," <value_name>}*] ["supports" <interface_name> {"," <interface_name>}*] (20) value_name> ::= <scoped name> Delete production 21. Replace section 3.8.1.3 by the following: 3.8.1.3 Value Inheritance Specification <value_inheritance_spec> ::= [":" ["truncatable"] <value_name> {"," <value_name>}*] ["supports" <interface_name> {"," <interface_name>}*] <value_name> ::= <scoped name> Each <value_name> and <interface_name> in a <value_inheritance_spec> must denote a previously defined value type or interface. See ?Valuetype Inheritance? on page 3-27 for the description of value type inheritance. The truncatable modifier may not be used if the value type being defined is a custom value.
Actions taken:
February 25, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2492: Error in IRObject definition in 98-12-04 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The definition of IRObject in 10.5.2 somehow got an additional attribute
 that makes no sense:  "readonly attribute InterfaceName type_name". 
 This is probably an editorial mistake.

Resolution: They have been fixed in ptc/98-12-04.
Revised Text:
Actions taken:
February 26, 1999: received issue
June 4, 1999: closed issue

Discussion:

Issue 2502: Need to specify exception for abstract interface error (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: An abstract interface type in an operation signature indicates that
 at runtime the value passed will either be an object reference or a
 valuetype.  However, it is possible for user code invoking this
 operation to supply (incorrectly) a runtime programming language object
 that is neither of these.  For example, an IDL abstract interface type
 maps into a Java interface, and the object passed at runtime could be
 any Java type that implements this interface.
 
 The spec does not currently define an exception to be used in this
 error case.  The Java to IDL mapping needs a defined exception so that
 it can detect this error and return a NotSerializableException to the
 application.

Resolution: Add a new minor code to the BAD_PARAM system exception:
Revised Text: Add a new minor code to the BAD_PARAM system exception table 3-13 on page 3-58: 6 Incorrect type for abstract interface
Actions taken:
March 3, 1999: received issue
March 8, 1999: moved from java2idl-rtf to orb_revision
September 16, 1999: closed issue

Discussion:

Issue 2507: Scope of SendingContextRunTime service context (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: It is not clear what is the scope of the SendingContextRunTime service
 context defined in section 13.6.7.
 
 Since the content of this service context will remain constant through
 the lifetime of a connection, it needs to be sent only once per
 connection.  This is much more efficient than requiring it to be sent
 on a per-request basis.
 
 This seems to parallel the current usage of the CodeSets service context.
 Section 13.7.2.6 says:
  Code set negotiation is not performed on a per-request basis, but only
  when a client initially connects to a server. All text data communicated
  on a connection are encoded as defined by the TCSs selected when the 
  connection is established.

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
March 3, 1999: received issue
March 4, 1999: moved from orb_revision to interop
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Discussion:

Issue 2508: omg.org prefix not well specified (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The core spec says in section 10.6.7 that:
 
 Unless pragma directives establishing RepositoryIds for all definitions
 are present in an IDL definition officially published by the OMG, the
 following directive is implicitly present at file scope preceding all 
 such definitions: 
  #pragma prefix �omg.org�
 
 What does an IDL compiler need to do to be compliant with this?  How
 is it supposed to recognize IDL definitions officially published by the
 OMG so that it can insert the required implicit pragma?

Resolution: Incorporate change in 2.4 and close issue
Revised Text: The sentence quoted is asking for the impossible, since as Simon has pointed out it is impossible for anyone to figure this info out of thin air. So it should be removed. The current policy is that each OMG standard IDL file must contain the pragma prefix "omg.org", unless the file is included in standard by reference to another standard from a different standards organization like the W3C, in which case there must be a pragma prefix identifying the source standards organization. Revised Text: In section 10.6.7. replace the following text:: "Unless pragma directives establishing RepositoryIds for all definitions are present in an IDL definition officially published by the OMG, the following directive is implicitly present at file scope preceding all such definitions: #pragma prefix �omg.org� For example, if an existing official specification included the IDL fragment: module CORBA { // non-normative example IDL interface Nothing { void do_nothing(); }; }; the RepositoryId of the interface would be �IDL:omg.org/CORBA/Nothing:1.0�. " by: "All official OMG IDL files shall contain a pragma prefix directive: #pragma prefix "omg.org" unless said file already contains a pragma prefix identifying the original source of the file (e.g "w3c.org")."
Actions taken:
March 3, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2509: Can an any with a tk_null or tk_void TypeCode be encoded with CDR? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The spec is silent about whether an any with a TypeCode of tk_null or
 tk_void can be marshalled and unmarshalled with CDR.

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
March 3, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Discussion:

Issue 2511: POA that has IdAssignmentPolicy=SYSTEM--portability problem (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: For a POA that has IdAssignmentPolicy=SYSTEM, there is a portability
 problem in the combination of the POA generation of an ObjectId and
 the language functions that convert between ObjectId and string.
 
 The C++ functions PortableServer::ObjectId_to_string (and wstring)
 state that
 
    If conversion of an ObjectId to a string would
    result in illegal characters in the string (such
    as a NUL), the [...] functions throw the
    CORBA::BAD_PARAM exception.
 
 This apparently assumes that the conversion does nothing but take the
 sequence of octet and recast it as a char*. Thus, an embedded null
 would cause the string to be interpreted as shorter than the sequence,
 so it"s an error.

Resolution: Close no change in 2.4
Revised Text: Let people write non-portable code and have redundant conversion routines. Recommend to the language mapping RTFs that the individual language RTFs that have null-octet restrictions for CORBA::ObjectId_to_string (and cousins) should add a warning. The warning should state that the use of these functions is intended only for converting from original, user-specified strings to ObjectId and back, not the reverse
Actions taken:
March 4, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2513: POA issue, section 11.3.8.10 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 11.3.8.10 of the Core draft 2.3a says that the application is
 free to assign its own servant manager to the root POA, but the next
 section says that the
 set_servant_manager() operation requires that the POA in question must
 support the request  processing policy of USE_SERVANT_MANAGER. But as
 the root
 POA has a req. proc. policy of USE_ACTIVE_OBJECT_MAP_ONLY, surely the
 user CANNOT assign a servant manager to the root POA.
 
 The text is a mistake, isn"t it? The application cannot "assign its own
 servant manager to the root POA". Unless there is some subtlety to the
 meaning of the word "assign" which make it different from "set". I
 thought the root POA was something the user could not tamper with in any
 way.

Resolution:
Revised Text:
Actions taken:
March 5, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2521: LocateReply body alignment issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Hi folks, I know this is a bit late but I  was going through some GIOP
 1.2 issues  with  Bob  and   I only  just  noticed  another   required
 clarification for LocateReply messages. Bascially the text added under
 Request/Reply which states "In  GIOP 1.2, the Request[/Reply]  Body is
 always aligned on   an 8 octet boundary"   was not also  added  to the
 description for LocateReply"s (15.4.2.2).   I presume  the requirement
 was intended for the body data of all message types. If so, perhaps it
 would make sense to move this  text to the  start of 15.4 and reworded
 to indicate the requirement for all message body data in general.
 
 If the LocateReply body  alignment issue will not  be clarified in the
 GIOP 1.2  specification then I  wish to  submit this as  a new interop
 issue.

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
March 8, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Discussion:

Issue 2522: forward declaration in ptc/98-10-04 (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Summary:   Pages 3-18 and 3-19 of the CORBA 2.3a spec state that a forward declaration consists of the following:
      [abstract] "interface" <identifier>
     I believe that this should be:
      [abstract] "interface" <scoped_name>
 
     Otherwise, the following would be illegal:
     module A
      {
        interface B::d;  //forward decl of d
        interface c
         {
            B::d f();
          };
       };
    module B
      {
         interface d
          {
             A::c f();
           };
       };

Resolution: Close no change in 2.4
Revised Text: This has already been recognized as illegal and we wanted it to stay that way. You can rewrite the code like this: module B { interface d; }; module A { interface c { B::d f(); }; }; module B { interface d { A::c f(); }; };
Actions taken:
March 9, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2529: RMI style repository ID hash code (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: There is a problem with the currently defined algorithm for computing
 the hash code component of the RMI Hashed Format repository ID as 
 defined in section 10.6.2.  Because it is based only on the structural
 information in the most derived Java class and does not take into 
 acoount any superclass information, it can give a "false positive"
 result when the state of a superclass changes but the state of the
 most derived class does not.
 
 This is a core RTF issue since the affected text is in chapter 10.

Resolution: Replace the currently defined algorithm with one that fixes the problem as described below
Revised Text: In section 10.6.2, replace the paragraph starting "The hash code is" by the following text: For classes that do not implement java.io.Serializable, and for interfaces, the hash code is always zero, and the RepositoryID does not contain a serial version UID. For classes that implement java.io.Externalizable, the hash code is always the 64-bit value 1. For classes that implement java.io.Serializable but not java.io.Externalizable, the hash code is a 64-bit hash of a stream of bytes. An instance of java.lang.DataOutputStream is used to convert primitive data types to a sequence of bytes. The sequence of items in the stream is as follows: 1. The hash code of the superclass, written as a 64-bit long. 2. The value 1 if the class has no writeObject method, or the value 2 if the class has a writeObject method, written as a 32-bit integer. 3. For each field of the class that is mapped to IDL, sorted lexicographically by Java field name, in increasing order: a. Java field name, in UTF encoding b. field descriptor, as defined by the Java Virtual Machine Specification, in UTF encoding The National Institute of Standards and Technology (NIST) Secure Hash Algorithm (SHA-1) is executed on the stream of bytes produced by DataOutputStream, producing a 20 byte array of values, sha[0..19]. The hash code is assembled from the first 8 bytes of this array as follows: long hash = 0; for (int i = 0; i < Math.min(8, sha.length); i++) { hash += (long)(sha[i] & 255) << (i * 8); }
Actions taken:
March 12, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2539: Incorrect IDL is section 5.5.3 (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: The IDL in section 5.5.3 is incorrect.  It refers to 
   CORBA::FullValueDescription
 but the correct name for this type according to chapter 10 is
   CORBA::ValueDef::FullValueDescription
 
 Proposed Resolution:
 
 Change chapter 5 to match up with chapter 10.

Resolution: make it so.
Revised Text: On page 5-15 and 5-16 replace occurences of CORBA::FullValueDescription by: CORBA::ValueDef::FullValueDescription
Actions taken:
March 15, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2543: confusing rules for operations on Object (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 4.3 of ptc/98-10-05 documents Object Reference Operations. These
 are described as "not operations in the normal sense, in that they are
 implemented directly by the ORB, not passed on to the object
 implementation".
 
 This includes a variety of operations, requiring varying contexts to be
 used successfully: 
 - Some require remote communication to the orb of the server
   or (contrary to the quote above) may actually be passed on
   to the object implementation, or something similar like a
   servant manager (e.g. is_a, non_existent)
 - some may require remote communication to an interface repository
   (e.g. get_interface)
 - some require the local orb to be operational
   (e.g. create_request)
 - some can function even without a local orb
   (e.g. is_nil, duplicate, release)

Resolution:
Revised Text:
Actions taken:
March 16, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2547: DynAny.insert_valuetype shoud be insert_val (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The IDL in section 9.2 of ptc/98-12-04 is incorrect.  The OBV RTF adopted
 method names insert_val and get_val instead of the original insert_value
 and get_value which conflicted with the get_value method in the DynFixed
 subclass.  The IDL incorectly shows these methods as insert_valuetype
 and get_valuetype.
 
 Proposed Resolution:
 
 Change insert_valuetype to insert_val and get_valuetype to get_val.

Resolution: fix the names in section 9.2
Revised Text: Do a global replace of all occurences of get_valuetype by get_val and insert_valuetype by insert_val in section 9.2
Actions taken:
March 16, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2548: Repository ID for Object (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Latest 2.3, draft (98-10-10), page 13-17:
 
 	"A Null TypeID is the only mechanism that can be used to represent
 	 the type CORBA::Object."
 
 I am aware of more than one ORB that uses "IDL:omg.org/CORBA/Object:1.0".
 
 I don"t understand why:
 
 	- a null ID should mean Object
 
 	- why a perfectly good repository ID for Object should be disallowed
 
 Related to this is the fact that we made repository IDs mandatory in
 reference TypeCodes with the 2.3 revision. Unless an implementation is
 very careful, this could mean that, if it gets a reference that doesn"t
 have the repository ID, it could present an illegal TypeCode (with an
 empty ID) for that reference to the application.

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
March 17, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Discussion:

Issue 2549: activate_object_with_id and exceptions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: If I use activate_object_with_id and the object ID is already in the AOM,
 the operation raises ObjectAlreadyActive.
 
 If I use activate_object_with_id and the servant is already in the AOM, and
 the POA has UNIQUE_ID, the operation raises ServantAlreadyActive.
 
 What happens if I have UNIQUE_ID, and I run the following code?
 
 	poa->activate_object_with_id(my_id, my_servant);
 	poa->activate_object_with_id(my_id, my_servant);	// ???
 
 Which exception is raised on the second call, ObjectAlreadyActive or
 ServantAlreadyActive?

Resolution:
Revised Text:
Actions taken:
March 18, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2553: ORB::shutdown again (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: I"m sorry to reopen this can of worms, but I believe that the shutdown()
 issue we voted on (1665) still only offers a partial solution. The problem
 appears to be that terminating the event loop and ORB destruction must be
 separate steps.
 
 Consider a very simple application that uses RETAIN, NO_IMPLICIT_ACTIVATION,
 and USER_ID. No servant manager is used.

Resolution: This issue should be closed no change.
Revised Text:
Actions taken:
March 23, 1999: received issue
February 27, 2001: closed issue

Discussion:

This issue should be closed no change. 

The best way to deal with the destruction of POAs issue 
is to arrange the POAs into a hierarchy such that POAs that depend 
on other POAs are destroyed first, followed by those POAs that don't depend 
on other POAs. The semantics of POA::destroy() are already sufficient 
to achieve this. 

In addition, by using reference-counted servants, the issue goes away too 
because one can then rely on the POA to take care of removing servants from the 
AOM, so one doesn't have to call deactivate_object() in the destructor.

Issue 2559: deactivate_object asymmetry (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In the POA, we have
 
 	ObjectId activate_object(in Servant s) raises(...);
 	void activate_object_with_id(in ObjectId id, in Servant s) raises(...);
 
 However, for deactivation, we have only one function:
 
 	void deactivate_object(in ObjectId id) raises(...);
 
 This lacks symmetry. If I can use implicit activation of a servant,
 why can"t I use implicit deactivation? For symmetry, I would have expected:
 
 	void deactivate_object() raises(...);
 	void deactivate_object_with_id(in ObjectId id) raises(...);

Resolution:
Revised Text:
Actions taken:
March 29, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2574: Clarification on IdUniquenessPolicy (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity:
Summary:

Summary: The description of IdUniquenessPolicy in section 11.3.7.3 fails to
 mention how this policy interacts with the ServantRetentionPolicy.
 
 My interpretation is that the IdUniquenessPolicy is irrelevant when the
 ServantRetentionPolicy is NON_RETAIN. If this is the case it should be
 explicitly stated. Alternatively, one specific value might be required
 when NON_RETAIN is in effect. (If so, it ought to be MULTIPLE_ID.)
 
 Without some statement clarifying this there could be portability
 problems with some orbs allowing either value while others require a
 particular value.

Resolution:
Revised Text:
Actions taken:
March 31, 1999: received issue
March 31, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2576: UNIQUE_ID and ServantActivator issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: What should happen if the servant returned from a
 ServantActivator::incarnate call is already registered for another
 object id, and the POA has the UNIQUE_ID policy?  
 
 Since this is clearly an error, I suggest raising the OBJ_ADAPTER
 exception (which will be returned to the client whose request prompted
 the call to incarnate).  I also suggest requiring the POA to call
 ServantActivator::etherealize for that object id.  The latter is
 necessary to allow the application to dispose of any resources
 associated with that object, and to ensure that an application will
 never recieve two calls to ServantActivator::incarnate for a particular
 object id without an intervening call to ServantActivator::etherealize.

Resolution: Incorporate change and close issue
Revised Text: Add the following sentence to the second-last paragraph of section 11.3.5.1 on page 11-24 (preceding the note): In this case, etherealize is not called by the POA because the servant was never added to the Active Object Map.
Actions taken:
April 2, 1999: received issue
October 6, 2000: closed issue

Discussion:

Based on the log, it seems that the behavior of raising OBJ_ADAPTER is 
already specified. 

Regarding the idea of calling etherealize, the are some possible 
benefits, but they are dubious for a servant locator that has already 
proven itself to be broken. Consequently, we should clarify that 
etherialize is not invoked in this case.

Issue 2577: sharing valuetypes across Anys (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Should valuetype identity be preserved across arguments when those
 valuetypes reside within Anys?

Resolution:
Revised Text:
Actions taken:
April 5, 1999: receive dissue
October 30, 2000: closed issue

Discussion:

 receive dissue

Issue 2579: is_abstract parameter missing from create_interface() IDL (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: I noticed the IDL for Container in ptc/98-12-04, page 10-59 is missing
 is_abstract parameter in create_interface() operation.
 The instance on page 10-16 does include it.

Resolution:
Revised Text:
Actions taken:
April 8, 1999: received issue
April 8, 1999: closed issue

Discussion:

Issue 2615: The insert_dyn_any and get_dyn_any operations are barely documented (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 1) The insert_dyn_any and get_dyn_any operations are barely documented. It
 seems the only explanation is given on 9-15: "The get_dyn_any and
 insert_dyn_any operations are provided to deal with any values that contain
 another any." The insert_dyn_any function should be specified as behaving
 identically to insert_any, except that it allows an any in the form of a
 DynAny to be inserted. The get_dyn_any should be specified as behaving
 identically to get_any, except that it returns its result in the form of a
 DynAny rather than an any.

Resolution: "The get_dyn_any and
Revised Text:
Actions taken:
April 20, 1999: received issue
April 20, 1999: received issue
April 26, 1999: moved to Core RTF from C++ RTF

Discussion:

Issue 2616: DynAny::equal operator issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The DynAny::equal operator does not mention how to compare object
 references or TypeCodes. It should be specified to require is_equivalent()
 to be called for object reference comparison and equivalent() to be called
 for TypeCode comparison.

Resolution:
Revised Text:
Actions taken:
April 20, 1999: received issue
April 26, 1999: moved from C++ to Core RTF
October 30, 2000: closed issue

Discussion:

Issue 2617: DynFactory or DynAnyFactory? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Page 9-10 of the new DynAny draft says that you pass "DynFactory" to
 resolve_initial_references() to get a DynAnyFactory. The third comment on
 page 9-2, however, says the string should be "DynAnyFactory". I believe the
 latter is correct.

Resolution:
Revised Text:
Actions taken:
April 20, 1999: received issue
April 26, 1999: closed issue, fixed

Discussion:

 fixed, issue is closed

Issue 2674: New "opaque" data type (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary:  I propose the addition of the new basic data type "opaque."
 
  Many applications require the sending or retrieving of opaque data,
 like graphical data or file contents. Currently, such data is packaged
 as sequence<octet>.
  In the past, the performance of passing sequence<octet> parameters
 was not satisfactory because of the generic mapping of sequences. In
 the recent C++ mapping, the dubious get_buffer() is introduced for
 the mapping of sequences.
  I feel that this matter is best resolved by adding a new data type
 which can then be mapped efficiently into target languages without
 the side effect of complicating the mapping of other sequences.
  After all, a "string," too, is nothing but a sequence of char.

Resolution:
Revised Text:
Actions taken:
May 30, 1999: received issue
December 16, 1999: ransferred from C++ RTF to Core RTF
October 30, 2000: closed issue

Discussion:

Issue 2791: Expected behavior of POA configured with ServantLocator receiving LocateRe (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Add a subsection to section 11.3.6 specifying "_locate" and its usage.
Revised Text: 1) New section 11.3.6.3 titled "ServantLocator and Location Determination" contain the following text: "Under certain circumstances, an ORB may need to determine the actual location of an object's implementation. For objects that are managed by a POA that is configured with a ServantLocator, it may invoke preinvoke and postinvoke or it may determine the object's location by some other means. If it invokes preinvoke and postinvoke under these circumstances it shall use the argument "_locate". " 2) New section 15.4.6.3 titled "Handling ForwardRequest exception from ServantLocator" containing the following text: "If the ServantLocator in a POA raises a ForwardRequest exception the ORB shall send a LocateReply message to the client with locate_status set to OBJECT_FORWARD, and with the body containing the object reference from the ForwardRequest exception's forward_reference field."
Actions taken:
July 8, 1999: received issue
July 16, 1999: moved from Java RTF to Core RTF
October 6, 2000: Incorporate core change and forward to interop RTF recommendi

Discussion:

Issue 2796: The syntax for stringified IORs in section 13.6.6 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Hewlett-Packard EIAL
Summary:

Summary: The syntax for stringified IORs in section 13.6.6 shows: =
 "IOR:" The problem is that URL scheme names are supposed to be case
 insensitive. So, "Ior:"
 or "ioR:" should be allowed to. I would suggest to add a footnote to
 state that case for the scheme name is ignored.

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
July 9, 1999: received issue
August 11, 1999: moved from Core RTF to Interop
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Discussion:

Issue 2817: Null Value semantics under specified (orb_revision)

Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature:
Severity:
Summary:

he description of null value semantics (in ptc/99-03-07) is insufficient to ensure an adequate mapping to an
implementation language. Issues that should be specified include: - Creation. How are null values created? Are all declared (but
uninitialized) values born null? Is this a language mapping requirement or allowance? - Invocation. Presumably invoking an
operation ON a null value should result in an exception. But, what exception? Shouldn't the exception be specified for application
portability? - Passing. Presumably, it is allowable to provide a null value as the actual parameter for a non member operation (i.e.,
not on itself). True? - Typing: are null values typed, untyped, or is this governed by the language mapping? - Substitutability (see
"typing" above): -- Presumably: a null value may be successfully widened to a null value of an ancestor stateful value type. True?
-- Can a null value be successfully widened to a (null) supporting concrete interface? (Can a null value be activated as a servant?)
-- Can a null value be successfully widened to a (null) supporting abstract interface? -- Can a null value be successfully widened
to a (null) ancestor abstract value type? The only mentions of null values currently are: - the bullet in 5.2 - 5.2.4.2

Resolution: close issue, no change
Revised Text:
Actions taken:
July 21, 1999: received issue
May 4, 2000: closed issue

Discussion:

1. Creation. How are null values created? Are all declared (but 
uninitialized) values born null? Is this a language mapping 
requirement or allowance? 

The DynAny aspect of this is being addressed in DynValue issue. 
The rest is a language mapping issue, and needs to be dealt with in each 
language mapping. 

2. Invocation. Presumably invoking an operation ON a null  value should 
result in an exception. But, what exception? Shouldn't the exception 
be specified for application portability? 

Yes, but the exception is language mapping specific, and hence 
should be specified for each language mapping, and not in the Core. 

3. Passing. Presumably, it is allowable to provide a null  value as the 
actual parameter for a non member operation (i.e., not on itself). True? 

True. 

4. Typing: are null values typed, untyped, or is this governed by the 
language mapping? 

The wire format for a null value contains no type information. 
 So technically I think that null values are untyped. That is about 
all that can be said by the core or interop. 

 In a language mapping that supports static typing, the variable that 
 contains a null value may be typed, and in this case the value may be 
 considered to have that type. But that is actually a property of the 
 variable and not the value. 

5. Substitutability (see "typing" above): 
    -- Presumably: a null value may be successfully widened to a null 
value of an ancestor stateful value type. True? 
   -- Can a null value be successfully widened to a (null) supporting 
concrete interface? (Can a null value be activated as a servant?) 
   -- Can a null value be successfully widened to a (null) supporting 
abstract interface? 
   -- Can a null value be successfully widened to a (null) ancestor 
abstract value type? 

These are entirely language mapping issues.

Issue 2819: interop issue: what system exceptions may be raised on GIOP 1.0? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: An issue we"ve run across is enumerating the set of system exceptions
 that are valid to be passed via GIOP 1.0 (and similarly for 1.1, and
 1.2).  This is important for implementations of GIOP, which are, for
 instance, attempting to map wire exceptions to C++ exceptions, and is
 also important for packet-sniffing implementations.
 
 Since many conforming GIOP 1.0 implementations were built (and bought)
 and incorporated into products before various CORBA system exceptions
 were added to the Core, it seems that servers should not raise `newer"
 exceptions back to older clients -- that is, clients speaking GIOP 1.0. 
 Instead, they should map those `newer" exceptions to UNKNOWN, I"d guess.

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
July 21, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Discussion:

Issue 2822: mixing giop versions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The spec is currently unclear on when and how messages with different
 giop versions may share a single connection.
 
 This has already been discussed, with different RTF members holding
 positions running the range from: "all messages on a connection must
 have the same giop version" to "messages with differing giop versions
 must be permitted on the same connection". So clearly there is an issue.
 
 The resolution of this issue should address at least the following
 unclear points:
 
 1) suppose a client orb supporting giop 1.2 initiates an invocation on
 an IOR with iiop version 1.1. As a result, it establishes a new
 connection and sends the request using giop 1.1. Later, the same client
 obtains another IOR referencing the same transport address, but
 specifying iiop version 1.0.
 
 - may the same connection be used to send a request to the new IOR?
 - if so, what giop version should be used to send the request?
 
 2) Later, the same client obtains another IOR referencing the same
 transport address, but specifying iiop version 1.2.
 
 - may the same connection be used to send a request to the new IOR?
 - if so, what giop version should be used to send the request
 - if so, what giop version should be used to send subsequent requests
   to the IORs mentioned in (1).
 
 3) Imagine a day in the not too distant future, when giop 1.3 has been
 approved and implemented. A client that supports giop 1.3 obtains an IOR
 with iiop version 1.2, establishes a new connection, and then sends a
 request using giop 1.2. A service context offering bidirectional giop is
 sent with this request, and accepted by the server. The client provides
 the server (that supports giop 1.3) with a callback IOR that has iiop
 version 1.3, and the server attempts to call back on it.
 
 - may the callback use the incoming connection?
 - if so, what giop version should the request use?
 - if so using v1.2, what if the callback request requires a feature
   only available in giop 1.3?

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
July 26, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue'

Discussion:

Issue 2828: (orb_revision)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution: resolved in interop RTF
Revised Text:
Actions taken:
August 2, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Discussion:

Issue 2843: Changebars missing from POA chapter (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution:
Revised Text:
Actions taken:
August 15, 1999: received issue

Discussion:

 change in PortableServer::POA::set_servant_manager()

Issue 2844: OBV interface support inconsistencies (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: CORBA 2.3 chapter 3.8.5 (docs/formal/99-07-07.pdf, p. 3-27) claims that
 a stateful value can only support a single interface.
 
 CORBA 2.3 chapter 5.2 (docs/formal/99-07-09.pdf, p. 5-2) claims that
 a concrete (stateful) value can support multiple interfaces.
 
 The latter is obviously wrong.

Resolution:
Revised Text:
Actions taken:
August 15, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2846: POA: false placement of paragraph (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In CORBA 2.3, chapter 11.3.8.11 (docs/formal/99-07-15.pdf, p. 11-35):
 seems to me as if the paragraph that was added to the description of
 get_servant_manager() is really intended for set_servant_manager().

Resolution:
Revised Text:
Actions taken:
August 15, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2847: ambiguity in wstrings having a Unicode escape sequence (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary:  According to the spec, a wide string may contain one or
  more Unicode escape sequences of the form \uxxxx, where
  the x"s are hex digits. It also says that such an
  escape sequence may not have the value 0, and that
  leading 0s are optional in the hex digits.
  Taking all this into account, how does a parser
  tell the difference between (imaginary parentheses
  inserted to show the writer"s intent)

Resolution:
Revised Text:
Actions taken:
August 13, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2848: chapter 3 and recursion (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: CORBA 2.3, chapter 3, section 3.10.2, page 3-35 says: "Although the IDL
 syntax allows the generation of recursive constructed type specifications,
 the only recursion permitted for constructed types is through the use of
 the sequence template type." With the introduction of valuetypes, this is
 no longer true. A valuetype is allowed to have a member of its own type,
 either directly or indirectly.

Resolution:
Revised Text:
Actions taken:
August 13, 1999: received issue
October 30, 2000: closed sisue

Discussion:

Issue 2849: CORBA 2.3: minor editorial issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 4-5 of CORBA 2.3 the deprecated create_recursive_sequence_tc
 operation is missing its open parenthesis for its parameter list.

Resolution:
Revised Text:
Actions taken:
August 13, 1999: received issue
October 30, 2000: closed issue

Discussion:

 received issue

Issue 2859: Wchar as discriminator in union (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 	Just got a question from our IDL compiler folks - I think they"ve
 found a bug in the 2.3 IDL chapter..... (actually the bug has been there
 for a while)..
 
 Looking at the new CORBA2.3 book,
 
 The syntax for discriminated unions are described on two pages (3-16 and
 3-36). 
 On both pages the <wchar_type> isn"t included in the grammar for
 <switch_type_spec>. Therefore my conclusion was that it shouldn"t be
 allowed. The problem is that further down on page 3-36 there is a table
 for "case label matching" and in that table wchar is listed as a
 discriminator type.
 
 
 
 So, was the wchar type forgotten from the grammar for switch type spec,
 or
 was wchar mistakenly added to the table?

Resolution:
Revised Text:
Actions taken:
August 26, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2861: POA exception minor codes (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: There are several cases in the POA specification where the POA is required to
 raise system exceptions.  We should assign OMG minor exception codes to
 each of these cases so that applications can diagnose these conditions
 better.
 
 Examples:
 
 1.  POA has the USE_DEFAULT_SERVANT policy but no servant is assigned, the
 POA raises OBJ_ADAPTER.
 
 2.  If no adapter activator is available (or the available one refuses to
 create a POA), the OBJECT_NOT_EXIST exception is raised.

Resolution:
Revised Text:
Actions taken:
August 31, 1999: received issue
August 31, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2883: IDL constant declarations (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 12, 1999: received issue

Discussion:

Issue 2892: DataInputStream specification is inefficient for Java (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: This issue is for the Core RTF.  Although it shows up in the context of Java,
 fixing it requires a change to an API defined in the CORBA core. 
 
 The CORBA::DataInputStream type (part of the CORBA core) is specified in
 a way that makes it extremely inefficient to implement in Java.  A small
 change to this IDL definition would reduce the number of Java classes needed
 to implement it from 27 to 1.  (Really!)

Resolution:
Revised Text:
Actions taken:
September 17, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2896: What is the RepId of Object? (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

"Can someone please clue me in as to what the
> repository ID of Object is? Is it "IDL:omg.org/CORBA/Object:1.0"? Or is
> it "IDL:omg.org/Object:1.0"?"

Resolution:
Revised Text:
Actions taken:
October 20, 1999: received issue
October 30, 2000: closed issue

Issue 2898: Why are Standard Exceptions defined in IDL chapter? (orb_revision)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Uncategorized Issue
Severity:
Summary:

I was wondering why the Standard Exception definitions are in Chapter 3 IDL
Syntax and Semantics. Shouldn't they be better in Chapter 4 ORB Interfaces?
I would like to get a feel for how the RTF membership feels about moving the
entire section 3.21 from Chapter 3 to Chapter 4.

Resolution:
Revised Text:
Actions taken:
October 13, 1999: received issue
October 30, 2000: closed issue

Issue 2900: URLs interact poorly with code set selection (orb_revision)

Click here for this issue's archive.
Source: Cisco Systems (Mr. Paul Kyzivat, pkyzivat(at)cisco.com)
Nature: Uncategorized Issue
Severity:
Summary:

The corbaname & corbaloc url formats provide a situation where an IOR
designating a server is created and used by a client without input by
that server.

One (optional) element of an IOR is a CodeSetComponent specifying the
code sets that the server is willing/able to utilize. Normally these are
examined by a client and used to select a pair of code sets (narrow and
wide) to be used for communication between client and server.

Chapter 13 of the Corba spec states: "If the code set component is not
present in a multi-component profile structure, then the deault char
code set is ISO 8859-1 for backward compatibility. However, there is no
default wchar code set. If a server supports interfaces that use wide
character data but does not specify the wchar code sets that it
supports, client-side ORBs will raise exception INV_OBJREF."

This seems to imply one of the following:
1) URLs may not be used to reference interfaces that employ wide
   characters;
2) URLs must generate IORs with a code set component supporting
   wchar data;
3) The CORE must be changed to relax the above restrictio

Resolution:
Revised Text:
Actions taken:
October 5, 1999: received issue
October 30, 2000: closed issue

Issue 2901: Semantics of DynAny with alias TypeCodes (orb_revision)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, crawley(at)dstc.edu.au)
Nature: Uncategorized Issue
Severity:
Summary:

The CORBA 2.3 spec for DynAny makes no mention whatsoever of how it should
handle Any values corresponding to TypeCodes whose kind is tk_alias.  

The implementation of (CORBA 2.2) DynAny in a popular free ORB strips off
typecode aliases when it creates a DynAny.  While this seems to be contrary to
the overall intent of the DynAny spec, I can find nothing in the 2.2 or 2.3 
spec that definitively precludes this (IMO bogus) behaviour.

Resolution:
Revised Text:
Actions taken:
October 14, 1999: received issue
October 30, 2000: closed issue

Issue 2903: Use of incomplete recursive TypeCodes underspecified (orb_revision)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, crawley(at)dstc.edu.au)
Nature: Uncategorized Issue
Severity:
Summary:

Section 10.7.3 of the CORBA 2.3 spec says that operations on recursive
TypeCodes and recursive sequence TypeCodes before they have been embedded
give undefined results.  

However, it is not clear whether this applies to other uses of these
TypeCodes ... or other incomplete TypeCodes or Anys that contain them.  For 
example, can an incomplete TypeCode be used:

  * as a parameter to create_dyn_any_from_type_code,

  * as a parameter to a DII or DSI operation; e.g. the arg_type parameter 
    of CORBA::Request::add_arg(), or

  * as a (CORBA IDL) parameter or result of a regular operation invocation?

Resolution:
Revised Text:
Actions taken:
October 14, 1999: received issue
October 30, 2000: closed issue

Issue 2906: DynFixed editorial issue (orb_revision)

Click here for this issue's archive.
Source: Progress Software (Mr. Steve Vinoski, steve.vinoski(at)iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the CORBA 2.3 spec for DynFixed::set_value (page 9-14) it says, "If val
contains a value whose scale exceeds that of the DynFixed or is not
initialized, the operation raises InvalidValue."

Later in the same paragraph it says, "If val has more fractional digits
than can be represented in the DynFixed, fractional digits are truncated
and the return value is false."

Given that the term "scale" is used with the fixed-point type to describe
the number of fractional digits, these two quoted sentences are confusing
and appear to contradict one another.

I propose changing the first quoted sentence to: "If val contains a value
whose number of digits exceeds the maximum number of digits specified by
the TypeCode of the DynFixed, or if val is not initialized, the operation
raises InvalidValue."

Resolution:
Revised Text:
Actions taken:
September 29, 1999: received issue
October 30, 2000: closed issue

Issue 2907: creation of arguments to TypeCode creation ops (orb_revision)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, crawley(at)dstc.edu.au)
Nature: Uncategorized Issue
Severity:
Summary:

It is not clear from section 10.7.3 of CORBA 2.3 how much param checking
the ORB operations for TypeCode creation should do.  It is also unclear
whether only the BAD_PARAM exception should be raised, or whether some
others are legitimate; e.g. BAD_TYPECODE.

Here are some detailed questions on TypeCode creation argument checking:

  1)  should the operations that take a "name" argument check that it 
      is a valid IDL name?  A non null string?

  2)  should the operations that take a "RepositoryId" argument check
      that it has a recognisable format?  

  3)  should the operations that take content and member types as
      parameters check that they are legitimate; i.e. that they
      don't have kinds tk_null, tk_void or tk_exception.

  4)  should the operations that take members check that the member
      names are valid IDL names and that they are unique within the
      member list?

  5)  should create_union_tc check that there are no duplicate label
      values?  Should it check that the labels' TypeCodes are equal to
      discriminator TypeCode?  Or equivalent?

  6)  should create_union_tc check that the supplied discriminator
      type is legitimate?

There are probably more cases as well.

Resolution:
Revised Text:
Actions taken:
October 14, 1999: received issue
October 30, 2000: closed issue

Issue 2908: CORBA::ORB::RequestSeq definition obsolete (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

CORBA 2.3 added the CORBA::RequestSeq definition to orb.idl.  The C++
mapping defines CORBA::ORB::RequestSeq, which is now redundant and
should be removed.

Resolution:
Revised Text:
Actions taken:
October 12, 1999: received issue
October 30, 2000: closed issue

Issue 2909: formal/99-08-01.txt missing pragmas (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The ORB Core IDL extracted in formal/99-08-01.txt is missing the various
'#pragma' definitions for the IFR interfaces.

Resolution:
Revised Text:
Actions taken:
October 12, 1999: received issue
October 30, 2000: closed issue

Issue 2910: CORBA 2.3 spec hasn't been updated with corrections in COM-CORBA Part B (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

 I notice that the CORBA 2.3 spec hasn't been updated with one of the corrections  in
 part B of the COM-CORBA Interworking spec (orbos/97-09-06).

page 13C-130 of the Part B spec, CORBA::Char mapping to UI1 has not been updated 
in the corresponding section in the CORBA 2.3 spec (19.3.1, page 19-10).

Resolution:
Revised Text:
Actions taken:
October 13, 1999: received issue
October 30, 2000: closed issue

Discussion:

 with one of the corrections  in
 part B of the COM-CORBA Interworking spec (orbos/97-09-06).

Issue 2911: Problem with text of POAManager::deactivate() (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The first paragraph of 11.3.2.6 says:

This operation changes the state of the POA manager to inactive. If
issued while the POA manager is in the inactive state, the
AdapterInactive exception is raised. Entering the inactive state causes
the associated POAs to reject requests that have not begun to be
executed as well as any new requests.

But the last paragraph says:

If deactivate is called multiple times before destruction is complete
(because there are active requests), the etherealize_objects parameter
applies only to the first call of deactivate; subsequent calls with
conflicting etherealize_objects settings will use the value of the
etherealize_objects from the first call. The wait_for_completion
parameter will be handled as defined above for each individual call
(some callers may choose to block, while others may not).

So which is right?  Is does a subsequent call to deactivate() raise
AdapterInactive, or does it succeed, perhaps blocking until completion?

Resolution: Incorporate changes and close issue
Revised Text: Replace the sentence in the first paragraph of 11.3.2.6 that says: "If issued while the POA manager is in the inactive state, the AdapterInactive exception is raised." with: "This operation has no affect on the POA manager's state if it is already in the inactive state, but may still block if wait_for_completion is TRUE and another call to deactivate on the same POA manager is pending."
Actions taken:
October 18, 1999: received issue
February 27, 2001: closed issue

Discussion:

In this case it is best to NOT throw the exception and allow 
multiple concurrent calls to deactivate().  Otherwise, if an 
application 
needs to have this behavior (where different threads might call 
deactivate()), it requires more code to catch the exception and then 
block waiting for the other deactivate call to complete.

Issue 2912: (CORBA Core) Data streams missing arrays of long double (orb_revision)

Click here for this issue's archive.
Source: Oracle (Dr. Dan Frantz, )
Nature: Uncategorized Issue
Severity:
Summary:

DataInputStream and DataOutputStream (CORBA 2.3, Section 5.5.2) has
definitions for reading and writing individual items and arrays of
primitive data types except long double. This seems to be an
oversight.

Resolution:
Revised Text:
Actions taken:
September 22, 1999: received issue
October 30, 2000: closed issue

Issue 2913: Component ids in 13.6.2.2 (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
September 28, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Issue 2944: Editorial issue for CORBA 2.3, 1.3.8.20 (orb_revision)

Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 11.3.8.20 (servant_to_id) was not updated in the same fashion as
section 11.3.8.21.

There are two problems:

1.  The RETAIN policy in the first paragraph needs bold face.

2.  Behaviors 1 & 2 should both require the RETAIN policy, just like the
text in section 11.3.8.21.

Resolution:
Revised Text:
Actions taken:
October 20, 1999: received issue
October 30, 2000: closed issue

Issue 2945: CORBA 2.3 Editorial issue for TypeCodes & abstract_interface (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The comments in the definition of TypeCode in 10.7.1 shows that id() and
name()
are valid for TypeCodes of kind tk_abstract_interface, but the text
descriptions of the id() and name() operations do not list abstract
interface TypeCodes as supporting these operations.

Resolution:
Revised Text:
Actions taken:
October 21, 1999: received issue
October 30, 2000: closed issue

Issue 2954: Exception section issue (orb_revision)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Uncategorized Issue
Severity:
Summary:

I was wondering why the Standard Exception definitions are in Chapter 3 IDL
Syntax and Semantics. Shouldn't they be better in Chapter 4 ORB Interfaces? I would like to get a feel for how the RTF membership feels about moving the
entire section 3.21 from Chapter 3 to Chapter 4.

Resolution:
Revised Text:
Actions taken:
October 14, 1999: received issue
October 30, 2000: closed issue

Issue 2955: General Exception Question (orb_revision)

Click here for this issue's archive.
Source: International Business Machines (Mr. Russell Butek, )
Nature: Uncategorized Issue
Severity:
Summary:

Could someone explain to me the justification for all the restrictions on
> exceptions?  Why CAN'T we:  pass exceptions as parameters, use them as
> elements in container types?  I know the IDL language doesn't allow it, I
> just want to know why it was designed that way.  Other languages certainly
> allow it.

Resolution:
Revised Text:
Actions taken:
October 26, 1999: received issue
October 30, 2000: closed issue

Issue 2959: Minor codes for Standard System Exceptions in Chapter 5 missing (orb_revision)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
October 26, 1999: received issue
October 30, 2000: closed issue

Issue 2960: Minor codes for Standard System Exceptions in Chapter 8 missing (orb_revision)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
October 26, 1999: received issue
October 30, 2000: closed issue

Issue 2963: Type Code Section issue (orb_revision)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Uncategorized Issue
Severity:
Summary:

I was wondering why the TypCodes definition section is in Chapter 10, Interface
Repository. Type Codes are used by lots of other things that have very little to
do with Interface Repository. Wouldn't it be better to move the TypeCode section
to Chapter 4.

Resolution:
Revised Text: Resolution: Move the TypeCode section from Chapter 10 to Chapter 4 and readjust section numbers in both chapters and update all cross references. Revised Text: All changes with reference to orbrev/01-03-01: 1. Move section 10.7 to become section 4.11. Slide section 4.11 "Exceptions" to become section 4.12, and old section 10.8 to become new section 10.7. 2. Remove the TypeCode related IDL from section 10.8 starting at about middle of page 10-73 and ending at the end of the section. This is already there in section 10.7 that is moved to Chapter 4. 3. Update all affected cross references appropriately.
Actions taken:
October 27, 1999: received issue
November 5, 1999: moved from core to components ftf
May 19, 2001: moved from components ftf back to core
October 3, 2001: closed issue

Issue 2974: PIDL vs Local (orb_revision)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Regarding using a version in a repository ID:

If old PIDL were to be recast to local, each time the
interface def would be enhanced (by adding new local
operations), the IDL module would have to be appropriately
versioned.

I also point out that using a version for corba::object's repository
id seems inappropriate, since there are multiple version of
corba::object which the omg never bothered to version, since they
did not have to.  

Thus, in summary, putting version 1.0 to correspond to a pidl interface
implies stability in that inteface (i.e., it will not change without
changing
the version number), which the OMG has never enforced for PIDL.

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
October 25, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Issue 2976: IDL and C++ relationship (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

page 3-2 of the spec says (Section 3.1, para 3 and para 5):

	OMG IDL obeys the same lexical rules as C++.

	[ ... ]

	The OMG IDL grammar is a subset of the proposed ANSI C++ standard...

Both paragraphs are simply wrong. IDL doesn't obey the same lexical rules
and it isn't a subset of C++. In addition, we now have the final ISO/IEC
C++ standard, so talking about the proposed or draft standard is out of date.

I would suggest to systematically replace references to ANSI C++, the
"proposed" standard, or the "draft" standard with the proper ISO/IEC
reference.

The verbage about IDL being a subset of C++ and obeying the same lexical
rules should be removed. It simply isn't true.

Resolution:
Revised Text:
Actions taken:
November 3, 1999: received issue
October 30, 2000: closed issue

Issue 2977: Preprocessing of IDL (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

Page 3-12:

        OMG IDL preprocessing, which is based on ANSI C++ preprocessing, ..
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The highlighted phrase is meaningless and should be deleted.

In addition, the last para of 3.3 says that

	A complete description of the preprocessing facilities may be found
	in the The Annotated C++ Reference Manual.

For one, the ARM is badly out of date. Second, the para implies, but doesn't
actually say, that IDL preprocessing is exactly like C++ preprocessing.

I would suggest to replace the last para with a definitive statement to
say that IDL is preprocessed as described for C++ in the ISO/IEC C++ standard.
In addition, that statement should probably be used as the lead-in to
section 3.3.

Resolution:
Revised Text:
Actions taken:
November 3, 1999: received issue
October 30, 2000: closed issue

Issue 2978: Meaningless sentence on page 3-11? (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature:
Severity:
Summary:

Page 3-11 says about string literals:

	The size of a string literal is the number of character literals
	enclosed by the quotes, after concatenation. The size of the
	literal is associated with the literal.

The final sentence appears to be meaningless. Suggest to delete it.

Resolution:
Revised Text:
Actions taken:
November 3, 1999: received issue
October 30, 2000: closed issue

Issue 2980: Problem with the "Special scoping" rules in 3.15.3 (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The special scoping rules make it clear that they apply only to
identifiers that name a type, however the second IDL example claims that
the import of a constant definition (in this case the identifier I) into
an interface scope behaves the same way.

So which one is it?  Do the rules only apply to type identifiers or to
all identifiers?

Resolution: The changes below provide clarification.
Revised Text: The text below is replacement text for page 3-56 and replaces the paragraph beginning with Once a type identifier has been *used* anywhere within the scope... up to (but excluding) the paragraph Note that redefinitinos of a type after use in a module is OK as in the example: Replacement text: The scope of of a type definition extends from the point of definition to the end of its enclosing scope. (Constant and exception definitions are considered type definitions.) A type is *introduced* into a scope by its use in that scope, if the type name is not a fully-qualified type name. For example: typedef short TempType; // Scope of TempType begins here module M { typedef string ArgType; // Scope of ArgType begins here struct S { ::M::ArgType a1; // Nothing introduced here M::ArgType a2; // M introduced here ::TempType temp; // Nothing introduced here }; // Scope of (introduced) M ends here // ... }; // Scope of ArgType ends here // Scope of global TempType ends here (at end of file) The scope of an introduced type name is from the point of introduction to the end of its enclosing scope. However, if a *type* name is *introduced* into a scope that is nested in a non-module scope definition, its *potential* scope extends over all its enclosing scopes out to the enclosing non-module scope. (For types that are defined outside an inon-module scope, the scope and the potential scope are identical.) For example: module M { typedef long ArgType; const long I = 10; typedef short Y; interface A { struct S { struct T { ArgType x[I]; // ArgType and I introduced long y; // a new y is defined, the existing Y // is not used } m; }; typedef string ArgType; // Error: ArgType redefined enum I { I1, I2 }; // Error: I redefined typedef short Y; // OK }; // Potential scope of ArgType and I ends here }; A type may not be redefined within its scope or potential scope, as shown in the preceding example. This rule prevents type names from changing their meaning throughout a non-module scope definition, and ensures that reordering of definitions in the presence of introduced types does not affect the semantics of a specification. Note that, in the following, the definition of M::A::U::I is legal because it is outside the potential scope of the I introduced in the definition of M::A::S::T::ArgType. However, the definition of M::A::I is still illegal because it is within the potential scope of the I introduced in the definition of M::A::S::T::ArgType. module M { typedef long ArgType; const long I = 10; interface A { struct S { struct T { ArgType x[I]; // ArgType and I introduced } m; }; struct U { long I; // OK, I is not a type name }; enum I { I1, I2 }; // Error: I redefined }; // Potential scope of ArgType and I ends here };
Actions taken:
November 8, 1999: received issue
February 27, 2001: closed issue

Issue 3000: Codeset conversions and unions (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

Recently, we decided not to permit wchar as the discrinator type for
unions because of the impossibility of dealing with different codesets.

Well, it looks like we have exactly the same problem for char

Resolution:
Revised Text:
Actions taken:
November 4, 1999: received issue
October 30, 2000: closed issue

Issue 3001: The algorithm for TypeCode::equivalent in 10.7.1 was not updated (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The algorithm for TypeCode::equivalent in 10.7.1 was not updated to
reflect the new TypeCode::member_visibility, TypeCode::type_modifier,
and TypeCode::concrete_base_type operations.

Resolution:
Revised Text:
Actions taken:
November 4, 1999: received issue
October 30, 2000: closed issue

Issue 3015: why was is_abstract added to structs in CORBA IR? (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity:
Summary:

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.

Resolution: flagged as urgent....resolved
Revised Text: 0. Add a new minor code <foo> to the BAD_PARAM exception in Section 3.17.2, that says "Attempt to derive abstract interface from non-abstract base interface in the Interface Repository". [Note: This is necessary to cover for the fact that someone could try to AbstractInterfaceDef::_set_base_interfaces with an InterfaceDefSeq that contains an InterfaceDef that is not an AbstractInterfaceDef.] 1. Add a new enum value dk_AbstractInterface to CORBA::DefinitionKind. This is used as the value returned by the inherited def_kind attribute. 2. add create_abstract_interface to CORBA::Container AbstractInterfaceDef create_abstract_interface( in RepositoryId id, in Identifier name, in VersionSpec version in AbstractInterfaceDefSeq base_interfaces ); and add the following text description: The create_abstract_interface operation returns a new empty AbstractInterfaceDef with the specified base_interfaces. Other types can be added in the same way as InterfaceDef allows types to be added. 3. Add a new section 10.5.xx as follows 10.5.xx AbstractInterfaceDef An AbstractInterfaceDef object represents a CORBA 2.3 abstract interface definition. It can contain constants, typedefs, exceptions, operations, and attributes. *Its base interfaces can only contain AbstractInterfaceDefs.* module CORBA { interface AbstractInterfaceDef; typedef sequence<AbstractInterfaceDef> AbstractInterfaceDefSeq; interface AbstractInterfaceDef : InterfaceDef { }; 10.5.xx.1 Read Interface [Note: I have filled in the actual text describing the operations from the corresponding text in InterfaceDef, so that minor changes can be made to the text to account for minor differences.] The inherited base_interfaces attribute returns a list of abstract interfaces from which this abstract interface inherits. Note: base_interfaces is of type InterfaceDefSeq, but since AbstractInterfaceDef is derived from InterfaceDef, a list of AbstractInterfaceDefs can legitimately be returned in an InterfaceDefSeq. The inherited is_a operation returns TRUE if the interface on which it is invoked either is identical to or inherits, directly or indirectly, from the abstract interface identified by its interface_id parameter, or if the value of interface_id is IDL:omg.org/CORBA/AbstractBase:1.0 . Otherwise it returns FALSE. The inherited describe_interface operation returns a FullInterfaceDescription describing the abstract interface, including its operations and attributes. The inherited describe operation for an AbstractInterfaceDef returns an InterfaceDescription. The inherited contents operation returns the list of constants, typedefs, and exceptions defined in this AbstractInterfaceDef and the list of attributes and operations either defined or inherited in this AbstractInterfaceDef. If the exclude_inherited parameter is set to TRUE, only attributes and operations defined within this interface are returned. If the exclude_inherited parameter is set to FALSE, all attributes and operations are returned. 10.5.xx.2 Write Interface Setting the inherited base_interfaces attribute causes a BAD_PARAM exception with standard minor code 5 to be raised if the name attribute of any object contained by this AbstractInterfaceDef conflicts with the name attribute of any object contained by any of the specified base AbstractInterfaceDefs. *If any of the InterfaceDefs in base_interface are not AbstractInterfaceDefs then a BAD_PARAM exception with standard minor code <foo> is raised.* The inherited create_attribute operation returns a new AttributeDef contained in the AbstractInterfaceDef on which it is invoked. The id, name, version, type_def, and mode attributes are set as specified. The type attribute is also set. The defined_in attribute is initialized to identify the containing AbstractInterfaceDef. An error is returned if an object with the specified id already exists within this object�s Repository, or if an object with the specified name already exists within this AbstractInterfaceDef. The inherited create_operation operation returns a new OperationDef contained in the AbstractInterfaceDef on which it is invoked. The id, name, version, result_def, mode, params, exceptions, and contexts attributes are set as specified. The result attribute is also set. The defined_in attribute is initialized to identify the containing AbstractInterfaceDef. An error is returned if an object with the specified id already exists within this object�s Repository, or if an object with the specified name already exists within this AbstractInterfaceDef. 4. Make the following changes to section 10.5.23: First paragraph: restore it to as it was before 2.3. An InterfaceDef object represents an interface definition. It can contain constants, typedefs, exceptions, operations, and attributes. IDL: restore this part to as it appeared in CORBA 2.2. module CORBA { interface InterfaceDef; typedef sequence <InterfaceDef> InterfaceDefSeq; typedef sequence <RepositoryId> RepositoryIdSeq; typedef sequence <OperationDescription> OpDescriptionSeq; typedef sequence <AttributeDescription> AttrDescriptionSeq; interface InterfaceDef : Container, Contained, IDLType { // read/write interface attribute InterfaceDefSeq base_interfaces; // read interface boolean is_a (in RepositoryId interface_id); struct FullInterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; OpDescriptionSeq operations; AttrDescriptionSeq attributes; RepositoryIdSeq base_interfaces; TypeCode type; }; FullInterfaceDescription describe_interface(); // write interface AttributeDef create_attribute ( in RepositoryId id, in Identifier name, in VersionSpec version, in IDLType type, in AttributeMode mode ); OperationDef create_operation ( in RepositoryId id, in Identifier name, in VersionSpec version, in IDLType result, in OperationMode mode, in ParDescriptionSeq params, in ExceptionDefSeq exceptions, in ContextIdSeq contexts ); }; struct InterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; RepositoryIdSeq base_interfaces; }; }; Read interface: Remove the description of the is_abstract attribute. 7. Remove all version pragmas from all IFR related IDL. [Note: This is necessary in order to make sure that a 2.2 InterfaceDef is not rejected as not equivalent to t 2.3 InterfaceDef. Admittedly this is a bit hokey since a 2.3 InterfaceDef derives from a 2.3 Container and hence has additional operations through derivation when compared to 2.2 InterfaceDef, but from an interoperability and backward compatibility perspective this is relatively benign since a 2.3 client attempting to invoke a 2.3 operation on a 2.2 IFR will merely get a BAD_OPERATION. A 2.2 client will never be able to invoke a 2.3 operation anyway. There are cases where a 2.2 client may get back a 2.3 IRObject containing a dk_* value that is unknown to the 2.2 client. In the better written ORBs these will cause MARSHAL exception due to failure to unmarshal the unknown value of an enumerator. In other ORBs the client may have a problem if it is not programmed defensively.]
Actions taken:
November 9, 1999: received issue
February 4, 2000: closed issue

Discussion:

Adding the is_abstract member to the Structs InterfaceDescription and FullInterfaceDescription and associated
changes to the InterfaceDef interface was an error. The correct way to do this is shown below.

A proper resolution to 3015 should recognize that because Abstract
Interfaces are a distinct type in IDL, they should be their own type in the
IFR as well. This distinction has already been addressed in TypeCodes with
create_abstract_interface_tc and tk_abstract_interface. Because the
behaviors of interfaces and abstract interfaces are very different, this
should also be stressed in the IFR.

Consequently, in keeping with the general pattern established with the way abstract
interfaces are handled in TypeCodes, it is porposed that AbstractInterfaceDef be
defined as an IFR object that represents Abstract Interfaces, and that otherwise
has all the attribtues, operations and properties similar to InterfaceDef. This is represented
by having AbstractInterfaceDef derive from InterfaceDef, sort of recognizing
that an AbstractInterfaceDef IR Object is an InterfaceDef of a special restricted kind.
It is necessary to ensure, however, that the base_interfaces of AbstractInterfaceDefs only
contain AbstractInterfaceDefs.

Also, It is necessary to remove version pragmas at least from InterfaceDef
in order to make sure that a 2.2 InterfaceDef is not
rejected as not equivalent to a 2.3 InterfaceDef. Admittedly this is a bit hokey
since a 2.3 InterfaceDef derives from a 2.3 Container and hence has additional
operations through derivation when compared to 2.2 InterfaceDef, but from
an interoperability and backward compatibility perspective this is relatively benign
since a 2.3 client attmepting to invoke a 2.3 operation on a 2.2 IFR will
merely get a BAD_OPERATION. A 2.2 client will never be able to invoke
a 2.3 operation anyway.

Since it would then be absurd for a 2.2 (aka 1.0) InterfaceDef to be deriving from
a 2.3 Container, it is necessary to remove version pragmas from the transitive closure
of the dependency graph for InterfaceDef. It is much easier to remove all version
pragmas from IFR interfaces and other IDL entities.

It is acknowledged that this is not a complete and clean resolution, but it is also acknowledged
that it is impossible to fix all version problems that have accumulated in the
IFR due to past carelessness. With these changes, it is believed that pre-2.3 and 2.3 IFR are
able to interoperate compatibly with pre 2.3 or 2.3 clients. Future enhancements to IFR
should be carried out with greater care and with more attention towards compatibility and
cleanliness of versioning.

Issue 3018: Missing "abstract" in forward declaration (orb_revision)

Click here for this issue's archive.
Source: Perot Systems (Mr. Charles W. Binko, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

In the new Core 2.3.1 (http://www.omg.org/cgi-bin/doc?formal/99-10-07),
section 3.7.4 is incorrect in that it does not mention the optional
"abstract" keyword.

A forward declaration declares the name of an interface without defining it.
This
permits the definition of interfaces that refer to each other. The syntax
consists simply

of the keyword interface followed by an <identifier> that names the
interface. The
actual definition must follow later in the specification.

The paragraph is not in sync with the idl grammar in section 3.4

(6) <forward_dcl> ::= [ "abstract" ] "interface" <identifier>

Resolution:
Revised Text:
Actions taken:
November 10, 1999: receive dissue
October 30, 2000: closed issue

Issue 3020: Question about IDL \uxxxx escape format (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Clarification
Severity:
Summary:

Why was the \uxxxx escape from C++ added to wide string & char literals
in IDL, but the equivalent \Uxxxxxxxx escape was not?

Resolution: Duplicate
Revised Text:
Actions taken:
November 11, 1999: received issue
October 30, 2000: closed issue

Issue 3021: Section 7.6: IDL context housecleaning (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Now that we've bitten the bullet and moved the Exception section from
chapter 3 to chapter 4, shouldn't we do the same thing with section 7.6,
since IDL contexts actually have little to do with the DII?

I propose that we move section 7.6 to chapter 4 as well.

Resolution:
Revised Text:
Actions taken:
November 12, 1999: received issue
October 30, 2000: closed issue

Issue 3022: What is the NO_RESPONSE exception good for? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 3.17.1.15 states:

"NO_RESPONSE

This exception is raised if a client attempts to retrieve the result of
a deferred synchronous call, but the response for the request is not yet
available."

Meanwhile, section 7.3.4 states:

"get_response returns the result of a request. If get_response is called
before the request has completed, it blocks until the request has
completed."

So if get_response blocks, how and when will and ORB ever raise
NO_RESPONSE?

Resolution:
Revised Text:
Actions taken:
November 12, 1999: received issue
October 30, 2000: closed issue

Issue 3041: Editorial glitch in DynAny::destroy, section 9.2.3.6 (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The first paragraph of 9.2.3.6 refers to "creation operations on the ORB
interface".  This needs to be changed to "creation operations on the
DynAnyFactory interface".

Resolution:
Revised Text:
Actions taken:
November 16, 1999: received issue
October 30, 2000: closed issue

Issue 3048: TypeCode issue (orb_revision)

Click here for this issue's archive.
Source: ZeroC (Mr. Marc Laukien, marc(at)zeroc.com)
Nature: Uncategorized Issue
Severity:
Summary:

At present, the following IDL code is illegal:

interface I
{
    CORBA::TypeCode get_type();
};

To make it legal, "orb.idl" must be included. From the spec:

"The file orb.idl contains the IDL definitions for the CORBA module. The
file orb.idl must be included in IDL files that use names defined in the
CORBA module."

I don't think that this is a good idea, because of the following
reasons:

- TypeCode is PIDL, not IDL. So orb.idl can only be used as a "switch"
to enable TypeCode, but it cannot contain a "real" IDL definition for
TypeCode.

- Having to include orb.idl for every little program that requires
TypeCode means a huge overhead, as orb.idl includes *everything* from
the CORBA module (including the IFR!).

I don't see any reason why TypeCode should only be available if orb.idl
is included. To me, TypeCode is "built-in", even if it doesn't have a
keyword. So it appears rather strange to me that I have to artificially
disable TypeCode in our  IDL parser if orb.idl is not included, just to
be compliant with the spec.

I would therefore propose to allow CORBA::TypeCode in IDL even if
orb.idl is not included.

Resolution:
Revised Text:
Actions taken:
November 23, 1999: receved issue
October 30, 2000: closed issue

Issue 3069: OMG IDL Syntax and Semantics issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The following thing is unnoticed in CORBA V2.3, June 1999, OMG document 
99-07-07.pdf, Chapter 3, "OMG IDL Syntax and Semantics", pages 3-37..3-39,
definition of "sequence" type:

There is no explicit definition what length sequence may have at run 
time. Things are perfectly defined for sequence bounds (i.e. maximum
size at compile time) which is explicitly declared to be a positive
integer. However, nothing is said whether length of sequence at run
time can be: (a) positive; or (b) non-negative; or even (c) negative.

Resolution:
Revised Text:
Actions taken:
November 29, 1999: received issue
October 30, 2000: closed issue

Issue 3072: value type substitutability (orb_revision)

Click here for this issue's archive.
Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com)
Nature: Uncategorized Issue
Severity:
Summary:

Chapter 5.2.5: Value type semantics should not define that an instance of a 
value type can be passed (directly) as a parameter that is declared as an 
interface type. The reason is that this is not true in some of the language 
mappings (e.g. C++) because it contradicts the kind and nature of value types.

A value type instance IS NOT an object reference even if it is registered with 
the ORB. Therefore, if a construct conceptually is not a subtype of another 
construct, it should not be possible that it substitutes the other. Also, it 
should not be required that there are any shortcuts which automatically convert 
a registered valuetype to it's associated object reference.

Resolution: Clarify the ambiguity that leads to the possible inappropriate interpretation
Revised Text: 1. Leave the first paragraph of section 5.2.5 unchanged. 2. Replace the second paragraph by: "There are three cases to consider: the parameter type is a regular interface, the parameter type is an abstract interface, and the parameter type is a value type." 3. Replace the current text in section 5.2.5.1 by: "A value type that supports a regular interface is not a subtype of that interface, and hence cannot be substituted for that interface in an invocation parameter. In this case an object reference corresponding to the value type instance that has been registered with the ORB must be obtained and this object reference must be used as the actual parameter. Different language mappings provide different facilities to aid in such parameter passing." 4. Add a new section 5.2.5.2 Value Instance -> Abstract interface type: "A value type that supports an abstract interface is a subtype of that interface, and can be substituted for that interface in an invocation parameter." 5. Renumber the existing section 5.2.5.2 to 5.2.5.3.
Actions taken:
November 30, 1999: received issue
February 27, 2001: closed issue

Issue 3073: create_POA and inactive state? (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

what should happen if I call create_POA() on a POA whose POA manager is
in the inactive state (that is, a POA on which, previously, deactivate()
was called?

The spec says nothing about this. Seeing that creating a new POA on a "dead"
POA doesn't make sense, I would suggest to raise BAD_INV_ORDER, possibly
with a new minor code.

Resolution:
Revised Text:
Actions taken:
December 2, 1999: received issue
October 30, 2000: closed issue

Issue 3095: Use of Principal in GIOP Module erroneous (orb_revision)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Uncategorized Issue
Severity:
Summary:

In spite of objections based on misunderstandings from certain quarters
I would like to propose that Principal in the IDL describing GIOP as
excerpted below be replaced by "sequence <octet>". For whatever it might
be worth, doing so would make the IDL in the GIOP module actually
compilable for the first time in its entire existence!:-)

module GIOP { // IDL extended for version 1.1 and 1.2
        // GIOP 1.0
        struct RequestHeader_1_0 { // Renamed from RequestHeader
                IOP::ServiceContextList service_context;
                unsigned long request_id;
                boolean response_expected;
                sequence <octet> object_key;
                string operation;
                Principal requesting_principal;
                ^^^^^^^^^
        };

        // GIOP 1.1
        struct RequestHeader_1_1 {
                IOP::ServiceContextList service_context;
                unsigned long request_id;
                boolean response_expected;
                octet reserved[3]; // Added in GIOP 1.1
                sequence <octet> object_key;
                string operation;
                Principal requesting_principal;
                ^^^^^^^^^
        };

        ...
};

Firstly, ever since the GIOP standard was adopted, the use of Principal 
in that struct has been erroneous, since it is undefined in GIOP module,
unless adorned with a CORBA:: prefix. Secondly, in effect all that it is
trying to say
is that the Principal is represented as a  sequence<octet> in the header
field
requesting_principal, not a Principal pseudo-interface, which is
undefined in that context anyway. Thirdly, even if you could find a
definition for an unadorned Principal somewhere, what is the meaning of
that type when CDR encoded? It really is
nothing but sequence<octet>.

I think this issue should go to the Interop RTF.

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
December 6, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Issue 3104: Non-standard system exceptions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Section 3.17.1 says that "ORB implementations may raise non-standard system
exceptions."  This raises a number of questions:

1. How are non-standard system exceptions defined?  Are they defined using
   IDL, or are they PIDL?  If they are IDL, how are they identified as
   system exceptions by the language mappings?

2. The definitions in section 3.17.1 for standard system exceptions appear
   to be IDL, but I believe the intention is that they are PIDL.  This 
   should be stated clearly.

3. Should non-standard system exceptions be defined in the CORBA module like
   the standard system exceptions?  There are three choices:
    a. They must be in the CORBA module.
    b. They must not be in the CORBA nmodule.
    c. They can either be in the CORBA nodule or in other modules.

4. Point 3 raises the more general question of whether it is legal for ORB 
   vendors to add non-standard definitions to the CORBA module.  Section 3.14 
   says that "Names defined by the CORBA specification are in a module named
   CORBA," but it does not say whether these are the only names that may appear
   in the module named CORBA.  This should be clarified.

Resolution: See text below for resolution
Revised Text: With reference to ptc/99-12-07, make the following changes: 1. Replace the paragraph in section 4.11.3 that reads: "The standard system exceptions are defined below. Clients must be prepared to handle system exceptions that are not on this list, both because future versions of this specification may define additional standard exceptions, and because ORB implementations may raise non-standard system exceptions." by: "The standard system exceptions are defined in this sections." 2. In the first sentence of the last paragraph of section 4.11.2 replace the phrase: "Each standard exception....." by the phrase: "Each system exception....." 3. Move the line of PIDL which reads #define ex_body {unsigned long minor; completion_status completed;} from the PIDL in section 4.11.3 to the IDL in section 4.11.2 4. Append the following paragraphs to section 4.11.2, immediately following table defining COMPLETED_YES etc.:: Client applications must be prepared to handle system exceptions other than the standard system exception defined below in section 4.11.3, both because future versions of this specification may define additional standard system exceptions, and because ORB implementations may raise non-standard system exceptions. Vendors may define non-standard system exceptions, but these exceptions are discouraged because they are non-portable. A non-standard system exception, when passed to an ORB that does not recognize it, shall be presented by that ORB as an UNKNOWN standard system exception. The minor code and completion status from the unrecognized exception shall be preserved in the UNKNOWN exception. Non-standard system exceptions shall have the same structure as of standard standard system exceptions as specified in section 4.11.3 below - ie., they have the same ex_body. They also shall follow the same language mappings as standard system exceptions. Although they are PIDL, vendors should ensure that their names do not clash with any other names following the normal naming and scoping rules as they apply to regular IDL exceptions."
Actions taken:
December 10, 1999: received issue
October 6, 2000: closed issue

Issue 3105: Errors in published IDL for CORBA module (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

I found a lot of errors in the CORBA IDL text file that's on the server
for download:
In general, the layout of the file is a mess. Inconsistent, meaningless
indentation, whitespace before semicolons on occasion, comments indented
poorly, etc, etc. Wouldn't hurt to clean this up -- it's quite embarrassing
as it is now.

Resolution:
Revised Text:
Actions taken:
December 10, 1999: received issue
October 30, 2000: closed issue

Issue 3109: DynAny & abstract interfaces don't mix! (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 9.2.2 states:

"The operation raises InconsistentTypeCode if value has a TypeCode with
a TCKind of tk_Principal, tk_native, or tk_abstract_interface."

This is totally broken for abstract interfaces.  What happens if I do
this:

// IDL
abstract interface I {
};

struct S {
    I	an_i;
};

// C++
    S		mys;
    CORBA::Any	a;
    
    a <<= s;

    DynamicAny::DynAnyFactory_var	daf = ...;
    DynamicAny::DynAny_var		da = daf->create_dyn_any(a);
    DynamicAny::DynAny_var		component = da->current_component();

Obviously the value of component must be meaningful, otherwise there is
no way to examine or construct a value of type S.

Resolution:
Revised Text:
Actions taken:
December 10, 1999: received issue
October 30, 2000: closed issue

Issue 3115: Do valueboxes have factories? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Nowhere in the CORBA 2.3 specification is it made clear whether or not
valueboxes have or need a valuefactory.

Since valueboxes are clearly completely concrete types, with no
operations, and with no factory initializers, there is no need for a
factory for valueboxes.

Proposal:

Add the following to secion 5.2.8.1:

"Value box types do not need or use factories."

Resolution:
Revised Text:
Actions taken:
December 14, 1999: received issue
October 30, 2000: closed issue

Issue 3132: What is the TypeCode for ValueBase? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

I know this is late, but I think it is quite urgent, and we ought to
add it to the last Core 2000 vote.]

The spec is silent about the existence and properties of a TypeCode
constant for ValueBase, even though it is necessary to define one so
that the DII, DSI and IFR can operate properly.

There also is no explicit information about what values operation calls
on the TC_Object typecode constant return.

Proposal:

1.  Add to the list of TypeCode constants in 10.7.2:

TC_ValueBase = tk_value { ValueBase }

2.  Add at the end of section 10.7.2:

For the TC_Object TypeCode constant, calling id returns
"IDL:omg.org/CORBA/Object:1.0" and calling name returns "Object".  For
the TC_ValueBase TypeCode constant, calling id returns
"IDL:omg.org/CORBA/ValueBase:1.0", calling name returns "ValueBase",
calling member_count returns 0, calling type_modifier returns
CORBA::VM_NONE, and calling concrete_base_type returns a nil TypeCode.

Resolution: Yes, this is a signficant outage. It should be fixed and the fix should be incorporated in 2.3 via t
Revised Text: 1. Add to the list of TypeCode constants in 10.7.2: TC_ValueBase = tk_value { ValueBase } 2. Add at the end of section 10.7.2: For the TC_Object TypeCode constant, calling id returns "IDL:omg.org/CORBA/Object:1.0" and calling name returns "Object". For the TC_ValueBase TypeCode constant, calling id returns "IDL:omg.org/CORBA/ValueBase:1.0", calling name returns "ValueBase", calling member_count returns 0, calling type_modifier returns CORBA::VM_NONE, and calling concrete_base_type returns a nil TypeCode.
Actions taken:
December 17, 1999: received issue
October 6, 2000: Incorporate changes in CORBA 2.3 via urgent resolution proces
October 6, 2000: closed issue

Discussion:

Yes, this is a signficant outage. It should be fixed and the fix should be incorporated in 2.3 via the urgent process.

Issue 3134: OMG wchar <-> COM WCHAR in CORBA 2.3 (orb_revision)

Click here for this issue's archive.
Source: IONA (Mr. Thomas Moriarty, Thomas.Moriarty(at)iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

The CORBA 2.3 spec states in table 18-2 that OMG IDL wstring maps to LPWSTR
in COM.

This was presumably added with the introduction of CORBA support for
wstrings. I don't see any mapping defined for OMG wchar. This would
naturally map to COM WCHAR.

Is this an error/omission in the 2.3 spec?

Resolution: OMG IDL wchar should indeed map to COM WCHAR. Add it to table 18-1
Revised Text: Add the following row to Table 18-1 on page 18-2: wchar WCHAR
Actions taken:
December 17, 1999: received issue
October 6, 2000: closed issue

Issue 3135: valuebox and DynAny (orb_revision)

Click here for this issue's archive.
Source: Progress Software (Mr. Steve Vinoski, steve.vinoski(at)iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

The DynAny chapter says absolutely nothing about value boxes. Do they
fulfill only the base DynAny interface, or the DynValue interface, or do we
need a new DynValueBox interface? If the DynValue interface is supposed to
be used, do you treat the boxed value as a single member? If so, what is
its name?

Resolution: Following text changes address the outage raised in this issue as well as the one from issue 3250
Revised Text: 1. Replace the IDL for DynValue in 9.2 with: interface DynValueCommon : DynAny { boolean is_null(); void set_to_null(); void set_to_value(); }; interface DynValue : DynValueCommon { FieldName current_member_name() raises(TypeMismatch, InvalidValue); CORBA::TCKind current_member_kind() raises(TypeMismatch, InvalidValue); NameValuePairSeq get_members() raises(InvalidValue); void set_members(in NameValuePairSeq value) raises(TypeMismatch, InvalidValue); NameDynAnyPairSeq get_members_as_dyn_any() raises(InvalidValue); void set_members_as_dyn_any(in NameDynAnyPairSeq value) raises(TypeMismatch, InvalidValue); }; interface DynValueBox : DynValueCommon { any get_boxed_value() raises(InvalidValue); void set_boxed_value(in any boxed) raises(TypeMismatch); DynAny get_boxed_value_as_dyn_any() raises(InvalidValue); void set_boxed_value_as_dyn_any(in DynAny boxed) raises(TypeMismatch); }; ------------------------------------------------------------------------------ 2. Change the complex type initialization bullet in section 9.2.2 for DynValue from: o For DynValue, the members are initialized as for DynStruct. to: o For DynValue and DynValueBox, initialize to a null value ------------------------------------------------------------------------------ 3. Replace section 9.2.10 with: 9.2.10 The DynValueCommon interface DynValueCommon provides operations supported by both the DynValue and DynValueBox interfaces. interface DynValueCommon : DynAny { boolean is_null(); void set_to_null(); void set_to_value(); }; boolean is_null(); The is_null operation returns TRUE if the DynValueCommon represents a null valuetype. void set_to_null(); The set_to_null() operation changes the representation of a DynValueCommon to a null valuetype. void set_to_value(); If the DynValueCommon represents a null valuetype, then set_to_value() replaces it with a newly constructed value, with its components initialized to default values as in DynAnyFactory::create_dyn_any_from_type_code. If the DynValueCommon represents a non-null valuetype, then this operation has no effect. 9.2.11 The DynValue interface DynValue objects are associated with non-boxed valuetypes. interface DynValue : DynValueCommon { FieldName current_member_name() raises(TypeMismatch, InvalidValue); CORBA::TCKind current_member_kind() raises(TypeMismatch, InvalidValue); NameValuePairSeq get_members() raises(InvalidValue); void set_members(in NameValuePairSeq value) raises(TypeMismatch, InvalidValue); NameDynAnyPairSeq get_members_as_dyn_any() raises(InvalidValue); void set_members_as_dyn_any(in NameDynAnyPairSeq value) raises(TypeMismatch, InvalidValue); }; 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. The remaining operations on the DynValue interface generally have equivalent semantics to the same operations on DynStruct. When invoked on a DynValue representing a null valuetype, get_members and get_members_as_dyn_any raise InvalidValue. When invoked on a DynValue representing a null valuetype, set_members and set_members_as_dyn_any convert the DynValue to a non-null valuetype. Warning: indiscriminantly changing the contents of private valuetype members can cause the valuetype implementation to break by violating internal constraints. Access to private members is provided to support such activities as ORB bridging and debugging and should not be used to arbitrarily violate the encapsulation of the valuetype. 9.2.12 The DynValueBox interface DynValueBox objects are associated with boxed valuetypes. interface DynValueBox : DynValueCommon { any get_boxed_value() raises(InvalidValue); void set_boxed_value(in any boxed) raises(TypeMismatch); DynAny get_boxed_value_as_dyn_any() raises(InvalidValue); void set_boxed_value_as_dyn_any(in DynAny boxed) raises(TypeMismatch); }; The DynValueBox interface can represent both null and non-null valuetypes. For a DynValueBox representing a non-null valuetype, the DynValueBox has a single component of the boxed type. A DynValueBox representing a null valuetype has no components and a current position of -1. any get_boxed_value() raises(InvalidValue); The get_boxed_value operation returns the boxed value as an any. If the DynBoxedValue represents a null valuetype, the operation raises InvalidValue. void set_boxed_value(in any boxed) raises(TypeMismatch); The set_boxed_value replaces the boxed value with the specified value. If the DynBoxedValue represents a null valuetype, it is converted to a non-null value. The get_boxed_value_as_dyn_any and set_boxed_value_as_dyn_any have the same semantics as their any counterparts, but accept and return values of type DynAny instead of any.
Actions taken:
December 17, 1999: received issue
October 6, 2000: closed issue

Issue 3159: null & void TCs and DynAny (orb_revision)

Click here for this issue's archive.
Source: Progress Software (Mr. Steve Vinoski, steve.vinoski(at)iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

The DynAny chapter says nothing about whether
DynAnyFactory::create_dyn_any_from_type_code is supposed to correctly
handle a TypeCode argument that has a TCKind of either tk_null or tk_void.

I assume these are valid argument TypeCodes that do not result in an
InconsistentTypeCode exception, and the returned DynAny is simply one that
fulfills the basic DynAny interface and has no components. However, it
would be nice to explicitly document the cases for these two TypeCodes,
though, given that they're a little different from other TypeCodes in that
they can't have any associated values.

Resolution: Clarify with additional text as shown below
Revised Text: With reference to ptc/99-12-07 Insert the following paragraph at the bottom of page 9-9, immediately following the new paragraph added by Core RTF 2k: "Creation of DynAnys with TCKind tk_null and tk_void is legal and results in the creation of a DynAny without a value and with zero components."
Actions taken:
December 21, 1999: received issue
October 6, 2000: Incorporate changes and close issue

Issue 3172: Bug in 11.3.7.6 (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

on page 11-30, we have:

	RETAIN and USE_ACTIVE_OBJECT_MAP_ONLY

	This combination represents the situation where the POA does no
	automatic object activation (that is, the POA searches only the
	Active Object Map). The server must activate all objects served
	by the POA explicitly, using either the activate_object or
	activate_object_with_id operation.

The final sentence is wrong. Implicit activation is controlled by the
ImplicitActivation policy.

Resolution: Remove the incorrect sentence
Revised Text: Remove the last sentence in the "RETAIN and USE_ACTIVE_OBJECT_MAP_ONLY" subsection on page 11-30, which reads: "The server must activate all objects served by the POA explicitly, using either the activate_object or activate_object_with_id operation."
Actions taken:
January 2, 2000: receive dissue
October 6, 2000: Incorporate change and close issue.

Issue 3173: IDL scoping rules (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

on page 3-48, we have:

	On the other hand, if module Inner2 were:

	module Inner2 {
		typedef Inner1::S1 S2;	// Inner1 introduced
		typedef string inner1;	// Error
		typedef string S1;	// OK
	};

	The definition of inner1 is now an error because the identifier
	Inner1 referring to the module Inner1 has been introduced in the
	scope of module Inner2 in the first line of the module declaration.
	Also, the declaration of S1 in the last line is OK since the
	identifier S1 was not introduced into the scope by the use of
	Inner1::S1 in the first line.

This is fine, but it doesn't make it clear that, if the name is qualified,
it is *not* introduced into the scope.

Resolution: Additional clarifying words are needed as shown below.
Revised Text: Append the following sentences to the paragraph that immediately follows the module Inner2 example on page 3-54: "Only the first identifier in a qualified name is introduced into the current scope. This is illustrated by Inner1::S1 in the example above, which introduces "Inner1" into the scope of "Inner2" but does not introduce "S1". A qualified name of the form "::X::Y::Z" does not cause "X" to be introduced, but a qualified name of the form "X::Y::Z" does."
Actions taken:
January 2, 2000: receive dissue
October 6, 2000: Incorporate changes and close issue.

Issue 3174: servant_to_id (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

the following text in the spec could be made a bit clearer:

	2. If the POA has the IMPLICIT_ACTIVATION policy and either the
	   POA has the MULTIPLE_ID policy or the specified servant is not
	   active, the servant is activated using a POA-generated Object Id
	   and the Interface Id associated with the servant, and that Object
	   Id is returned.

Although it is stated elsewhere that IMPLICIT_ACTIVATION requires SYSTEM_ID,
it wouldn't hurt to reflect this here too:

	2. If the POA has the IMPLICIT_ACTIVATION policy and either the
	   POA has the MULTIPLE_ID policy or the specified servant is not
	   active and the POA has the SYSTEM_ID policy, the servant is
		  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	   activated using a POA-generated Object Id
	   and the Interface Id associated with the servant, and that Object
	   Id is returned.

Another question:

	What should be returned if the USER_ID policy is present?

The spec doesn't say. Given that we can't add a new user exception,
OBJ_ADAPTER seems appropriate.

Resolution: Close with no change, since a POA cannot have IMPLICIT_ACTIVATION and USER_ID.
Revised Text:
Actions taken:
January 4, 2000: received issue
October 6, 2000: Close no change.

Issue 3177: local interfaces and the DII (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

The current spec for local interfaces disallows making calls to a local
interface via the DII. It turns out that this is rather inconvenient
for implementors of scripting languages. That's because, for a scripting
language, *everything* is a DII request. Local interfaces, therefore, force
the implementor to wrap all pseudo-objects and local interfaces in
special wrapper objects.

For pseudo-objects, there is nothing we can do. However, for local
interfaces, we could require DII calls to be supported.

Resolution: resolved, see above
Revised Text:
Actions taken:
January 5, 2000: received issue
January 5, 2000: moved from core rtf to components ftf
May 19, 2001: moved from components ftf back to core
May 13, 2002: closed issue

Discussion:

Since local interfaces are allowed to take native values for parameters, which 
you cannot pass via DII. So we'll have to limit DII usage on local inter- 
faces anyway (e.g. you could not call activate_object on the POA).

Issue 3181: special-casing TypeCode is unnecessary (orb_revision)

Click here for this issue's archive.
Source: Progress Software (Mr. Steve Vinoski, steve.vinoski(at)iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

The resolution to issue 3048 special-cases TypeCode in a manner that
essentially makes it a keyword. First of all, given that TypeCode lives in
the CORBA module, and thus is properly named CORBA::TypeCode, this is
highly irregular because it means we have a scoped keyword. Second, this
change also significantly breaks working products -- it adopts
implementation details of certain compilers and rules out already-working
implementation approaches of other existing compilers. The OMG is not
supposed to dictate implementation. Finally, the rationale for the changes
made for 3048 centered around unquantifiable performance issues that IMO
affect only a very small minority of applications.

Resolution: Incorporate changes and close issue.
Revised Text: n Section 3.14, page 3-51 orbrev/00-09-01, replace the following paragraph: "The file orb.idl contains the IDL definitions for the CORBA module. Except for CORBA::TypeCode, the file orb.idl must be included in IDL files that use names defined in the CORBA module. CORBA::TypeCode can be used in IDL files without having to include orb.idl." by: " The file orb.idl contains the IDL definitions for the CORBA module. Except for CORBA::TypeCode, the file orb.idl must be included in IDL files that use names defined in the CORBA module. IDL files that use CORBA::TypeCode may obtain its definition by including either the file orb.idl or the file TypeCode.idl. The exact contents of TypeCode.idl are implementation dependent. One possible implementation of TypeCode.idl may be: // PIDL #ifndef _TYPECODE_IDL_ #define _TYPECODE_IDL_ #pragma prefix "omg.org" module CORBA { interface TypeCode; }; #endif // _TYPECODE_IDL_ For IDL compilers that implicitly define CORBA::TypeCode, TypeCode.idl could consist entirely of a comment as shown below: // PIDL // CORBA::TypeCode implicitly built into the IDL compiler // Hence there are no declarations in this file Because the compiler implicitly contains the required declaration, this file meets the requirement for compliance. "
Actions taken:
January 6, 2000: received issue
February 27, 2001: closed issue

Discussion:

This issue requests reversal of an action taken in a previous RTF which was supported by an overwhelming majority. Such a step
would be justified if new facts have come to light to justify such a reversal. Implementors have had considerable time to gain
experience with the change that was put in place. So the first question to vote on was: 

Have any new facts come to light as a result of experience gained since the change was made to justify considering reversal of
the resolution for issue 3048 that was adopted with iverwhelming majority?. 

Since YES prevailed it is further decided that the previous change in 3048 resolution went too far causing invalidation of perfectly
legitimate implementations of IDL compilers which actually gets the definition of TypeCode from its IDL declaration instead of
implicitly defining it within the compiler. In order to make both kinds of compilers admissible as compliant, the changes shown
below are proposed. 

These changes allow compilers that depend on the declaration of TypeCode in IDL file to  deliver said definition in the
TypeCode.idl file and #include that file at an appropriate place in the orb.idl file, or use any other combination that works. 

Additionally, compilers that implicitly define TypeCode in the compiler can deliver in effect an empty TypeCode.idl file, and
comply with this change. 

Users of any IDL compiler that need the definition of TypeCode are expected to either #include TypeCode.idl or #include orb.idl.

Issue 3185: Efficient construction of Any types w/o DynamicAny (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

 The current C++ mapping does not offer efficient insertion or
extraction of data from CORBA::Any if static type information
(IDL-generated insertion and extraction operators) are not
available.

 I'm thinking of a dynamic DII gateway that needs to shovel large
amounts of data, such as a sequence<octet>. Presently, the gateway
must employ the DynAny type, and loop over the number of elements,
calling insert_octet() or get_octet() repeatedly. This is inefficient,
especially for large sequences/arrays of basic types.

 I think that a more efficient mechanism might be useful for some
applications.

Resolution: Incorporate changes and close issue
Revised Text: 1) Add the following operations to the DynamicAny::DynAny interface: module DynamicAny { ... interface DynAny { ... void insert_boolean_seq(in CORBA::BooleanSeq value) raises(TypeMismatch, InvalidValue); void insert_octet_seq(in CORBA::OctetSeq value) raises(TypeMismatch, InvalidValue); void insert_char_seq(in CORBA::CharSeq value) raises(TypeMismatch, InvalidValue); void insert_short_seq(in CORBA::ShortSeq value) raises(TypeMismatch, InvalidValue); void insert_ushort_seq(in CORBA::UShortSeq value) raises(TypeMismatch, InvalidValue); void insert_long_seq(in CORBA::LongSeq value) raises(TypeMismatch, InvalidValue); void insert_ulong_seq(in CORBA::ULongSeq value) raises(TypeMismatch, InvalidValue); void insert_float_seq(in CORBA::FloatSeq value) raises(TypeMismatch, InvalidValue); void insert_double_seq(in CORBA::DoubleSeq value) raises(TypeMismatch, InvalidValue); void insert_longlong_seq(in CORBA::LongLongSeq value) raises(TypeMismatch, InvalidValue); void insert_ulonglong_seq(in CORBA::ULongLongongSeq value) raises(TypeMismatch, InvalidValue); void insert_longdouble_seq(in CORBA::LongDoubleSeq value) raises(TypeMismatch, InvalidValue); void insert_wchar_seq(in CORBA::WCharSeq value) raises(TypeMismatch, InvalidValue); CORBA::BooleanSeq get_boolean_seq() raises(TypeMismatch, InvalidValue); CORBA::OctetSeq get_octet_seq() raises(TypeMismatch, InvalidValue); CORBA::CharSeq get_char_seq() raises(TypeMismatch, InvalidValue); CORBA::ShortSeq get_short_seq() raises(TypeMismatch, InvalidValue); CORBA::UShortSeq get_ushort_seq() raises(TypeMismatch, InvalidValue); CORBA::LongSeq get_long_seq() raises(TypeMismatch, InvalidValue); CORBA::ULongSeq get_ulong_seq() raises(TypeMismatch, InvalidValue); CORBA::FloatSeq get_float_seq() raises(TypeMismatch, InvalidValue); CORBA::DoubleSeq get_double_seq() raises(TypeMismatch, InvalidValue); CORBA::LongLongSeq get_longlong_seq() raises(TypeMismatch, InvalidValue); CORBA::ULongLongongSeq get_ulonglong_seq() raises(TypeMismatch, InvalidValue); CORBA::LongDoubleSeq get_longdouble_seq() raises(TypeMismatch, InvalidValue); CORBA::WCharSeq get_wchar_seq() raises(TypeMismatch, InvalidValue); ... }; ... }; 2) Add the following text to the end of section 9.2.3.8: In the same way that basic types are inserted/extracted from a DynAny object, arrays or sequences of basic types can be inserted/extracted from a DynAny. For example, the get_boolean_seq operation extracts a sequence of booleans from a DynAny that contains either a sequence or an array of booleans, and the insert_boolean_seq operation stores the sequence back into the DynAny. The TypeCode of the DynAny, or the TypeCode of the component at the current position of the DynAny, must be equivalent to a sequence or array TypeCode with the basic type as its element, otherwise the operations raise TypeMismatch. For the insert operations, if the length of the sequence is incompatible with a bounded sequence or array represented by the DynAny, then the operations raise InvalidValue.
Actions taken:
January 7, 2000: received issue
January 7, 2000: moved from C++ to Core RTF
February 27, 2001: closed issue

Discussion:

New operations cribbed from the DataInputStream & 
DataOutputStream interfaces for custom valuetypes are added 
to facilitate this.  I only added inserters and extractors for types that 
map to a fixed memory size, since they are the only ones that I anticipate 
a good performance gain.

Issue 3194: Ordering issues in the DII (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

The following are currently undefined in the spec:

	- What happens if poll_response or get_response is called
	  before send_deferred?

	- What happens if get_response is called after invoke?

	- What if get_response is called more than once?

	  [ Interestingly, the resolution to issue 2341 resolved something,
	    but it wasn't issue 2341 ;-)  That's because the resolution
	    doesn't say that calling get_response twise is illegal. ]

	- Is it legal to call poll_response more than once?

I think that, for the first three, we should raise BAD_INV_ORDER. We
also need minor codes for those.

For case four, I'd suggest that calling poll_response multiple times is OK,
but that calling it once get_response was called should raise BAD_INV_ORDER.

Resolution: Fix as described above.
Revised Text: Section and page numbers are based on 2.3.1. Symbolic names for standard minor codes will need to be replaced with manifest constants for table 3-13 on page 3-58 as follows (all entries are to be made in the BAD_INV_ORDER section): REUSE Attempt to send a DII request after it was sent previously. NO_INIT Attempt to poll a DII request or to retrieve its result before the request was sent. FINAL Attempt to poll a DII request or to retrieve its result after the result was retrieved previously. SYNC Attempt to poll a synchronous DII request or to retrieve results from a synchronous DII request. Change the final para of 7.2.3, last sentence to read: Calling invoke on a request after invoke, send, or send_multiple_requests for that request was called raises BAD_INV_ORDER with standard minor code REUSE. Add the following text at the end of section 7.3.1: Calling send on a request after invoke, send, or send_multiple_requests for that request was called raises BAD_INV_ORDER with standard minor code REUSE. Add the following text at the end of section 7.3.2: Calling send_multiple_requests for a request after invoke, send, or send_multiple_requests for that request was called raises BAD_INV_ORDER with standard minor code REUSE. If send_multiple_requests raises BAD_INV_ORDER, the actual number of requests that were sent is implementation dependent. Add the following text at the end of section 7.3.3: Calling poll_response before send or send_multiple_requests for that request raises BAD_INV_ORDER with standard minor code NO_INIT. Calling poll_response after calling invoke raises BAD_INV_ORDER with standard minor code SYNC. Calling poll_response after calling get_response raises BAD_INV_ORDER with standard minor code FINAL. Calling poll_response after that request was returned by get_next_response raises BAD_INV_ORDER with standard minor code FINAL. Add the following text at the end of section 7.3.4: Calling get_response before send or send_multiple_requests for that request raises BAD_INV_ORDER with standard minor code NO_INIT. Calling get_response after calling invoke raises BAD_INV_ORDER with standard minor code SYNC. Calling get_response after calling get_response raises BAD_INV_ORDER with standard minor code FINAL. Calling get_response after that request was returned by get_next_response raises BAD_INV_ORDER with standard minor code FINAL. Add the following text at the end of section 7.3.5: Calling get_next_response or poll_next_response at a time when no requests are outstanding raises BAD_INV_ORDER with standard minor code NO_INIT. If concurrent calls to get_next_response or poll_next_response are in progress, the exact outcome is implementation dependent; however, get_next_response is guaranteed not to return the same completed request to more than one caller.
Actions taken:
January 11, 2000: received issue
October 6, 2000: Incorporate changes and close issue.

Issue 3196: poll_response() (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

there really is a different issue here. On page 7-5:

	boolean poll_response();

On page 7-9:

	boolean poll_response ( in Request req);

Resolution: Already fixed editorially in draft.
Revised Text:
Actions taken:
January 11, 2000: received issue
October 6, 2000: closed issue, no change

Issue 3203: Inheritence table 3-10 wrong? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

There appears to be a minor glitch in table 3-10.  It states that
stateful valuetypes can only support one non-abstract interface, but it
is not clear what is correct for abstract valuetypes or abstract
interfaces, since it uses the words "supports", not "supports single" or
"multiple" which are used elsewhere.  It certainly does not appear
reasonable for abstract valuetypes to be able to inherit from more than
one non-abstract interface when stateful valuetypes cannot.

This brings up a question: Can abstract valuetypes support non-abstract
interfaces?  It's not clear to me what the answer to this ought to be.

Anyway, it appears to me that part of the table should look like this
instead:

May inherit from:	| Interface		| Abstract Interface
---------------------------------------------------------------------------
Abstract		| *no or supports single| multiple
Value			|
---------------------------------------------------------------------------
Stateful		| supports single	| multiple
Value			|			|
---------------------------------------------------------------------------

* depending on the answer to the question above

Resolution: The table needs to be changed to clarify as shown below
Revised Text: May inherit from: | Interface | Abstract Interface --------------------------------------------------------------------------- Abstract | supports single | supports multiple Value | --------------------------------------------------------------------------- Stateful | supports single | supports multiple Value | | ---------------------------------------------------------------------------
Actions taken:
January 10, 2000: received issue
October 6, 2000: Incorporate changes and close issue

Issue 3205: Semantics for DynAny::equal underspecified (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

CORBA 2.3.1, 9.2.3.5 says:  "Two DynAny values are equal if their
TypeCodes are equivalent and, recursively, all component DynAnys have
equal values."

We already added text in the Y2K RTF to clarify equal for object
references & typecodes, but this leaves an exercise for the reader to
figure out what equal means for some IDL types, particularly fixed,
sequences & valuetypes.  I believe that an experienced person thinking
about it can come up with the correct rules, but why leave it up to
mistaken interpretation.

Resolution: Resolve as suggested
Revised Text: Ok, now for the specific proposal for issue 3205: 1. Change the IDL for DynAnyFactory interface to: module DynamicAny { ... exception MustTruncate { }; ... interface DynAnyFactory { exception InconsistentTypeCode {}; DynAny create_dyn_any(in any value) raises(InconsistentTypeCode); DynAny create_dyn_any_from_type_code(in CORBA::TypeCode type) raises(InconsistentTypeCode); DynAny create_dyn_any_without_truncation(in any value) raises(InconsistentTypeCode, MustTruncate); DynAnySeq create_multiple_dyn_anys(in AnySeq values, in Boolean allow_truncate) raises(InconsistentTypeCode, MustTruncate); AnySeq create_multiple_anys(in DynAnySeq values); }; }; 2. Add the following text to section 9.2.2 to describe the new DynAnyFactory operations: The create_dyn_any_without_truncation operation has the same semantics as create_dyn_any, but will raise the MustTrucate exception if it cannot avoid truncating a valuetype. The create_multiple_dyn_anys operation converts a sequence of anys into a sequence of DynAnys, ensuring that each reference to a valuetype instance is converted consistently to the same DynValue or DynValueBox instance. If the allow_truncate parameter is false, the operation will raise the MustTruncate exception if it cannot avoid truncating a valuetype. The create_multiple_anys operation converts a sequence of DynAnys into a sequence of anys, ensuring that each DynValue or DynValueBox instance is consistently converted to the same valuetype instance. 3. Change the the last paragraph of 9.2.3.5 to: The equal operation compares two DynAny references for equality and returns true if the DynAnys are equal, false otherwise. For DynAny references that are not derived from DynValueCommon, they are equal if their TypeCodes are equivalent and, recursively, all component DynAnys are equal. For DynAny references that are derived from DynValueCommon, they are equal only if they are exactly the same reference. The current position of the two DynAnys being compared has no effect on the result of equal. To determine equality of object references, the equal operation uses Object::is_equivalent. To determine equality of type codes, the equal operation uses TypeCode::equivalent. 4. Add the following text to the end of section 9.2.10: A reference to a DynValueCommon interface (and interfaces derived from it) exhibit the same sharing semantics as the underlying valuetype that it represents. This means that the relationships between valuetypes in a graph of valuetypes will remain unchanged when converted into DynAny form and vice versa. This is necessary to ensure that applications that use the DII and DSI can correctly view and preserve the semantics of the valuetype graph.
Actions taken:
January 10, 2000: received issue
May 13, 2002: closed issue

Discussion:

As briefly as possible, here is a description of the problems that 
valuetypes and the DynAny interfaces have in the Corba 2.4.2 
specification right now: 

#1.  There is confusion over what a DynValue represents:  is it a 
reflective interface to a real underlying valuetype instance, or is it 
a separate thing that represents a valuetype and is converted to/from 
a real valuetype via DynAny::to_any()/from_any()? 

#2.  The semantics of DynAny::equal() when applied to DynValues is 
underspecified:  is it reference equality or contents equality? 

#3.  The DynAny/DynValue interface is lacking expressiveness to properly 
implement a DII/DSI application that can properly inspect/copy/construct 
a valuetype graph that appears in more than one argument of an 
invocation.  This also breaks the ability to write a generic bridge 
that can handle valuetypes. 

#4.  The interaction between valuetype truncation and conversion to a 
DynValue is underspecified. 

My first suggested solution to the problem was to declare that 
DynValue is actually a reflective interface that provides access 
directly to the members of an underlying real valuetype instance. 
This generated some pretty strong objections from a couple of RTF 
members and that stalled the discussion about a year ago. 

After quite a while to reflect on this, I've got another approach that 
avoids this problem.  However, it does have some implications that I 
want to air before working up a final proposal. 

The basic idea is to treat DynValue (and DynValueBox) as a proxy for a 
real valuetype with the same identity semantics.  This means that if I 
convert a graph of valuetypes into its representation as a collection 
of DynAny objects, each valuetype will be represented by a single 
DynValue instance, no matter where it appears in the graph. 

Along with this, we need operations added to DynAnyFactory to batch 
convert multiple anys to DynAnys and vice versa.  This batch 
conversion process will map the same valuetype instance to the same 
DynValue instance. 

As for truncation & DynValue, since the CCM spec has put a stake in 
the ground that a valuetype that remains in an Any should be able to 
be retransmitted by a server that does not know the specific type of 
that valuetype, it's clear to me that a mode of conversion to DynAny 
that avoids truncation is necessary, since otherwise we break DII/DSI 
and bridges again.  The DynAnyFactory might use the 
SendingContextRunTime service context or the IFR directly to lookup 
the complete TypeCode of the truncatable valuetype.  Also, the 
DynAnyFactory needs a new exception to indicate that it could not find 
the TypeCode of a truncatable valuetype. 

I think this solves the four problems listed above as follows: 

#1.  DynValue stands as a proxy for a valuetype instance that will be 
constructed when the DynValue is converted into a real valuetype 
embedded in an any.  It is not a reflective interface to a real 
valuetype instance with all of the baggage that entails. 

#2.  DynAny::equal for valuetypes should be defined as reference 
equality in order to get the same comparison semantics that we 
already have for valuetypes. 

#3.  The batch conversion operations on DynAnyFactory allow a DII/DSI 
to preserve the relationships between valuetypes when they are 
converted to DynValues and vice versa. 

#4.  When a truncatable valuetype is converted to a DynValue, the 
application can indicate that the valuetype not be truncated.  This 
allows generic DII/DSI applications to manipulate truncatable 
valuetypes correctly as long as the application can find the correct 
TypeCode for the valuetype.

Issue 3219: attributes and system exceptions (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: withdrawn by submitter
Revised Text:
Actions taken:
January 18, 2000: received issue
February 3, 2000: closed issue

Issue 3220: Does a value in a valuebox make sense? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Although legal in the CORBA 2.3 IDL grammar, creating a valuebox of
another valuebox or valuetype is of dubious use.  I can't see why having
an extra level of indirection here would ever be useful.  None of the
language mappings that have defined mappings for valuebox (C++, Java,
Ada) address this issue either.

Does it make sense to disallow valueboxing valueboxes or valuetypes?

Resolution: Incorporate changes and close issue.
Revised Text: In section 3.8.2 insert the following right before the paragraph that starts "The declaration of a boxed value type...": "Any IDL type may be used to declare a value box except for a valuetype."
Actions taken:
January 15, 2000: received issue
October 6, 2000: Incorporate changes and close issue.

Discussion:

It makes sense to disallow valueboxing of valuetypes. This was 
apparently the sense of the original OBV RTF, but it never got reflected in 
any text in the spec

Issue 3221: International Strings in Encapsulations (orb_revision)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

It seems that the only time an international string will ever appear in an
encapsulation
would be a private IOR component.  

If we can keep the issue down to International strings in encapsulations
this will
simplify the solution.   

If anyone has an example of how any other GIOP header string could carry an
international
string please come forth with it quickly.

The use of international strings in GIOP 1.1 and 1.2 is dependant on the
asserted use
of service context code set negotiation. In particular:
	1) if the negotiatiation is not initiated, then strings are passed
as latin-1 only and wstrings are not allowed to be passed as parameters.
	2) If the negotiation is initated and successfully completed, the
agreed codesets are used
respectively for string and wstring
	3) If negotiation is initated by no comon codeset is agreed, then
UTF-8 is the default for
string and UTF-16 is the default for Wstring (note: the current codeset
negotiation does not
discuss the big endian or litte endian aspects of UTF-16).

There is also text somewhere in GIOP stating that Encapsulations in IORs
should be
encoded in giop 1.0 for maximum interoperability.

It just occured to me that disallowing international strings in IOR
encapsulations (i.e., private
IOR components) is equivalent to assuming that negotiation is not initiated
for encapsulations.
This seems to be a consistent set of semantics.

The only problem with this interpretation, is that it does not allow
international strings
in IOR encapsulations.

Resolution: closed in interop/2000-05-01
Revised Text:
Actions taken:
January 17, 2000: received issue
March 7, 2002: moved to Core RTF

Issue 3250: Null valuetypes not supported by DynValue (orb_revision)

Click here for this issue's archive.
Source: IONA (Mr. Mark Spruiell, )
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Merge with 3135 and provide resolution as part of 3135
Revised Text:
Actions taken:
January 25, 2000: received issue
October 6, 2000: Merged with 3135 and closed

Issue 3258: Can native be used in constructed IDL types? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

CORBA 2.3.1, section 3.10.5 says:

"A native type may be used to define operation parameters and results.
However, there is no requirement that values of the type be permitted in
remote invocations, either directly or as a component of a constructed
type."

This is ambiguous as to whether a native type may be used in a
constructed IDL type that is intended to be used only locally:

// IDL

native MyNative;

struct MyStruct {
    MyNative	a_native;
};

So, should the first sentence in 3.10.5 be read to mean that native may
ONLY be used in parameters & results?  If so, we ought to put the word
"only" in there.

Resolution: Incorporate changes and close issue.
Revised Text: This is done by changing the two sentences in CORBA 2.3.1 section 3.10.5 that says: "A native type may be used to define operation parameters and results. However, there is no requirement that values of the type be permitted in remote invocations, either directly or as a component of a constructed type." to read: "A native type may be used only to define operation parameters and results. Native type parameters are permitted only in operations of local interfaces or valuetypes."
Actions taken:
January 26, 2000: received issue
February 27, 2001: closed issue

Discussion:

While the second sentence in the quoted text from 2.3.1 section 3.10.5 
alludes to using natives in constructed types, trying to generalize its 
use in general structs etc adds considerable complexity to marshaling 
time checking etc. So native should not be allowed anywhere else other 
than as parameter or return value type sepecification unless of course a 
very pressing use case is found for allowing it. Since we have not seen 
such a use case yet, it is prposed that native be restricted to 
specifying parameter types only.

Issue 3268: Editorial mistake in IDL chapter (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

On page 10-46 of the latest draft, at the end of section 10.6.5.2,
there are three paragraphs that talk about a SoftCo printer. It looks
like these are somewhere else in previous version and accidentally
got moved or left behind during the edition for the chapter.
(If that's a wrong guess, I'd like to know what they are doing there
because they most certainly don't contribute to the content of this
section ;-)

Resolution: Move the text in question to a more appropriate place as suggested below
Revised Text: Move the last three paragraphs of 10.6.5.2 to the beginning. Specifically, break the first para after the sentence ... sets the current prefix used in generating OMG IDL format RepositoryIds. Move the three paras in question from the end of 10.6.5.2 to here. Then continue with The specified prefix applies to... in a new para.
Actions taken:
February 2, 2000: received issue
October 6, 2000: Incorporate changes and close issue

Issue 3269: #pragma rules are too restrictive (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

I think the current rules for #pragma are too tight and we need to relax
them. In particular, for the ID pragma (page 10-43):

	If an attempt is made to assign a repository ID to the same
	IDL construct a second time, a compile-time diagnostic shall
	be emitted, regardless of whether the second ID is in conflict or not:

	interface A {};
	#pragma ID A "IDL:A:1.1"
	#pragma ID A "IDL:X:1.1" // Compile-time error

	interface B {};
	#pragma ID B "IDL:BB:1.1"
	#pragma ID B "IDL:BB:1.1" // Compile-time error

This causes problems with separate compilation. For example:

	// x.idl
	namespace Foo {
		// ...
	};
	#pragma ID Foo "IDL:blah:1.0"

	// y.idl
	namespace Foo {
		// ...
	};
	#pragma ID Foo "IDL:blah:1.0"

	// z.idl
	#include "x.idl"
	#include "y.idl"

The same problem arises with the version pragma, because I may want to
change the version in two different source files.

Resolution: Clarify as suggested
Revised Text: 1. Change the last paragraph of page 10-43 to read: An attempt to assign a repository ID to the same IDL construct a second time shall be an error unless the repository ID used in the attempt is identical to the previous one. 2. Change the first IDL example on page 10-44 to read: interface B {}; #pragma ID B "IDL:BB:1.1" #pragma ID B "IDL:BB:1.1" // OK, same ID 3. Change the sentence following this example to read: It is also an error to apply an ID to a forward-declared IDL construct (interfaces, valuetypes, structures, and unions) and then later assign a different ID to that IDL construct.
Actions taken:
February 4, 2000: received issue
October 6, 2000: Incorporate change and close issue.

Issue 3270: Minor glitch about forward declared things (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

When value types added forward declarations, and when we added forward
declarations for structs and unions, we forgot to update the version pragma
text. Currently, it says (page 10-45):

	Attempts to assign a prefix to a forward-declared interface
	and a different prefix to that interface later result in
	a compile-time diagnostic:

Proposal:

Change that sentence to read:

	Forward-declared constructs (interfaces, value types, structures,
	and unions) must have the same prefix in effect wherever they appear.
	Attempts to assign conflicting prefixes to a forward-declared
	construct result in a compile-time diagnostic. For example:

Resolution: Add the following clarification:
Revised Text: On page 10-45 (ptc/99-12-07) replace the sentence that reads: Attempts to assign a prefix to a forward-declared interface and a different prefix to that interface later result in a compile-time diagnostic: to read:: Forward-declared constructs (interfaces, value types, structures, and unions) must have the same prefix in effect wherever they appear. Attempts to assign conflicting prefixes to a forward-declared construct result in a compile-time diagnostic. For example:
Actions taken:
February 4, 2000: received issue
October 6, 2000: Incorporate changes and close issue

Issue 3302: Definition of COMPLETED_NO needs to be clarified (orb_revision)

Click here for this issue's archive.
Source: BROKAT Informationssysteme (Mr. Blake Biesecker, )
Nature: Uncategorized Issue
Severity:
Summary:

In order to resolve the OTS RTF issue 1819, we need
to have clearer wording regarding what COMPLETED_NO.

Since we now have the POA, the following phrase from
section 3.17 is not clear enough:

COMPLETED_NO The object implementation was never initiated prior to the exception being raised

In order to get proper rollback logic for transactions
that get system exceptions and, I'd imagine, to get
proper fault tolerant behavior, it needs to be made
clear that COMPLETED_NO means that absolutely no execution 
on the server took place prior to the exception being
raised. Without such a clarification, it is not possible 
to guarantee data integrity for fault tolerance and it 
forces the OTS to insist on a strict rollback policy when  
a system exception is raised.

In particular, with the advent of the POA, "object implementation"
is not as clear as it once was. Does this include servant
locators, for example.

As a place to start, I'd like to suggest this instead:

COMPLETED_NO No execution was initiated in the server prior to the exception being raised

(The archive for issue 1819 contains a lot more
discussion on this topic as it relates to the
OTS.)

Resolution: Close no change
Revised Text:
Actions taken:
February 8, 2000: received issue
October 30, 2000: closed issue

Discussion:

Given the myriads of possible configurations and scenarios that are 
possible exploiting the great flexibility that is afforded by the POA 
specification, it is not possible to nail down the semantics of 
COMPLETED_NO any more tightly than it is currently. Consequently this 
issue should be closed no change, as was informally agreed to at the 
Burlingame Core RTF meeting.

Issue 3305: valuetype factory inheritence? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The CORBA 2.3.1 Core specification is silent on the issue of whether
factories defined for a valuetype are "inherited" into derived
valuetypes.  I assume that there is no such inheritence.

Proposal:

Add to the end of the first paragraph in 3.8.1.5:

"Initializers defined in a valuetype are not inherited by derived
valuetypes."

Resolution: Add clarifying text as shown below:
Revised Text: Add to the end of the first paragraph in 3.8.1.5: "Initializers defined in a valuetype are not inherited by derived valuetypes, and hence the names of the initializers are free to be reused in a derived valuetype."
Actions taken:
February 9, 2000: received issue
October 6, 2000: Incorporate changes and close issue.

Issue 3319: symbolic constants for minor exception codes (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

in section 3.17.2, we show all the minor codes for exceptions. Unfortuantely,
these are all magic numbers rather than symbolic constants. In turn,
these means that I can't write portable code unless I use the magic numbers
directly.

It would be nice to have constant definitions for these instead, so I
can refer to minor numbers in the code without having to resort to
hard-wired magic numbers.

Resolution: Close no change.
Revised Text:
Actions taken:
February 16, 2000: received issue
October 6, 2000: Close no change.

Discussion:

I thought we could fix this by simply adding another column to the table that 
provided a symbolic name for each minor code, and a footnote to say that 
these symbolic names are provided for language mappings that want to make 
minor codes available at the API level as symbolic constants. However, 
the problem I have now is that the minor codes are quite numerous and are 
likely to continue to grow. In turn, this means that the symbolic names 
would probably have to be scoped by their "parent" exception name, otherwise 
it gets too hard to come up with unique names. 

I think we should just drop the issues as "too hard".

Issue 3329: Scope of inherited valuetype initializers (orb_revision)

Click here for this issue's archive.
Source: IONA (Mr. Mark Spruiell, )
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Same as Issue 3305, Therefore same resolution as 3305
Revised Text:
Actions taken:
February 17, 2000: received issue
October 6, 2000: Close as the same as 3305

Issue 3330: Valuetype "copying" semantics underspecified? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature:
Severity:
Summary:

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

Resolution: Merge with issue 3364 and close this issue
Revised Text:
Actions taken:
February 18, 2000: received issue
October 6, 2000: Merge with issue 3364 and close this issue

Issue 3337: BAD_QOS system exception (orb_revision)

Click here for this issue's archive.
Source: IONA (Mr. Matthew Newhook, )
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: closed issue, available in current draft
Revised Text:
Actions taken:
February 21, 2000: received issue
March 20, 2000: closed issue

Issue 3338: response_flags in interop draft (orb_revision)

Click here for this issue's archive.
Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com)
Nature: Uncategorized Issue
Severity:
Summary:

n the interop draft (ptc/00-02-04) the response_flags are defined now in terms 
of SyncScope. However, SyncScope does only apply to oneway, DII with 
INV_NO_RESPONSE, and sendc-stubs with no reply handler. The Messaging 
submission explicitly defines that it is ignored in the other cases.

from CORBA Messaging:

interface SyncScopePolicy

This interface is a local object derived from CORBA::Policy. It is applied to 
oneway
operations to indicate the synchronization scope with respect to the target of 
that
operation request. It is ignored when any non-oneway operation is invoked. This
policy is also applied when the DII is used with a flag of INV_NO_RESPONSE since
the implementation of the DII is not required to consult an interface 
definition to
determine if an operation is declared oneway. The default value of this Policy 
is not
defined. Applications must explicitly set an ORB-level SyncScopePolicy to ensure
portability across ORB implementations. When instances of SyncScopePolicy are
created, a value of type Messaging::SyncScope is passed to
CORBA::ORB::create_policy. This policy is only applicable as a client-side
override. The client�s SyncScopePolicy is propagated within a request in the
RequestHeader�s response_flags as described in GIOP Request Header.

Resolution: resolved in interop RTF
Revised Text:
Actions taken:
February 21, 2000: received issue
August 3, 2001: moved from core to Interop
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Discussion:

This is clearly an Interop issue. Transfer to the Interop RTF

Issue 3364: Problem with valuetype parameter copying (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Corba 2.3.1 section 5.2.4.3 states that valuetypes passed as parameters
are copied when passed into the receiving context.  Is this also true
for valuetypes that are embedded in a contructed IDL type passed as a
parameter?

Example:

// IDL

valuetype V { };

struct S {
    V	a_v;
};

interface I {
    S op(in S s1, inout S s2, out S s3);
};

When I::op is called are the valuetypes embedded in s1, s2, s3 and the
return value supposed to be copied when making a collocated call?

Example 2:

// IDL

interface J {
    any op(in any a1, inout any a2, out any a3);
};

If one of the any parameters to J::op contains a valuetype, must it be
copied before/after a collocated call?  What if the any contains a
struct S instead?

It seems to me we need to revisit the valuetype copying issue.  We have
three choices:

1.  Valuetypes are not copied for collocated calls.
2.  Only valuetypes as explicit parameters are copied for collocated
calls.
3.  All valuetypes are copied no matter how deeply they are nested in
parameters.

Currently the specification is ambiguous as to whether the semantics are
supposed to be case 2 or 3.  Case 3 is the only one that provides
guaranteed location transparency, but the cost to implement case 3 for
collocated calls far too high.  It would effectively require the same
overhead as marshalling/unmarshalling for any operation that has a
valuetype embedded in a complex IDL type or any.

So, given that transparency for collocated calls cannot be maintained
without high overhead, should we completely remove the copying
requirement because transparency cannot be maintained, or should we just
document that case 2 is the accepted semantic?

Resolution: resolved, see below
Revised Text: When this was brought up, there was a clear consensus that valuetype copying must occur everywhere, even for collocated invocations, and for valuetypes embedded in structured IDL types and in anys. However, I still think the wording in the spec needs to be improved to make this clear. Revised Text: Change section 5.2.4.3 from: "Identity Semantics When an instance of the value type is passed as a parameter, an independent copy of the instance is instantiated in the receiving context. That copy is a separate independent entity and there is no explicit or implicit sharing of state." to: "Identity Semantics When an instance of the value type is passed as a parameter to an operation of a non-local interface, the effect in all cases shall be as if an independent copy of the instance is instantiated in the receiving context. While certain implementation optimizations are possible the net effect shall be as if the copy is a separate independent entity and there is no explicit or implicit sharing of state. This applies to all valuetypes involved in the invocation, including those embedded in other IDL datatypes or in an any. This notional copying occurs twice, once for in and inout parameters when the invocation is initiated, and once again for inout, out and return parameters when the invocation completes. Optimization techniques such as copy on write etc. must make sure that the semantics of copying as described above is preserved."
Actions taken:
February 25, 2000: receive dissue
October 3, 2001: closed issue

Issue 3402: destroy on POA (orb_revision)

Click here for this issue's archive.
Source: Borland Software Corporation (Mr. Andy Cutright, acutright(at)borland.com)
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution: closed no change
Revised Text:
Actions taken:
March 6, 2000: received issue
October 6, 2000: Merged with issue 3436 and subsumed by it.

Discussion:

In section 21.7.2: Delete the following methods, exceptions and types. 



    register_initial_reference


    resolve_initial_references


    codec_factory


    InvalidName


    ObjectId



Add: 



    readonly attribute CORBA::ORB orb;



Add a new section to describe this attribute: 



    This attribute is the ORB being initialized.



In addition I propose two additions to the section: 

Proposal A:

The ORB shall be considered partially constructed in that any method invocations on objects created by this ORB will not have
request interceptors called. Calling work_pending()/perform_work()/run()/shutdown() or destroy() on the ORB is not
permitted and shall have undefined results. 

Proposal B: 

The ORB shall be considered partially constructed in that no method invocations on objects created by this ORB are
permitted. Calling work_pending()/perform_work()/run()/shutdown() or destroy() on the ORB is not permitted and shall have
undefined results. 

I prefer Proposal A since not being able to make method invocations implies that things that narrowing of object references is
not permitted. What this essentially means is that interceptors probably cannot be fully initialized in the ORB initializer. 



PIDL Mapping for C++:





[I'm not sure exactly how this should look -- this is essentially


trimmed output from out IDL translator]





namespace PortableInterceptor


{





class ORBInitInfo : virtual public CORBA::Object


{


public:





    static inline ORBInitInfo_ptr


    _duplicate(ORBInitInfo_ptr p)


    {


        if(p)


            p -> _OB_incRef();


        return p;


    }





    static inline ORBInitInfo_ptr


    _nil()


    {


        return 0;


    }





    static ORBInitInfo_ptr _narrow(CORBA::Object_ptr);


    static ORBInitInfo_ptr _narrow(CORBA::AbstractBase_ptr);





    struct DuplicateName : public CORBA::UserException


    {


        DuplicateName() { }


        DuplicateName(const DuplicateName&);


        DuplicateName& operator=(const DuplicateName&);





        static DuplicateName* _downcast(CORBA::Exception*);


        static const DuplicateName* _downcast(const CORBA::Exception*);


        virtual void _raise() const { throw *this; }


        virtual const char* _name() const;


        virtual const char* _rep_id() const;


        virtual char* _to_string() const;





        DuplicateName(const char*);


    };





    virtual CORBA::StringSeq* arguments() = 0;





    virtual char* orb_id() = 0;





    virtual CORBA::ORB_ptr orb() = 0;





    virtual void add_client_request_interceptor(ClientRequestInterceptor_ptr interceptor) = 0;





    virtual void add_server_request_interceptor(ServerRequestInterceptor_ptr interceptor) = 0;





    virtual void add_ior_interceptor(IORInterceptor_ptr interceptor) = 0;





    virtual SlotId allocate_state_slot() = 0;





    virtual void register_policy_factory(CORBA::PolicyType type,


                                         PolicyFactory_ptr policy_factory) = 0;


};





class ORBInitializer : virtual public CORBA::Object


{


public:





    static inline ORBInitializer_ptr


    _duplicate(ORBInitializer_ptr p)


    {


        if(p)


            p -> _OB_incRef();


        return p;


    }





    static inline ORBInitializer_ptr


    _nil()


    {


        return 0;


    }





    static ORBInitializer_ptr _narrow(CORBA::Object_ptr);


    static ORBInitializer_ptr _narrow(CORBA::AbstractBase_ptr);





    virtual void pre_init(ORBInitInfo_ptr info) = 0;





    virtual void post_init(ORBInitInfo_ptr info) = 0;


};





} // End of namespace PortableInterceptor





namespace CORBA


{





inline void


release(PortableInterceptor::ORBInitInfo_ptr p)


{


    if(p)


        p -> _OB_decRef();


}





inline Boolean


is_nil(PortableInterceptor::ORBInitInfo_ptr p)


{


    return p == 0;


}





} // End of namespace CORBA





//


// IDL:omg.org/PortableInterceptor/ORBInitializer:1.0


//


namespace CORBA


{





inline void


release(PortableInterceptor::ORBInitializer_ptr p)


{


    if(p)


        p -> _OB_decRef();


}





inline Boolean


is_nil(PortableInterceptor::ORBInitializer_ptr p)


{


    return p == 0;


}





} // End of namespace CORBA



PIDL mapping for Java (still to be supplied...)

Issue 3436: POA status during destruction is unclear (orb_revision)

Click here for this issue's archive.
Source: Cisco Systems (Mr. Paul Kyzivat, pkyzivat(at)cisco.com)
Nature: Uncategorized Issue
Severity:
Summary:

The description of POA destroy in section 11.3.8.4 is unclear.
There are several ways to implement this, which may result in problems
porting application code between orbs.

Some of the ambiguities are:

1) It may or may not be legal for an application to create new child POAs
while the existing children are being destroyed. This could happen
explicitly or via AdapterActivators. Such behavior could prevent destruction
from ever completing.

2) If the POA's POAManager is in the holding state at the time of
destruction (or if its state is changed to holding during the destruction
process), it isn't clear what happens to the held requests.

3) If the POA's POAManager is active, what happens to requests that arrive
after the call to destroy but before the destruction becomes apparent? If
they are to be serviced, a sufficiently rapid arrival rate may prevent the
destruction from ever completing.

Resolution: Clarify POA behavior during destruction as described below
Revised Text: 1. Following the statement "When destroy is called the POA behaves as follows" in section 11.3.8.4, replace the bullet list with: * The POA assumes the DISCARDING state except when its POAManager is in the INACTIVE state in which case the POA assumes the INACTIVE state. Any further changes to the POAManager's state do not affect this POA. * The POA disables the create_POA operation. Subsequent calls to create_POA will result in a BAD_INV_ORDER system exception with standard minor code yyy. * The POA calls destroy on all of its immediate descendants. * 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. At this point, apparent destruction of the POA has occurred. * After destruction has become apparent, the POA may be re-created via either an AdapterActivator or a call to create_POA. * If the etherealize_objects parameter is TRUE, the POA has the RETAIN policy, and a servant manager is registered with the POA, the etherealize operation on the servant manager is called for each active object in the Active Object Map. The apparent destruction of the POA occurs before any calls to etherealize are made. Thus, for example, an etherealize method that attempts to invoke operations on the POA receives the OBJECT_NOT_EXIST exception. * If the POA has an AdapterActivator installed, any requests that would have caused unknown_adapter to be called cause a TRANSIENT exception with standard minor code xxx to be raised instead. 2. Add new standard minor codes for the following exceptions in section 4.11.4: BAD_INV_ORDER yyy POA cannot create POAs while undergoing destruction. TRANSIENT xxx POA destroyed.
Actions taken:
March 22, 2000: received issue
February 27, 2001: closed issue

Issue 3439: return type of TypeCode::fixed_scale() (orb_revision)

Click here for this issue's archive.
Source: AdNovum Informatik (Mr. Stefan Wengi, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

in 10.7.1 the fixed_scale() operation is defined to return a short but
the 'scale' value of a fixed type is defined to be a positive integer
(in 3.4 (96)) and also in the C++ mapping.
It seems to me there is some inconsistency here.

Resolution: Close no change.
Revised Text:
Actions taken:
March 22, 2000: received issue
October 6, 2000: Close no change.

Issue 3441: POA namespace and ORB ID (orb_revision)

Click here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

Section 4.6 of CORBA 2.3.1 addresses the meaning of the ORBid argument.  It is clear
that ORB_init can be called multiple times in the same address space resulting in
different ORBs.  I think the CORBA spec should make it clear that all of these ORBs
have different POA namespaces.  This should probably be indicated in section 11.2.3
by stating something like:

If an application makes use of multiple ORBs in the same address space, each
ORB defines its own separate POA namespace.  In particular, each ORB returns a
distinct root POA in response to a resolve_initial_references( "RootPOA" )
call.

Resolution: Clarifying sentence is justified.
Revised Text: Add to the end of section 11.2.3 of orbrev/00-09-01: Each distinct ORB created as the result of an ORB_init call in an application has its own separate root POA and POA namespace. Actions taken: Incorporate change and close issue.
Actions taken:
March 22, 2000: received issue
October 30, 2000: closed issue

Issue 3443: how are valid ORBids determined (orb_revision)

Click here for this issue's archive.
Source: Cisco Systems (Mr. Paul Kyzivat, pkyzivat(at)cisco.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 4.5.1 of the CORBA core document explains the ORBid argument to
ORBinit. However, it is sufficiently vague to present implementation and
usage problems. 

It says: 

	"All ORBid strings other than the empty string are allocated
	by ORB administrators and are not managed by the OMG." 

It fails to define ORB administrator. This administrator could be the
developer of the application calling the ORB, or it could be the
administrator of the machine on which the ORB will run, or it could be the
developer of the ORB itself. Each answer to this question may result in a
different mechanism for determining if a supplied ORBid is valid.

Resolution: Incorporate change and close issue
Revised Text: After the above quoted sentence, add the following: "ORB administration is the responsibility of each ORB supplier. ORB suppliers may optionally delegate this responsibility."
Actions taken:
March 22, 2000: received issue
February 27, 2001: closed issue

Discussion:

Not much can further can be said about this ecept for clarifying that ORB suppliers may allow someone else to
specify this for a particular installation, and leave it at that.

Issue 3449: POA deactivate_object description is ambiguous (orb_revision)

Click here for this issue's archive.
Source: Borland Software Corporation (Mr. Vishy Kasar, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

CORBA 2.3.1 section 11.2.8.17 states that "An ObjectId which has been
deactivated continues to process requests until there are no active
requests for that ObjectId"

In the short window where  deactivate_object is called but object is not

yet deactivated, the above sentence is open to interpretation. The 2
interpretation are:

1. Active requests are those requests that came *before*
deactivate_object was called. In this case, POA continues to service
those requests and throws OBJECT_NOT_EXIST for future requests if the
object is not activable.

2. Active requests are *any* requests. In this case, POA will continue
to service  requests that come even  after deactivate_object was called
as long as deactivation is not complete.

So what is the intended interpretation? I suspect it is 1. If so, can we

make this section clearly state that?

Resolution: Incorporate changes and close issue
Revised Text: In section 11.3.8.17 on page 11-37 of orbrev/00-09-01, immediately following th sentence in para 2 that reads: "An ObjectId which has been deactivated continues to process requests until there are no active requests for that ObjectId", insert the following sentence: "Active requests are those requests that arrived before deactivate_object was called."
Actions taken:
March 23, 2000: received issue
February 27, 2001: closed issue

Discussion:

Clarify the meaning of active object in this context. It is 
not clear that anything needs to be said about OBJECT_NOT_EXIST here. 
The description further down says that reactivation is blocked until 
deactivation is complete. Presumably whether reactivation succeed or an 
OBEJCT_NOT_EXIST is raised is a matter for the reactivation process, and 
not a concern of the deactivation process.

Issue 3460: ORB mediation for servant managers, references for servant managers? (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

Two questions:

	1) Are calls to operations on servant managers mediated by the ORB?

	2) Is it legal to export the object reference for a servant manager
	   to another process?

For question 1, the answer would appear to be no. Here is why:

	Page 11-17:

	Inactive state

	When a POA manager is in the inactive state, the associated POAs
	will reject new requests. [...] If the client is co-resident in
	the same process, the ORB could raise the OBJ_ADAPTER system
	exception, with standard minor code 1, to indicate that the
	object implementation is unavailable. [...]

	If the transition into the inactive state is a result of calling
	deactivate with an etherealize_objects parameter of

	- TRUE - the associated POAs will call etherealize for
	  each active object associated with the POA once all
	  currently executing requests have completed processing
	  (if the POAs have the RETAIN and USE_SERVANT_MANAGER
	  policies). If a servant manager has been registered for
	  the POA, the POA will get rid of the object. If there
	  are any queued requests that have not yet started
	  executing, they will be treated as if they were new
	  requests and rejected.

If calls to servant managers were to be ORB-mediated, the calls to
etherealize() cannot possibly be dispatched because the corresponding
servant manager is already in the inactive state. The only logical conclusion
I can see is that calls to servant managers are not mediated by the ORB.

I think the spec should be updated to state this.

For question 2, the answer would also appear to be no:

Exporting a reference to a servant manager outside my own address space
makes no sense whatsoever. Here a servant manager offers either
incarnate() and etherealize(), or it offers preinvoke() and postinvoke().
These are the *only* operations that are possible (apart from operations
on Object). If it were possible to export a reference to a servant
manager to another address space, there is nothing the receiver of
the reference could do with it (other than call operations on Object).
That's because incarnate(), etherialize(), and preinvoke use a native
type (servant). postinvoke() doesn't use a native type, but
accepts a parameter of type POA, so postinvoke cannot be invoked
remotely either (because POA is locality constrained and its
reference cannot be marshaled).

So, it appears clear that export of servant manager references should be
illegal and flagged the same way as an attempt to export a POA manager
reference.

The spec currently says this about servant managers:

	A ServantManager object must be local to the process containing
	the POA objects it is registered with.

Contrast this with POA managers, for which the spec says:

	A POAManager object must not be exported to other processes,
	or externalized with ORB::object_to_string. If any attempt is
	made to do so, the offending operation will raise a MARSHAL
	system exception. An attempt to use a POAManager object with
	the DII may raise the NO_IMPLEMENT exception.

To me, it looks like we should say the same thing for servant managers as
for POA managers.

And, by the same reasoning, I think it also must be said for the
AdapterActivator interface: it doesn't make sense to marshal a reference
for an adapter activator because the only operation (unknown_adapter) has
an in parameter of type POA, which cannot come from a remote location.

Resolution: Merge into Issue 4264 and close this with the resolution of 4264.
Revised Text: Resolution: Both POAManager and ServantManager are specified to be "local" objects in the adopted Component specification. Those changes are incorporated into the Core Chapter 11 through the resolution of issue 4264, thus removing the ambiguity raised in this issue. 1) ServantManagers are not mediated by ORB. 2) It is not legal to export object references to ServantManagers since ServantManagers are local objects. Hence with the adoption of the resolution for Issue 4264, this issue can also be closed.
Actions taken:
March 28, 2000: received issue
October 3, 2001: closed issue

Issue 3525: Inheritance description incorrect (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

On page 3-46, CORBA 2.3, we have some old words that got forgotten during
the scope resolution rule cleanup we did some time ago:

	Inheritance produces shadow copies of the inherited identifiers;
	that is, it introduces names into the derived interface, but these
	names are considered to be semantically the same as the original
	definition. Two shadow copies of the same original (as results
	from the diamond shape in Figure 3-1 on page 3-21) introduce a
	single name into the derived interface and don't conflict with
	each other.

That's wrong because it confuses visibility of an identifier with introduction
of an identifier (which are different things). I would suggest to reword
as follows:

	Inheritance produces shadow copies of the inherited identifiers;
	that is, inherited identifiers are visible in derived interfaces.
	Such identifiers are considered to be semantically the same as
	the original definition. Two shadow copies of the same original (as
	results from the diamond shape in Figure 3-1 on page 3-21) do
	not conflict with each other.

This simply gets rid of the word "introduces", which has the wrong meaning.

Note that these words have been wrong all along, even before we changed
the name lookup rules. That's because, if inherited identifiers were
indeed introduced into the derived interface, the following would be illegal
(but has in fact never been illegal):

	interface B {
		typedef string S;
	};

	interface D : B {
		typedef long S;
	};

Resolution: Fix as suggested below
Revised Text: 1. On page 3-46, CORBA 2.3, replace the following paragraph: Inheritance produces shadow copies of the inherited identifiers; that is, it introduces names into the derived interface, but these names are considered to be semantically the same as the original definition. Two shadow copies of the same original (as results from the diamond shape in Figure 3-1 on page 3-21) introduce a single name into the derived interface and don't conflict with each other. by: Inheritance causes all identifiers defined in base interfaces, both direct and indirect, to be visible in derived interface. Such identifiers are considered to be semantically the same as the original definition. Multiple paths to the same original identifier (as results from the diamond shape in Figure 3-1 on page 3-21) do not conflict with each other. 2. In Section 3.7.5 on Page 3-2, replace the following sentence: "Interface inheritance causes all identifiers in the closure of the inheritance tree to be imported into the current naming scope." by: "Interface inheritance causes all identifiers defined in base interfaces, both direct and indirect, to be visible in the current naming scope."
Actions taken:
March 31, 2000: receive dissue
October 6, 2000: Incorporate change and close issue

Issue 3560: ValueMemberDef section omitted from CORBA 2.3.1 spec (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

In the CORBA 2.3.1 99-10-07.pdf spec, where "The Interface Repository
chapter has been updated based on CORE changes from
ptc/98-09-04 and the Object by Value documents (orbos/98-01-18 and
ptc/98-07-06).", ValueMemberDef is not fully documented.

ValueMemberDef should have it's own section in the Interface Repository
chapter but it does not.  This would contain it's IDL and at least two
subsections, one for the read interface and one for the write interface.

Resolution: Missing section should be filled in
Revised Text: 1. Insert the following new sections immediately following the current section 10.5.24 "AbstractInterfaceDef" (c.f. ptc/00-03-02): 10.5.25 ValueMemberDef A ValueMemberDef IR Object represents a value member. typedef short Visibility; const Visibility PRIVATE_MEMBER = 0; const Visibility PUBLIC_MEMBER = 1; interface ValueMemberDef : Contained { readonly attribute TypeCode type; attribute IDLType type_def; attribute Visibility access; }; 10.5.25.1 Read Interface The type attribute provides the TypeCode describing the type of this value member. The type_def attribute identifies the object defining the type of this value member. The access attribute specifies private or public access for this value member. The describe operation for a ValueMemberDef object returns a ValueMember. 10.5.25.2 Write Interface Setting the type_def attribute also updates the type attribute. 2. Remove the following lines of IDL from the IDL in (old) section 10.5.25 "ValueDef", since they have now been placed in the ValueMemberDef section: typedef short Visibility; const Visibility PRIVATE_MEMBER = 0; const Visibility PUBLIC_MEMBER = 1; interface ValueMemberDef : Contained { readonly attribute TypeCode type; attribute IDLType type_def; attribute Visibility access; };
Actions taken:
April 13, 2000: received issue
October 6, 2000: Incorporate changes and close issue

Issue 3564: Typo on page 7-9 of 2.3.1 (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

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();

Resolution: closed issue...editorial
Revised Text:
Actions taken:
April 14, 2000: received issue
April 14, 2000: closed issue

Issue 3566: is_equivalent and policies (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

How should is_equivalent() behave if I compare two references that denote
the same object at the same location, using the same profiles, etc, but
differ in the policies? Do differences in the policies affect the outcome?

My gut feeling is that is_equivalent() should return false in this case
because it uses reference identity, not object identity. However, we
are rapidly approaching the point where is_equivalent() might as well
unconditionally return false because we are adding more and more flavours
of additional information into IORs as time goes by. Invocation policies,
transaction policies, codesets, multiple profiles, optional components,
etc, etc.

Does is_equivalent() require a more precise definition in order to remain
useful?

Resolution: Incorporate changes and close issue
Revised Text: Append the following sentence to the second paragraph in section 4.3.6.2 "Equivalence Testing" of orbrev/00-09-01, page 4-16: "Setting of local policies on the object reference is not taken into consideration for the purposes of determining object reference equivalence".
Actions taken:
April 15, 2000: received issue
February 27, 2001: closed issue

Discussion:

s_equivalent does not take into consideration any local policies that are set on the object reference in order to arrive at its result.
Clarify this.

Issue 3581: Incorrect use of negative fixed scale (orb_revision)

Click here for this issue's archive.
Source: Cisco Systems (Mr. Paul Kyzivat, pkyzivat(at)cisco.com)
Nature: Uncategorized Issue
Severity:
Summary:

In section 3.9.2 (of ptc/99-12-07) on semantics of constants,
an example is given showing 3000.00D being of type fixed<1,-3>.
This is inconsistent with statements elsewhere that fixed scale is a
non-negative quantity.

Also, the preceding explanation states: "... leading and trailing zeros are
factored out, INCLUDING NON-SIGNIFICANT ZEROS BEFORE THE DECIMAL POINT."
This rule of course leads to negative scale factors, so it must also be
incorrect.

Suggested Revision:

Change the following text:

"A fixed-point literal has the apparent number of total and fractional
digits, except leading and trailing zeros are factored out, including
non-significant zeros before the decimal point. For example, 0123.450d is
considered to be fixed<5,2> and 3000.00d is fixed<3,-1>."

to:

"A fixed-point literal has the apparent number of total and fractional
digits, except leading zeros before the decimal point and trailing zeros
after the decimal point are factored out. For example, 0123.450d is
considered to be fixed<5,2> and 3000.00d is fixed<4,0>."

Resolution: Remove the specification for stripping leading and trailing zeros, and fix the examples accordingly
Revised Text: Change the following text in section 3.9.2 page 3-31 of orbrev/00-09-01:: "A fixed-point literal has the apparent number of total and fractional digits, except leading and trailing zeros are factored out, including non-significant zeros before the decimal point. For example, 0123.450d is considered to be fixed<5,2> and 3000.00d is fixed<3,-1>." to: "A fixed-point literal has the apparent number of total and fractional digits. For example, 0123.450d is considered to be fixed<7,3> and 3000.00d is fixed<6,2>."
Actions taken:
April 25, 2000: received issue
February 27, 2001: closed issue

Issue 3582: Section 4.3.7.1 get_client_policy? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: temporary bug....fixed, and issue closed
Revised Text:
Actions taken:
April 27, 2000: received issue
April 27, 2000: closed issue

Issue 3589: Valuetypes with multiple interfaces (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

consider the following, which as valid IDL as best as I can figure out:

	interface I1 {};
	abstract valuetype V1 supports I1 {};

	interface I2 {};
	abstract valuetype V2 supports I2 {};

	interface I3 {};
	valuetype V3 : V1, V2 supports I3 {};

The above raises some *very* interesting issues. For one, this can't be
mapped into C++ for a number of reasons (largely having to do with
ambiguous multiple inheritance). However, there much deeper issues here
relating to the object model. Some questions:

	- What is the type of the a V3 instance?

	- What is the repository ID of that instance?

	- What is the return value of a call to _this()?

	- What is the result of invoking

		is_a("IDL:I1");
		is_a("IDL:I2");
		is_a("IDL:I3");
	
	  on an I3 reference?
	
	- What are the results of I1::narrow(), I2::narrow(), and I3::narrow()
	  on an I3 reference?

	- What is returned by a call to get_interface()?

	- What are the results of traversing the above in an IFR?

There are probably more questions along these lines. They all aim at
the fact that the above construct effectively creates an object that has
multiple unrelated interfaces. This flies in the face of the CORBA
type system, which fundamentally requires every object to have exactly
one most-derived type.

I think we need to put the axe through constructs such as the one above
in a hurry!

Resolution: Resolve no change with explanation as above.
Revised Text:
Actions taken:
April 28, 2000: received issue
February 27, 2001: closed issue

Discussion:

The issue is based on a reading of the text that is fixed in issue 3072. The clarified text in issue 3072 makes this issue
go away.

Issue 3607: POA servant_to_id inconsistent with servant_to_reference (orb_revision)

Click here for this issue's archive.
Source: Humboldt-Universitaet (Mr. Martin von Loewis, loewis(at)informatik.hu-berlin.de)
Nature: Uncategorized Issue
Severity:
Summary:

In CORBA 2.3, servant_to_id does not work if the POA has the RETAIN,
MULTIPLE_ID, and NO_IMPLICIT_ACTIVATION policies, even if
servant_to_id is invoked in the context of the specified servant.
According to 11.3.8.20, such a call raises WrongPolicy.

Inconsistent with that specification, it is apparently still possible
to obtain the ID for that servant, using

id = poa.reference_to_id(poa.servant_to_reference(self))

This works since 11.3.8.21/3 supports all cases of currently-active
servant, not only USE_DEFAULT_SERVANT

Resolution: Same as Issue 3636, and is fixed by the fix for 3636.
Revised Text:
Actions taken:
May 10, 2000: received issue
October 30, 2000: closed issue

Issue 3608: ORB shutdown vs destroy (orb_revision)

Click here for this issue's archive.
Source: Borland Software Corporation (Mr. Vishy Kasar, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

CORBA2.3.1 section 4.11.5 destroy() has following information.

Once an ORB is destroyed, another call to ORB_init with same ORBid will
return a reference to a newly constructed ORB.

My assumption here is if I call shutdown() on an ORB followed by
ORB_init() with the same ORBid as of the shutdown ORB, I get the same
ORB back. Essentially, we can not get rid of that ORB until destroy() is
called. Is this a valid assumption? If so, can we add a sentence to that
effect to shutdown() section?

Resolution: Incorporate changes and close issue
Revised Text: Append the following paragraph to section 4.5.1 "ORB Initialization" on page 4-29 of orbrev/00-09-01: "If ORB_init is called with an ORBid of an ORB than has been shutdown but not destroyed, then it shall return the ORB that was shut down in the shutdown state. It is not possible to reinitialize this ORB. See section 4.2.3.4 for properties of ORBs that are in the shutdown state."
Actions taken:
May 12, 2000: received issue
February 27, 2001: closed issue

Discussion:

Clarify two things: 
1. ORB_init in this case will return the same ORB in a shutdown state. 
2. The only thing that can be done with such an ORB are as described in section 4.2.3.4 last paragraph.. 
3. Invocation of any other operation of such an ORB that has been shutdown will cause the BAD_INV_ORDER standard system
exception to be raised with minor code foo. This is actually stated to be so in the last para of section 4.2.3.4 of orbrev/00-09-01 so
needs no additional text.

Issue 3612: Some problems (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity:
Summary:

I thought there are some error in Grammer which number are (24) and (27).
The grammer which number is 24 in specification is 
<init_param_decls> ::= <init_param_decl> { "," <init_param_decl> }
 
I thought it may be  <init_param_decls> ::= <init_param_decl> { "," <init_param_decl> } *
Can you see asterisk?
 
And grammer number 27 is miss-printing.
 
It is all of my question in grammer and next problem is in Preprocessing.
User can use #include for source inclusion.
But in case of C++, there are two kind of source inclusion. One is standard library inclusion using angle brackets.
Another is using quotation mark.
Is the rule adapted in IDL preprocessor?
Could you send me a document about Preprocessing rule?
 
Another question is #ifdef, #ifndef.
Is this option able to be duplicated?
 
Last question is about position of inclusion command.
In some example in specification 2.3, I find this example.
 
module M{
    #include <E.idl>
};
 
- from CORBA V2.3, June 1999, 10-43
 
The source inclusion command - #incude - is in module block.
How that source will be compiled and mapped?
I thought that source is wrong....

Resolution: Close no change with explanation as above.
Revised Text:
Actions taken:
May 15, 2000: received issue
June 23, 2000: moved from Java RTF to Core RTF
October 30, 2000: closed issue

Discussion:

The specific change requested has already been made by an earlier RTF. 
This has already been fixed in CORBA 2.4 draft. See 
ptc/00-05-02. Closethis one NO change, or better still don't 
even create an issue. 

> It is all of my question in grammer and next problem is in 
  Preprocessing. 
> User can use #include for source inclusion. 
> But in case of C++, there are two kind of source inclusion. One is 
  standard 
> library inclusion using angle brackets. 
> Another is using quotation mark. 
> Is the rule adapted in IDL preprocessor? 

Yes. 

> Could you send me a document about Preprocessing rule? 

See the C++ preprocessor standard document, the IDL specification 
includes the definition of include statement by reference to the C++ 
preprocessor standard. 

> Another question is #ifdef, #ifndef. 
> Is this option able to be duplicated? 

I don't understand the question. It is exactly the same as in the C++ 
preprocessor. 

> Last question is about position of inclusion command. 
> In some example in specification 2.3, I find this example. 
> 
> module M{ 
>   #include <E.idl> 
> }; 
> 
> - from CORBA V2.3, June 1999, 10-43 
> 
> The source inclusion command - #incude - is in module block. 
> How that source will be compiled and mapped? 
> I thought that source is wrong....<BR> 

The contents of E.idl will be inserted at the point where the 
#include statement appears and then the resulting character stream 
willbe parsed by the IDL compiler. I guess, again I don't understand the 
question.

Issue 3614: Policy Management in the ORB core (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

(All document refs to ptc/00-03-02, but I think the relvant sections are the
same in ptc/00-04-05)

(a) Sec. 4.3.7.1 (Object::get_policy) says that the "effective Policy is the
intersection of the values allowed by the effective override and the
IOR-specified Policy."  What does this mean?  For example, the example
MyPolicy given in 4.8.5 appears to define some range or interval, so the
intersection of two MyPolicy objects has some meaning - but I doubt if it's
reasonable to expect the ORB to deduce that.

I suggest that the effective policy is:

- any override of that type if there is one, else
- any IOR-specified policy of that type if there is one, else
- the system default of that type if there is one, else
- the null Policy reference (or a system exception? which?).

This is feasible and consistent with normal meaning of "override" as
"replace", not "modify".

(b) Sec. 4.3.7.2 (Object::get_client_policy) suggests that the ORB searches
the object's overrides, then PolicyCurrent's overrides, then PolicyManager's
overrides.  If it can't find any in those, then it can return the system
default.  I suggest the system default be left out of this search - it's not
an override, it's a final default - and that we define what happens if no
policy of the right type can be found, either null or a system exception.

(c) Sec. 4.3.8.1 (Object::set_policy_overrides) and sec. 4.9.3.1
(PolicyManager::set_policy_overrides) both allow the existing set of
overrides either to be replaced or to be extended.

If the set is to be extended, and the new overrides contain a Policy of a
type for which there is already an override, should the supplied Policy
(1) replace the existing Policy silently, or
(2) be ignored silently, or
(3) cause a system exception (and which)?

Whatever the value of 'set_add', if the supplied Policy list contains two
Policies of the same type, which one prevails, if any?  I suggest
"implementation defined", but we could mandate a system exception.

Resolution: Incorporate changes and close issue
Revised Text: (All references to ptc/00-05-02) Sec. 4.3.7.1 (Object::get_policy): In the first paragraph, replace: " ... This Policy is determined first by obtaining the effective override for the PolicyType as returned by get_client_policy. The effective override is then compared with the Policy as specified in the IOR. The effective Policy is the intersection of the values allowed by the effective override and the IOR-specified Policy. If the intersection is empty, the standard system exception INV_POLICY is raised. Otherwise, a Policy with a value legally within the intersection is returned as the effective Policy. The absence of a Policy value in the IOR implies that any legal value may be used. Invoking non_existent ... " by: " ... This Policy is determined first by obtaining the effective override for the PolicyType as returned by get_client_policy. The effective override is then compared with the Policy as specified in the IOR. The effective Policy is determined by reconciling the effective override and the IOR-specified Policy (see section 4.9.2). If the two policies cannot be reconciled, the standard system exception INV_POLICY is raised. The absence of a Policy value in the IOR implies that any legal value may be used. Invoking non_existent ..." Sec 4.3.8.1 (Object::set_policy_overrides) In the 'parameters' section, replace: " policies - a sequence of Policy objects that are to be associated with the new copy of the object reference returned by this operation. set_add - whether the association is in addition to (ADD_OVERRIDE) or as replacement of (SET_OVERRIDE) any existing overrides already associated with the object reference. " by: " policies - a sequence of Policy objects that are to be associated with the new copy of the object reference returned by this operation. If the sequence contains two or more Policy objects with the same PolicyType value, the operation raises the standard sytem exception BAD_PARAM with minor code xxx. set_add - whether the association is in addition to (ADD_OVERRIDE) or as a replacement of (SET_OVERRIDE) any existing overrides already associated with the object reference. If SET_OVERRIDE is supplied, the supplied policies completely replace all existing overrides associated with the object reference. If ADD_OVERRIDE is supplied, the supplied policies are added to the existing overrides associated with the object reference, except that if a supplied Policy object has the same PolicyType value as an existing override, the supplied Policy object replaces the existing override. " Sec 4.9.3.1 (interface PolicyManager): In the 'Parameter' section for the set_policy_overrides operation, replace: " policies a sequence of policies the are to be overridden. set_add specifies whether these policies are to be added as replacement for existing poslicies [sic] or simply added to the existing set of policies. " by: " policies a sequence of Policy objects that are to be associated with the PolicyManager object. If the sequence contains two or more Policy objects with the same PolicyType value, the operation raises the standard sytem exception BAD_PARAM with minor code xxx. set_add whether the association is in addition to (ADD_OVERRIDE) or as a replacement of (SET_OVERRIDE) any existing overrides already associated with the PolicyManager object. If SET_OVERRIDE is supplied, the supplied policies completely replace all existing overrides associated with the PolicyManager object. If ADD_OVERRIDE is supplied, the supplied policies are added to the existing overrides associated with the PolicyManager object, except that if a supplied Policy object has the same PolicyType value as an existing override, the supplied Policy object replaces the existing override. " Sec 4.11.4 (Standard Minor Exception Codes): Add a new minor code for the exception BAD_PARAM with value xxx (to be allocated by OMG), and the explanation: " Two or more Policy objects with the same PolicyType value supplied to Object::set_policy_overrides or PolicyManager::set_policy_overrides.
Actions taken:
May 15, 2000: received issue
February 27, 2001: closed issue

Discussion:

The necessary rationale for Policy management is in 4.9.1 after all. 

So the proposed resolution is now confined to a 
relatively minor clarification in 4.3.7.1 and error cases in 4.3.8.1 & 
4.9.3.1. 

The key elements are as follows: 

Sec. 4.3.7.1 (Object::get_policy): 

We no longer talk about the 'intersection' of the effective override and the 
IOR policy but use 'reconciliation' and reference 4.9.2 for its meaning. 
  

Sec. 4.3.7.2 (Object::get_client_policy): 

No change; this is still OK because it's talking about the policies set 
somewhere on the client side (including the default). 
  

Sec 4.3.8.1 (Object::set_policy_overrides) & 
Sec 4.9.3.1 (PolicyManager::set_policy_overrides): 

1) When the set_add parameter is ADD_OVERRIDE and the policies parameter 
contains a policy 'new' whose type is the same as an existing override 
'old', 'new' replaces 'old' in the updated list of overrides. 

2) When the policies parameter contains two or more policies of the same 
type, the operations raise BAD_PARAM with some minor code t.b.d.

Issue 3618: ORB::shutdown underspecified (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

If I call ORB::shutdown(), it implicitly calls POA::destroy() on the
Root POA.

I assume that the value of the wait_for_completion parameter to
ORB::shutdown() should be passed through to POA::destroy()? The spec isn't
entirely clear on this point.

Further, what is the effect of calling ORB::shutdown() on the value
of the etherealize_objects parameter for POA::destroy()? Since ORB::shutdown()
doesn't have an etherealize_objects parameter itself, the value passed
through to POA::destroy must be implicit, but the spec doesn't say what
it is.

Similarly, ORB::destroy() implicitly calls ORB::shutdown(). From the
second-last para on page 4-35, it would appear that this implicit call
is made as ORB::shutdown(true) rather than ORB::shutdown(false). It
might be nice to make this explicit so I don't have to read between the
lines to figure it out.

Resolution: Incorporate changes and close issue.
Revised Text: 1. In orbrev/00-09-01 in section 4.2.3.4 "shutdown", insert the paragraph immediately preceding the 5th paragraph that begins "While the ORB is in the process....": "Additionally,in systems that have Portable Object Adapters (POA Ref Chapter 11) shutdown behaves as if POA::destroy is called on the Root POA with its first parameter set to TRUE and the second parameter set to the value of the wait_for_completion parameter that shutdown is invoked with." 2. In orbrev/00-09-01 section 4.2.3.5 second paragraph, insert the following sentence immediately following the first sentence: "The behavior is similar to that achieved by calling shutdown with the wait_for_completion parameter set to TRUE."
Actions taken:
May 17, 2000: received issue
February 27, 2001: closed issue

Discussion:

Yes, it should be clarified that the apparent behavior of the system under these conditions should be consistent with
the invocations as described below:

Issue 3621: Minor typo (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Editorial, fixed editorially in 2.4
Revised Text:
Actions taken:
May 18, 2000: received issue
August 17, 2000: closed issue

Issue 3634: Typo: "Wrongpolicy" (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Editorial, fixed editorially in 2.4
Revised Text:
Actions taken:
May 21, 2000: received issue
May 21, 2000: received issue
August 17, 2000: closed issue

Issue 3635: Typo: "Wrongpolicy" (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Duplicate of 3634.
Revised Text:
Actions taken:
August 17, 2000: closed issue
October 30, 2000: closed issue

Issue 3636: servant_to_id versus servant_to_reference (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

	This operation requires the USE_DEFAULT_SERVANT policy or a
	combination of the RETAIN policy and either the UNIQUE_ID or
	IMPLICIT_ACTIVATION policies; if not present, the WrongPolicy
	exception is raised.

Note that there is nothing conditional here. If these policies are not
present, the operation raises an exception.

Compare this with servant_to_reference:

	This operation requires the RETAIN policy and either the
	UNIQUE_ID or IMPLICIT_ACTIVATION policies if invoked outside
	the context of an operation dispatched by this POA.

Note that, in this case, we have a qualification:

	"... if invoked outside the context of an operation..."

Why the difference between the two? They almost do the same thing, namely,
map from a servant to an object ID. It's just that servant_to_reference,
after it has the object ID, also embeds that object ID in a reference.

So, shouldn't the two operations behave the same way? In particular,
why should servant_to_id raise an exception if I call it from within the
context of an executing operation on the specified servant?

In other words, it seems that the behavior specified for servant_to_reference
is correct and should apply equally to servant_to_id. In effect, calling
the operation from withing an executing operation on the specified servant
should do the same thing as calling get_object_id on the POA Current and
use the resulting id.

Am I missing something?

Resolution:
Revised Text: The specification of servant_to_id in section 11.3.8.20 should be changed to read: This operation requires the USE_DEFAULT_SERVANT policy or a combination of the RETAIN policy and either the UNIQUE_ID or IMPLICIT_ACTIVATION policies *if invoked outside the context of an operation dispatched by this POA*. *If this operation is not invoked in the context of executing a request on the specified servant and the policies specified previously are not present, the WrongPolicy exception is raised.*
Actions taken:
May 22, 2000: received issue
October 30, 2000: closed issue

Discussion:

The difference is a leftover from when thespecification of servant_to_reference was changed. Provide additional clarification by
making the changes shown below.

Issue 3685: Non-escaped keywords in published IDL (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

I know that this is probably not the best RTF to send this to, but the
issue spans RTFs and we don't have RTFs for the collection or the life cycle
service, so I'm sending this to the Core RTF for want of a better task force...

In the CosLifeCycle IDL (formal/98-10-01.idl), we have:

	module CosLifeCycle{

		typedef CosNaming::Name Key; 
		typedef Object Factory;
		typedef sequence <Factory> Factories;

The two occurences of "Factory" are illegal. According to the comment
at the beginning of the module, this should read:

	module CosLifeCycle{

		typedef CosNaming::Name Key; 
#ifdef NO_ESCAPED_IDENTIFIERS
		typedef Object Factory;
		typedef sequence <Factory> Factories;
#else
		typedef Object _Factory;
		typedef sequence <_Factory> Factories;
#endif

The same problem also appears in formal/98-10-15.idl.


Also in formal/98-10-01.idl:

// C o l l e c t i o n F a c t o r i e s
interface CollectionFactories : CollectionFactory { 
	boolean add_factory (
		in Istring            collection_interface, 
		in Istring            impl_category, 
		in Istring            impl_interface, 
		in CollectionFactory  factory);

// ...

// R A C o l l e c t i o n F a c t o r i e s
interface RACollectionFactories : RACollectionFactory {
	boolean add_factory (
		in Istring              collection_interface, 
		in Istring              impl_category, 
		in Istring              impl_interface, 
		in RACollectionFactory  factory);

Both operation definitions need the same #ifdef to map away from the
"factory" keyword that is used as a parameter name.

That same problem also appears in formal/98-10-03.idl.

I guess the IDL in the formal CORBAservices documents should be fixed too.

Resolution: Fix IDL as suggested
Revised Text: See issue summary for details
Actions taken:
July 6, 2000: receive dissue
February 27, 2001: closed issue

Issue 3694: Pragma version 2.3 (orb_revision)

Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Bill Beckwith, bill.beckwith(at)ois.com)
Nature: Uncategorized Issue
Severity:
Summary:

Since pragma version only applies to the name given in the
pragma and not to anything in the scope of the name this
means that the rep id of things like Bounds and BadKind are
still "...:1.0":

interface TypeCode { // PIDL
# pragma version TypeCode 2.3
	exception Bounds {};
	exception BadKind {};

This is just one example of many things inside version 2.3
pragma'ed scopes that are defaulting to 1.0.

Resolution:
Revised Text:
Actions taken:
June 9, 2000: received issue
October 30, 2000: closed issue

Discussion:

Close no change with the following explanation: 

If the exceptions Bound and BadKind have not themselves changed and do 
not depend on anything else that has changed, then in principle there 
is no reason for their version to be upped. No changes required since 
things are OK the way they are, given the limitations of the way 
Repids are defined.

Issue 3737: AbstractBase not declared. (orb_revision)

Click here for this issue's archive.
Source: D�partement Informatique & R�seaux (Mr. Thomas Quinot, quinot(at)inf.enst.fr)
Nature: Revision
Severity: Significant
Summary:

The standard IDL files included in the corba/ subdirectory
	of the IDL text files archive, formal/00-04-01, should be compilable
	with any compliant IDL parser. Most notably, these files comprise
	a "corba/orb.idl" source file, whose inclusion in application
	IDL files is necessary whenever an application has to manipulate
	type CORBA::TypeCode (as mandated by section "3.14 CORBA module"
	of the CORBA specification v. 2.3).

	It is thus expected that the file corba/orb.idl be a legal
	IDL specification.

	This is not the case, because the corba/orb.idl files #includes
	a CORBA_Stream.idl file, which contains the following declaration:

	abstract valuetype DataOutputStream {
	  [...]
	  void write_Abstract         (in AbstractBase        value);
          [...]
	}

	In this declaration, the syntax of the language imposes that
	the name AbstractBase be interpreted as a <scoped_name>.
	This <scoped_name> is not defined in corba/orb.idl or any of
	the files it #includes.
	The declaration is therefore illegal.

	According to the CORBA 2.3 specification, section
	"4.2 The ORB operations", module CORBA contains a declaration
	"native AbstractBase".

	The following resolution is therefore proposed for this issue:
	
	In file corba/orb.idl, include the followinf declaration:

	native AbstractBase;		// Chapter 4

Resolution: Declaration of native AbstractBase needs to be added to orb.idl as stated above.
Revised Text: In formal/00-04-01 file orb.idl insert the line: native AbstractBase; immediately following the line that reads: typedef string identifier;
Actions taken:
July 4, 2000: received issue
October 30, 2000: closed issue

Issue 3738: Missing exception for activation (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

For explicit activation, the spec says:

	11.3.8.15 activate_object

	ObjectId activate_object(in Servant p_servant)
			raises (ServantAlreadyActive, WrongPolicy);

	This operation requires the SYSTEM_ID and RETAIN policy; if not
	present, the WrongPolicy exception is raised.

And:

	11.3.8.16 activate_object_with_id

	void activate_object_with_id(
			in ObjectId oid,
			in Servant p_servant)
		raises (ObjectAlreadyActive, ServantAlreadyActive, WrongPolicy);

	This operation requires the RETAIN policy; if not present, the
	WrongPolicy exception is raised.

Neither section says that IMPLICT_ACTIVATION would be required.

The intent for IMPLICIT_ACTIVATION was that it permits implicit activation
as well as explicit activation. However, I can infer this only by reading
between the lines. In particular, in section 11.2.7, the intent is never
made clear.

I would suggest to change the the text in section 11.2.7 from:

	When a POA supports implicit activation, an inactive servant may
	be implicitly activated in that POA by certain operations that
	logically require an Object Id to be assigned to that servant.
	Implicit activation of...

to read:

	When a POA supports implicit activation, an inactive servant may
	be implicitly activated in that POA by certain operations that
	logically require an Object Id to be assigned to that servant.
	(IMPLICIT_ACTIVATION does not disallow explicit activation; instead,
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	it enables both implicit and explicit activation.)
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	Implicit activation of...

Resolution: The proposed clarification is in order.
Revised Text: change the the text in para 1 of section 11.2.7 in orbrev/00-09-01 from: When a POA supports implicit activation, an inactive servant may be implicitly activated in that POA by certain operations that logically require an Object Id to be assigned to that servant. Implicit activation of... to read: When a POA supports implicit activation, an inactive servant may be implicitly activated in that POA by certain operations that logically require an Object Id to be assigned to that servant. *IMPLICIT_ACTIVATION does not disallow explicit activation; instead, it enables both implicit and explicit activation.* Implicit activation of...
Actions taken:
July 5, 2000: received issue
February 27, 2001: closed issue

Issue 3739: reference_to_servant raises ObjectNotActive, WrongAdapter, and WrongPolicy (orb_revision)

Click here for this issue's archive.
Source: Oracle (Dr. Anita Jindal, anita.jindal(at)sun.com)
Nature: Uncategorized Issue
Severity:
Summary:

1.  According to CORBA V2.3 spec, 99-10-07.pdf, section 11.3.8.22, 
reference_to_servant  raises ObjectNotActive, WrongAdapter, and WrongPolicy 
exceptions.  

This is inconsistent with the method signature specified in the poa.idl (section 
11.4).  According to the idl the reference_to_servant raises only 
ObjectNotActive and WrongPolicy exceptions.

It is requested that the signature of reference_to_servant in poa.idl be changed
to match the description in section 11.3.8.22.

Resolution: Fix the editorial error
Revised Text: Fix the editorial error on page 11-48 of orbrev/00-09-01 by changing the line: raises(ObjectNotActive, WrongPolicy); associated with the operation reference_to_servant, to read: raises(ObjectNotActive, WrongAdapter, WrongPolicy); and reflect the change in published IDL.
Actions taken:
July 5, 2000: received issue
February 27, 2001: closed issue

Issue 3740: description of unknown_adapter (orb_revision)

Click here for this issue's archive.
Source: Oracle (Dr. Anita Jindal, anita.jindal(at)sun.com)
Nature: Uncategorized Issue
Severity:
Summary:

2.  According to CORBA V2.3 spec, 99-10-07.pdf, section 11.3.3.2
description of unknown_adapter, indicates that:
" The implementation of this operation should either create the specified 
POA and return TRUE, or it should return FALSE. If the operation returns TRUE, 
the ORB will proceed with processing the request. If the operation returns 
FALSE, 
the ORB will return OBJECT_NOT_EXIST to the client."

In Section 11.3.8.3, find_POA specifies the following:

"If a child POA with the specified name does not exist and the value of 
the activate_it parameter is TRUE, the target POA's AdapterActivator, 
if one exists, is invoked, and, if it successfully activates the child POA, 
that child POA is returned. Otherwise, the AdapterNonExistent exception is 
raised."

Since find_POA itself invokes the unknown_adapter() method on the 
AdapterActivator.
If the unknow_adapter() returns false, the find_poa() should throw an 
OBJECT_NOT_EXIST exception.  This is not very clear from explanation in
section 11.3.8.3.

Resolution: Clearly the current text potentially leads readers astray, so clarify it as shown below:
Revised Text: 1. append the following text to find_POA() (immediately before section 11.3.8.4, as part of the final paragraph): "If find_POA receives a system exception in response to a call to unknown_adapter on a POA, find_POA raises OBJ_ADAPTER system exception with standard minor code 1." 2. In addition append the following to the last paragraph of section 11.3.3.2 "unknown_adapter" which partially describes what happens when find_POA calls unknown_adapter: "If unknown_adapter returns FALSE then find_POA raises AdapterNonExistent. If unknow_adapter raises any system exception then find_POA passes through the system exception it gets back from unknown_adapter."
Actions taken:
July 5, 2000: received issue
February 27, 2001: closed issue

Issue 3743: There is inconsistency in the POA.IDL and description in section 11.3.8.19 (orb_revision)

Click here for this issue's archive.
Source: Oracle (Dr. Anita Jindal, anita.jindal(at)sun.com)
Nature: Uncategorized Issue
Severity:
Summary:

There is inconsistency in the POA.IDL and description in section 11.3.8.19
in formal/99-10-07.pdf.

According to poa.idl the signature for create_reference_with_id is:

                Object create_reference_with_id ( in ObjectId oid,
                                                  in CORBA::RepositoryId intf )
                        raises (WrongPolicy);

whereas, section 11.3.8.19 completely omits this exception in the
signature and does not even describe under what condition it is raised.

Resolution: The POA IDL should be fixed by removing the raises(WrongPolicy) clause
Revised Text: Remove the line that reads "raises(WrongPolicy)", immediately following the specification of the operation "create_reference_with_id" in section 11.4 on page 11-48 of orbrev/00-09-01.
Actions taken:
July 14, 2000: received issue
February 27, 2001: closed issue

Issue 3749: With reference to forward declarations of structs and unions. (orb_revision)

Click here for this issue's archive.
Source: ICL (Mr. Trevor Nash, nobody)
Nature: Uncategorized Issue
Severity: Significant
Summary:

Clause 48 <constr_type_spec> in the syntax has been modified to include a choice <constr_forward_decl>. This does not in fact allow things like struct a; though that is the obvious intention. But it does allow bizarre stuff such as typedef struct a, array_of_a[100]; which IMHO should not be legal (I am not that keen on typedef struct a b;) 

I think this choice should be deleted from clause 48 and inserted in clause 42 <type_dcl> instead.

Resolution:
Revised Text: All changes with reference to draft CORBA Core 2.4 as in working document http://cgi.omg.org/pub/orbrev/drafts/UnofficialReviewDraft.pdf. 1. Section 3.4 Page 3-14: Move "| <constr_forward_decl>" from production 48 into production 42. 2. Change the first sentence of section 3.10.2 on page 3-37 to read: "Structs, unions and enums are the constructed types. Their syntax is presented in this section." 3. Section 3.10.2 Page 3-37: Delete "| <constr_forward_decl>" from production 48. Insert the following immediately preceding production 48: (42) <type_decl> ::= "typedef" <type_declarator> | <struct_type> | <union_type> | <enum_type> | "native" <simple_declarator> | <constr_forward_decl> Delete the text following production 99 (beginning with "Although the IDL syntax...") up to the beginning of section 3.10.2.1. (With this edit, the only thing in section 3.10.2 are two introductory sentences followed by the three productions.)
Actions taken:
July 8, 2000: received issue
October 30, 2000: closed issue

Discussion:

That is correct. Changes enumerated below to be incorporated to fix this problem urgently so as to allow inclusion of
these changes before 
2.4 is published.

Issue 3751: incomplete rules for forward declaration of structs/unions (orb_revision)

Click here for this issue's archive.
Source: ICL (Mr. Trevor Nash, nobody)
Nature: Clarification
Severity: Significant
Summary:

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.

Resolution: Incorporate changes and close issue
Revised Text: 1.a. - On page 3-35, delete the text beginning with Although the IDL syntax allows... up to and *including: See Section 3.10.4.1, "Sequence," on page 3-39 for details of the sequence template type. With this edit, the only text in section 3.10.2 (preceding 3.10.2.1) are the two grammar productions. There is no point in retaining this text because the same text appears again in section 3.10.3, so it was redundant all along. 1.b. - On page 3-37, cut the entire section 3.10.3 "Constructed Recursive Types and Forward Declarations" and paste it at the end of 3.10.2.2 "Discriminated Unions" and immediately preceeding 3.10.2.3 "Enumerations" as a new section 3.10.2.3 (making "Enumerations the new section 3.12.2.4). This puts the text for constructed recursive types where it belongs, namely, under the 3.10.2 heading "Constructed Types". (Note that making this edit changes the numbers of what follows. For example, 3.10.4 "Template Types" now becomes 3.10.3 "Template Types.) 1.c. - Reword the first two paragraphs of the old section 3.10.3 (now the new section 3.10.2.3) as follows: The IDL syntax allows the generation of recursive structures and unions via members that have a sequence type. The element type of a recursive sequence struct or union member must identify a struct, union, or valuetype. (A valuetype is allowed to have a member of its own type either directly or indirectly through a member of a constructed type--see Section 3.8.1.6, "Value Type Example," on page 3-24.) For example, the following is legal: struct Foo { long value; sequence<Foo> chain; // Deprecated (see Section 3.10.6) }; [ Note the change to the section number in the comment. That should really be made a proper Frame cross-reference. The change from Section 3.10.3 to Section 3.10.6 I made here assumes that the old 3.10.3 will be moved to become 3.10.2.3. ] 2.a. - Replace the first paragraph on page 3-38 with the following: Forward declarations are legal for structures and unions. A structure or union type is termed "incomplete" until its full definition is provided; that is, until the scope of the structure or union definition is closed by a terminating "}". For example: struct Foo; // Introduces Foo type name, // Foo is incomplete now // ... struct Foo { // ... }; // Foo is complete at this point 2.b. - Replace the third paragraph on page 3-38 with the following: If a recursive structure or union member is used, sequence members that are recursive must refer to an incomplete type currently under definition. For example: 2.c. - Replace the last paragraph on page 3-38 with the following: An incomplete type can only appear as the element type of a sequence definition. A sequence with incomplete element type is termed an "incomplete sequence type": struct Foo; // Forward declaration typedef sequence<Foo> FooSeq; // incomplete An incomplete sequence type can appear only as the element type of another sequence, or as the member type of a structure or union definition. For example: 2.d. - Replace the example at the top of page 3-39 with the following: struct Foo; // Forward declaration typedef sequence<Foo> FooSeq; // OK typedef sequence<FooSeq> FooTree; // OK interface I { FooSeq op1(); // Illegal, FooSeq is incomplete void op2(in FooTree t); // Illegal, FooTree is incomplete }; struct Foo { // Provide definition of Foo long l_mem; FooSeq chain; // OK FooTree tree; // OK }; interface J { FooSeq op1(); // OK, FooSeq is complete void op2(in FooTree t); // OK, FooTree is complete }; 3.a. - Change the last example on page 3-38 to read: union Bar; // Forward declaration typedef sequence<Bar> BarSeq; union Bar switch(long) { // Define incomplete union case 0: long l_mem; case 1: struct Foo { double d_mem; BarSeq nested; // OK, recurse on enclosing // incomplete type } s_mem; }; [ Note that I changed the comments as well. ]
Actions taken:
July 8, 2000: received issue
February 27, 2001: closed issue

Discussion:

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

The wording is indeed suboptimal and needs fixing. See edits under 1 below. 

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

Yes, see  edits under 1 below.. 

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

The Core RTF explicitly decided some time ago that forward-declared interfaces 
and valuetypes need not have a definition in the same source file. That 
decision was made because members that use such a forward-declared type 
have reference semantics, so there is no need for the compiler to see 
the complete definition of the type (and therefore know the sizes involved) 
in the same source file. 

For recursive structs and unions, the situation is different. The recursive 
sequence elements (which have the forward-declared type) have *value* 
semantics. In turn, this means that the compiler must find out what the 
size of things is in the same source file. We could relax this definition, 
but that would have negative implementation consequences. In particular, 
the compiler would be forced to generate sequence implementations that 
store each sequence element on the heap and hold a pointer to each element 
(because the size of the element would not be known at compile time.) 
In the interest of efficiency and not making compiler implmentations 
overly complex, I suggest to retain the rule as is. 

The text forces the compiler to emit a diagnostic as a matter of principle; 
otherwise, a compliant compiler would be allowed to compile 
non-compliant IDL without emitting a message. That's not useful behavior. 

>4.  I believe the following should be legal: 
> 
>       struct R; 
>       typedef sequence<R> SqR; 
>       typedef sequence<SqR> SqSqR; 
>       struct R { 
>               SqSqR square_chain; 
>       }; 
> 
> But the existing wording seems to forbid this because the second 
> typedef falls foul of the last pragraph on page 3-38.  I think you 
> need to add that a sequence type that has a forward declared element 
> type may also be used to declare a further sequence type, which is 
> itself similarly restricted. 

Agreed -- the intent was to permit this but the text in the spec does 
not properly capture the intent. The edits in item 2 below should fix it: 

>5. The syntax of the "union Bar" example is wrong: the declarator is 
> missing.  It should read something like: 
> 
> ... 
> case 1: 
>       struct Foo { 
>               ... 
>       } s_mem; 
>         ^^^^^ 

Yes, thanks. A line is missing from the example. The edits in item 
3 below will fix it:

Issue 3764: Nested Recursive Structs Legal in 2.3.x? (orb_revision)

Click here for this issue's archive.
Source: Perot Systems (Mr. Charles W. Binko, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

	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 {
      sequence<TestStruct1> list;
    };
// Nested Struct: This is legal
  struct TestStruct2 {
      struct TestStruct3
        {
          long threeMember;
        } twoMember;
    };
// Nested Recursive Case: IS THIS LEGAL?  
  struct One {
      struct Two {
        sequence<One> twoMember;
      } 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.

Resolution: Close no change with explanation as above.
Revised Text:
Actions taken:
July 25, 2000: received issue
February 27, 2001: closed issue

Discussion:

Close with clarfication: 
Yes. Nested recursive structs are legal in 2.3.x. It is a matter of 
implementation to determine where the recursion occurs in the typecode 
itself. This is determined at runtime based on what the starting point of 
the type() method is: 

Given the example in the issue: 
struct one { 
  struct two { 
    sequence<one> twoMember; 
    }; oneMember; 
}; 

if two.type() is called. Then the typecode looks like this: 
tk_struct{"two", 
  member{ 
    {tk_sequence{ 
       {tk_struct{"one", 
          member{ 
            {tk_recursive{"two"}, oneMember} 
          } //end "one" 
        }, 
     0}, //end sequence 
   twoMember} 
}; //end "two" 

if one.type() is called. Then the typecode may look like this: 
tk_struct{"one", 
  member{ 
    {tk_struct 
       member { 
          tk_struct{"two", 
            member{ 
              {tk_sequence{tk_recursive("one"), twoMember},0} 
            } 
          } //end "two" 
        }, 
        twoMember} 
}; //end "one"

Issue 3768: IDL: Clashes with inherited identifiers (orb_revision)

Click here for this issue's archive.
Source: AT&T (Dr. Duncan Grisby, )
Nature: Uncategorized Issue
Severity:
Summary:

Is the following IDL legal?

  interface A {
    void B();
  };
  interface B : A {};

Interface B has an inherited operation named B. Whether it is legal or
not depends on whether the inherited operation is considered "defined"
within interface B.

This issue is subtly different from the discussions in issue 3525.
Operations and attributes are more strongly "introduced" into the
inherited interface than type declarations are, since inherited type
declarations can be overridden, but operations and attributes cannot.

I think the IDL specification should be clarified to state whether the
above IDL is legal or not.

Resolution: Close no change with explanation as above.
Revised Text:
Actions taken:
July 31, 2000: received issue
October 30, 2000: closed issue

Discussion:

I don't think we need to say anything special there? The spec 
explicitly says that directly-nested, same-named constructs are 
illegal. It doesn't say that I can't inherit an operation from 
a base interface with the same name as a derived interface 
(and it shouldn't, IMO). 

There is no danger of name clashes at the language mapping level here 
because ::A and ::B::A are in different scopes and therefore end 
up getting mapped to different classes.

Issue 3781: Initializers and user exceptions (orb_revision)

Click here for this issue's archive.
Source: IONA (Mr. Mark Spruiell, )
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution: No won for B above so this issue is closed no change.
Revised Text:
Actions taken:
August 9, 2000: received issue
February 27, 2001: closed issue

Discussion:

The following two preliminary questions need to be answered first: 

A. Should exceptions be added to valuetype initializers? [Yes, No, Abstain] 

B. Is this within the scope of what an R/FTF can do? [Yes, No, Abstain] 

If No wins for either A or B above this issue will be closed no change. 

NO won for B, so issue is closed no change

Issue 3799: read_fixed() and write_fixed() methods missing (orb_revision)

Click here for this issue's archive.
Source: Oracle (Dr. Anita Jindal, anita.jindal(at)sun.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Incorporate changes and close issue.
Revised Text: In orbrev/00-09-01 in Chapter 5 Section 5.2.2 make the following changes:: 1. On page 5-12 immediately following the IDL line that reads typedef sequence <long double> LongDoubleSeq; insert the line: exception BadFixedValue { unsigned long offset; }; 2. On page 5-13 insert the following operation signatures in the IDL as the last two operations of the DataOutputStream: void write_fixed( in any fixed_value) raises (BadFixedValue); void write_fixed_array( in AnySeq seq, in unsigned long offset, in unsigned long length) raises (BadFixedValue); 3. On page 5-14 insert the following operation signatures in the IDL as the last two operations of the DataInputStream: any read_fixed( in unsigned short digits, in short scale) raises (BadFixedValue); void read_fixed_array( inout AnySeq seq, in unsigned long offset, in unsigned long length, in unsigned short digits, in short scale) raises (BadFixedValue); 4. Append the following paragraphs to section 5.2.2: For write_fixed, the fixed_value parameter must be an "any" containing a fixed value. If the "any" passed in does not contain a fixed value, then a BadFixedValue exception is raised with the offset field set to 0. For write_fixed_array, the elements of the seq parameter that are specified by the offset and length parameters must be a sequence of "any"s each of which contains a fixed value. If any of these "any"s does not contain a fixed value, or if any of them contains a fixed value whose digits and scale (as specified by the TypeCode in the "any") differ from those of the first of these "any"s (as specified by its TypeCode), then a BadFixedValue exception is raised with the offset field set to a zero-origin ordinal number indicating the position of the first incorrect "any" within the subsequence of fixed values written to the stream. For both write_fixed and write_fixed_array, the TypeCode within each "any" being written specifies the digits and scale to be used to write the fixed value contained in the "any." The TypeCode itself is not written to the DataOutputStream. read_fixed returns an "any" containing the fixed value that was read from the DataInputStream. The digits and scale in the TypeCode of the returned "any" are set to the digits and scale parameters passed to read_fixed. If the fixed value read from the DataInputStream is incompatible with the digits and scale parameters passed to read_fixed, then a BadFixedValue exception is raised with the offset field set to 0. read_fixed_array sets the elements of the seq parameter that are specified by the offset and length parameters. These elements are set to "any"s with TypeCodes specifying a fixed value whose digits and scale are the same as the digits and scale parameters, and fixed values that were read from the DataInputStream. The previous contents of these "any"s, including their TypeCodes, are destroyed by the read_fixed_array operation. Other "any"s in the seq parameter (if any) are left unchanged. No TypeCode information is read from the DataInputStream. If any of the fixed values read from the DataInputStream is incompatible with the digits and scale parameters, then a BadFixedValue exception is raised with the offset field set to a zero-origin ordinal number indicating the position of the first incorrect "any" within the subsequence of fixed values read from the stream. The stream representation of a fixed value is considered incompatible if its digit and scale values do not match the digits and scale values being used to read it from the stream.
Actions taken:
August 31, 2000: received issue
November 2, 2000: moved from Java RTF to Core RTF
February 27, 2001: closed issue

Discussion:

Add read_fixed and write_fixed to DataOutputStream and 
DataInputStream respectively, and let them be mapped using the usual 
Java mapping. 

And while at it, also add read_fixed_array and write_fixed_array.

Issue 3817: ORB ID accessor (orb_revision)

Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

ORB_init allows me to specify an ORB ID, but there is no way to get that
ORB ID back from an ORB. It seems wrong to force people to specify an
object identity during object creation but to not allow access to that
identity later.

I would suggest to add an accessor to the ORB interface:

	interface ORB {
		ORBid id();
		// ...
	};

Resolution: Add the proposed accessor to ORB.
Revised Text: 1. Insert the operation id into the ORB interface in IDL on page 4-3 in section 4.2 as its first operation: interface ORB { ORBid id(); // ... }; 2. Insert a new section 4.2.1: 4.2.1 ORB Identity 4.2.1.1 id ORBid id(); The id operation returns the identity of the ORB. The returned string is the string that was passed to ORB_init as the "orb_identifier" parameter when the ORB was created. If that was the empty string, the returned string is the value associated with the "-ORBid" tag in the "arg_list" parameter (see Section 4.5.1, "ORB Initialization"). Calling id on the default ORB returns the empty string. 3. Change the section numbers of existing section 4.2.1 to 4.2.2 etc.
Actions taken:
September 8, 2000: received issue
February 27, 2001: closed issue

Issue 3862: "omg.org" prefix missing from interceptor specification and its reference (orb_revision)

Click here for this issue's archive.
Source: Oracle (Dr. Harold Carr, Ph.D., harold.carr(at)sun.com)
Nature: Uncategorized Issue
Severity:
Summary:

The specification, ptc/00-08-06, defines the following modules:

	Dynamic
	IOP_N
	PortableInterceptor

These modules reference the following modules:

	CORBA
	IOP
	Messaging

The CORBA 2.4 specification, orbrev/00-09-01, only explicitly specifies:

	#pragma prefix "omg.org"

for:

	DynamicAny (page 196)
	CORBA, the Interface Repository Case, (p 280)
	PortableServer (page 338)

and the Messaging specification, orbos/98-05-05, specifies the prefix
for messaging.

----------

Proposed solution:

Either explicitly add

	#pragma prefix "omg.org"

before Dynamic, IOP_N, PortableInterceptor, CORBA (in general), and IOP

OR

Change, the second paragraph of 10.6.7 RepositoryIDs for OMG-Specified Types
(page 270)

from:

"All official OMG IDL files shall contain the following pragma prefix
directive: 

	#pragma prefix "omg.org"

unless said file already contains a pragma prefix identifying the
original source of the file (e.g., "w3c.org")."

to:

"All official OMG IDL modules shall contain the following pragma prefix
directive: 

	#pragma prefix "omg.org"

unless said file already contains a pragma prefix identifying the
original source of the module (e.g., "w3c.org")."

----------

Discussion:

Perhaps we can interpret 10.6.7 above to mean already mean the all
official OMG modules have the "omg.org" prefix.  In that case, there
is no issue.

Resolution: The last sentence of the summary states the way things are, so there really is no issue here
Revised Text:
Actions taken:
September 19, 2000: received issue
February 27, 2001: closed issue

Issue 3877: module IOP_N needs a real name (orb_revision)

Click here for this issue's archive.
Source: Oracle (Dr. Harold Carr, Ph.D., harold.carr(at)sun.com)
Nature: Uncategorized Issue
Severity:
Summary:

The interceptors specification, ptc/00-08-06, defines:

	IOP_N

Issue: "_N" needs to be replaced with the correct version such that
	this module has a real name.

Resolution:
Revised Text: Requires special handling while merging ptc/00-08-06 changes into the mainline Core 2.4 in order to get Core 3.0. The instructions in the Resolution section will suffice quite unambiguously on what needs to be done in the merge process.
Actions taken:
September 19, 2000: received issue
February 27, 2001: closed issue

Discussion:

 _N should be replaced by the null string, i.e. whatever is in IOP_N in ptc/00-08-06 should be appended to the IOP
module.

Issue 3905: Values for CORBA::ARG_IN,... not defined (orb_revision)

Click here for this issue's archive.
Source: Oracle (Dr. Harold Carr, Ph.D., harold.carr(at)sun.com)
Nature: Uncategorized Issue
Severity:
Summary:

This is a core issue.

	formal/99-10-07 (and orbrev/00-09-01) section 7.1.1 claims
	arg_modes is a bit mask with CORBA::ARG_IN, ... as possible values.
	The values are not defined in that document.
	
	The values defined in ptc/00-01-08 (IDL to Java mapping)
	section 1.19.4 do not look like bit masks:
	
	typedef unsigned long Flags;
	const Flags ARG_IN = 1;
	const Flags ARG_OUT = 2;
	const Flags ARG_INOUT = 3;
	const Flags CTX_RESTRICT_SCOPE = 15;

	This needs clarification (e.g., how wide is the bit mask, what
	are the values, or, if not a bit mask, a better definition).

Resolution:
Revised Text: 1. In orbrev/00-09-01 replace the first three paragraphs and the table at the top of page 7-4 immediately preceding section 7.1.2 by the following text and table: The arg_mode field is of type Flags which is an unsigned long. This field is used as follows in this structure. It should be noted that Flags type is used as parameter type in many operations and the meaning of the constants passed in those cases are specific to those operations. Those values should not be confused with the specific use of this type in the context of the NamedValue structure. These values are reserved, as are the high order 16 bits of the unsigned long. Name of Constant Constant Value Associated Meaning ARG_IN 1 The associated value is an "in" argument ARG_OUT 2 The associated value is an "out" argument ARG_INOUT 3 The associated value is an "inout" argument The specific usage of Flags in other contexts are described as part of the description of the operation that uses this type of parameters. 2 Append the following sentence to the last bullet in section 4.6.2.4 "get_values": "The value of this flag is 15."
Actions taken:
September 20, 2000: received issue
February 27, 2001: closed issue

Discussion:

Doing a complete fix of all possible usages of the Flag type will require considerable rewrite of Chapter 7, so that is
not attempted in this resolution. This resolution addresses the specific problem mentioned in this issue relative to the actual values
of ARG_IN, ARG_OUT, ARG_INOUT and CTX_RESTRICT_SCOPE.

Issue 3918: Should POA spec examples use string_to_ObjectId? (orb_revision)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, crawley(at)dstc.edu.au)
Nature: Uncategorized Issue
Severity:
Summary:

As I understand things, string_to_ObjectId is an artifact of the
C++ POA mapping.  It certainly isn't defined in the core POA spec.
However, some of the example code in the POA spec uses this routine.
Is this kosher?  Shouldn't the relevant examples at least have a 
cross-reference to the C++ mapping?

Resolution: Resolve no change
Revised Text:
Actions taken:
September 28, 2000: received issue
February 27, 2001: closed issue

Discussion:

close 3918 without change. Given that the examples are in 
C++, I don't see how they can avoid to use features of the C++ mapping. 
I don't think that a cross-reference is needed. I think it's obvious that, 
for C++, it's the C++ mapping that is used.

Issue 3919: Conflict between POA & Exceptions spec for OBJECT_NOT_EXIST (orb_revision)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, crawley(at)dstc.edu.au)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Close no change
Revised Text:
Actions taken:
September 28, 2000: received issue

Discussion:

A server can signal the case where it's prevented (by 
resource/config problems, say) from creating a POA on demand by raising 
OBJ_ADAPTER or some other system exception.  Since _by_definition_, 
returning null from an AdapterActivator triggers OBJECT_NOT_EXIST, returning 
null to signal some other condition is simply a programming error. 

An incorrect/noncompliant application, all bets 
are off and the spec can and should say nothing useful.  After all, by 
accident or design, OBJECT_NOT_EXIST might mean "today's Thursday" in my 
app.

Issue 3970: Format of RMI Hashed Format repid (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Clarify as suggested below
Revised Text: n the seventh paragraph of section 10.6.2, after the text "the hash code is a 64-bit hash of a stream of bytes", add the text "(transcribed as a 16-digit upper-case hex string)".
Actions taken:
October 18, 2000: received issue
February 27, 2001: closed issue

Discussion:

Proposal:

In the seventh paragraph of section 10.6.2, after the text "the hash code
is a 64-bit hash of a stream of bytes", add the text "(transcribed as a
16-digit upper-case hex string)".

Issue 4003: Can a valuetype support multiple non-abstract interfaces via inheritance? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The CORBA 2.4 specification is not clear about whether a valuetype can
support multiple non-abstract interfaces via inheritance.  Here is an
example:

interface I1 {};

interface I2 {};

valuetype V1 supports I1 {};

valuetype V2: V1 supports I2 {};

Is V2 legal?

I see three possible resolutions to this issue:

1.  Make V2 illegal.  A valuetype may not support a non-abstract
interface if any of its base valuetypes supports a non-abstract
interface.  This is a pretty simple rule, but I think it is far too
restrictive, and can get in the way of some cases where supporting
multiple interfaces could be genuinely useful.

2.  Make V2 legal.  Since we have clarified (assuming that the proposed
resolution of 3589 passes, which it appears it will) that valuetypes
that support an interface are not synonymous with an object reference
that uses that valuetype as a servant, I don't see any actual core
issues that break the object model.  Also, my inspection of the language
mappings does not reveal any problems on that front either.

3.  Make V2 illegal, but make it legal if I2 inherited from I1.  The
rule would be that a valuetype can support a non-abstract interface only
if that interface is derived (directly or indirectly) from all other
non-abstract interfaces that are supported by base valuetypes.  This
allows the use of the ladder inheritance pattern, which I think is very
useful in this case:

interface I1 {};

valuetype V1 supports I1 {};

interface I2 {};

valuetype V2 supports I2 {};

interface I3 : I1, I2 {};

valuetype V3 : V1, V2 supports I3 {};

Of these three posible resolutions, I prefer #2, since I don't see any
practical implementation problems, so the restriction in #3 is really
not necessary.

Resolution: see below
Revised Text: Add the following paragraph to 3.8.5, right after the paragraph that starts "The single immediate base concrete value type..." While a valuetype may only directly support one interface, it is possible for the valuetype to support other interfaces as well through inheritance. In this case, the supported interface must be derived, directly or indirectly, from each interface that the valuetype supports through inheritance. This rule does not apply to abstract interfaces that the valuetype supports. For example: interface I1 { }; interface I2 { }; interface I3: I1, I2 { }; abstract valuetype V1 supports I1 { }; abstract valuetype V2 supports I2 { }; valuetype V3: V1, V2 supports I3 { }; // legal valuetype V4: V1 supports I2 { }; // illegal
Actions taken:
October 27, 2000: received issue
May 13, 2002: closed issue

Discussion:

Essentially do what is suggested in (3) above for reasons given above, 
and futher expounded upon in the archive.

Issue 4005: DynUnion incomplete (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

	union u switch (long) {
	case 0:
		long l;
	case 1:
		char c;
	case 2:
		double d;
	default:
		float f;
	};

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 {
		boolean is_set_to_default_case();
		// ...
	};

	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.

Resolution: Add the is_set_to_default_member function with the functionality as described for is_set_to_default_
Revised Text: 1. In the IDL at the beginning of section 9.2.7 insert the following line immediately preceding the closing }: boolean is_set_to_default_member(); 2. Append the following at the end of section 9.2.7: boolean is_set_to_default_member(); The is_set_to_default_member 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.
Actions taken:
October 30, 2000: received issue
February 27, 2001: closed issue

Issue 4014: Servant deactivation callback? (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

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)
	{
		my_poa->deactivate_object(my_oid);
		// Cannot remove database record here or do any other
		// cleanup.
	}

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.

Resolution: Close no change.
Revised Text:
Actions taken:
November 2, 2000: received issue
February 27, 2001: closed issue

Discussion:

   (USE_SERVANT_MANAGER + RETAIN) = 
    USE_ACTIVE_OBJECT_MAP_ONLY +  life_cycle_control; 

i.e. Use ACTIVE_OBJECT_MAP_ONLY when you do not care about life cycle control and 
use SERVANT_MANAGER + RETAIN when you want the life cycle control. 

You can even selectively bypass incarnate by explicitly activating your objects even 
when  SERVANT_MANAGER is being used. That way, you get notified only when the object 
is deactivated and not when it is created. 

There seems to be insufficient justification for changing the semantics of 
USE_ACTIVE_OBJECT_MAP_ONLY to fix these race & deadlock conditions when 
simply using a ServantActivator solves the problem. 

Re

Issue 4016: #pragma version issue (orb_revision)

Click here for this issue's archive.
Source: AT&T (Dr. Duncan Grisby, )
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution: Incorporate changes and close issue
Revised Text: Change the final paragraph of section 10.6.5.3 on page 10-48, plus the final two code examples following that paragraph to read: An attempt to assign a version to the same IDL construct a second time shall be an error unless the version used in the attempt is identical to the existing one. interface A {}; #pragma version A 1.1 #pragma version A 1.1 // OK #pragma version A 1.2 // Error interface B {}; #pragma ID B "IDL:myB:1.2" #pragma version B 1.2 // OK
Actions taken:
November 3, 2000: received issue
February 27, 2001: closed issue

Discussion:

A non-conflicting version pragma should be considered 
benign, just as a non-conflicting ID pragma.

Issue 4031: Valuetypes supporting local interfaces are local types? (orb_revision)

Click here for this issue's archive.
Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, Vijaykumar.Natarajan(at)borland.com)
Nature: Uncategorized Issue
Severity:
Summary:

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)

Resolution:
Revised Text: 1. change the second bullet in section 5.2 that reads: supports a single interface to: supports a single non-abstract interface 2. Append the following paragraph to section 3.8.1.3 "Value Inheritance Specification" A valuetype that supports a local interface does not itself become local (i.e. unmarshalable) as a result of that support. 3. Insert the following paragraph immediately following the first paragraph in section 3.8.1.4 "State Member" A valuetype that has a state member that is "local" (i.e. non-marshalable like a local interface), is itself rendered local. That is, such valuetypes behave similarly to local interfaces when an attempt is made to marshal them.
Actions taken:
November 8, 2000: received issue
February 27, 2001: closed issue

Discussion:

1. Can it support multiple? In addition to a unconstrained non abstract interface? 

No, for the same reason that it cannot support more than one non abastract interface. In fact , it can support only one non-abstract
interface. That supported interface may or may not be local. 

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, it does not become a local type, in the sense that it cannot be marshaled. For that to happen on of the state variables must be
of a local (unmarshalable) type.

Issue 4033: POAManager::deactivate does not specify behavior for "reject" (orb_revision)

This is the first issue I found w/ POAManager::deactivate definition.

The spec states in section 11.3.2.6, paragraph 1.

Entering the inactive state causes the associated POAs to reject
requests that have not
begun to be executed as well as any new requests.

However, there is no definition of what "reject" means. What does the
client see in this case?

Proposal:

Add to the paragraph:
When a request is rejected, an OBJECT_NOT_EXIST system exception with
standard minor code XX is returned to the client.

Resolution: The proposal proved to be too controversial. So suggest close no change
Revised Text:
Actions taken:
November 8, 2000: received issue
October 3, 2001: closed issue

Issue 4034: POAManager::deactivate should not mandate ORB::shutdown implementation (orb_revision)

Section 11.3.2.6 has a paragraph that states:

If the ORB::shutdown operation is called, it makes a call on deactivate
with a
TRUE etherealize_objects parameter for each POA manager known in the
process;
the wait_for_completion parameter to deactivate will be the same as the
similarly
named parameter of ORB::shutdown.

Shouldn't this be reworded to not require an explicit call to
deactivate(but only the effect). Also, since ORB::shutdown already does
the equivalent of destroy on the POAs shouldn't the order of these
operations be specified. I also think they should be specified in the
text for ORB shutdown rather than here.

Resolution: Right, make it so
Revised Text: 1. Remove paragraph from section 11.3.2.6 (second last paragraph in the section) [This specification does not belong here]: "If the ORB::shutdown is called...." 2. Replace paragraph in section 4.2.3.4 that reads: "Shutting down the ORB causes all object adapters to be destroyed, since they cannot exist in the absence of an ORB. Shut down is complete when all ORB processing (including request processing and object deactivation or other operations associated with object adapters) has completed and the object adapters have been destroyed. In the case of the POA, this means that all object etherealizations have finished and root POA has been destroyed (implying that all descendent POAs have also been destroyed)." by:: "Shutting down the ORB causes all object adapters to be destroyed, since they cannot exist in the absence of an ORB. In the case of the POA, all POAManagers are deactivated prior to destruction of all POAs. The deactivation that the ORB performs should be the equivalent of calling deactivate with the value TRUE for etherealize_objects and with the wait_for_completion parameter same as what shutdown was called with. Shut down is complete when all ORB processing (including request processing and object deactivation or other operations associated with object adapters) has completed and the object adapters have been destroyed. In the case of the POA, this means that all object etherealizations have finished and root POA has been destroyed (implying that all descendent POAs have also been destroyed)." 1. In the resolution for issue 4034, Revised Text item 1: The section to which the change is to be applied should be section 4.2.4.4 not 4.2.3.4. Section 4.2.4.4 contains documentation for shutdown, which this issue is concerned with.
Actions taken:
November 8, 2000: received issue
October 3, 2001: closed issue

Discussion:

Issue 4035: IDL format for RepositoryId (orb_revision)

Click here for this issue's archive.
Source: UBS (Karsten-Oliver Starr, karsten-oliver.starr(at)ubs.com)
Nature: Uncategorized Issue
Severity:
Summary:

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:

Resolution: Incorporate changes and close issue.
Revised Text: 1. Replace the first two sentences in the second paragraph of section 10.6.5.4 by: "The ID string shall be generated by starting with the string "IDL:". Then, if the current prefix pragma is a non-empty string, it is appended, followed by a "/" character." 2. Append the following paragraph to section 10.6.5.4: See section 10.6.5.2 for further details of the effects of various prefix pragma settings on the generated RepositoryIds.
Actions taken:
November 9, 2000: received issue
February 27, 2001: closed issue

Discussion:

 * Firstly I propose to change  >>"IDL."<<  into  >>"IDL".<< 

Editing style detail. Both are valid depending on which style is being followed. There are numerous examples in the chapter which
precludes the possibility of misinterpreting the existing "IDL." as if it is saying that an OMG IDL RepId should be of the form
"IDL.:foo:1.0". Nochange required. 

   * 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: 

Not clear that this affects interoperability in any way. As long as ORBs follow the instructions in section 10.6.5.4 "Generation of
OMG IDL - Format IDs." So no further specificity in definition is required. However, some changes in section 10.6.5.4 for
clarifying its meaning is in order as shown below:

Issue 4036: Definition of TRANSIENT minor code 1 confusing (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Make it so
Revised Text: Replace the TRANSIENT minor code 1 description in Table 4-3 by: "Request discarded because of resource exhaustion in POA or because POA is in DISCARDING state"
Actions taken:
November 9, 2000: received issue
February 27, 2001: closed issue

Issue 4037: Minor code 2 description for OBJECT_NOT_EXIST not consistent w/ use (orb_revision)

I was looking at the spec to amend 4033 to not use up a new minor code but
noticed this text for minor code 2 under OBJECT_NOT_EXIST:

POAManager::incarnate failed to create POA.

This is clearly not consistent with its use under the TRANSIENT POA Lifespan
Policy description (I also found other inconsistent uses, detailed below).

There are two things that need fixing here. The first one is probably
straightforward.
1. The minor code allocated for 4033 must be used in the text for TRANSIENT
Lifespan Policy in section 11.3.7.2

2.  POAManager::incarnate is not a valid operation at all.
I found references to OBJECT_NOT_EXIST with minor code 2 in the following
places:

A - Section 11.2.6, paragraph 2

The adapter activator has the opportunity to create the required POA. If it
does not, the client receives the
OBJECT_NOT_EXIST exception with standard minor code 2.

B - Section 11.2.6
If the POA has the NON_RETAIN policy or has the RETAIN policy but didn't
find a
servant in the Active Object Map, the POA takes the following actions:
  Bullet 3
  - If t he USE_OBJECT_MAP_ONLY policy is in effect, the POA raises the
    OBJECT_NOT_EXIST system exception with standard minor code 2.

C - 11.3.3.2 unknown_adapter
If the operation returns TRUE, the ORB will
proceed with processing the request. If the operation returns FALSE, the ORB
will
return OBJECT_NOT_EXIST with standard minor code 2 to the client.

D - 11.3.3.2 unknown_adapter
If the parent of a nonexistent POA does not have an
associated adapter activator, the ORB will return the OBJECT_NOT_EXIST
system
exception with standard minor code 2.

E - 11.3.7.6 Request Processing Policy
USE_ACTIVE_OBJECT_MAP_ONLY - If the Object Id is not found in the
Active Object Map, an OBJECT_NOT_EXIST system exception with standard
minor code 2 is returned to the client.


Cases A, C and D hint that minor code 2 should actually say "Could not
create or locate POA" or something to that effect. Cases B and E should
really be using another minor code ("Could not locate object in AOM?").

Resolution: incorporate change and close issue
Revised Text: All changes in orbrev/01-03-01 1. In Section 4.11.4 change the description of minor code 2 for OBJECT_NOT_EXIST and add a new minor code for object adapter inactive: System Exception | Minor Code | Explanation OBJECT_NOT_EXIST | 2 | Failed to create or locate Object Adapter | XX | Object Adapter Inactive 2. In Section 11.3.7.2 Change the following in description for Transient Policy Once the POA is deactivated, use of any object references generated from it will result in an OBJECT_NOT_EXIST system exception with standard minor code 2. to: [Note: I think this encroaches into the discussion and conflict in 4033. However, I will make an attempt at a proposal here] Once the POA's POAManager enters the deactivated state, any requests received by this POA will cause the POA to raise an OBJECT_NOT_EXIST system exception with standard minor code XX.
Actions taken:
November 14, 2000: received issue
October 3, 2001: closed issue

Discussion:

Taking the factors from above into consideration, the best way to resolve 
this issue is to change the description of OBJECT_NOT_EXIST/Minor code 2) to be 
consistent w/ use. This minor code is used to indicate either a failure 
to create a POA by an AdapaterActivator or a failure to locate the POA 
or an associated AdapterManager.

Issue 4117: ServantLocator preinvoke/ postinvoke semantics (orb_revision)

Click here for this issue's archive.
Source: Borland Software Corporation (Mr. Andy Cutright, acutright(at)borland.com)
Nature: Uncategorized Issue
Severity:
Summary:

the 2.4 specification states that 'preinvoke and postinvoke operations
are always called in paris in response to any ORB activity...' the spec
details in particular the case of what happens when preinvoke is called
when processing a GIOP Locate message: postinvoke is called subsequent
to calling preinvoke.

if the preinvoke raises an exception, what is the expected behavior?
should postinvoke be called if preinvoke raises a system exception or
ForwardRequest? are there any situations in which postinvoke would not
be called following a call to preinvoke?

Resolution: Clarify the expected behavior if preinvoke raises an exception
Revised Text: Insert the following sentence at the beginning of the last bullet point on page 11-26: If preinvoke raises an exception, postinvoke is not called. Modify the beginning of the next (currently first) sentence to read: *Otherwise,* the preinvoke and postinvoke operations are always called in pairs...
Actions taken:
January 10, 2001: received issue
October 3, 2001: closed issue

Issue 4128: CORBA::ORB::object_to_string() raising INV_OBJREF or BAD_PARAM (orb_revision)

Click here for this issue's archive.
Source: Progress Software (Mr. Eoghan Glynn, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

There appears to be a contradiction in CORBA 2.4.1 (00-11-07) as to
whether CORBA::ORB::object_to_string() should raise INV_OBJREF or
BAD_PARAM when an invalid string is passed.

Here's where I see a contradiction in the spec:

CORBA 2.4.1: "4.11.3.6 INV_OBJREF
This exception indicates that an object reference is internally
malformed. For example, the repository ID may have incorrect syntax or
the addressing information may be invalid. This exception is raised by
ORB::string_to_object if the passed string does not decode correctly."

This explicitly specifies that INV_OBJREF is thrown if a non-decodable
stringified IOR is passed to string_to_object(). 

On the other hand the table:
CORBA 2.4.1: "4.11.4 Standard Minor Exception Codes ...
BAD_PARAM ...
7 string_to_object conversion failed due to bad scheme name.
8 string_to_object conversion failed due to bad address.
9 string_to_object conversion failed due to bad bad schema specific
part.
10 string_to_object conversion failed due to non specific reason."

indicates that BAD_PARAM/10 should be raised for non-specific
string_to_object failures, contradicting 4.11.3.6 above. 

Is this simply an editing issue in that 4.11.3.6 has not yet been
updated to take cognizance of 4.11.4? I propose that 4.11.3.6 is updated
to allow BAD_PARAM to be raised on string_to_object failures where the
problem lies in the string content.

Resolution: see above, Close issue, already fixed
Revised Text:
Actions taken:
December 19, 2000: received issue
October 3, 2001: closed issue

Discussion:

The sentence: 
"This exception is raised by ORB::string_to_object if the passed string does not decode correctly." 
was removed editorially in 2.4.2, since this specification does not belong in Chapter 4.

Issue 4132: Legal IDL? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Is the following legal IDL?

 module M
 {
     abstract interface I
     {
         string s();
     };

     valuetype V supports I
     {
         private string s;
     };
 };

Our interpretation of the spec is that it is legal but we have been informed
that some other IDL compilers consider it an error.

Resolution: see below
Revised Text: Add the following text to 3.8.5 "Valuetype inheritance", second paragraph, after the first sentence: "For the purpose of name resolution, valuetype state members are treated as operations. It is illegal for a state member to have a name that is already declared as either a state member or operation in an inherited valuetype, or an operation in a supported interface or abstract interface."
Actions taken:
December 20, 2000: received issue
October 3, 2001: closed issue

Discussion:

The potential for name clashes in the implementation language mappings for 
many commonly used implementation languages is avoided if declaration of 
new identifiers in valuetypes deal with  the naming scope of supporting interfaces 
being inherited into the scope of the valuetype, following the normal 
inheritence rules as they apply to scopes of interfaces and valuetypes. 
Resolve this issue by spelling out that restriction, and clearly making the 
IDL presented above illegal.

Issue 4135: Section 2.1.7 of CORBA 2.3 and 2.4 (orb_revision)

Click here for this issue's archive.
Source: Object Management Group (Mr. Jon M. Siegel, siegel(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:

Section 2.1.7 of CORBA 2.3 and 2.4 (and presumably all earlier 
versions) concludes with the sentence 

Object-oriented programming languages, such as C++ and Smalltalk, 
do not require stub interfaces. 


I suspect that this is a relic of some prehistoric age when early 
OMG folk imagined that OO languages would handle some stub stuff 
via language mechanisms. Since this has not turned out to be the 
case, the sentence should be excised.

Resolution: incorporate change and close issue
Revised Text: In orbrev/01-03-01 1. Remove the last paragraph of section 2.1.7. 2. Remove the first sentence of the first paragraph of section 2.1.7. 3. In the second sentence in section 2.1.7 replace the phrase: "Generally, the stubs...." by: "Generally, the client stubs...."
Actions taken:
January 3, 2001: received issue
October 3, 2001: closed issue

Discussion:

Remove the quoted sentence, and repair collateral damage as suggested below. 

General comment..... perhaps it is time to redo significant parts of chapter 2.

Issue 4152: Container::lookup() ordering requirements (orb_revision)

Click here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the Interface Repository, Container::contents() and describe_contents()
do not seem to have any restrictions on ordering. However, these seem to
be necessary for interoperability, so that a dynamic bridge that tries to
find out about a Value by using Container::contents (dk_ValueMember, 0)
does the right thing.

Resolution: Add language to require preservation of order of elements in IR as shown below
Revised Text: In section 10.5.4.1 Read Interface section for Containers append the following paragraph: "contents and describe_contents return a list of elements in their original order (i.e. the order in which the elements were created in or moved into the container). If exclude_inherited is false, the ordering of inherited elements is undefined."
Actions taken:
January 16, 2001: received issue
October 3, 2001: closed issue

Issue 4159: core issue: unchecked narrow (orb_revision)

Click here for this issue's archive.
Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com)
Nature: Uncategorized Issue
Severity:
Summary:

CORBA Core should state that language mappings providing a narrowing mechanism 
are also required to provide an 'unchecked narrowing'-mechanism.

The original CORBA Messaging specification (orbos/98-05-05) specifies an 
unchecked narrow operation that has not been changed by any Messaging RTF. 
'unchecked narrowing' is not an issue of a single language mapping. Therefore, 
it would be good if this was formulated in the CORBA Core as a general 
requirement for any language mapping.

The originally adopted CORBA Messaging specification, orbos/98-05-05, had an 
explanatory paragraph for this purpose:

'3.3.7 Note on Asynchrony and Narrowing of Object References
Many programming languages map IDL interfaces to programming constructs that
support inheritance. In those language mappings (such as C++ and Java) that 
provide
a mechanism for narrowing an Object reference of a base interface to a more 
derived
interface, the act of narrowing may require the full type hierarchy of the 
target. In this case, the implementation of narrow must either contact an 
interface repository or the target itself to determine whether or not it is 
safe to narrow the client�s object reference. This requirement is not 
acceptable when a client is expecting only
asynchronous communication with the target. Therefore, for the appropriate 
languages
this specification adds an unchecked narrow operation to the IDL mappings for
interface. This unchecked narrow always returns a stub of the requested type 
without
checking that the target really implements that interface. If a client narrows 
the target to an unsupported interface type, invoking the unsupported 
operations will raise the system exception CORBA::BAD_OPERATION.'


However, the semantics of the above have obviously not made it into CORBA 2.4.

Resolution: Incorporate changes and close issue
Revised Text: 1. Insert section 4.3.7 "Type Coercion Considerations" as follows: 4.3.7 Type Coercion Considerations Many programming languages map Object to programming constructs that support inheritance. Mappings to languages (such as C++ and Java) typically provide a mechanism for narrowing (down-casting) an object reference from a base interface to a more derived interface. To do such down-casting in a type safe way, knowledge of the full inheritance hierarchy of the target interface may be required. The implementation of down-cast must either contact an interface repository or the target itself, to determine whether or not it is safe to down-cast the client�s object reference. This requirement is not acceptable when a client is expecting only asynchronous communication with the target. Therefore, for the appropriate languages an unchecked down-cast operation (also referred to as unchecked narrow operation) shall be provided in the mapping of Object. This unchecked narrow always returns a stub of the requested type without checking that the target really implements that interface.
Actions taken:
January 19, 2001: received issue
October 3, 2001: closed issue

Discussion:

This indeed needs to be mentioned in Chapter 4. Unfortunately, since 
narrow only applies to strongly typed languages, it is not an operation in the 
Object reference, and nor should it be. However, the issue of type coercion does 
deserve a mention in section 4.3. So what is proposed is to insert a section after 
section 4.3.6 "Object Reference Identity" with the title 
"Type Coercion Considerations" with contents as shown below

Issue 4165: PortableServer::ObjectId (orb_revision)

Click here for this issue's archive.
Source: IONA (Mr. Matthew Newhook, )
Nature: Uncategorized Issue
Severity:
Summary:

 I propose that ObjectId be changed from:

  typedef sequence<octet> ObjectId;

  to:

  typedef CORBA::OctetSeq ObjectId;

  This shouldn't cause any existing code to break. However, currently
  PortableInterceptor::ObjectId (needed so that the PI module doesn't
  depend on the PortableServer module) isn't directly assignable to
  PortableServer::ObjectId which means additional copying that doesn't
  seem necessary. It also reduces the code-size of the ORB somewhat
  (since a sequence type can be removed from the core).

Resolution: Incorporate changes and close issue
Revised Text: On page 11-43, change the definition of ObjectId to read: typedef CORBA::OctetSeq ObjectId; Change the IDL in formal/00-04-01, in the file PortableServer.idl, accordingly.
Actions taken:
January 20, 2001: receive dissue
January 22, 2001: moved from C++ RTF to the Core RTF
October 3, 2001: closed issue

Discussion:

Issue 4170: Type redefinition in derived interface (orb_revision)

Click here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The discussion for issue 3525 shows that it is legal to redefine a type
in a derived interface, as in

interface B     { typedef string S; };
interface D : B { typedef long S; };

However, I don't think that this legality is obvious from the text. On
page 3-52, it says that "inheritance causes all identifiers defined in
base interfaces to be visible in derived interfaces." Then, on page
3-56, it is said that "once a type has been defined anywhere within
the scope of a module, interface or valuetype, it may not be redefined
except within the scope of a nested module or interface."

Since B::S is not "defined" but only "visible" in D, and D is not a
nested interface but a derived interface, there seems to be a gray
area.

Proposed resolution:

Edit the first paragraph of 3.15.3 (Special Scoping Rules for Type
Names) on p 3-56 to read:

"Once a type has been defined anywhere within the scope of a module,
interface or valuetype, it may not be redefined except within the
scope of a nested module, interface or valuetype, or within the
scope of a derived interface or valuetype."

Edit the following example to include, after interface A, but before
the erroneous redefinition of ArgType,

interface B : A {
  typedef long ArgType;    // OK, redefined in derived interface
  struct S {               // OK, redefined in derived interface
    ArgType x;             // x is a long
    A::ArgType y;          // y is a string
  };
};

Resolution: Make the suggested change clarifying the inheritance case
Revised Text: 1. Change the first paragraph of 3.15.3 (Special Scoping Rules for Type Names) on to read: "Once a type has been defined anywhere within the scope of a module, interface or valuetype, it may not be redefined except within the scope of a nested module, interface or valuetype, or within the scope of a derived interface or valuetype." 2. Change the following example to include, after interface A, but before the erroneous redefinition of ArgType, interface B : A { typedef long ArgType; // OK, redefined in derived interface struct S { // OK, redefined in derived interface ArgType x; // x is a long A::ArgType y; // y is a string }; };
Actions taken:
January 23, 2001: received issue
October 3, 2001: closed issue

Issue 4171: Introduction of identifiers (orb_revision)

Click here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

I cannot seem to come to grips with the introduction of identifiers
by their use in a nested scope. The example on page 3-54 reads
(simplified)

module Inner1 {
  typedef string S1;
};

module Inner2 {
  typedef Inner1::S1 S2; // Inner1 introduced
  typedef string inner1; // Error
};

The text goes on to explain that the above construct introduces the
identifier "Inner1", while using the absolute name, "::Inner1::S1"
in the typedef wouldn't. Therefore, the following code would be
legal:

module Inner2 {
  typedef ::Inner1::S1 S2; // Inner1 not introduced
  typedef string inner1;   // legal
};

I fail to see the rationale in this. Also, this is not in sync with
the Interface Repository, which cannot even detect that the first
example is illegal, because it never sees relative names.

My proposed resolution would be to get rid of "introduced names"
altogether and to declare the above example legal.

Resolution: Close no change
Revised Text:
Actions taken:
January 23, 2001: received issue
October 3, 2001: closed issue

Discussion:

No specific bug has been identified above. It is not clear 
what it means for this to be out of sync with IFR, and what relevance it 
has to this discussion. Insufficient justification for change. 
Revised Text: 
Actions taken: Close no change

Issue 4176: ForwardRequest from normal operations (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

interface Foo {
		void op() raises(PortableServer::ForwardRequest);
	};

What happens if a client invokes op() and op() throws ForwardRequest?
Is this received by the client as a locate forward or does the client
simply receive the exception?

The spec doesn't say either way. However, thinking about how all this is
implemented, I strongly suspect that current implementations will simply
marshal the exception back to the client instead of sending a locate forward
reply.

Personally, I think that's how it should be. If it werent, we'd have to
insert additional code into the user exception processing path to deal
with this special exception (which would probably set a bad precedent).

I'd suggest to amend the spec to state that ForwardRequest has the effect
of causing a locate forward reply only if thrown from preinvoke() and
incarnate() and is otherwise just a normal exception.

Resolution: Incorporate change and close issue
Revised Text: : All references relative to orbrev/01-03-01: 1. Replace the last sentence of section 11.2.6 by: "The ORB will process this exception as specified in section 11.3.4.1." 2. In section 11.3.4.1 insert the following single sentence paragraph immediately preceding the last paragraph of the section: "If the ForwardRequest exception is raised anywhere else it is passed through the ORB as a normal user exception."
Actions taken:
January 26, 2001: received issue
October 3, 2001: closed issue

Discussion:

Add a clarifying sentence or two to the Portable Server chapter to 
make the behavior of PortableServer::ForwardRequest consistent with that of 
PortableInterceptor::ForwardRequest.

Issue 4189: Inconsistent text for unknown system exception (orb_revision)

Click here for this issue's archive.
Source: IONA (Mr. Mark Spruiell, )
Nature: Uncategorized Issue
Severity:
Summary:

In document 01-01-01, there are the following paragraphs which seem
contrary to one another regarding the minor code to be used when an
ORB receives an unrecognized system exception.

4.11.2
Vendors may define non-standard system exceptions, but these exceptions are
discouraged because they are non-portable. A non-standard system exception, when
passed to an ORB that does not recognize it, shall be presented by that ORB as an
UNKNOWN standard system exception. The minor code and completion status from
the unrecognized exception shall be preserved in the UNKNOWN exception.

15.3.5.5 Exception
Exceptions are encoded as a string followed by exception members, if any. The string
contains the RepositoryId for the exception, as defined in the Interface Repository
chapter. Exception members (if any) are encoded in the same manner as a struct.
If an ORB receives a non-standard system exception that it does not support, or a user
exception that is not defined as part of the operation's definition, the exception shall be
mapped to UNKNOWN, with standard minor code set to 2 for a system exception, or
set to 1 for a user exception.

Resolution: Incorporate changes and close issue
Revised Text: Replace the sentence that reads: "The minor code and completion status from the unrecognized exception shall be preserved in the UNKNOWN exception." by the sentence: "The completion status shall be preserved in the UNKOWN exception, and the minor code shall be set to standard value 2 for system exception and standard value 1 for user exception."
Actions taken:
February 3, 2001: received issue
October 3, 2001: closed issue

Discussion:

Make section 4.11.2 consistent with section 15.3.5.5 by changing section 
4.11.2 as shown below.

Issue 4217: misleading wording in 10.5.22.2 Write Interface (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The mode attribute can only be set to OP_ONEWAY if the result is TC_void and all
elements of params have a mode of PARAM_IN.

which might be taken to mean that the mode attribute *must* be set to
OP_ONEWAY if the signature is as described. A better wording might be

The mode attribute can be set to OP_ONEWAY only if the result is TC_void and all
elements of params have a mode of PARAM_IN.

This was brought to my attention by an email question I received today, from
someone who thought he understood CORBA oneway semantics until he
read that sentence - then he became confused.

Resolution: make it so
Revised Text: : In orbrev/01-03-01 Change the last para of section 10.5.22.2 to read: "The mode attribute can be set to OP_ONEWAY only if the result is TC_void and all elements of params have a mode of PARAM_IN."
Actions taken:
March 2, 2001: received issue
October 3, 2001: closed issue

Issue 4224: DynValueBox::set_boxed_value should also raise InvalidValue (orb_revision)

Click here for this issue's archive.
Source: IONA (Mr. Mark Spruiell, )
Nature: Uncategorized Issue
Severity:
Summary:

As with other DynAny operations that accept an Any parameter,
the set_boxed_value operation should be capable of raising
InvalidValue.

Proposal:

* In sections 9.2 and 9.12, add InvalidValue to the raises clause for
  set_boxed_value

* In section 9.12, replace the text describing set_boxed_value with the
  following:

  "The set_boxed_value operation replaces the boxed value with the specified
   value. If the type of the passed Any is not equivalent to the boxed type,
   the operation raises TypeMismatch. If the passed Any does not contain a
   legal value, the operation raises InvalidValue. If the DynBoxedValue
   represents a null valuetype, it is converted to a non-null value."

Resolution: Make it so
Revised Text: Errata: 2. In the resolution for issue 4224, Summary section and Revised text sections, section number 9.12 should be replaces by section 9.2.12. The issue as filed was incorrect in identifying the relevant section, and the error carried through into the resolution. There is no section 9.12 in the document.
Actions taken:
March 16, 2001: received issue
October 3, 2001: closed issue

Issue 4226: #include issue (orb_revision)

Click here for this issue's archive.
Source: AT&T (Dr. Duncan Grisby, )
Nature: Uncategorized Issue
Severity: Minor
Summary:

A minor issue with section 3.3 of the 2.4 specification:

  "... Text in files included with a #include directive is treated as
   if it appeared in the including file. ..."

That is not true since, as we find out in chapter 10, included files
behave specially with regard to assigning repository identifiers.

e.g. in

  // a.idl
  #pragma prefix "foo"
  interface bar {};

the repository id of bar is IDL:foo/bar:1.0, but in

  // a.idl
  #pragma prefix "foo"
  #include "b.idl"

  // b.idl
  interface bar {};

it is just IDL:bar:1.0.

Resolution: Incorporate changes and close issue
Revised Text: Replace the last two sentences of section 3.3 of orbrev/01-03-01 by the following: "Text in files included with a #include directive is treated as if it appeared in the including file, except that RepositoryId related pragmas are handled in a special way. The special handling of these pragmas is described in Section 10.6 RepositoryIds on page 10-42."
Actions taken:
March 20, 2001: received issue
October 3, 2001: closed issue

Discussion:

The quoted sentence in section 3.3 is somewhat misleading. 
Word it better as proposed below.

Issue 4233: What is the semantics of the DataInputStream::read_*_array() operations? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Ms. Yvonne Biggar, von(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The CORBA::DataInputStream abstract valuetype has operations like:

void read_boolean_array( inout BooleanSeq seq,
			in unsigned long offset,
			in unsigned long length);

However, the spec says nothing about whether the provided sequence must
already have sufficient length to satisfy the offset+length or whether
the operation will extend the sequence to fit.

Resolution: Clarify that the operations are expected to extend the sequence to fit
Revised Text: : In orbrev/01-03-01 section 5.5.2, on page 5-16, insert the following paragraph, immediately after the first paragraph that follows the IDL for DataInputStream: "The read_* operations that have an inout parameter named seq are expected to extend the sequence to fit the read value."
Actions taken:
March 23, 2001: received issue
October 3, 2001: closed issue

Issue 4241: 3.7.4 Forward Declaration (for interfaces) doesn't mention local (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 3.7.4 doesn't mention local as a legal prefix for an interface
forward declaration.

Proposal 1:

Change the sentence:

"The syntax is: optionally the keyword abstract, followed by the keyword
interface, followed by an <identifier> that names the interface."

to:

"The syntax is: optionally either the keyword abstract or the keyword
local, followed by the keyword interface, followed by an <identifier>
that names the interface."

Proposal 2:

Just strike the sentence entirely, since it is redundant.

Resolution: Make the recommended change in Proposal 1
Revised Text: In orbrev/01-03-01 in section 3.7.4 replace the sentence: "The syntax is: optionally the keyword abstract, followed by the keyword interface, followed by an that names the interface." by the sentence: "The syntax is: optionally either the keyword abstract or the keyword local, followed by the keyword interface, followed by an identifier that names the interface."
Actions taken:
March 27, 2001: received issue
October 3, 2001: closed issue

Issue 4246: Definition of NamingContextExt interface in IDL of Appendix A not consisten (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The definition of the NamingContextExt interface in the IDL of Appendix A is not consistent with the definition in section 2.5.4. 

Specifically, 

1. The Appendix A version has an extra operation: resolve_context 

2. In Appendix A, there is an extra exception type in the raises clause of the resolve_str operation: AlreadyBound

Resolution: see above
Revised Text: No text changes in Core chapters.
Actions taken:
March 29, 2001: received issue
April 4, 2001: assigned to orb_revision
October 3, 2001: closed issue

Discussion:

In the absence of a Naming Service RTF carry out the following to resolve this issue: 

1. In formal/01-02-65, page A-3, delete the resolve_context() operation 
from the IDL. 

2. In formal/01-02-65, page A-3, delete the AlreadyBound exception from 
the raises clause of resolve_str(). 

3. formal/98-10-19.idl contains old IDL. Republish formal/98-10-19.idl as 
as new document, with the correct IDL. A copy of that corrected IDL 
is attached to this message, as 98-10-19_new.idl. 

4. Republish formal/98-10-01.txt and formal/98-10-01.idl. A copy of the 
correct IDL is attached to this message as 98-10-01_new.idl. 

5. Remove the Names Library IDL from 98-10-01.idl. (This has been done in 
the attached 98-10-01_new.idl.) 

6. Remove advertisements for formal/98-10-20.idl from the OMG server. (The 
Names Library no longer exists.) 

7. Update the web pages to remove references to 98-10-20 and replace them with 
the new version of that document. The main page is 
http://www.omg.org/technology/documents/formal/corbaservices_omg_idl_text_files.htm, 
but there may be others that reference this document.

Issue 4261: Incorrect example for recursive definitions which can span multiple levels (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Incorrect example for recursive definitions which can span multiple levels. I and my IDL compiler are missing an identifier in the following example union for the last struct member. 

union Bar; // Forward declaration typedef sequence<Bar> BarSeq; union Bar switch(long) { // Define forward-declared union case 0: long l_mem; case 1: struct Foo { double d_mem; BarSeq nested;// OK, recurse on enclosing type being defined } ???identifier missing???; };

Resolution: This has already been fixed in the previous RTF see orbrev/2001-03-01
Revised Text:
Actions taken:
April 9, 2001: received issue
April 10, 2001: closed issue

Issue 4262: Clarification about include files and IDL compiler behavior (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

I think it would be nice to mention something about code generation in
section 19.5.22.2. People seem to either expect that the compiler will
generate code for everything, or that it will generate code only for
things that are not in included files. The following might help to clear
this up:

"Note that whether a particular IDL compiler generates code for included
files is an implementation-specific issue. To support separate
compilation, IDL compilers may not generate code for included files, or
do so only if explicitly instructed."

Resolution: Insert the sugested text in section 3.3
Revised Text: Append the following text as the last paragraph of section 3.3: Note that whether a particular IDL compiler generates code for included files is an implementation-specific issue. To support separate compilation, IDL compilers may not generate code for included files, or do so only if explicitly instructed.
Actions taken:
April 10, 2001: received issue
October 3, 2001: closed issue

Issue 4264: Restrictions on native types (orb_revision)

Click here for this issue's archive.
Source: Humboldt-Universitaet (Mr. Martin von Loewis, loewis(at)informatik.hu-berlin.de)
Nature: Uncategorized Issue
Severity:
Summary:

The new text in 3.10.5 states: "Native type parameters are permitted
only in operations of local interfaces or valuetypes". However, 11.4
states that:
a) Servant is a native type, and
b) that it is used on the POA::get_servant operation, and
c) that POA is not a local interface
(Taking POA as an arbitrary example here; other POA interfaces show
the same problem). Does that mean that CORBA 2.5 will be inconsistent?

Resolution: see above
Revised Text: In document orbrev/01-03-01 make the following changes: 1. Remove section 11.3.2.2, thus renumbering all following subsections at the same level appropriately, and append the following paragraph immediately following the s econd paragraph of section 11.3.2: "POAManager is a local interface." 2. Remove the section title 11.3.3.1 and renumber all following subsections at the same level appropriately. This will cause the single sentence in section 11.3.3.1 to become the last paragraph in section 11.3.3. Append the following sentence to this paragraph: "AdapterActivator is a local interface." 3. Remove section 11.3.4.2 and append the following paragraph to section 11.3.4 (immediately preceding section 11.3.4.1): "ServantManager is a local interface. A ServantManager object must be local to the process containing the POA objects it is registered with." 4. Insert the following as paragraph number two in section 11.3.6: "ServantLocator is a local interface. A ServantLocator object must be local to the process containing the POA objects it is registered with." 5. Append the following sentence to the first para of section 11.3.7: "All Policy interfaces defined in this section are local interfaces." 6. Rplace section 11.3.8.1 by the single sentence: "The POA interface is a local interface." Renumber all following subsections of section 11.3.8 at the same level or below appropriately. 7. In section 11.3.9 insert the following paragrpah immediately following para 2: "PortableServer::Current is a local interface." 8. In the IDL in section 11.4 prepend the keyword "local" to the following interface declarations: ThreadPolicy LifespanPolicy IdUniquenessPolicy IdAssignmentPolicy ImplicitActivationPolicy ServantRetentionPolicy RequestProcessingPolicy POAManager AdapterActivator ServantManager ServantActivator ServantLocator POA Current
Actions taken:
April 10, 2001: received issue
October 3, 2001: closed issue

Discussion:

Incorporate changes implied in  the adopted Components specification 
regarding local interfaces, in the process explicitly declaring the interfaces that contain 
operations passing native parameters as local, thus resolving this issue

Issue 4266: Section 10.5.22.2 what happens when conditions not met (orb_revision)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Uncategorized Issue
Severity:
Summary:

What happens when someone attempts to set the mode attribute while not
adhering to the restrictions spelled out?

We should say what happens if these conditions
   aren't met.  Furthermore, a oneway method can't have exceptions.
   I suggest:

   * add a new row to the BAD_PARAM block in Table 10-1 (p.10-10):

     Exception      Minor Code    Explanation

     BAD_PARAM      N             Attempt to define a oneway
                                  operation with non-void result,
                                  out or inout parameters or
                                  exceptions

   * Add a similar entry to table 4.3 (p.4-61).

   * Change the last para of 10.5.22.2 to read:

     "The mode attribute can be set to OP_ONEWAY only if the result is
     TC_void, all elements of params have a mode of PARAM_IN, and the
     list of exceptions is empty.  If the mode is set to OP_ONEWAY
     when these conditions do not hold, a BAD_PARAM exception is
     raised with minor code N."

   This is perhaps rather large to be a friendly ammendment.  I'm
   happy to vote YES to the current resolution, which is still a
   useful change, and raise this for next time.  I can't discuss
   further in this round, as I'm on vacation for a week from this
   evening.

Resolution: see above
Revised Text: 1. add a new row to the BAD_PARAM block in Table 10-1 (p.10-10): Exception Minor Code Explanation BAD_PARAM N Attempt to define a oneway operation with non-void result, out or inout parameters or exceptions 2. Add a similar entry to table 4.3 (p.4-61). 3. Change the last para of 10.5.22.2 to read: "The mode attribute can be set to OP_ONEWAY only if the result is TC_void, all elements of params have a mode of PARAM_IN, and the list of exceptions is empty. If the mode is set to OP_ONEWAY when these conditions do not hold, a BAD_PARAM exception is raised with minor code N."
Actions taken:
April 11, 2001: received sisue
October 3, 2001: closed issue

Discussion:

We should say what happens if these conditions 
aren't met.  Furthermore, a oneway method can't have exceptions. 
So the solution must depend on standard system exceptions. Make the 
changes shown below to resolve this issue

Issue 4275: Issue: Error in section 4.5.3.2 ORBInitRef (orb_revision)

Section 4.5.3.2 says:
<ObjectURL> can be any of the URL schemes supported by
CORBA::ORB::string_to_object (Sections 13.6.6 to 13.6.7 CORBA 2.3
Specification).

Couple of problems w/ this. Shouldn't the reference be Section 13.6.10
of this spec. Also, the ObjectURL specifications in chapter 13 include a
"rir" protocol which obviously makes no sense for ORBInitRef.

Proposal:

Replace first sentence of last paragraph of section 4.5.3.2 from:

<ObjectURL> can be any of the URL schemes supported by
CORBA::ORB::string_to_object (Sections 13.6.6 to 13.6.7 CORBA 2.3
Specification).

to

<ObjectURL> can be any of the URL schemes supported by
CORBA::ORB::string_to_object (Section 13.6.10), with the exception of
the corbaloc URL scheme with the rir protocol (i.e. corbaloc:rir:...).

Resolution: Fix as suggested above
Revised Text: : In orbrev/01-03-01: Replace first sentence of last paragraph of section 4.5.3.2 from: <ObjectURL> can be any of the URL schemes supported by CORBA::ORB::string_to_object (Sections 13.6.6 to 13.6.7 CORBA 2.3 Specification). to <ObjectURL> can be any of the URL schemes supported by CORBA::ORB::string_to_object (Section 13.6.10), with the exception of the corbaloc URL scheme with the rir protocol (i.e. corbaloc:rir:...).
Actions taken:
April 17, 2001: received issue
October 3, 2001: closed issue

Issue 4276: Cross-reference refers to wrong section (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The second paragraph of "3.10.1.7 Any Type" uses a cross-reference to explain the concept of the TypeCode in an Any value. This cross-reference refers to section 3.10, which is useless. 

Suggestion: Change this cross-reference to read as follows: '(see Section 10.7, "Type Codes", on page 10-51)'

Resolution: Fix as suggested
Revised Text: Change this cross-reference in the second paragraph of "3.10.1.7 Any Type" that refers erroneously to section 3.10, to read as follows: '(see Section 10.7, "Type Codes", on page 10-51)'
Actions taken:
April 18, 2001: received issue
October 3, 2001: closed issue

Issue 4285: BAD_OPERATION needs minor code and completion status (orb_revision)

Click here for this issue's archive.
Source: Oracle (Dr. Harold Carr, Ph.D., harold.carr(at)sun.com)
Nature: Uncategorized Issue
Severity:
Summary:

"This indicates that an object reference denotes an existing object,
but that the object does not support the operation that was invoked."

This text does not specify a minor code nor a completion status.


Section 11.3.4.1 (last paragraph) says:

"If the ServantManager returns the wrong type of Servant, it is
indeterminate when that error is detected. It is likely to result in a
BAD_OPERATION with standard minor code 5 or MARSHAL exception at the
time of method invocation."

This implies that 4.11.3.13 should specify a '5' for the minor code.


A specific minor code for this case is necessary since BAD_OPERATION
may be raised in other contexts (e.g., IDL->Java mapping for union,
Any, any extraction, ...).

I am not sure why it says '5' in 4.11.3.13.  Is this minor code
specified somewhere else that I'm missing?

Assuming that this is underspecified I would suggest:

1. assigning a minor code for the case discussed in 4.11.3.13,

2. making sure that 11.3.4.1 is in sync with that assignment,

3. specifying a completion status of COMPLETED_NO (since there is no
way anything could be completed since the call never makes it out of
the skeleton into the servant).

Resolution: see above
Revised Text: 1. In Table 4-1 Insert a line: BAD_OPERATION X "ServantManager returned wrong servant type" 2. In Section 11.3.4.1 change the '5' to 'X' [X to be assigned by OMG].
Actions taken:
April 26, 2001: received issue
October 3, 2001: closed issue

Discussion:

Currently there are no minor codes defined for BAD_OPERATION. 
In order to actually assign a minor code for this case make the changes shown below. 

[Will it actually be possible to determine the root cause when the problem is discovered 
at some indeterminate time with sufficient accuracy to actually be able to use this minor code?]

Issue 4297: Missing POAManager identity (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

the current way of dealing with POAManager objects is less than satisfactory.
Consider:

    interface POA {
        // ...
        POA create_POA(
                in string            adapter_name,
	        in POAManager        a_POAManager,
                in CORBA::PolicyList policies
            ) raises(AdapteraAlreadyExists, InvalidPolicy);

        readonly attribute POAManager the_POAManager;
    };

The problem here is twofold:

	- There is no way to get at the list of all existing POA managers,
	  at least not easily; I have to either keep a list myself,
	  or I have to traverse the POA tree and build the list as I go.

	- POA managers have no identity. There is no name or other piece
	  of state that would allow me to distinguish one POA manager from
	  another.

The second problem is the more serious one because POA managers are used
to control the behavior of one or more transport endpoints. Most ORBs
permit configuration control over transports. For example, it is usually
possible to configure things such as which protocols/transports should
be associated with a POA manager, how many protocols/transports should
be associated, at what address/port the transport controlled by a
POA manager should listen for requests, what timeouts to apply, etc, etc...

Currently, ORBs have to resort to proprietary means to attach such
configuration information. For example, in ORBacus, we use a proprietary
POA manager factory that permits a name to be attached to a POA manager.
That name then is used as a hook to attach configuration information
to POA managers, so we can do things like configure port numbers, etc.

I'd like to improve the spec such that it becomes possible to control
identity for POA managers through a standard API. The thoughts are:

	- Add a POAManagerFactory interface that allows

		- creation of POA managers

		- listing of existing POA managers

		- searching for POA managers by name

	- Add an id() accessor to POAManager that returns the name

For creation of POA managers, a CORBA::PolicyList can be passed into
the call in addition to the POA manager name. That policy list would permit
configuration of POA managers through a defined API (even though the
actual policies that apply would still be proprietary).

These changes would be completely backward-compatible, so no existing
code breaks.

Resolution: see below
Revised Text: All changes relative to document ptc/01-06-10 1. In section 11.4, "IDL for the PortableServer Module", add the following IDL to the PortableServerModule, following the definition of the POAManager interface: local interface POAManagerFactory { typedef sequence<POAManager> POAManagerSeq; exception ManagerAlreadyExists {}; POAManager create_POAManager( in string id, in CORBA::PolicyList policies ) raises(ManagerAlreadyExists, CORBA::PolicyError); POAManagerSeq list(); POAManagerSeq find( in string id); }; 2. n section 11.4, add the following the POAManager interface: local interface POAManager { // ... string get_id(); }; 3. In section 11.4, add the following to the POA interface, immediately following the the_POAManager attribute definition: local interface POA { // ... readonly attribute POAManagerFactory the_POAManagerFactory; // ... }; 4. Add a new bullet point to the list on page 11-4, following the bullet for "POA Manager": POA Manger Factory -- A POA Manager Factory allows explicit creation of POA managers and lookup of existing POA managers. With explicit creation, the developer can control the identity (the name) of a POA manager as well as pass configuration policies to the factory operation. 5. Add a new bullet point to the list at the beginning of section 11.3, immediately following the bullet "POAManager". - POAManagerFactory 6. Replace the second paragraph of section 11.3.2 by the following two paragraphs: Each POAManager has a unique string as its identity. The scope of the POAManager identity is the ORB, so no two POAManagers within the same ORB can have the same identity (but POAManagers in different ORBs can). The POAManager for the Root POA has the name "RootPOAManager". If a POAManager is created implicitly (as part of the creation of a new POA), it is assigned a unique identity by the ORB run time. If a POAManager is created explicitly (using the POAManagerFactory), its identity is the string passed to the factory operation. (An empty identity string is legal.) A POAManager is destroyed implicitly, when the last of its POAs is destroyed. 7. Add a new section 11.3.2.8: 11.3.2.8 get_id string get_id(); This operation returns the POAManager's unique identity. The id of the POAManager for the Root POA is "RootPOAManager". 8. Add a new section 11.3.3 "POAManagerFactory Interface" following section 11.3.2 (renumbering the current 11.3.3, "AdapterActivator Interface" to be 11.3.4). 11.3.3 POAManagerFactory Interface POAManagers can be created implicitly, by passing a nil POAManager reference to the create_POA operation, or can be created explicitly using a POAManagerFactory. Explicit creation of a POAManager permits application control of the POAManager's identity, whereas implicit creation results in creation of a unique identity by the ORB run time. Explicit creation of a POAManager also permits the application to assign policies to the new POAManager. 11.3.3.1 create_POAManager exception ManagerAlreadyExists {}; POAManager create_POAManager( in string id, in CORBA::PolicyList policies ) raises(ManagerAlreadyExists, CORBA::PolicyError); This operation creates a new POAManager with the given id. If a POAManager with the given id exists already within the ORB, the operation raises ManagerAlreadyExists. (Note that placing a POAManager into the inactive state does not necessarily result in destruction of the POAManager because destruction of a POAManager only occurs once the last of its POAs has been destroyed. create_POAManager succeeds in creation of a new POAManager with the same identity as a previous POAManager only once the previous POAManager's POAs are destroyed.) The policies parameter permits an arbitrary number of policies to be passed; these policies can be used by an ORB implementation to influence the POAManager's behavior in some way; for example, an ORB may choose to use this mechanism to pass configuration information to the factory. The policies passed to create_POAManager are deep-copied during creation; modification of a policy sequence after creation has therefore no effect on already existing POAManagers. If one or more of the policies are invalid, create_POAManager raises CORBA::PolicyError. The newly created POAManager is in the Holding state. 11.3.3.2 list typedef sequence<POAManager> POAManagerSeq; POAManagerSeq list(); The list operation returns all POAManagers (whether created implicitly or explicitly) that currently exist within the ORB. 11.3.3.3 find POAManager find(in string id); The find operation return the POAManager with the specified id. If no such POAManager exists, find returns a nil reference. 9. Add a new section 11.3.9.10 (following the current section 11.3.8.9, "the_POAManager": 11.3.9.10 the_POAManagerFactory readonly attribute POAManagerFactory the_POAManagerFactory; This attribute returns the POAManagerFactory that created the POA. 10. Update the UML diagram to include the new POAManagerFactory interface, the get_id() operation, and the the_POAManagerFactory attribute. 11. Update Figure 11-2 to include the POAManagerFactory interface. 12. The final adopted ORT specification with all FTF changes is ptc/01-08-31. The required changes to this specification to reflect the change proposed in this resolution is: In section 21.5.5, change typedef long AdapterManagerId to typedef string AdapterManagerId Also make the same change to the consolidated IDL in section 21.10.
Actions taken:
May 9, 2001: received issue
May 13, 2002: closed issue

Discussion:

There appears to be general consensus that this is a good idea 
The following changes are needed to make it happen 
Revised Text:

Issue 4306: Minor code (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

"If a ServantManager returns a null Servant (or the equivalent in a language mapping) as the result of an incarnate() or preinvoke() operation, the POA will return the OBJ_ADAPTER system exception with standard minor code 3 as the result of the request." 

Should that be minor code 2 rather than 3? I couldn't find any other reference to OBJ_ADAPTER minor code 2 and the description makes more sense for this condition.

Resolution: Yes the minor code in this case should indeed be 2. Make it so
Revised Text: Change the first sentence of the last paragraph of section 11.3.4.1 to read: "If a ServantManager returns a null Servant (or the equivalent in a language mapping) as the result of an incarnate or preinvoke operation, the POA will return the OBJ_ADAPTER system exception with standard minor code 2 as the result of the request."
Actions taken:
May 14, 2001: received issue
October 3, 2001: closed issue

Discussion:

Issue 4310: Inconsistent minor code for MARSHAL (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

on page 3-23 of section 3.7.6.1, first bullet point, we find:

	Local types cannot be marshaled and references to local objects
	cannot be converted to strings. Any attempt to marshal a local
	object, such as via an unconstrained base interface, as an Object,
	or as the contents of an any, or to pass a local object to
	ORB::object_to_string, shall result in a MARSHAL system exception
	with OMG minor code 2.
	     ^^^^^^^^^^^^^^^^
However, the minor code table, page 4-59, section 4.11.4 shows:

	MARSHAL		1 Unable to locate value factory.
			2 ServerRequest::set_result called before
			  ServerRequest::ctx when the operation IDL contains a
			  context clause.
			3 NVList passed to ServerRequest::arguments does not
			  describe all parameters passed by client.
			4 Attempt to marshal Local object.

This is inconsisent -- the text requires minor code 2, but the table
requires minor code 4.

I would suggest to update the first bullet of 3.7.6.1 to require minor code 4,
in line with what is shown in the table.

Resolution: Make it so
Revised Text: Change the first last sentence of the first bullet point on page 3-23 of section 3.7.6.1 to read: " Any attempt to marshal a local object, such as via an unconstrained base interface, as an Object, or as the contents of an any, or to pass a local object to ORB::object_to_string, shall result in a MARSHAL system exception with OMG minor code 4." instead of: "Any attempt to marshal a local object, such as via an unconstrained base interface, as an Object, or as the contents of an any, or to pass a local object to ORB::object_to_string, shall result in a MARSHAL system exception with OMG minor code 2." Errata: 3. In the resolution for issue 4310, Revised text section, first sentence: The phrase "Change the first last sentence....." should read "Change the last sentence.....".
Actions taken:
May 17, 2001: received issue
October 3, 2001: closed issue

Issue 4317: SYNC_WITH_SERVER (orb_revision)

Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

On page 22-6, we say for SYNC_WITH_SERVER:

	For a server using a POA, the reply would be sent after invoking
	any ServantManager, but before delivering the request to the target
	Servant.

What's the motivation for this? Why wait that long? The ServantManager
may still fail to return a servant for the request, meaning that
the ORB might as well acknowledge the request before the ServantManager is
called without losing anything.

Also, as specified, the receiving ORB has to first run any adapter
activators. Again, there doesn't seem any point in waiting this long.
Why can't the receiving ORB simply acknowledge the request as soon as
it has read the request header off the wire?

Resolution: withdrawn by submitter
Revised Text:
Actions taken:
May 21, 2001: received issue

Issue 4320: String literal definition incorrect. (orb_revision)

The following from the CORBA 2.4.1 specification.
3.2.5.2 Character Literals
A character literal is one or more characters enclosed in single quotes,
as in �x.�
Character literals have type char.
A character is an 8-bit quantity with a numerical value between 0 and
255 (decimal).

3.2.5.4 String Literals
A string literal is a sequence of characters (as defined in Section
3.2.5.2, �Character
Literals,� on page 3-9) surrounded by double quotes, as in �...�.


The above statements together implies that a string literal may contain
embedded NULL characters. That is incorrect. The definition of string
literals must explicitly eliminate NULL.

Proposal:
Revised text:

Section 3.2.5.4 String Literals

replace this first paragraph 
A string literal is a sequence of characters (as defined in Section
3.2.5.2, �Character
Literals,� on page 3-9) surrounded by double quotes, as in �...�.

with
A string literal is a sequence of characters (as defined in Section
3.2.5.2, �Character
Literals,� on page 3-9), with the exception of the character with
numeric value 0, surrounded by double quotes, as in �...�.

Resolution: Make it so
Revised Text: In orbrev/01-03-01: In section 3.2.5.4: replace this first paragraph which reads: "A string literal is a sequence of characters (as defined in Section 3.2.5.2, �Character Literals,� on page 3-9) surrounded by double quotes, as in �...�." with: "A string literal is a sequence of characters (as defined in Section 3.2.5.2, �Character Literals,� on page 3-9), with the exception of the character with numeric value 0, surrounded by double quotes, as in �...�." Actions taken:
Actions taken:
May 21, 2001: received issue
October 3, 2001: closed issue

Issue 4322: Ambiguity in non_existent (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 4.3.5.1 non_existent last paragraph says:

Probing for object non-existence may require contacting the ORB that
implements the
target object. Such an attempt may fail at either the local or the
remote end. If non-existent
cannot make a reliable determination of object existence due to failure,
it
raises an exception in the calling application code. This enables the
application to
distinguish among the true, false, and indeterminate cases.


This does not define what exception gets thrown in the indeterminate
case. I picked TRANSIENT, but COMM_FAILURE or NO_RESPONSE may also be
valid choices.

Proposal:

Change the sentence in last paragraph of section 4.3.5.1:
If non-existent cannot make a reliable determination of object existence
due to failure, it
raises an exception in the calling application code. 

to:
If non-existent cannot make a reliable determination of object existence
due to failure, it
raises a TRANSIENT with XX minor code in the calling application code.

Resolution: close, no change
Revised Text:
Actions taken:
May 24, 2001: received issue
October 3, 2001: closed issue

Discussion:

The language in the spec is already quite clear and gives the freedom to 
the implementor to give as much specific information as possible. It would be 
inappropriate to tie the implementors hands to require returning just the TRANSIENT exception

Issue 4331: DII create_request (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

CORBA 2.4.1 final, Section 7.2.1 (create_request), page 7-7, last
paragraph reads:

"If the name of an implicit operation that is not invocable through DII
is passed to create_request with a "_" prepended, create_request shall
raise a BAD_PARAM standard system exception".

This does not specifies the minor code for the exception.

Resolution: see above
Revised Text: In orbrec/01-03-01 make the following changes: 1. In Table 4-3 add a line under BAD_PARAM: xxxx DII asked to create request for an implicit operation 2. In Section 7.2.1 last paragraph append the following to the last two sentences: "with the standard minor code xxxx". 3. Add the following paragraph to section 4.11.4 after table 4-3 If an exception that is to be raised for an error condition does not explicitly specify a specific standard minor code for that error condition, implementations can either use a minor code of zero, or use a vendor-specific minor code to convey more detail about the error.
Actions taken:
June 1, 2001: received issue
October 3, 2001: closed issue

Discussion:

Allocate a new minor code for BAD_PARAM to cover this case 
and update section 7.2.1 with info about using it. 

In addition, incorporate the boilerplate language in chapter 4 as suggested in the archive 
covering cases where specific minor code has not been standardized yet.

Issue 4333: Typo in UML for POA (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

The UML diagram on page 11-49 uses "the_manager" in two places. This
should be "the_POAManager".

In one place, it uses the attribute "the_servant_manager". No such attribute
exists.

Resolution: Make the suggested corrections
Revised Text: In orbrev/01-03-01: 1. Change the occurence of the_manager in the POA block in the UML diagram on page 11-51 to the_POAmanager. 2. In the same POA block remove the attribute line "the_servant_manager". (Note: couldn't find the secong the_manager in the diagram).
Actions taken:
June 4, 2001: received issue
October 3, 2001: closed issue

Issue 4335: get_interface() underspecified (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

the text for get_interface() says:

	An operation on the object reference, get_interface, returns an object
	in the Interface Repository, which provides type information that may
	be useful to a program. See the Interface Repository chapter for a
	definition of operations on the Interface Repository. The
	implementation of this operation may involve contacting the ORB
	that implements the target object.

This does not say what should happen if I call _get_interface() and

	- the interface repository isn't running,

	- the interface repository is running and can be reached, but
	  doesn't contain an entry for the object's interface.

Looking at the INTF_REPOS exception, we have:

	An ORB raises this exception if it cannot reach the interface
	repository, or some other failure relating to the interface
	repository is detected.

This would indicate that, if the repository isn't running, the client should
get INTF_REPOS. However, we have no idea what should happen if the repository
is in fine shape, but no entry exists for the interface.

Since an unpopulated interface repository is very much the same thing as
no interface repository at all, I would like to flag both scenarios as an
error.

Proposal: add the following sentence to the end of 4.11.3.22:

	If the interface repository is not available, get_interface() raises
	INTF_REPOS with minor code 1. If the interface repository does not
	contain an entry for the object's (most derived) interface,
	get_interface() raises INTF_REPOS with minor code 2.

Update the minor code table in 4.11.4 accordingly.

Resolution: Make the suggested change and the additional change suggested in the archive
Revised Text: In orbrev/01-03-01: 1. In table 4-2 insert the following lines: INTF_REPOS 1 Interface repository not available 2 No entry for requested interface in interface repository 2. Add the following sentence to the end of 4.11.3.22: If the interface repository is not available, get_interface raises INTF_REPOS with minor code 1. If the interface repository does not contain an entry for the object's (most derived) interface, get_interface raises INTF_REPOS with minor code 2. 3. Change the first sentence of 4.3.1.1, which currently reads: An operation on the object reference, get_interface, returns an object in the Interface Repository, which provides type information that may be useful to a program. to read get_interface returns an object in the Interface Repository that describes the most derived type of the object addressed by the reference. Errata: 4. In the resolution for issue 4335, Revised text section, in item 2, the section to which the new text is to be appended should be 4.3.1.1, and not 4.11.3.22. Section 4.3.1.1 contains documentation for the operation get_interface, which the proposed additional text is associated with. Section 4.11.3.22 is the generic description of the exception INTF_REPOS, and should not contain operation specific documentation.
Actions taken:
June 5, 2001: received issue
October 3, 2001: closed issue

Issue 4385: Problem with resolution to 4285 and 4306 (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

 Please take a look at the resolution of issues 4285 and 4306 in
> ptc/2001-06-08 - the RTF report that is up for recommendation to adopt
> at this upcoming meeting, and see if they do not fix these problems.
> 4285 fixes the BAD_OPERATION problem most definitely. 4306 seems to fix
> the OBJ_ADAPTER problem too, although slightly differently from how you
> suggest. If these fixes address the problem that you raise in your
> message, could you please ask Juergen to not create an issue?I didn't CC issues, so I don't think Juergen will create an issue (at least,
that was the intent). My apologies for the duplication. However, looking
at 4285 once again, I think there may be a problem:

In order to return something that means "ServantManager returned wrong
servant type", I think the ORB core has to insert an active check
at the point where the servant manager returns. If it doesn't, it will
either get an unmarshaling error or return a BAD_OPERATION exception with
some other minor code when it detects that the operation isn't in the
function pointer table for the servant. In the latter case, the ORB won't
know anymore *why* the operation is missing (for example, it could also
be missing because the client used the DII to invoke a non-existent operation.)

I am also not sure whether BAD_OPERATION is really the correct exception to
use. To me, BAD_OPERATION tells the client "you invoked an operation that
doesn't exist". If we give this exception to the client when it invokes
an operation that's perfectly good, that's highly misleading because the
actual problem isn't with the client, but with the servant manager.

So, I think that using OBJ_ADAPTER, as I suggested, would be better.

For the resolution to 4306, I think we also have something that is suboptimal.
That's because minor code 2 say "Servant not found" in table 4-3. But
I don't see how this is possible. Basically, a servant manager isn't allowed
to return a null servant. If it can't find the servant, it's supposed to
throw a system exception. So, a servant manager that returns null is simply
broken and needs to be recoded. 4306 (by using "Servant not found" as
the explanation of minor code 2) is misleading, because that condition simply
can't happen.

So, without trying to create a procedural mess, could we reconsider the
resolution to these two issues, maybe for the next vote?

Resolution: Fix inconsistency as described below
Revised Text: 1. Change table 4-3 as follows: - Replace the text for OBJ_ADAPTER with minor code 2 with: Incorrect servant type returned by servant manager - Add a new minor code 7 to OBJ_ADAPTER: OBJ_ADAPTER 7 Null servant returned by servant manager - Add a new entry to BAD_OPERATION: BAD_OPERATION 2 Operation or attribute not known to target object 2. Change the final para of 11.3.4.1 to read: If a ServantManager returns a null servant (or the equivalent in a language mapping) as the result of an incarnate() or preinvoke() operation, the POA returns the OBJ_ADAPTER system exception with standard minor code 7 as the result of the request. If the ServantManager returns the wrong type of servant, it is indeterminate when that error is detected. An ORB that chooses to detect the error shall raise OBJ_ADAPTER with standard minor code 2; an ORB that does not explicitly check for this error condition likely raises BAD_OPERATION with standard minor code 2 or a MARSHAL exception (with unspecified minor code) at the time of method invocation. 3. Change the last sentence of the final para of section B.2.5 on page 22-82 to read: If a client narrows the target to an unsupported interface type, invoking the unsupported operations raises BAD_OPERATION with standard minor code 2. 4. Change the last para on page 24-36 to read: In case of an explicit bind (via validate_connection), this service context is passed on a request message for a _bind_priority_band implicit operation. This implicit operation is defined for Real-Time CORBA only at this time. It is possible that a non-Real-Time ORB might receive such a request message. If so, that ORB shall raise a BAD_OPERATION exception with standard minor code 2. A future version of IIOP should formalize Real-Time CORBA''s use of the _bind_priority_band operation name in a GIOP Request message. Note that there is no API exposed for this implicit operation (unlike, for example, _is_a).
Actions taken:
June 23, 2001: received issue
May 13, 2002: closed issue

Issue 4386: Missing TypeCode identity (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

Steve's and my book contains a bit of code that pretty-prints a TypeCode.
(See page 704ff, in particular, 709-711.) No big deal -- just write
a recursive function that does a depth-first traversal of a TypeCode tree
and prints things out, except for one thing: recursive types.

For recursive types, the code has to be careful not to get trapped in
infinite recursion. In essence, this means that the pretty-printer has to
remember which TypeCodes it has already seen and end the recursion if it gets
to a TypeCode that was printed previously. This is where we run into
problems because there is no legal way to do this:

	- I cannot rely on the repository ID in the TypeCode to determine
	  TypeCode identity because the repository ID for structs and
	  unions is optional prior to GIOP 1.2, but recursion happens
	  via structs and unions. (A GIOP 1.2 implementation may interoperate
	  with a GIOP 1.0 or 1.1 implementation and still end up sending
	  TypeCodes without repository IDs.)

	- The code in the book uses is_equivalent() to determine whether
	  it has seen a TypeCode previously. However, doing this is
	  completely illegal (even though it happens to work with most
	  ORBs) because:

		- is_equivalent() does not provide object identity.

		- TypeCode is a pseudo-object, and pseudo-objects do
		  not inherit from CORBA object. This means that TypeCode
		  doesn't even *have* an is_equivalent() operation that I
		  could call.

So, as far as I can see, there is no compliant way to reliably and portably
determine TypeCode identity and, as a result, I can't ever reliably parse
a TypeCode...

I can see several solutions for this problem, all with different drawbacks:

	1) Add an identity() operation of some kind to TypeCode.

	   An ORB that receives a TypeCode would have to make sure that
	   it generates a unique ID for each TypeCode. But that's not
	   all that easy to implement -- in particular, if we have an
	   older TypeCode where all the optional bits are missing, we
	   can't reliably establish object identity for a TypeCode.
	   (Only structural comparison is possible.)

	2) Add an identity() operation to TypeCode, but have the TypeCode's
	   identity generated at the sending end instead of the receiving
	   end.

	   Major drawbacks: the identity would have to large because it
	   needs to be globally unique (e.g. a UUID) and it would change
	   the marshaling of TypeCodes.

	3) Add is_equivalent() and hash() operations to TypeCode.

	   This might break existing ORB implementations because a lot
	   of ORBs seem to inherit from Object for TypeCode and other PIDL
	   objects, even though they shouldn't.
	
	4) Make PIDL objects implicitly inherit from CORBA::Object.

Note that making the repository ID mandatory is impossible because we
can't legislate for existing GIOP 1.0 or 1.1 implementations...

On a related note, we seem to have further problems with the idea that
PIDL objects don't inherit from CORBA::Object. For example, in the C++ mapping,
pseudo-objects such as TypeCode, ORB, etc. can be passed as Object_ptr
(for example, to CORBA::is_nil()). This really means that the C++ mapping
(and possible mappings for other languages) are completely in conflict
with the core spec...

My feeling is that option 4 is really the least-intrusive one. But I'm
not sure that I fully understand all the ramifications of making that change.

Resolution: see above
Revised Text:
Actions taken:
June 28, 2001: received issue
May 13, 2002: closed issue

Discussion:

There appears to be significant discomfort about the ramifications 
of making any of the proposed changes. So it would be appropriate to close this 
issue no change

Issue 4387: Wither pseudo-objects? (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

the terms "pseudo-object", "pseudo-interface", and "PIDL" appear in many
places in the spec. However, there does not appear to be a definition
of what these things actually are anywhere in the spec. Now, for many years
now, I've been telling people that PIDL objects differ from normal ones
in the following ways:

	- They don't inherit from Object.

	- They can't be invoked via the DII.

	- They don't have definitions in the IFR.

	- They can't be passed as arguments to remote operations
	  (except for TypeCode).

	- They may have special mapping rules.

I know that, once upon a time, when I first wrote these points into a CORBA
training course, I didn't just make them up -- I found them in the spec.
However, I'm damned if I can find them now. I looked in the 2.0 spec as
well as the 2.4.2 spec to no avail. Can someone help me out?

At any rate, we should add the definition somewhere because, write now,
we have lots of free-floating terms in the spec.

On a related note, by searching for "pseudo", I found a few places where
it is stated that "pseudo-objects do not have object references". That
seems to be wrong. After all, we pass these things across (local) interfaces
by reference (instead of by value) and, at the language mapping level,
pseudo-objects have references that are indistinguishable from any other
reference. We should correct this.

Resolution: see above
Revised Text:
Actions taken:
June 29, 2001: received issue
May 13, 2002: closed issue

Discussion:

There appeared to be preponderance of opinion that while pseudo 
objects are accessed through implementation language references and even some 
of the CORBA::Object operations may be available from some of them, that does 
not imply that they are accessible through a CORBA object reference. 

The only definition of PIDL that covers it all is that the are things of which the 
interface is specified using an IDL-like language and they do not follow all of the 
rules that would make them a full-fledged CORBA object or a full-fledged 
CORBA local object. 

So unless there is a specific suggested change this issue should be closed no change

Issue 4388: Local interface is-a Object? (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

For local interfaces, we seem to have internal inconsistencies in the spec.
For one, it is not clear whether or not a local interface implicitly inherits
from Object. There is one sentence in the spec that seems to imply that
there *is* implicit inheritance from object, on page 3-23 of the 2.5 draft
(http://doc.omg.org/ptc/1-6-10):

	Any attempt to marshal a local object, such as via an unconstrained
	base interface, as an Object, or as the contents of an any, or to
	pass a local object to ORB::object_to_string, shall result in a
	MARSHAL system exception with OMG minor code 4.

This implies that I can at least try to pass local object as CORBA::Object,
which implies that local interfaces do indeed implicitly inherit from Object.

But then, a bit further down, it says:

	The is_a, get_interface, get_domain_managers, get_policy,
	get_client_policy, set_policy_overrides, get_policy_overrides, and
	validate_connection pseudo-operations, and any DII support
	pseudo-operations, may result in a NO_IMPLEMENT system exception
	with minor code 3 when invoked on a reference to a local object.

"*May* result in a NO_IMPLEMENT system exception"? I would suggest "shall"!

But, more seriously, I can't call is_a() on a local interface. In turn,
that seems to imply that I can't narrow a local interface either, but
narrowing is clearly necessary in the presence of inheritance for local
interfaces.

It seems that local interfaces *must* inherit from Object. After all,
it would be difficult to see, for example, how resolve_initial_references
can return a reference to the Root POA if it were otherwise... But then,
if local interfaces *do* inherit from Object, It doesn't make sense to
prohibit calling is_a() on them.

Related to that then is the question of "What is the repository ID of
a local interface?" Given that they can be narrowed, it would seem that
they must have repository IDs. (Although, you could argue that narrowing
is to be achieved via some mechanism other than repository IDs -- that
would also permit is_a() not to be supported and would make narrowing
an issue that is specific to each language mapping.)

But the inheritance issue seems serious -- if something doesn't inherit
from Object, I can't return or pass it as an Object, but we are doing
just that for local objects.

I think this will require some careful thought. We don't want to find
ourselves in yet another maze of twisty little passages, all different,
as we did with pseudo-objects...

Resolution: Incorporate changes and close issue
Revised Text: In ptc/01-06-10 substitute the first sentence of section 3.7.6.2 by: "Local interfaces are implemented by using CORBA::LocalObject which derives from CORBA::Object and provides implementations of Object pseudo operations and any other ORB specific support mechanisms that are appropriate for such objects."
Actions taken:
June 29, 2001: received issue
May 13, 2002: closed issue

Discussion:

Resolution: 
Clarify that CORBA::LocalObject is derived from CORBA::Object. 
This clearly was intended to be so as is bvious from looking at the C++ 
and Java language mappings of local objects.

Issue 4392: CORBA 2.4.2 (01-02-01.pdf) 4.2.3.4 shutdown (relevant portion) (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

CORBA 2.4.2 (01-02-01.pdf) 4.2.3.4 shutdown (relevant portion): "If the wait_for_completion parameter is TRUE, this operation blocks until the shut down is complete. If an application does this in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock." 

But does this mean that things will be as if the operation has not been called (suggested by the name of the exception raised?), or will they be as if the operation had been called with wait_for_completion FALSE (seems more appropriate)? Or should the implementation decide, and should it just use an appropriate completion code? In this case, is COMPLETION_MAYBE allowed? Letting the implementation decide puts a higher burden on the developer, though, if s/he wants to write portable code, so that developer may decide to just program for the current implementation... 

This question has additional relevance for me because I'm implementing an ORB.

Resolution: Clarify that BAD_INV_ORDER is raised in this case with COMPLETED_NO
Revised Text: Replace 4.2.4.4 shutdown (relevant portion): "If the wait_for_completion parameter is TRUE, this operation blocks until the shut down is complete. If an application does this in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock." by: "If the wait_for_completion parameter is TRUE, this operation blocks until the shut down is complete. If an application does this in a thread that is currently servicing an invocation, the ORB will not shutdown, and the BAD_INV_ORDER system exception will be raised with the standard minor code 3, and completion status COMPLETED_NO, since blocking would result in a deadlock."
Actions taken:
June 29, 2001: received issue
May 13, 2002: closed issue

Issue 4395: COBRA problem using pragma prefix for modules (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

Please have a look at the news article below. Basically, the problem is
that we don't say in the spec what has to happen if I try to give
conflicting prefixes/IDs/versions to a module (which can happen if a module
is reopened).

My feeling is that we should deal with this the same way as for forward
declarations, that is, force the compiler to emit a diagnostic. I think
we should also add a note that this can't be enforced by the compiler
under all circumstances because of separate compilation.
> Orbacus distribution contains following IDL file.
> 
> > #pragma prefix "omg.org"
> > 
> > module CosNaming
> > {
> >     typedef string Istring;
> > 
> >     struct NameComponent
> >     {
> > 	Istring id;
> > 	Istring kind;
> >     };
> > };
> > 
> > #pragma prefix "ooc.com"
> > 
> > module CosNaming
> > {
> >     typedef string Ostring;
> > };
> 
> And here the error message of IDL to Visual Basic compiler.
> 
> orbacusnaming.idl:16(8): Attempt to assign a different prefix
>                          to a forward-declared identifier
> orbacusnaming.idl:3(8): Position of the first identifier definition

The error message is misleading becuase there is no forward-declared
identifier here. But the compiler has a point -- something strange is
going on there...

> I look in the CORBA specification and found that modules do have
> repository ids.

Absolutely.

> > Forward-declared constructs (interfaces, value types, structures,
> > and unions) must have the same prefix in effect wherever
> > they appear. Attempts to assign conflicting prefixes
> > to a forward-declared construct result in a compile-time
> > diagnostic. For example:
> [...]
> 
> And what about reopened modules?

This part of the spec simply doesn't apply because it talks about
forward-declared things only.

> Which repository id do they
> have if someone use different prefix statements? I think
> they can have only one because the IFR of CORBA allows only
> one (if the repository version is equal).

Yes. The spec isn't really clear on this point. Here is your example
once more, simplified to the bare bones:

	#pragma prefix "X"
	module M {
		typedef string foo;
	};

	#pragma prefix "Y"
	module M {
		typedef string var;
	};

The spec simply does not address this problem, so we have a hole. Thinking
about it, there are two possible interpretations:

	1) Module M gets a prefix "X" initially. Then, when the prefix
	   changes to "Y" and the compiler sees M for the second time,
	   it could just ignore the prefix for M because M has the prefix
	   "X" already.

	2) The compiler could notice that M previously got prefix "X"
	   and then complain when it sees M for the second time because
	   it would get a conflicting prefix.

For forward-declared things, the spec applies the philosophy that
the prefixes must not change. Seeing that a reopened module is somewhat
similar to a forward declaration (because the same definition can be seen
more than once), I'd be inclined to amend the spec to say that the prefix
for a module must not change.

For cases where the compiler can actually detect this, we can even force
a diagnostic. However, as for forward-declared things, this is not always
detectable by the compiler. In particular, if the reopened module is
reopened in different source files and the two source files are compiled
separately, there is no way for the compiler to detect that the module
is getting a different prefix in each source file. If the generated code
from the two files is linked into the same binary, you should at least
get a multiple definition error. But if the code for the two files ends
up in different executables, there is no way to detect the error at all
and you will get strange things happening at run time.

As far as the ORBAcus IDL is concerned, I think it needs fixing. The second
prefix pragma should be inside the module, to avoid the conflict:

	#pragma prefix "omg.org"

	module CosNaming
	{
	    typedef string Istring;

	    struct NameComponent
	    {
		Istring id;
		Istring kind;
	    };
	};

	module CosNaming
	{
	#pragma prefix "ooc.com"

	    typedef string Ostring;
	};

> Is my IDL2VB compiler again buggy or the Orbacus IDL file
> or the CORBA specification not clear?

Well, a little bit of all three :-)  I'll raise an issue with the core RTF.

> I recently solve all founded bugs in IDL2VB and it compiles now
> all examples of syntax chapter in CORBA spec and find
> all errors. CORBA is to difficult for humans...

That's why we use compilers for IDL instead of humans :-)

Resolution: Clarify as described below
Revised Text: Add a new section 10.7.7 "Uniqueness Constraints on RepositoryIDs" to section 10.7: (Note: As adopted, the resolution required inserting a section 7.8, which turned out to be inappropriate. So editorial descretion was applied to find the right place and section number for this material and appropriate editorial changes were made in the report to reflect the reality.) 10.7.7 Uniqueness Constraints on Repository IDs Within an IDL definition, a module must have the same repository ID throughout. For example: #pragma prefix "A" module M { // ... }; #pragma prefix "B" module M { // Error, inconsistent repository ID // ... }; This definition attempts to use the same type name M with two different repository IDs in the same compilation unit. Compilers shall issue a diagnostic for this error. The same error can arise through inclusion of source files in the same compilation unit. For example: // File1.idl module M { module N { // ... }; #pragma ID N "abc" }; // File2.idl module M { module N { // ... }; }; // File3.idl #include "File1.idl #include "File2.idl // Error, inconsistent repository ID Similarly: // File1.idl module M { // ... }; // File2.idl #include File1.idl #pragma prefix "X" module M { // Error, inconsistent repository ID // ... }; Such errors are detectable only if they occur in a single compilation unit (or in files included in a single compilation unit); if, in different compilation units, different repository IDs are used for the same module, and these compilation units are combined into a single executable, the behavior is undefined.
Actions taken:
June 24, 2001: received issue
May 13, 2002: closed issue

Issue 4441: There is no mapping for fixed types in the COM/CORBA mapping (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

There is no mapping for fixed types in the COM/CORBA mapping. Why has this been omitted? Is there a submission underway?

Resolution: Close with answers to the qestions raised, as given above under Resolution
Revised Text:
Actions taken:
July 31, 2001: received issue
May 13, 2002: closed issue

Discussion:

1. Mapping for fixed type is not defined because fixed type in IDL did not exist when COM/CORBA mapping was adopted. 
2. There is no submission under way to address this.

Issue 4468: Interpretation of time field in UtcT? (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

in the absence of an RTF for the time service, I'm sending this to the
core RTF. (You could argue that this is a core issue anyway, since
the core depends on the time service for messaging.)

What is the interpretation of the time and tdf fields in a UtcT?

The spec shows:

	struct UtcT {
		TimeT		time;		// 8 octets
		unsigned long	inacclo;	// 4 octets
		unsigned short	inacchi;	// 2 octets
		TdfT		tdf;		// 2 octets
						// total 16 octets.
	};

For TimeT, the spec says:

	TimeT represents a single time value, which is 64 bits in size, and
	holds the number of 100 nanoseconds that have passed since the base
	time. For absolute time the base is 15 October 1582 00:00.

For UtcT, the spec says:

	UtcT defines the structure of the time value that is used
	universally in this service. The basic value of time is of type
	TimeT that is held in the time field. Whether a UtcT structure
	is holding a relative or absolute time is determined by its history.
	[...]
	The tdf field holds time zone information. Implementation must
	place the time displacement factor for the local time zone in this
	field whenever they create a UTO.

Resolution: see below
Revised Text: Replace the text in section 1.3.2.4 of formal/00-06-26 and section 2.2.1.4 of ptc/00-04-02, "Type UtcT" in its entirety with the following text: UtcT defines the structure of the time value that is used universally in this service. The basic value of time is of type TimeT that is held in the time field. Whether a UtcT structure is holding a relative time (that is, a duration) or an absolute time is determined by context; there is no explicit flag within the object holding that state information. (Note that, if a UtcT structure is used to hold a duration, its tdf must be set to zero.) The iacclo and inacchi fields together hold a 48-bit estimate of inaccuracy in the time field. These two fields together hold a value of type InaccuracyT packed into 48 bits. The tdf field holds time zone information. Implementations must place the time displacement factor for the local time zone in this field whenever they create a UTO that expresses absolute time. The time field of a UtcT used to express absolute time holds UTC time, irrespective of the local time zone. For example, to express the time 3:00pm in Germany (which is one hour east of the Universal Time Zone), the time field must be set to 2:00pm on the given date, and the tdf field must be set to 60. This means that, for any given UtcT value 'utc', the local time can be computed as utc.time + utc.tdf * 600,000,000 Note that it is possible to produce correct UtcT values by always setting the tdf field to zero and only setting the time field to UTC time; however, implementations are encouraged to include the local time zone information for the UtcT values they produce.
Actions taken:
August 9, 2001: received issue
May 13, 2002: closed issue

Discussion:

The proposed replacement text below need to be applied to both the original Time Service 
and the Enhnced View of Time Specification ptc/00-04-02

Issue 4532: Nil return from resolve_initial_references() (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

The spec doesn't say whether or not resolve_initial_references() is allowed
to return nil. Clearly, it doesn't make sense for it to do that -- we
should say so in the spec.

Resolution: see below
Revised Text: On page 4-24, insert the following paragraph immediately preceding the para starting with "Currently reserved ObjectIds are...": resolve_initial_references never returns a nil reference. Instead, the non-availability of a particular reference is indicated by throwing an InvalidName exception (even if a nil reference is explicitly configured for an ObjectId).
Actions taken:
August 23, 2001: received issue
May 13, 2002: closed issue

Discussion:

resolve_initial_references was never intended to return a Nil reference. It was always supposed to 
raise a designated exception in case no object reference was found matching the search criteria. 
Make ths explicit.

Issue 4620: Section 11.3.8.16 - ambiguity (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity:
Summary:

My issue is the ambiguity surrounding the following statement: 

"If the POA has the SYSTEM_ID policy and it detects that the Object Id value was not generated by the system or for this POA, the activate_object_with_id operation may raise the BAD_PARAM system exception." 

So the spec says the operation may raise the BAD_PARAM exception, but doesn't have to. It would be nice if the spec were to clarify the exact behaviour that should be followed to remove ambiguity, because I'm finding some ORB implementations are throwing a BAD_PARAM exception whereas others are not raising an error condition at all.

Resolution:
Revised Text: In ptc/01-06-10 in section 11.3.8.15, append the following sentence to the third paragraph clarifying why in general an ORB cannot be required to raise this exception: "A POA is not required to raise the BAD_PARAM exception in this case because, in the general case, accurate rejection of an invalid Object Id requires unbounded persistent memory of all previously generated Id values."
Actions taken:
October 16, 2001: received issue
May 13, 2002: closed issue

Discussion:

Since POAs in general do not have persistent memory 
it is impossible for them to verify the correctness of an ObjectId. That is 
why the word "may" was used instead of "shall". Any ORB that can actually 
do the necessary verification can raise that exception, but need not.

Issue 4623: Support for is_a for local interfaces (orb_revision)

Proposal: Section 3.7.6.1: Change the bullet that says
- The is_a, get_interface, get_domain_managers, get_policy,
get_client_policy, set_policy_overrides, get_policy_overrides, and
validate_connection pseudo-operations, and any DII support
pseudo-operations,
may result in a NO_IMPLEMENT system exception with minor code 3 when
invoked on a reference to a local object.

to:

- The get_interface, get_domain_managers, get_policy,
get_client_policy, set_policy_overrides, get_policy_overrides, and
validate_connection pseudo-operations, and any DII support
pseudo-operations,
may result in a NO_IMPLEMENT system exception with minor code 3 when
invoked on a reference to a local object.

Resolution: Reflect this fact as follows
Revised Text: Section 3.7.6.1: Change the bullet that says - The is_a, get_interface, get_domain_managers, get_policy, get_client_policy, set_policy_overrides, get_policy_overrides, and validate_connection pseudo-operations, and any DII support pseudo-operations, may result in a NO_IMPLEMENT system exception with minor code 3 when invoked on a reference to a local object. to: - The get_interface, get_domain_managers, get_policy, get_client_policy, set_policy_overrides, get_policy_overrides, and validate_connection pseudo-operations, and any DII support pseudo-operations, may result in a NO_IMPLEMENT system exception with minor code 3 when invoked on a reference to a local object.
Actions taken:
October 23, 2001: receivd issue
May 13, 2002: closed issue

Issue 4654: Chapter 11, section 11.3.8.19 (WrongPolicy)" (orb_revision)

Click here for this issue's archive.
Source: PrismTech (Mr. Jason Courage, )
Nature: Uncategorized Issue
Severity:
Summary:

In chapter 11, section 11.3.8.19, the "raises (WrongPolicy)" clause has been omitted from the specification of the create_reference_with_id operation. (This exception clause is included in the IDL definition in section 11.4.)

Resolution: see above
Revised Text:
Actions taken:
November 1, 2001: received issue
May 13, 2002: closed issue

Discussion:

Already fixed in 2.5 formal/01-09-15 by removing raises clause from 
section 11.4.

Issue 4657: Problem with IDL Context interface (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

a few problems with IDL contexts:

1) On page 4-32, with have:

	"CORBA::CTX_DELETE_DESCENDENTS deletes the indicated context
			   ^^^^^^^^^^^
	object and all of its descendent context objects, as well."
			       ^^^^^^^^^^
	The standard system exception BAD_PARAM is raised if there are one
	or more child context objects and the CTX_DELETE_DESCENDENTS
							  ^^^^^^^^^^^
	flag was not set."


   That's a bit embarrassing because the correct spelling is "descendants",
   not "descendents".

2) For the get_values() operation, we have:

	"Scope indicates the context object level at which to initiate the
	search for the specified properties (e.g. "_USER", "_SYSTEM"). If
	the property is not found at the indicated level, the search
	continues up the context object tree until a match is found
	or all context objects in the chain have been exhausted."

   This does not say exactly how this is meant to work. I assume that
   the idea is to start at the current context object, checking whether its
   name matches the start_scope parameter. If it does, start the search here;
   otherwise, go up a level and repeat. Once a context object has been found
   with a matching name, then start looking for the properties and collect
   them together, with lower level settings overriding higher level settings,
   until either all property values have been determined or we run out of
   context objects.

   If this is the intended interpretation, the words in the spec are a long
   way from actually expressing that...

3) Context objects have names. Those names are used to control the behavior
   of get_values(). However, we have two problems:

	- The top-level context object does not have a defined name, so
	  I can't specify its name for get_values().

	- Once I've given a context object a name, I can't get it back out.
	  (Yet another case where I am forced to give identity to an object
	  only to be denied any opportunity of ever asking what that
	  identity is...)

4) For create_child(), what happens if I:

	- specify a name that doesn't look like an IDL identifier?

	- call create_child() twice with the same name on the same
	  parent context?

5) For delete_values(), what is the behavior if the specified property
   does not exist?

6) For delete(), what is the minor code of the BAD_PARAM exception
   if I don't set the CTX_DELETE_DSCENDENTS [sic] flag and the context
   has child contexts?

7) For get_values(), what does it mean to "omit" the scope name? The only
   way to omit it, as far as I can see, is to pass the empty string. If so,
   that should be stated.

8) For get_values(), what exception is raised if the specified scope name
   is not found?

9) get_values() and delete() accept a Flags parameter. It is not specified
   how to *not* set a flag (only what it may be set to). Given that Flags
   is an unsigned long, presumably I have to pass zero to indicate that a
   flag is not set. However, this is not specified.

10) For get_values(), what is the minor code of the BAD_CONTEXT system
    exception if a property isn't found? Why a BAD_CONTEXT exception? Why
    an exception at all (instead of returning an empty sequence)?

11) For get_values(), it says:

	The NO_MEMORY exception is raised if dynamic memory allocation fails.

    This sentence is utterly redundant.

12) For get_values(), we have:

	The values returned may be freed by a call to the list free operation.

    What "list free operation"? There is no such operation on NVList.
    There is CORBA::free, but that is specific to the C mapping.

13) For get_values(), we have:

	"Scope indicates the context object level at which to initiate the
	search for the specified properties (e.g. "_USER", "_SYSTEM")."

    However, for create_child(), we have:

	"Context object names follow the rules for OMG IDL identifiers."

    "_USER" and "_SYSTEM" are not valid IDL identifiers (at least they were
    not at the time this was written, and you can argue that they still are
    not valid IDL identifiers because the underscore is stripped immediately
    by the IDL compiler).

14) What happens if I call get_default_context() multiple times? Presumably,
    I will get a reference to the same single context object?

15) In the first para of page 4-29, it says:

	"... although a specified property may have no value associated
	with it"

    This would appear to be impossible. If the property itself exists,
    it always has a value, namely a string. The closest thing to "no value"
    would appear to be the empty string (or a property doesn't exist at all).

16) "An operation definition may contain a clause specifying those context
     properties that may be of interest to a particular operation. These
     context properties comprise the minimum set of properties that will
     be propagated to the server's environment..."

     So, what happens if I have

	interface I {
		void op() context("C");
	};

     and no property "C" exists in the context object passed by the client?

     Does this mean that the call will be made, but no property "C" will
     be available to the server? (I don't think so, because that would
     contradict the above words about "minimum set of properties that *will*
     be propagated")

     Or does it mean that the call will be made, but that the value of "C"
     will be the empty string?

     Or does it mean that the call will be refused because the caller has
     not supplied the required properties? If so, what exception is be
     raised?

17) "Context property names (which are strings) *typically* have the
    form of an OMG IDL identifier, or a series of OMG IDL identifiers
    separated by periods."

    This is in conflict with the words about property name syntax elsewhere.

This is a total mess. One interface with six operations, and about a dozen
bugs. Impressive! :-(

Resolution: Indeed it is hopelessly broken. Fix as suggested below.:
Revised Text: Rather than write up lots of edits, I've rewritten the entire section in toto. Note that the IDL itself is unchanged, but that I've clarified the semantics of the operations. (This is the best we can do for this utter mess, unless we want to completely change the IDL, and all the language mappings). Please also see the notes at the end of the new section and the few modifications to the remainder of chapter 4. --- 1. Replace section 4.6 by the following: 4.6 Context Object 4.6.1 Introduction A context object contains a list of properties, each consisting of a name and a string value associated with that name. By convention, context properties represent information about the client, environment, or circumstances of a request that are passed as a single parameter representing that collection of information. Context properties represent a portion of a client's or application's environment that is meant to be propagated to (and made available to) a server's environment (for example, a window identifier, or user preference information). Once an operation has been invoked in the server, the operation implementation may query its context object for these properties. An operation definition may contain a context clause that specifies the context properties that may be of interest to a particular operation. These context properties (if present for the actual call) are propagated to the server. A client-side ORB may choose to pass more properties than are specified by an operation's context clause. An example of an operation with a context clause is interface Example { void op() context("USER", "X*"); }; This context clause specifies that the "USER" property is to be made available to the server, as well as all properties with names beginning with "X". Note that there is no obligation on the client to actually pass values for these properties at run time; if the client omits one or more properties, the call proceeds normally and the operation implementation simply will not be able to retrieve the corresponding property values. Property names are non-empty strings that cannot contain the character '*'; there are no other syntactic restrictions on property names. Property names that differ only in case are distinct names, so the following is a legal context clause that transmits two distinct properties: interface Example2 { void op() context("FOO", "foo"); }; Context property values are strings. An empty string is a legal property value. Property values are modified and accessed via the Context interface. A Context object represents a collection of property values. Context objects may be connected into hierarchies; properties defined in child Context objects lower in the hierarchy override properties in parent Context objects higher in the hierarchy. 4.6.2 Context Object Operations Properties are represented as named value lists. module CORBA { interface Context { // PIDL void set_one_value( in Identifier prop_name, // property name to set in string value // property value to set ); void set_values( in NVList values // property values to set ); void get_values( in Identifier start_scope, // search scope in Flags op_flags, // operation flags in Identifier prop_name, // name of property(s) to retrieve out NVList values // requested property(s) ); void delete_values( in Identifier prop_name // name of property(s) to delete ); void create_child( in Identifier ctx_name, // name of context object out Context child_ctx // newly created context object ); void delete( in Flags del_flags // flags controlling deletion ); }; }; 4.6.2.1 get_default_context void get_default_context( // PIDL out Context ctx // context object ); This operation creates a new empty Context object every time it is called. The operation is defined in the ORB interface. 4.6.2.2 set_one_value void set_one_value( in Identifier prop_name, // property name to set in string value // property value to set ); This operation sets a single context object property. If prop_name is the empty string or contains the character '*', the operation raises BAD_PARAM with minor code 35. 4.6.2.3 set_values void set_values( in NVList values // property values to set ); This operation sets one or more property values in its context object. If a property name appears more than once in the NVList, the value with higher index (later in the list) overwrites the value with lower index. The flags field of each passed NVList element must be zero. A non-zero flag in any of the NVList elements raises INV_FLAGS. The property name of each NVList element must be a non-empty string not containing the character '*'; otherwise, the operation raises raises BAD_PARAM with minor code 35. The value of each property of the passed NVList must be a (possibly empty) unbounded string. Property values other than unbounded strings raise BAD_TYPECODE with minor code 3. 4.6.2.4 get_values void get_values( in Identifier start_scope, // search scope in Flags op_flags, // operation flags in Identifier prop_name, // name of property(s) to retrieve out NVList values // requested property(s) ); This operation returns an NVList with those properties that match the prop_name parameter. Legal values for prop_name are: - a non-empty string that does not contain the character '*' In this case, the values parameter returns the property with the name specified by prop_name. - a string beginning with one or more characters other than '*', followed by a single '*' at the end, such as "XYZ*" In this case, the values parameter contains the properties that have names beginning with "XYZ" (such as "XYZABC" or "XYZ"). If prop_name is the empty string, the string "*", contains more than one '*' character, or contains a '*' anywhere but at the end of the string, the operation raises BAD_PARAM with minor code 36. The start_scope parameter controls the context object level at which to initiate the search for the specified properties as follows: - The start_scope parameter specifies the name of the context object in which the search for properties is to start. - If the context object on which get_values is invoked has a name equal to start_scope, that context object becomes the starting context object for the search. - If start_scope is "", the context object on which get_values is invoked becomes the starting context object for the search. - If the context object on which get_values is invoked does not have a name equal to start_scope (and start_scope is not ""), the parent context object is retrieved and its name compared to start_scope; this process repeats until either a starting context object whose name equals start_scope is found, or the search terminates because it runs out of parent objects. The name of the root context object created by get_default_context is "RootContext". If no starting context object can be found, the operation raises BAD_CONTEXT with minor code 1. - Once a starting context object is found, get_values searches for properties in the matching context object: - If op_flags is CORBA::CTX_RESTRICT_SCOPE, get_values searches only the starting context object for properties that match prop_name. (The value of CTX_RESTRICT_SCOPE is 15.) - If op_flags is zero, get_values searches the starting context and its parent contexts for properties that match prop_name. The property values that are returned are taken from the first context object in which they are found, so properties in child contexts override the values of properties in parent contexts. In either case, if no property matches prop_name, the operation raises BAD_CONTEXT with minor code 2. 4.6.2.5 delete_values void delete_values( in Identifier prop_name // name of property(s) to delete ); This operation deletes the properties that match prop_name. prop_name may have a trailing '*' character, in which case all properties whose name matches the specified prefix are deleted. If prop_name is the empty string, the string "*", contains more than one '*' character, or contains a '*' anywhere but at the end of the string, the operation raises BAD_PARAM with minor code 36. The operation only affects the context object on which it is invoked (that is, parent contexts are never affected by delete_values). If no property name matches prop_name, the operation raises BAD_CONTEXT with minor code 2. 4.6.2.6 create_child void create_child( in Identifier ctx_name, // name of context object out Context child_ctx // newly created context object ); This operation creates an empty child context object. The child context has the name ctx_name. ctx_name may not be the empty string or "RootContext"; otherwise, the operation raises BAD_PARAM with minor code 37. Calling create_child more than once with the same name on the same parent context is legal and results in the creation of a new, empty child context for each call. 4.6.2.7 delete void delete( in Flags del_flags // flags controlling deletion ); This operation deletes the context object on which it is invoked: - If del_flags is zero, the context object is deleted only if it has no child contexts; otherwise, if del_flags is zero and the context object has child contexts, the operation raises BAD_PARAM with minor code 38. - If del_flags is CORBA::CTX_DELETE_DESCENDANTS, the context object on which delete is invoked is destroyed, together with (recursively) its child contexts. The value of CTX_DELETE_DESCENDANTS is 1. If del_flags has a value other than zero or CTX_DELETE_DESCENDANTS, the operation raises INV_FLAGS. --- 2. Change the second-last paragraph of section 3.12.4 to read: Each string_literal is a non-empty string. If the character '*' appears in string_literal, it must appear only once, as the last character of string_literal, and must be preceded by one or more characters other than '*'. --- 3. Change section 15.3.5.4 to append the following text: If an operation has an IDL context clause but the client does not supply any properties matching the context clause at run time, an empty sequence is marshaled. --- 4. Add the following entries to the table in section 4.11.4 (Standard Minor Exception Codes): BAD_PARAM 35 Illegal IDL context property name BAD_PARAM 36 Illegal IDL property search string BAD_PARAM 37 Illegal IDL context name BAD_PARAM 38 Non-empty IDL context BAD_CONTEXT 1 IDL context not found BAD_CONTEXT 2 No matching IDL context property BAD_TYPECODE 3 Illegal parameter type --- Notes: I've replaced CTX_DELETE_DESCENDENTS [sic] by CTX_DELETE_DESCENDANTS (because spelling errors such as this are rather embarrassing). Existing implementations can define both CTX_DELETE_DESCENDANTS and CTX_DELETE_DESCENDENTS to avoid breaking legacy code. The value of CTX_DELETE_DESCENDENTS is defined nowhere :-( I've arbitrarily made it 1. I've removed the reference to section 4.2.2 that appeared with get_default_context because that section talks about converting between strings and IORs. I've removed a lot of non-normative weasel words about "influencing method binding" and such, because they are meaningless and IDL contexts are definitely *not* the way to do this. (Of course, implementations can do what they like, albeit non-portably.) I've allowed property names to be anything, except the empty string and strings containing a '*'. This matches existing implementations; the words about "IDL identifier" syntax never made any sense anyway and there is no need to restrict property (or context) names to IDL identifier syntax. I've nailed down the missing error conditions by raising system exceptions with defined minor codes. The addition to section 15.3.5.4 is necessary because, otherwise, the DSI can't work -- the DIR must have something to unmarshal when it calls ctx() to get the context.
Actions taken:
November 1, 2001: received issue
May 13, 2002: closed issue

Issue 4708: DynUnion operations (orb_revision)

Click here for this issue's archive.
Source: PrismTech (Mr. Jason Courage, )
Nature: Uncategorized Issue
Severity:
Summary:

In the section describing DynUnion operations, the restatement of the IDL definition of the get_discriminator() operation includes a raises (InvalidValue) clause. This exception is not discussed in the paragraph describing the operation, nor does it appear in the IDL definintion of this operation anywhere else in the chapter.

Resolution: see below
Revised Text: In ptc/01-0-10 on page 9-19 replace the self standing IDL lines that read DynAny get_discriminator() raises(InvalidValue); by the single line: DynAny get_discriminator(); In ptc/01-0-10 on page 9-19 replace the self standing IDL lines that read DynAny get_discriminator() raises(InvalidValue); by the single line: DynAny get_discriminator();
Actions taken:
November 16, 2001: received issue
May 13, 2002: closed issue

Discussion:

Resolve by removing the InvalidValue exception from 
the definition of get_discriminator. it shouldn't be there. (The IDL 
in section 9.2 correctly shows get_discriminator() without a raises clause.)

Issue 4709: the IDL include directive should introduce declarations into the namespace (orb_revision)

Click here for this issue's archive.
Source: Hewlett-Packard (Mr. Michael A. Matzek, )
Nature: Clarification
Severity: Significant
Summary:

The IDL specification for the include directive follows the ANSI C++ specification. This means that the include statement is replaced by the included file's text. The C++ mapping then calls for the generation of stubs and skeletons for the now inline included interfaces. But if the same IDL file, for example CosTransactions.idl, is included in multiple compilation units, the included interfaces become multiply defined. It's like including C++ class definitions rather than class declarations in a C++ program. The problem arises because IDL language mappings specify implementation. Wrapping include directives in different modules has the undesirable effect of requiring multiple implementations of the same operations that differ only in their qualified names. The IDL specification should provide a specification similar to the Java language import statement. That is, the IDL include directive should introduce declarations into the namespace but not implementation via the language. mappings.

Resolution: close, no change
Revised Text:
Actions taken:
November 16, 2001: received issue
May 13, 2002: closed issue

Discussion:

This issue becomes moot in CORBA 3.0 IDL in which  "#include" 
is deprecated and replaced by "import" in CORBA 3.0 IDL. 

A clarification of this has been attempted i the past but to no avail, because 
there are too many IDL compilers that handle this differently. 

Therefore the best way to deal with this is to let the "#include" bugs 
rest in peace, and move away from "#include" to "import". 

If the same problem exists in the specification of "import" let us raise 
a different issue and fix it in "import" only.

Issue 4713: set_length operation of the DynSequence interface (orb_revision)

Click here for this issue's archive.
Source: PrismTech (Mr. Jason Courage, )
Nature: Uncategorized Issue
Severity:
Summary:

The set_length operation of the DynSequence interface is defined as: 

void set_length(in unsigned long len) raises(InvalidValue); 

in the IDL but is defined as: 

void set_length(in unsigned long len) raises(TypeMismatch, InvalidValue); 

in the discussion that follows the IDL in section 9.2.8. The TypeMismatch exception appears inconsistently in the definition of the operation.

Resolution: see below
Revised Text: On page 9-21 of ptc/01-06-10 replace the IDL line: void set_length(in unsigned long len) raises(TypeMismatch, InvalidValue); by: void set_length(in unsigned long len) raises(InvalidValue);
Actions taken:
November 20, 2001: received issue
May 13, 2002: closed issue

Discussion:

Resolution: Remove the TypeMismatch from the raises clause in the discussion of the 
operation.

Issue 4718: IDL for ORB::resolve_initial_references (orb_revision)

Click here for this issue's archive.
Source: Hewlett-Packard (Mr. Michael A. Matzek, )
Nature: Uncategorized Issue
Severity:
Summary:

The IDL for ORB::resolve_initial_references declares that it may throw the standard user exception InvalidName, however the Specification does not specify when, if ever the ORB may do so. Two cases of interest are an unknown name such as a misspelled well-known name and an unimplemented well-known name such as Trading Service.

Resolution: close, no change
Revised Text:
Actions taken:
November 27, 2001: received issue
May 13, 2002: closed issue

Discussion:

Close this without change because the proposal that has 
already been recommended for 4532 clarifies this already: if a token is 
not configured, or configured with a nil object reference, resolve_initial_references() 
throws invalid name. 

The return value from resolve_initial_references() is configurable, so 
there is no point in distinguishing between well-known (but 
not available) and unknown tokens. (All tokens are potentially well-known.) 
Revised Text:

Issue 4719: Implied IDL for interfaces in modules (orb_revision)

Click here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

The Messaging Programming Model introduces implied interfaces. These
interfaces have the same name as the original interface, but with an
AMI_ prefix.

What happens if the original interface is in a module? Will AMI_ be
prepended to the unqualified name, or to the absolute name? E.g.

module Stock {
  interface StockManager { ... };
};

In this case, will the absolute name of the ReplyHandler be
::AMI_Stock::StockManagerHandler, or ::Stock::AMI_StockManagerHandler ?

All examples in the spec (formal/2001-09-26) are outside any module.
Since it never talks about absolute names, but only of names, it might
indicate that it should be the latter (AMI_ prepended to the unquali-
fied name).

However, the precedent for prefixes, the POA, always prepends the POA_
prefix to the absolute name, and I would find it confusing if the AMI_
prefix was used differently.

Resolution: see below
Revised Text: 1. change the phrase "where ifaceName is the name of the original interface" to "where ifaceName is the *unqualified* name of the original interface" on page 22-21 in the Type-Specific ExceptionHolder Mapping section. 2. Make the same change in the Type-Specific ReplyHandler Mapping section on page 22-22. 3. Make the same change in the Basic Type-Specific Poller section on page 22-27. 4. In the Persistent Type-Specific Poller section on page 22-29, replace "For an interface named ifaceName" with "For an interface with the *unqualified* name ifaceName".
Actions taken:
November 30, 2001: received issue
May 13, 2002: closed issue

Discussion:

Resolution: It was always intended that the prefix be applied to the local i.e. unqualified 
name. Otherwise, modules need to get created on the fly, and that was not the intention. 

So in the above example, the correct name is ::Stock::AMI_StockManagerHandler.

Issue 4722: section 7.1.1 claims to define the "NVList structure", but doesn't (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

In the Corba 2.5 spec,
section 7.1.1 claims to define the "NVList structure",
but doesn't.  Section 7.5 defines the "NVList interface".
Is this a typo in 7.1.1, then?

This is a bit confusing.  Is NVList a struct, or an interface?
Inquiring minds want to know :-)

Resolution: see below
Revised Text: In ptc/01-06-10 make the following changes: 1. On page 7-2 remove the second sentence of the first paragraph and the entire second paragraph (the paragraph following the PIDL for NamedValue) of section 7.1.1. 2. In section 7.5 on page 7-16 replace the first paragraph that reads: "The list operations use the named-value structure defined above. The list operations that create NVList objects are defined in the ORB interface described in the ORB Interface chapter, but are described in this section. The NVList interface is shown below." by: "NVList is a pseudo-interface that facilitates manipulation of list of name value pairs. The operations that create NVList objects are defined in the ORB interface section of Chapter 4, but are described in this section. The NVList pseudo-interface is shown below."
Actions taken:
November 15, 2001: received issue
May 13, 2002: closed issue

Discussion:

NVList is a pseudo interface and NamedValue is a struct. To clarify, remove references 
to NVList from section 7.1.1 and fix the introductory paragraph of the "List Operations" 
section 7.5.

Issue 4742: Syntax error in CORBA IDL (orb_revision)

Click here for this issue's archive.
Source: Humboldt-Universitaet (Mr. Martin von Loewis, loewis(at)informatik.hu-berlin.de)
Nature: Uncategorized Issue
Severity:
Summary:

In formal/01-11-01.txt, the second occurrence of create_native reads

 NativeDef create_native(
	in RepositoryId 	id,
	in Identifier 		name,
	in VersionSpec 		version,
 );


This is incorrect; the comma after version must be removed.

Resolution: see below
Revised Text: In formal/01-11-01.txt, the second occurrence of create_native change NativeDef create_native( in RepositoryId id, in Identifier name, in VersionSpec version, ); to read: NativeDef create_native( in RepositoryId id, in Identifier name, in VersionSpec version );
Actions taken:
December 9, 2001: received issue
May 13, 2002: closed issue

Discussion:

Fix issue as suggested, by removing the extraneous comma.

Issue 4747: New core issue: need UNKNOWN reply status (orb_revision)

Click here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

The Java RTF recently passed a resolution to fix some problems with the
use of portable interceptors with the co-located call optimization.  This 
resolution introduced a new abstract class ServantObjectExt that extends 
org.omg.CORBA.portable.ServantObject with methods for reporting 
normal and exceptional completion of the co-located call.

When we look at the issue of mixed versions of stubs and ORBs with
this change, there is one case that is particularly interesting:
an old stub (uses only ServantObject) with a new ORB (provides 
ServantObjectExt).  In this case, the ORB can detect that an old
stub was used, because neither one of the two new methods was called.
However, this leaves the ORB with no way to report the reply status
correctly in the RequestInfo::reply_status attribute.

To handle this special case, I propose that we add a new value of
UNKNOWN for the reply status.  This will only be used if the ORB
cannot determine the reply status of an operation.  This occurs 
with any co-located optimized call with the existing Java mapping.
With the passage of the resolution to issue 4701, the scope of
this occurence is smaller but still possible.

Revised text:

In section 21.3.12.10, add after PortableInterceptor::TRANSPORT_RETRY:

    PortableInterceptor::UNKNOWN

In section 21.3.12.10, replace the third bullet under client with:

    Within the receive_other interception point, this attribute will
    be any of: SUCCESSFUL, LOCATION_FORWARD, TRANSPORT_RETRY, or UNKNOWN.
    SUCCESSFUL means an asynchronous request returned successfully.
    LOCATION_FORWARD means that a reply came back with LOCATION_FORWARD 
    as its status. TRANSPORT_RETRY means that the transport mechanism
    indicated a retry - a GIOP reply with a status of NEEDS_ADDRESSING_MODE,
    for instance. UNKNOWN means that the ORB was unable to determine
    the correct status. This can occur for example in the Java language
    mapping when the optimized path for a co-located call is used.

In section 21.3.12.10, replace the third bullet under server with:

    Within the send_other interception point, this attribute will
    be any of: SUCCESSFUL, LOCATION_FORWARD, or UNKNOWN.
    SUCCESSFUL means an asynchronous request returned successfully.
    LOCATION_FORWARD means that a reply came back with LOCATION_FORWARD 
    as its status.  UNKNOWN means that the ORB was unable to determine
    the correct status. This can occur for example in the Java language
    mapping when the optimized path for a co-located call is used.

In section 21.10, add the following after const ReplyStatus TRANSPORT_RETRY = 4:

    const ReplyStatus UNKNOWN = 5;

Resolution:
Revised Text: In section 21.3.12.10, add after PortableInterceptor::TRANSPORT_RETRY: PortableInterceptor::UNKNOWN In section 21.3.12.10, replace the third bullet under client with: Within the receive_other interception point, this attribute will be any of: SUCCESSFUL, LOCATION_FORWARD, TRANSPORT_RETRY, or UNKNOWN. SUCCESSFUL means an asynchronous request returned successfully. LOCATION_FORWARD means that a reply came back with LOCATION_FORWARD as its status. TRANSPORT_RETRY means that the transport mechanism indicated a retry - a GIOP reply with a status of NEEDS_ADDRESSING_MODE, for instance. UNKNOWN means that the ORB was unable to determine the correct status. This can occur for example in the Java language mapping when the optimized path for a collocated call is used. In section 21.3.12.10, replace the third bullet under server with: Within the send_other interception point, this attribute will be any of: SUCCESSFUL, LOCATION_FORWARD, or UNKNOWN. SUCCESSFUL means an asynchronous request returned successfully. LOCATION_FORWARD means that a reply came back with LOCATION_FORWARD as its status. UNKNOWN means that the ORB was unable to determine the correct status. This can occur for example in the Java language mapping when the optimized path for a collocated call is used. In section 21.10, add the following after const ReplyStatus TRANSPORT_RETRY = 4: const ReplyStatus UNKNOWN = 5;
Actions taken:
December 12, 2001: received issue
May 13, 2002: closed issue

Discussion:

Accept the proposed change based on the discussion above. 
Revised Text:

Issue 4785: Valuetype initialzers need exceptions (orb_revision)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Uncategorized Issue
Severity: Critical
Summary:

Valuetype initializers need exception declarations in order to provide
complete mapping of Java declarations to IDL declarations in Java to IDL
mapping.

Discussion: This was discussed in te past and rejected because of the
backward non-compatible changes required in the IFR. This time
around.... the IFR changes are already part of the backward compatible
changes maded in connection with the addition of exeptions to attributes
etc in CCM in resolution to issue 3233. So all that is needed is change
to one grammar rule and provision of language mappings. As the results
of Components FTF is merged into Core to create CORBA Core 3.0
everything then falls into place to give us initializers with exceptions
for valuetypes.

Issue 3641 in Java-IDL RTF is handling the Java language mapping issue,
and Simon is shepherding that.

We need to create a C++ language mapping issue and resolve it with the
obvious mapping in C++ (Michi?)

Specfic text changes:

All changes specified here relative to document ptc/01-06-10:

1. On page 3-13 change grammar production rule 23 to read:

(23) <init_dcl> ::= �factory� <identifier>
�(� [ <init_param_decls> ] �)� [ <raises_expr> ] �;�

instead of:

(23) <init_dcl> ::= �factory� <identifier>
�(� [ <init_param_decls> ] �)� �;�

2. On page 3-26 in section 3.8.1.5 change grammar production 
rule 23 to read:

(23) <init_dcl> ::= �factory� <identifier>
�(� [ <init_param_decls> ] �)� [ <raises_expr> ] �;�

instead of:

(23) <init_dcl> ::= �factory� <identifier>
�(� [ <init_param_decls> ] �)� �;�

Resolution: Accept the proposed change based on discussion above
Revised Text: All changes specified here relative to document ptc/01-06-10: 1. On page 3-13 change grammar production rule 23 to read: (23) <init_dcl> ::= �factory� <identifier> �(� [ <init_param_decls> ] �)� [ <raises_expr> ] �;� instead of: (23) <init_dcl> ::= �factory� <identifier> �(� [ <init_param_decls> ] �)� �;� 2. On page 3-26 in section 3.8.1.5 change grammar production rule 23 to read: (23) <init_dcl> ::= �factory� <identifier> �(� [ <init_param_decls> ] �)� [ <raises_expr> ] �;� instead of: (23) <init_dcl> ::= �factory� <identifier> �(� [ <init_param_decls> ] �)� �;�
Actions taken:
December 17, 2001: received issue
May 13, 2002: closed issue

Issue 4803: TypeCode interface issue (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The section concerning with the TypeCode interface was removed from the Interface Repository chapter into the ORB Interface chapter, but the Minimum CORBA chapter refers to it in the old place.

Resolution:
Revised Text:
Actions taken:
January 10, 2002: received issue
January 10, 2002: closed issuem, editorial