Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — Open Issues

  • Acronym: CORBA
  • Issues Count: 78
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA34-429 Can value type inherit from Value Box type CORBA 2.2 open
CORBA34-428 Section 5.5 Interface repository (01) CORBA 2.2 open
CORBA34-427 Section 5.5 Interface repository (02) CORBA 2.2 open
CORBA34-426 Which TypeCode operations apply to Value and ValueBox? CORBA 2.2 open
CORBA34-425 "Safe" keyword identifier issue CORBA 2.2 open
CORBA34-424 Can Value type inherit from Value Box type? CORBA 2.2 open
CORBA34-423 New lexical type - Keyword Identifie CORBA 2.2 open
CORBA34-422 Section 5.3.3: can value inherit from a boxed value? CORBA 2.2 open
CORBA34-421 p.6.68 boxed values of complex types map to same type CORBA 2.2 open
CORBA34-420 Value type ansd Value Box"s single data member name CORBA 2.2 open
CORBA34-419 describe_value() operation issue CORBA 2.2 open
CORBA34-418 Missing member_kind and member_tc CORBA 2.2 open
CORBA34-417 Type code issue CORBA 2.2 open
CORBA34-416 Clarify the hash code algorithm CORBA 2.2 open
CORBA34-415 Section 5.6.2 Repository Id CORBA 2.2 open
CORBA34-414 Repository Id (02) CORBA 2.2 open
CORBA34-413 Repository Id (03) CORBA 2.2 open
CORBA34-412 Section 5.6.3 Hashing Algorythm CORBA 2.2 open
CORBA34-411 Semantics of computing the hash code.. CORBA 2.2 open
CORBA34-410 Concrete value class CORBA 2.2 open
CORBA34-409 Section 7.3.5 ValueBase and Reference Counting CORBA 2.2 open
CORBA34-408 Section 7.3.6 Reference Counting Mix-in Classes CORBA 2.2 open
CORBA34-407 Section 7 C++ Language mapping CORBA 2.2 open
CORBA34-406 Java mapping example and C++ mapping example CORBA 2.2 open
CORBA34-405 Section 7.3.10 Value Factories CORBA 2.2 open
CORBA34-404 Why is ValueBase a value and not a native type? CORBA 2.2 open
CORBA34-403 Can an instance of C be passed by value to an operation that expects an A? CORBA 2.2 open
CORBA34-402 Editorial page 8-107 CORBA 2.2 open
CORBA34-401 p 5-24, first paragraph of 5.3.1.3 CORBA 2.2 open
CORBA34-400 Suggested changes (to section 5.4.1 of orbos/98-01-18) are CORBA 2.2 open
CORBA34-399 Editorial: p 5-50 CORBA 2.2 open
CORBA34-398 p 5-50 2nd paragraph of 5.6.2.1 CORBA 2.2 open
CORBA34-397 Can public modifier be applied to value operations? CORBA 2.2 open
CORBA34-396 Reconcile RMI/IIOP upcall and helper class CORBA 2.2 open
CORBA34-395 Keyword identifiers (01) CORBA 2.2 open
CORBA34-394 Keyword identifiers (02) CORBA 2.2 open
CORBA34-393 Keyword Identifiers(03) CORBA 2.2 open
CORBA34-392 Keyword identifiers (04) CORBA 2.2 open
CORBA34-391 No portable way to obtain list of type safe repository IDs CORBA 2.2 open
CORBA34-390 Marshaling engine issue CORBA 2.2 open
CORBA34-389 Sections 5.3.1.2 vs. 6.3.1: Mapping of non-public state to java private CORBA 2.2 open
CORBA34-388 Narrowing from abstract interfaces CORBA 2.2 open
CORBA34-387 "in". "out", and "inout" modifiers on value operation parameters CORBA 2.2 open
CORBA34-386 Typo on page 8-107 of OBV specification CORBA 2.2 open
CORBA34-385 Can "public" mofifier be applied to value operations? CORBA 2.2 open
CORBA34-384 OBV "chunking" CORBA 2.2 open
CORBA34-383 CDR Streams CORBA 2.2 open
CORBA34-382 TypeCodes defined in section 5.8.2 CORBA 2.2 open
CORBA34-381 ValueMemberSeq: What is to be done with the RepositoryID parameter? CORBA 2.2 open
CORBA34-380 OBV C++ problem with "supports" CORBA 2.2 open
CORBA34-379 OBV spec inefficient for dending large number of small objects CORBA 2.2 open
CORBA34-378 Some explicit semantics seem to be missing in section5.8.6 CORBA 2.2 open
CORBA34-377 Forward declaration of value boxes CORBA 2.2 open
CORBA34-376 TypeCodes for values CORBA 2.2 open
CORBA34-375 Boxed values need extension to write_Value call CORBA 2.2 open
CORBA34-374 Default constructor for Java values CORBA 2.2 open
CORBA34-373 Custom marshalling support for IDL fixed type CORBA 2.2 open
CORBA34-372 C++ boxed value member clashes CORBA 2.2 open
CORBA34-371 OBV TypeCode parameters wrong CORBA 2.2 open
CORBA34-370 P 5-44: use of base type CORBA 2.2 open
CORBA34-369 Abstract Interface issue (write_Abstract/read_Abstract)(01) CORBA 2.2 open
CORBA34-368 No typecodes for abstract interfaces CORBA 2.2 open
CORBA34-367 TypeCode complexity for value types CORBA 2.2 open
CORBA34-366 Memory Management for Value Factories Unspecified CORBA 2.2 open
CORBA34-365 CodeBase interface uses undefined type CORBA 2.2 open
CORBA34-364 OBV init CORBA 2.2 open
CORBA34-363 Status of hashed repository IDs CORBA 2.2 open
CORBA34-362 "Tool" issue for IDL compilers too complex CORBA 2.2 open
CORBA34-361 ValueHelper Interface issue CORBA 2.2 open
CORBA34-357 The values of these tags need to be assigned CORBA 2.2 open
CORBA34-356 Issue for Firewall RTF - Chapter 5 needs clarification CORBA 2.2 open
CORBA34-355 passthrough connection CORBA 2.2 open
CORBA34-354 issue with TCPfirewallMechanism CORBA 2.2 open
CORBA34-353 Issue for Firewall RTF - HTTP tunnelling. CORBA 2.2 open
CORBA34-248 Circular References in CosStream and CosCompoundExternalization CORBA 2.2 open
CORBA34-223 TypedConsumerAdmin interface (4.9.2)) CORBA 2.2 open
CORBA34-218 ObjectCreationError and Nofactory exceptions in Externilazition CORBA 2.2 open
CORBA34-215 COM/CORBA keywords CORBA 2.2 open

Issues Descriptions

Can value type inherit from Value Box type

  • Legacy Issue Number: 1055
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1) Can a Value type inherit from a Value Box type (the Value Box is
    described as been syntactic sugar for a Value type)? If so, what is the
    implicit name of the Value Box"s single data member?

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Section 5.5 Interface repository (01)

  • Legacy Issue Number: 1064
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1) ValueDefSeq is used in a couple of places but is never defined. A typedef
    for it is missing.

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Section 5.5 Interface repository (02)

  • Legacy Issue Number: 1065
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 2) Attribute "name" in interface ValueMemberDef clashes with attribute "name"
    inherited from Contained. A different name should be used, something like
    "value_member_name"

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Which TypeCode operations apply to Value and ValueBox?

  • Legacy Issue Number: 1140
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec (orbos/98-01-18) does not specify which TypeCode operations apply
    to Value and ValueBox types. For example, are id(), name(), member_name(),
    member_count(), member_type(), etc. valid for Value and ValueBox or should they
    raise BadKind exception?

    I don"t see why they should not be valid. Normative text should be added in
    CORBA 2.2 section 8.7.1 TypeCode Interface to reflect this and the comments in
    the IDL should also be updated.

  • Reported: CORBA 2.2 — Thu, 9 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

"Safe" keyword identifier issue

  • Legacy Issue Number: 1251
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Above rules seem to imply that the
    "safe" keyword identifier can only occur before the first scoped name in the
    <value_parent_spec>, whereas I think the actual intent is that it can only
    occur before a non-abstract value type, of which there is at most one in the
    list, although it need not be the first. Since this can"t be expressed in the
    rules exactly, I would simply amend the rule to be:

    <value_parent_spec> ::= ":" [ <safe_token> ] <scoped_name>

    { "," [ <safe_token> ] <scoped_name> }

    *

    and simply express the semantic restriction in the text. There already is a
    brief mention of the semantics of the "safe" keyword in section 5.3.2.5
    "Substitutability Issues". Perhaps another sentence or two would help clarify
    the intended usage.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Can Value type inherit from Value Box type?

  • Legacy Issue Number: 1252
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Can a Value type inherit from a Value Box type (the Value Box is described
    as been syntactic sugar for a Value type)?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

New lexical type - Keyword Identifie

  • Legacy Issue Number: 1253
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 5.4.2 "New lexical type - Keyword Identifier" the statement is made that
    "new keyword identifiers should only be added such that the resulting grammar is
    still easily parsable, e.g. is LALR(1).". It seems to me that is not true even for
    the newly introduced keyword identifiers in many cases.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Section 5.3.3: can value inherit from a boxed value?

  • Legacy Issue Number: 1255
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 5.3.3: Is it possible to have a value inherit from (ie, support) a
    boxed value ? If yes, the Java mapping of boxed values of type
    string, sequence and arrays should be changed because String
    and arrays can"t be extended in Java.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

p.6.68 boxed values of complex types map to same type

  • Legacy Issue Number: 1256
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: p.6.68: It is a bit awkward that boxed values of "complex" types map
    all to the same type (i.e., as for typedefs, the value"s name appears
    only in holder/helper classes), and that each boxed value of "basic" type
    maps to its individual class. Instead, boxed values of basic types
    could map to the corresponding java.lang.* class, e.g.
    java.lang.Integer, java.lang.Short, etc. An issue with this approach
    is that java.lang.Short and java.lang.Byte are not defined in JDK
    1.0.2. I doubt however this JDK is still much in use; for its users,
    short and octet could optionally map to e.g. CORBA.ShortValue and
    CORBA.ByteValue (inspired from CORBA::StringValue).

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Value type ansd Value Box"s single data member name

  • Legacy Issue Number: 1257
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If a value type can inherit from a Boxed Value then what is the implicit name of
    the Value Box"s single data member?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

describe_value() operation issue

  • Legacy Issue Number: 1258
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Also, the OBV spec defines a describe_value() operation in interface ValueDef
    which returns a FullValueDescription structure. Is there supposed to be another
    operation which returns the shorter ValueDescription structure?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Missing member_kind and member_tc

  • Legacy Issue Number: 1260
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Missing member_kind and member_tc

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Type code issue

  • Legacy Issue Number: 1261
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: TypeCodes:

    • It is not clear whether the IDL compiler has to generate
      a TypeCode object for each Value type.
  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Clarify the hash code algorithm

  • Legacy Issue Number: 1262
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Clarify the hash code algorithm

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Section 5.6.2 Repository Id

  • Legacy Issue Number: 1263
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is not clear whether the #pragma prefix is still part
    of the repository Id. I think it should be.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Repository Id (02)

  • Legacy Issue Number: 1264
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Why is the 64 bit hash code at the end of the string and
    not at the beginning ? This can speed up the comparison
    when two repository Ids are different.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Repository Id (03)

  • Legacy Issue Number: 1265
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 2) How does one find out a RepositoryID for registering a factory or a streaming
    policy?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Section 5.6.3 Hashing Algorythm

  • Legacy Issue Number: 1266
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 5.6.3 Hashing Algorithm (and 5.6.2)

    • It is not clear whether the hash value is translated
      into ascii or not.
    • I assume the result is a long long:

    long long hash = sha[1] << 32 + sha[0]

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Semantics of computing the hash code..

  • Legacy Issue Number: 1267
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Clarify the exact semantics of computing the hash code and comparison semantics for type equivlanece. (lost email, paraphrase of issue)

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Concrete value class

  • Legacy Issue Number: 1268
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I have an important issue concerning the C++ mapping and the fact
    that application developers need to define/implement the concrete
    value class.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Section 7.3.5 ValueBase and Reference Counting

  • Legacy Issue Number: 1269
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: - What is the return type of "_add_ref" and "_remove_ref"
    (defaults to "int", but what is the semantic of the result value)
    => propose to change to "void"

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Section 7.3.6 Reference Counting Mix-in Classes

  • Legacy Issue Number: 1270
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The default ref-counting classes are said to be "fully concrete".
    Is this really necessary?
    What is the semantic of "_copy_value" for the ref-counting class?
    => suggest that "_copy_value" MUST NOT be implemented
    (It is implemented by "_copy_value" of the real value type)

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Section 7 C++ Language mapping

  • Legacy Issue Number: 1271
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: According to the object-by-value C++ mapping, the value type that is
    not boxed results in an abstract C++ class. Basically, the reference
    counting methods are not provided (abstract). It is the responsibility of
    application developer to define/implement a concrete class. Althought
    this can be done, there are some issues:

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Java mapping example and C++ mapping example

  • Legacy Issue Number: 1272
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In the Java mapping example on page 6-64 the operations are mapped to
    public operations of the Java class. However in the C++ mapping example on page
    7-95, the operations are mapped to protected pure virtual functions of the
    generated C++ class.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Section 7.3.10 Value Factories

  • Legacy Issue Number: 1273
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Semantic of register_value_factory is not clear
    What do applications should expect if a factory is already
    registered for a given repositoryId?

    The operation returns the previous factory. But it is not
    clear whether it is overriden or not.

    • When should register_factory be called ?
      I assume that this is after the ORB is initialized (since we
      need a pointer to the ORB). This means that initialization
      of "Component Libraries" is not trivial.
  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Why is ValueBase a value and not a native type?

  • Legacy Issue Number: 1274
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What is the rationale for making ValueBase a value and not a native type?
    It seems strange to me that a ValueBase "value" maps to java.io.serializable
    in Java. Isn"t that what native was invented for?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Can an instance of C be passed by value to an operation that expects an A?

  • Legacy Issue Number: 1275
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Given:

    abstract interface A {};
    interface B : A {};
    value C : supports B {};

    Can an instance of C be passed by value to an operation that expects an A?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Editorial page 8-107

  • Legacy Issue Number: 1277
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: A typo: on page 8-107, interface Account should inherit ":" from Describable and
    value Currency should support Describable.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

p 5-24, first paragraph of 5.3.1.3

  • Legacy Issue Number: 1279
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: p 5-24, first paragraph of 5.3.1.3:
    The implementation of operations may be remote if the value also
    supports CORBA.Object.
    typo p 5-30, last line of 5.3.2.6: may BE defined

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Suggested changes (to section 5.4.1 of orbos/98-01-18) are

  • Legacy Issue Number: 1280
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Suggested changes (to section 5.4.1 of orbos/98-01-18) are:

    1. Remove the ``;"" from the end of the definition of <value>. (It"s
    in the modified <definition>.)

    2. Remove [ <supports_token> <scoped_name>

    { ``,"" <scoped_name> }

    * ]
    from the <value_inheritance_spec> non-terminal move it to a new
    non-terminal, <value_supports_spec>.

    3. Change the definitions of <value_abs_dcl> and <value_header>,
    replacing [ <value_inheritance_spec> ] by [ <value_inheritance
    _spec ] [ <value_supports_spec> ].

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Editorial: p 5-50

  • Legacy Issue Number: 1282
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: typo p 5-50, first paragraph of 5.6.2.1: *s*IDL compilerS keep on spitting...

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

p 5-50 2nd paragraph of 5.6.2.1

  • Legacy Issue Number: 1283
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: p 5-50, 2nd paragraph of 5.6.2.1: it seems to me that in existing
    ORBs, version inconsistencies between, eg, structs, may already corrupt
    memory. The difference now is that preservation of values sharing
    could make matters worse. It would be great to have this issue better
    explained.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Can public modifier be applied to value operations?

  • Legacy Issue Number: 1284
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1) Can the "public" modifier be applied to value operations? What is the default?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:58 GMT

Reconcile RMI/IIOP upcall and helper class

  • Legacy Issue Number: 1286
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Reconcile RMI/IIOP upcall and helper class

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Keyword identifiers (01)

  • Legacy Issue Number: 1310
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary:
    The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
    the concept of "keyword identifiers" in an effort to avoid breaking
    existing IDL specifications.
    1) First and foremost, the addition of keyword identifiers changes
    the IDL grammar into a context-sensitive grammar, which are known to
    be notoriously difficult to parse.

  • Reported: CORBA 2.2 — Fri, 8 May 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Keyword identifiers (02)

  • Legacy Issue Number: 1311
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary:
    The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
    the concept of "keyword identifiers" in an effort to avoid breaking
    existing IDL specifications.It allows IDL specifications that are simply unparseable. For example:

    interface ValueBase {};
    struct S

    { ValueBase v; }

    ;

    This is ambiguous because the compiler cannot know whether the type
    of struct member "v" refers to the ValueBase interface or the
    ValueBase keyword identifier.

  • Reported: CORBA 2.2 — Fri, 8 May 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Keyword Identifiers(03)

  • Legacy Issue Number: 1312
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
    the concept of "keyword identifiers" in an effort to avoid breaking
    existing IDL specifications. It specifies that a keyword identifier
    is a word that is treated as a keyword only when used in a keyword
    context, and is otherwise treated as a regular identifier.
    3) It allows IDL specifications that, while not unparseable, are
    highly ambiguous, especially to a human reader. For example, Jeff
    recently posted answers on how the following is to be parsed, but
    there is no way that someone reading the OBV spec would be able to
    figure out the rules he gave:

    interface public

    { ... };
    interface custom { ... }

    ;
    value safe

    { ... };

    value foo : safe { ... }

    ; // Is this legal or an error?
    value foo2 : safe safe

    { ... }

    ; // What about this?
    value foo3

    { public x; // Is this legal or an error? public public y; // What about this? custom value(); // Is this a valid operation or a syntax error? }

    ;

    While all of these constructs can all be parsed using the appropriate
    number of look-ahead tokens (by the way, the grammar is not LALR(1)
    as the OBV Spec suggests), it is hard to read and even harder to
    parse correctly. Many IDL compilers still fail to properly implement
    the name lookup rules in the existing CORBA specification, and adding
    keyword identifiers will only make that situation much worse.

  • Reported: CORBA 2.2 — Fri, 8 May 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Keyword identifiers (04)

  • Legacy Issue Number: 1313
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
    the concept of "keyword identifiers" in an effort to avoid breaking
    existing IDL specifications. It specifies that a keyword identifier
    is a word that is treated as a keyword only when used in a keyword
    context, and is otherwise treated as a regular identifier.
    4) Finally, the keyword identifier approach gives the impression that
    IDL extensions can be made at no cost, which is simply not true.

  • Reported: CORBA 2.2 — Fri, 8 May 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

No portable way to obtain list of type safe repository IDs

  • Legacy Issue Number: 1352
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In Section 5.9.1 on p. 5-55 of orbos/98-01-18, the spec says "the sending context is responsible for listing the repository ID"s for all the base types to which it is safe to truncate the real
    type, going up (the derivation hierarchy) to, and including if appropriate the formal type". Currently, there is no portable way to obtain the list of type safe repository ID"s
    from within the marshaling engine in order to be marshaled on-the-wire properly.

  • Reported: CORBA 2.2 — Fri, 15 May 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Marshaling engine issue

  • Legacy Issue Number: 1353
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Using the idl defined in Issue # 1352, we have the send() method, in interface Foo, which takes a Base value type as it"s formal parameter. Now supposet we wish to pass a Derived value type. When marshaling the list of repository id"s, the marshaling engine has no notion of the formal type of the parameter , thus it
    does not know how many safe repository id"s it needs to marshal.

  • Reported: CORBA 2.2 — Fri, 15 May 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Sections 5.3.1.2 vs. 6.3.1: Mapping of non-public state to java private

  • Legacy Issue Number: 1380
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 5.3.1.2 says that non-public data members should be mapped
    so that "the private part of the state is only accessible to the
    implementation code and the marshaling routines."

    Section 6.3.1 says that non-public data members are mapped to
    private instance variables.

    The problem is that the Java marshaling routines are in the Helper
    class, which cannot see private instance variables in the value class.

    The proposed solution is to modify the Java mapping to map the default
    IDL state to the default (package visibility) Java state instead of
    private.

  • Reported: CORBA 2.2 — Fri, 15 May 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Narrowing from abstract interfaces

  • Legacy Issue Number: 1382
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It has been pointed out to me that we have no way of narrowing
    from abstract interfaces to non-abstract interfaces and value
    classes. In Java, the helper"s narrow method has a signature of
    org.omg.CORBA.Object, so it cannot take an abstract interface
    type. In C++, the generated classes for abstract interfaces
    have an _narrow method with the right signature (taking an
    AbstractBase_ptr), but generated classes for values and regular
    interfaces don"t have such a method. It seems like we would
    need to add overloaded narrow methods in all these places to
    make this work as envisaged in (for example) numbered paragraph
    3 of section 8.3.

  • Reported: CORBA 2.2 — Mon, 18 May 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

"in". "out", and "inout" modifiers on value operation parameters

  • Legacy Issue Number: 1419
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The "in", "out", and "inout" modifiers on value operation parameters are
    effectively comments. This is the case as a value maps to a language
    pointer or reference. When it is passed in a local interface
    there is no way to guarantee "in" or "out" semantics; it is passed by
    reference which essentially has "inout" semantics.

    These semantics should be explicitly stated.

  • Reported: CORBA 2.2 — Tue, 2 Jun 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Typo on page 8-107 of OBV specification

  • Legacy Issue Number: 1420
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: A typo: on page 8-107 of the OBV spec., interface Account should inherit ":" from
    Describable and value Currency should support Describable.

  • Reported: CORBA 2.2 — Tue, 2 Jun 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Can "public" mofifier be applied to value operations?

  • Legacy Issue Number: 1421
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Can the "public" modifier be applied to value operations? What is the default?
    In the Java mapping example on page 6-64 the operations are mapped to
    public operations of the Java class. However in the C++ mapping example on page
    7-95, the operations are mapped to protected pure virtual functions of the generated
    C++ class.

  • Reported: CORBA 2.2 — Tue, 2 Jun 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

OBV "chunking"

  • Legacy Issue Number: 1522
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec adds the notion of "chunking" because it claims that "it is
    anticipated that value types may be rather large, particularly when a graph
    is being transmitted. Hence the encoding supports the breaking up of the
    serialization into an arbitrary number of "chunks" in order to facilitate
    incremental processing." (orbos/98-01-18, page 5-55)

    This "feature" should be removed from the spec, since it is the job of the
    underlying transport to handle this issue. GIOP already provides
    fragmentation, allowing transports to handle large parameters efficiently
    – why should we build yet another fragmentation solution on top of it?

  • Reported: CORBA 2.2 — Thu, 11 Jun 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

CDR Streams

  • Legacy Issue Number: 1523
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec defines CDROutputStream and CDRInputStream types values for
    custom marshaling. The names of these types should not contain "CDR" since
    there is nothing that prevents them from being implemented to use a data
    representation other than CDR.

  • Reported: CORBA 2.2 — Thu, 11 Jun 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

TypeCodes defined in section 5.8.2

  • Legacy Issue Number: 1527
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1) The fill_in_recursive_sequence_tc method is intended to act
    upon an existing "tk_value" TypeCode. The signature indicates
    that it should return a TypeCode pointer.

    What TypeCode is supposed to be returned ?
    If the signature is in error, the specification should
    be corrected – if not, the specification requires
    some additional explanation as to which TypeCode
    needs to be returned.

  • Reported: CORBA 2.2 — Thu, 18 Jun 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

ValueMemberSeq: What is to be done with the RepositoryID parameter?

  • Legacy Issue Number: 1528
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 2) In addition to the ValueMemberSeq, the input parameters to
    fill_in_recursive_sequence_tc include the target TypeCode
    pointer, and the RepositoryId.

    What is to be done with the RepositoryId parameter ?
    Is the method supposed to update the Id as well ?
    If that is the case, is it an optional/required parameter ?

  • Reported: CORBA 2.2 — Thu, 18 Jun 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

OBV C++ problem with "supports"

  • Legacy Issue Number: 1539
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec allows a value to support multiple interfaces. In C++, such
    values
    are specified to derive from the POA skeletons generated from those
    interfaces.
    This presents a potentially intractable problem: skeletons are not designed to
    be inherited together with skeletons for other interfaces because servants do
    not support multiple interfaces. (The Multiple Interface RFP isn"t finished
    yet, right?) The top of page 20-104 of the latest C++ mapping (orbos/98-05-08)
    explicitly says

  • Reported: CORBA 2.2 — Tue, 23 Jun 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

OBV spec inefficient for dending large number of small objects

  • Legacy Issue Number: 1614
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: One of the common patterns used in IDL specifications is to pass a
    sequence of a data type in order to cut down on network round trips.
    The current OBV spec (orbos/98-01-01) even suggests sending a graph of
    objects and optimizing for the case where the same object occurs
    multiple times in the graph (which I assume will normally be a small
    number of the total objects). The spec seems to be inefficient for
    sending a large number of small objects though. I have looked at the
    errata before and don"t recall any relavent changes but know the RTF are
    considering some now.

  • Reported: CORBA 2.2 — Tue, 30 Jun 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Some explicit semantics seem to be missing in section5.8.6

  • Legacy Issue Number: 1615
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 5.8.6 gives the BNF for the GIOP encoding of values but does not
    describe the semantics behind them. Some of the semantics are referred
    to in earlier section and intuitive for an outsider with a little CORBA
    experience. Some of the the explicit semantics seem to be missing
    altogether (e.g. the "" in <end_tag>). It would be useful if the
    descriptions explicitly used the names within the BNF grammar or
    explicit specifications for each name in the grammar was given.

  • Reported: CORBA 2.2 — Tue, 30 Jun 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Forward declaration of value boxes

  • Legacy Issue Number: 1624
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is not clear from the spec whether or not value boxes can be
    forward declared, and used recursively. For example,

    value v;
    struct s

    { long s0; v next; }

    ;
    value v s;

    If value boxes are indeed syntactic sugar, the answer should be yes.
    That brings the next question: Does this mean that one can call
    create_box_value_tc(), supplying NULL for the original_type, and
    then later on fill in the member typecode via fill_in_recursive_tc,
    supplying a ValueMemberSeq of length 1?

  • Reported: CORBA 2.2 — Wed, 1 Jul 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

TypeCodes for values

  • Legacy Issue Number: 1625
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The spec does not contain a clear definition of how TypeCodes for
    values and value boxes are constructed. There is something about
    this in section 5.6.3, but this seems to describe a variant of the
    algorithm rather than the algorithm itself. Section 5.9.7 needs to
    be expanded to describe this in at least as much detail as the
    description of the encoding of recursive sequence TypeCodes in the
    current CORBA spec.

  • Reported: CORBA 2.2 — Wed, 1 Jul 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Boxed values need extension to write_Value call

  • Legacy Issue Number: 1650
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There"s a problem with the mapping to Java for boxed IDL values
    for non-primitive Java types, for example, a boxed string or a
    boxed sequence. The currently specified write_Value call doesn"t
    allow these to be marshalled correctly.

  • Reported: CORBA 2.2 — Wed, 8 Jul 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Default constructor for Java values

  • Legacy Issue Number: 1654
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec is not very clear about whether the Java class
    generated for an IDL value has a default (no-argument) constructor.

    A no-argument constructor is needed so that the Helper class
    can construct a value when demarshalling. However, it should be
    package-private in order to limit its visbility to the Helper
    class and not expose it to client code. This is also true for
    state fields declared as private in the IDL value type (which the
    spec currently states are mapped to private in Java).

  • Reported: CORBA 2.2 — Thu, 9 Jul 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Custom marshalling support for IDL fixed type

  • Legacy Issue Number: 1673
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The custom marshalling streams CDRInputStream and CDROutputStream
    don"t support the IDL fixed type. I propose adding the following
    type definition and methods:

    typedef sequence<fixed> FixedSeq;

    abstract value CDROutputStream

    { ... void write_fixed (in fixed value); void write_fixed_array (in FixedSeq seq, in unsigned long offset, in unsigned long length); }

    ;

    abstract value CDRInputStream

    { ... fixed read_fixed (); void read_fixed_array (inout FixedSeq seq, in unsigned long offset, in unsigned long length); }

    ;

  • Reported: CORBA 2.2 — Mon, 13 Jul 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

C++ boxed value member clashes

  • Legacy Issue Number: 1674
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: For boxed values that are structs, unions, or other constructed types with
    member accessor and modifier functions, their member functions such as
    value(), boxed_in(), boxed_inout(), etc. may potentially clash with the
    names of those accessor and modifier functions.

    Solution: make the names of such special member functions start with an
    underscore, e.g., _value(), _boxed_in().

  • Reported: CORBA 2.2 — Tue, 14 Jul 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

OBV TypeCode parameters wrong

  • Legacy Issue Number: 1676
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 5.9.7 of orbos/98-01-18 says that the TypeCode parameters for both
    tk_value and tk_value_box start with a string which is the type"s
    repository ID. Why? For everything except tk_interface, the repository ID
    is not visible as a parameter. I believe these parameter lists should not
    include repository IDs to make them consistent with the others.

    I assume that the

    {member_name, TypeCode}

    pairs in the tk_value parameter
    list should appear in the order of declaration of the members in the
    valuetype. This is not stated anywhere.

    The visibility of each member should be added to the tk_value parameter
    list. Each entry in the list should contain

    {member_name, TypeCode, short}

    where the short refers to the Visibility of the member.

    The parameter list for tk_value should probably have an additional
    parameter which is the TypeCode of the concrete valuetype base, if any.

  • Reported: CORBA 2.2 — Tue, 14 Jul 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

P 5-44: use of base type

  • Legacy Issue Number: 1697
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: On page 5-44, a new production has been added to the grammar to allow the use of ValueBase to be used as a base type. (<base_type_spec> ::= ... | <value_type_spec). My concern is that all other types of base type specifiers have a PrimitiveKind. However, either you guys forgot or didn"t want to have, that a value or ValueBase does not have a corresponding PrimitiveKind enum value. This becomes essential later on when we want to go into the InterfaceRepository, and find that some type is a ValueBase, we will need to know this. The easiest way to do this could be through a PrimitiveDef, where it"s def_kind attribute is a dk_Primitive, and to satisfy the IDLType interface for they type attribute, we could return a TCKind of tk_value or tk_ValueBase. An alternate could be to not go the PrimitiveDef route and use a different approach. Perhaps we could have a method in the Container or Repository interfaces called create_ValueBase. This would be much like creating an unnamed type such as a sequence, a string, primitive, or array (i.e. get_primitive(), create_string(), etc. in the Repository interface). This is less likely though because create_ValueBase would need to return a type. We could return a ValueDef, but create_ValueBase wouldn"t have enough information passed to it to create on and besides, a ValueDef is named. We could have a whole new definition interface called ValueBaseDef, but this way is a pain if you ask me.

  • Reported: CORBA 2.2 — Mon, 20 Jul 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Abstract Interface issue (write_Abstract/read_Abstract)(01)

  • Legacy Issue Number: 1699
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1. There are no write_Abstract and read_Abstract methods on
    DataInputCtream and DataInputStream. This looks like an oversight
    to me.

  • Reported: CORBA 2.2 — Mon, 20 Jul 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

No typecodes for abstract interfaces

  • Legacy Issue Number: 1719
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There are no typecodes for abstract interfaces. Does this mean
    that abstract interfaces cannot be members of structs, unions,
    or values? If so, I think this is a problem and we should add
    typecodes for abstract interfaces.

  • Reported: CORBA 2.2 — Wed, 22 Jul 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

TypeCode complexity for value types

  • Legacy Issue Number: 1726
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV design for the "CORBA::tk_value" TypeCode defines a
    potentially recursive constructed type that involves ValueMembers.
    The "tk_value" TypeCode defines the entire complexity of the types
    within the Value.

    It is our understanding that when the ORB code that handles "Anys" for
    C++ detects a tk_value TypeCode and needs to encode/decode the associated
    Value object – (e.g., for Any::replace(TypeCode, void *) – it will
    need to invoke a method on that object that understands the object
    instance data and the associated state information. Further
    examination of the TypeCode complexity will not be necessary by the
    Any implementation, since this code would not have knowledge of or
    ability to set the state information within the Value object itself.

    The reason why the layout of the state information within a value
    cannot be known by external code is that virtual inheritance of
    abstract values and/or abstract interfaces makes it impossible to
    calculate the offsets of the data members in a compiler
    independent manner.

  • Reported: CORBA 2.2 — Thu, 23 Jul 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Memory Management for Value Factories Unspecified

  • Legacy Issue Number: 1748
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There are no rules governing how to free value factories in C++.
    Specifically, the ORB does not know what to do with the value factory at
    shutdown, and applications do not know what to do with the factory
    returned by register_value_factory. Directly deleting the factories may
    be hazardous (e.g. if they are shared across multiple valuetypes or even
    multiple ORBs), and leaving them around may introduce memory leaks.

  • Reported: CORBA 2.2 — Tue, 28 Jul 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

CodeBase interface uses undefined type

  • Legacy Issue Number: 1771
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The definition for interface CodeBase in module SendingContext
    has a method
    CORBA::InterfaceRepository get_ir();

    There is no type CORBA::InterfaceRepository. I believe this was
    intended to say
    CORBA::Repository get_ir();

  • Reported: CORBA 2.2 — Tue, 4 Aug 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

OBV init

  • Legacy Issue Number: 1816
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec introduces the concept of initializers, which maps
    cleanly only to languages that support overloaded constructors.

    Other languages, such as C, would typically offer functions to provide
    inialization of values. Since initializers are not named, an intuitive
    mapping is hard to find.

  • Reported: CORBA 2.2 — Fri, 14 Aug 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

Status of hashed repository IDs

  • Legacy Issue Number: 1817
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec orbos/98-01-18 introduces a new repository ID
    mechanism. It says in 5.6.2.1

    >> We don"t recommand the classic id format "IDL:" <scoped name> ":"
    >> <major> "." <minor> because it is not "foolproof" enough. (It is of
    >> course allowable to use this format, since the CORE specification
    >> does not mandate any particular form.)

    The last sentence is not entirely correct, as 8.6.4 of formal/98-02-33
    specifies

    >> A definition is globally identified by an OMG IDL - format
    >> RepositoryId if no ID pragma is encountered for it.

    The issue is whether the OBV specification changes this default for
    values or not

  • Reported: CORBA 2.2 — Fri, 14 Aug 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:57 GMT

"Tool" issue for IDL compilers too complex

  • Legacy Issue Number: 1932
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 2. The current language mapping mixes both generated code with user
    written code in the same source file. This poses a very complex "tool"
    issue for IDL compilers which is unnecessarily complex.

  • Reported: CORBA 2.2 — Tue, 1 Sep 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:56 GMT

ValueHelper Interface issue

  • Legacy Issue Number: 1934
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 5. The ValueHelper interface contains the method get_safe_base_ids, which is
    inconsistent with current OBV terminology.

  • Reported: CORBA 2.2 — Tue, 1 Sep 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:56 GMT

The values of these tags need to be assigned

  • Legacy Issue Number: 1996
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The firewall spec defines a number of tag values from OMG managed spaces.
    The values of these tags need to be assigned.

  • Reported: CORBA 2.2 — Thu, 24 Sep 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:56 GMT

Issue for Firewall RTF - Chapter 5 needs clarification

  • Legacy Issue Number: 2240
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Chapter 5 - Bi-directional GIOP misled me in a number of points, even after
    numerous readings and a discussion with an author. I believe the chapter
    contains all the pertinent information; it just has to be a bit more
    carefully presented.

  • Reported: CORBA 2.2 — Mon, 7 Dec 1998 05:00 GMT
  • Updated: Tue, 27 Aug 2019 10:56 GMT

passthrough connection

  • Legacy Issue Number: 2261
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary:
    I would like to get some clarification on the PASSTHROUGH/Untrusted Proxy
    issue.

    In page 4-45, the spec says "It is possible to support pass-through through
    multiple proxies. For example if in the above example there was another
    proxy B2 between B and C, during processing the new_target operation from A,
    B can try to establish a pass-through connection to C via a call to
    new_target on B2. If this fails, due to NO_PERMISSION for example, B should
    fall back to try to connect through B2 using the NORMAL mode.".

    If the connection (B - B2) is NORMAL, the whole connection is not a
    PASSTHROUGH since the client will see the B2"s identity in the SSL session.
    Should B throw back the NO_PERMISSION to the client if B get NO_PERMISSION
    from B2 for PASSTHROUGH connection? If the answer is no (seems to me that is
    what spec says), does this mean that it is possible that the client request
    a PASSTHROUGH connection but actually get a NORMAL connection?

  • Reported: CORBA 2.2 — Wed, 16 Dec 1998 05:00 GMT
  • Updated: Tue, 27 Aug 2019 10:56 GMT

issue with TCPfirewallMechanism

  • Legacy Issue Number: 2304
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The issue comes from the following configuration:

    Client - Tcp Firewall - Giop Proxy Server - Server

    The server"s IOR will contains a FirewallComponent, which includes two
    FirewallMechanisms - a TcpFirewallMechanism and a GIOPProxy. The issue
    comes when the GIOP Proxy has multiple profiles, which may have different
    host/port, and the TcpFirewallMechanism can only have one host/port. Does
    that mean for any host/port specified in one of the GIOP Proxy "s profiles,
    you always to connect to the host/port specified in the
    TcpFirewallMechanism? This seems unrealistic since the Tcp firewall usually
    provide a one-to-one mapping.

  • Reported: CORBA 2.2 — Wed, 13 Jan 1999 05:00 GMT
  • Updated: Tue, 27 Aug 2019 10:56 GMT

Issue for Firewall RTF - HTTP tunnelling.

  • Legacy Issue Number: 2455
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The submission makes no mention of HTTP tunnelling. There are many
    firewalls which filter HTTP, FTP and email related traffic. Is the
    omission based on the assumption that such firewalls will comprise
    a CORBA conformant GIOP proxy on a well-known IIOP port? The Bi-
    directional GIOP specification suggests not (section 5-1,
    paragraph 2).

    Is tunnelling regarded as an implementation matter? If so there
    will be important issues such as relaxing GIOP/HTTP mapping and
    security which the specification should clarify.

  • Reported: CORBA 2.2 — Wed, 17 Feb 1999 05:00 GMT
  • Updated: Tue, 27 Aug 2019 10:56 GMT

Circular References in CosStream and CosCompoundExternalization

  • Legacy Issue Number: 1401
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Circular refrences to CosStream and CosCompoundExternalization,
    i have not been able to find an idl compiler that can compile
    these modules.

    as aside, i have foud many syntax errors in the IDL you provide
    as CORBAServices98-03-02.idl, in many of its interfaces, there are
    typos, and it is not correct with the specifications.

  • Reported: CORBA 2.2 — Mon, 1 Jun 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:53 GMT

TypedConsumerAdmin interface (4.9.2))

  • Legacy Issue Number: 961
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: in section 4.9.2 last paragraph:

    "Such a ProxyPushSupplier is guaranteed only to invoke operations defined in
    interface I. Any event on the channel that does not correspond to an
    operation defined in interface I is NOT passed on to the consumer. Such a
    ProxyPushSupplier is therefore an event filter based on type".

    My question is: if we have this proxy to block generic calls (push() in this
    case) why does TypedPushConsumer inherit CosEventComm::PushConsumer, whish does
    support push() ? Why should the generic calls like push() be blocked anyway
    if (according to 4.7.1) TypedPushConsumer should support both typed and generic
    models ?

    Is there something I am misunderstanding ?

  • Reported: CORBA 2.2 — Thu, 5 Feb 1998 05:00 GMT
  • Updated: Tue, 27 Aug 2019 10:52 GMT

ObjectCreationError and Nofactory exceptions in Externilazition

  • Legacy Issue Number: 1293
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There is a bit of confusion in the specification concerning the
    exceptions that are possible during the internalization process.

    The internalize operation can raise CosLifeCycle::NoFactory and
    StreamDataFormatError exceptions. This operation calls the
    internalize_from_stream operation of the Streamable interface that can
    raise the CosLifeCycle::NoFactory, StreamDataFormatError, and
    ObjectCreationError exceptions.The last paragraph on page 8-20 (August
    1997 release) states that the ObjectCreationError and
    StreamDataFormatError exceptions of the internalize_from_stream
    operation originate from the read_object amd read_<type> operations on
    the StreamIO interface. However, the ObjectCreationError is not raised
    by any of these, according to the IDL in figure 8-6.

  • Reported: CORBA 2.2 — Thu, 30 Apr 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:52 GMT

COM/CORBA keywords

  • Legacy Issue Number: 2009
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I can"t find in the COM/CORBA spec parts A and B any mention of how to
    deal with IDL identifiers that are keywords to the Microsoft "mktyplib" tool.
    This tool mangles the following identifier (not necessarily a complete list) by
    prepending them with "_":

    "BSTR", "CALLCONV", "coclass", "CY",
    "CURRENCY", "DATE", "DECIMAL", "DISPID", "DISPPARAMS",
    "dual", "EXCEPINFO", "guid", "GUID",
    "HRESULT", "importlib", "IDispatch",
    "INTERFACEDATA", "IUnknown", "LCID",
    "METHODDATA", "odl", "oleautomation",
    "PARAMDATA", "properties", "propget", "propput", "retval",
    "SAFEARRAY", "SAFEARRAYBOUND", "SCODE",
    "VARIANT", "VARIANTARG", "VARIANT_BOOL",
    "VARTYPE", "VARENUM"

    As far as I can tell, the output of the "mktyplib" tool makes use
    (directly or indirectly) of the regular C++ bindings, whose identifiers
    are not mangled the same way. This makes it impossible to emit COM bindings
    for IDL files that contain the above keywords.

    The problem that I"m running into is in CosTrading IDL, where the identifier
    "properties" is used.

  • Reported: CORBA 2.2 — Tue, 29 Sep 1998 04:00 GMT
  • Updated: Tue, 27 Aug 2019 10:52 GMT