Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — Closed Issues

  • Acronym: CORBA
  • Issues Count: 1,376
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA34-451 Ordering of user exception and return values CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-450 Standard uuid for interfaces (COM/CORBA Part A) CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-453 CORBA section 11 struct PortableGroup::GroupInfo CORBAe 1.0b1 CORBA 3.4 Deferred closed
CORBA34-447 What should Automation View accept in bounded sequences? CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-445 Section 4.1.12: DICORBA TypeCode::kind CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-446 Standard ProgramId CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-449 Section 4.1.18.5 enum should be named CORBA_CompletionStatus CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-448 VB cannot handle array out-parameters CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-443 Add CORBATCKind to end of enum list CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-442 Return value type of DICORBATypeCode::member_type should be changed CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-440 page 2-25 contradicts first sentence of 3rd full para on p 4-106 CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-441 uuid for DForeignException has an extra 0 CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-444 Remove EX_repositoryID readonly property from IForeignException CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-435 boundary violations should cause View to propagate DISP_E_OVERFLOW CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-433 page 4-129, section 4.1.17: change term "CORBA proxy" CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-434 page 4-129, section 4.1.17.1: retval attribute CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-432 INSTANCE_Clone does not need an in-parameter CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-439 ODL is erroneous CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-438 Page 2-41, section 2.9.7.2 Add name for Automation View interface CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-437 page 2-30: There is a label "Examples", but no examples CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-436 page 4-109, section 4.1.5.3: editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-425 "Safe" keyword identifier issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-426 Which TypeCode operations apply to Value and ValueBox? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-427 Section 5.5 Interface repository (02) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-424 Can Value type inherit from Value Box type? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-429 Can value type inherit from Value Box type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-430 Automation View should generate HRESULT DISP_E_TYPEMISMATCH CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-428 Section 5.5 Interface repository (01) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-431 Dispatch versions of DCORBAObject and DORBObject CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-419 describe_value() operation issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-418 Missing member_kind and member_tc CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-421 p.6.68 boxed values of complex types map to same type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-423 New lexical type - Keyword Identifie CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-422 Section 5.3.3: can value inherit from a boxed value? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-420 Value type ansd Value Box"s single data member name CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-411 Semantics of computing the hash code.. CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-410 Concrete value class CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-412 Section 5.6.3 Hashing Algorythm CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-414 Repository Id (02) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-415 Section 5.6.2 Repository Id CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-413 Repository Id (03) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-417 Type code issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-416 Clarify the hash code algorithm CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-405 Section 7.3.10 Value Factories CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-407 Section 7 C++ Language mapping CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-406 Java mapping example and C++ mapping example CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-404 Why is ValueBase a value and not a native type? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-408 Section 7.3.6 Reference Counting Mix-in Classes CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-409 Section 7.3.5 ValueBase and Reference Counting CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-398 p 5-50 2nd paragraph of 5.6.2.1 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-399 Editorial: p 5-50 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-400 Suggested changes (to section 5.4.1 of orbos/98-01-18) are CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-403 Can an instance of C be passed by value to an operation that expects an A? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-401 p 5-24, first paragraph of 5.3.1.3 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-402 Editorial page 8-107 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-395 Keyword identifiers (01) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-397 Can public modifier be applied to value operations? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-396 Reconcile RMI/IIOP upcall and helper class CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-391 No portable way to obtain list of type safe repository IDs CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-393 Keyword Identifiers(03) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-392 Keyword identifiers (04) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-394 Keyword identifiers (02) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-384 OBV "chunking" CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-387 "in". "out", and "inout" modifiers on value operation parameters CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-385 Can "public" mofifier be applied to value operations? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-386 Typo on page 8-107 of OBV specification CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-388 Narrowing from abstract interfaces CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-389 Sections 5.3.1.2 vs. 6.3.1: Mapping of non-public state to java private CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-390 Marshaling engine issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-379 OBV spec inefficient for dending large number of small objects CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-378 Some explicit semantics seem to be missing in section5.8.6 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-377 Forward declaration of value boxes CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-376 TypeCodes for values CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-380 OBV C++ problem with "supports" CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-382 TypeCodes defined in section 5.8.2 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-381 ValueMemberSeq: What is to be done with the RepositoryID parameter? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-383 CDR Streams CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-370 P 5-44: use of base type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-371 OBV TypeCode parameters wrong CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-368 No typecodes for abstract interfaces CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-369 Abstract Interface issue (write_Abstract/read_Abstract)(01) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-373 Custom marshalling support for IDL fixed type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-374 Default constructor for Java values CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-372 C++ boxed value member clashes CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-375 Boxed values need extension to write_Value call CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-363 Status of hashed repository IDs CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-362 "Tool" issue for IDL compilers too complex CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-361 ValueHelper Interface issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-367 TypeCode complexity for value types CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-366 Memory Management for Value Factories Unspecified CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-364 OBV init CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-365 CodeBase interface uses undefined type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-353 Issue for Firewall RTF - HTTP tunnelling. CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-351 Section number: 3.3.4 and elsewhere CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-352 Title does not cover the use of SS7 as signaling transpor CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-355 passthrough connection CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-354 issue with TCPfirewallMechanism CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-356 Issue for Firewall RTF - Chapter 5 needs clarification CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-357 The values of these tags need to be assigned CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-360 Minimum CORBA and POA CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-345 Section number: 4.2.1 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-349 Sec.: 3.5.1.1, item 4 plus appropriate section of interaction translation CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-348 Section number: 3.5.1.1, item 3 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-347 How can we bound the range of invoke ids in the IDL? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-346 It should be possible to have negative invoke ids CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-350 Section number: 3.3.4 make factory creation operations conform to the IDL CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-341 Section 4.3.2.1 Title and text should be changed CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-340 Section 4.7.1: RelativeRoundTripPolicy CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-344 Problem: Why is AssociationId a string? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-342 There is a difference between the responder and initiator interfaces CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-343 The current text for DialogFlowCtr is for outgoing only CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-337 Section number: 5.4.1 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-336 ShouldnÂ’t it be typedef string CORBA::ScopedName? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-335 Section number: Fig. 27 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-339 ShouldnÂ’t this section really be called TC Service Interface? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-338 Section number: 5.2 and other sub-sections CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-328 Bi-Directional GIOP: which connections may be used? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-329 Section number: 2.3 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-333 Should SIOP version number start with 1.2? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-331 Problem: There is no way to send dialogue data in a continue confirm. CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-332 Section number: 6.2.2 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-330 Section number: 5 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-334 Could SIOP be changed to 7IOP, pronounced "seven-up"? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-325 Firewall POA Policy does not control access CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-323 new_target CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-322 new_callback CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-324 Firewall Traversal algorithm CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-327 Bi-Directional GIOP: Masquerade security issue needs to be more explicit CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-326 Outgoing local port in Bi-directional IIOP CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-320 Proxified object references CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-318 Clarification is needed on the passing of credentials CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-319 Reusing PASSTHRU CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-321 How to obtain initial reference to the GIOPProxy object CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-311 TcPdu User and Provider interfaces CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-313 Why one to one association between a TcPduUser and TcPduProvider interface? CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-312 Specification Translation from ASN to IDL issue CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-316 Traversal algorithm not sufficient CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-317 Problems with routing and/or traversal of firewalls. CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-314 When does a multiassociation TcUse know that it has been finished with? CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-315 Use of InvokeId as the type name for both invoke id and link id. CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-305 BiDir GIOP Policy Clarification CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-306 Use of PolicyType id CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-309 Allow GIOP 1.3 messages to be transported. CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-307 Missing definition on security tags in the SIOP CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-308 There is currently no valuetype support in SIOP. CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-310 use of the SSN number in the 1988 TCAP version CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-299 Discrepancy in the changes proposed to CSIIOP and CSI modules CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-298 GIOP version 2.0 issue CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-300 Bidirectional Policy insufficient for persistent objects CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-301 Server Authentication CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-304 MAIN_THREAD_MODEL questions CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-303 Negotiate Session Message Orientation CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-302 Negotiation Session message is unwieldy CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-290 Implications about BiDirIds CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-291 paragraph limits use of BiDirOfferContext CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-292 Negotiate Session Message Issues CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-293 CodeSet issue (05) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-296 CodeSet issue (02) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-295 CodeSet issue (03) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-297 CodeSet issue (01) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-294 CodeSet issue (04) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-284 What BiDirIds shall be sent over what bidirectional connections? CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-285 Interplay of Contexts allowed in NegotiateSession messages too ill-defined CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-283 Firewall FTF Issue: No ene-to-end security for firewall traversal CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-286 Firewall Issue: Random BiDirIds can't be used for persistent POAs CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-287 Firewall Issue: Connection over which BiDir offers are sent is unspecified CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-288 Firewall Issue: Response to failed BiDir challenge is unclear CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-289 Firewall issue - Number of BiDirIds in a BiDirOffer CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-275 use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-277 Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-276 Bi-directional connections considered volatile at connection acceptor side CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-279 connection_complete field of the FirewallPathRespContext is under specified CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-278 How many BI_DIR_GIOP_OFFER service contexts are allowed CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-281 Targets of Export and Offer Policies incompletely specified CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-280 Expected behavior of a non-conformant implementation CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-282 Processing of NegotiateSession messages at various stages of connection set CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-269 Multiple objects on a stream CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-270 Definition of stream portability CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-273 Lifecycle Key type definition CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-272 Stream contexts and internalization CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-271 Start and end of context tags CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-274 when is a connection a "bi-directional connection"? UML 2.0 CORBA 3.4 Deferred closed
CORBA34-264 Coordinator remembering LockCoordinator CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-263 Input values for "which" arg of non-trans. LockCoordinator CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-265 Freeing of locks at the end of a transaction CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-266 Getting the thread ID in a non-transactional lock request CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-267 Communication failure issue CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-268 Timeout while locking CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-255 CosCompoundExternalization Service CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-256 $issue.summary CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-257 $issue.summary CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-260 CosGraphs::deep CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-261 Common format on stream CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-259 performing a compound copy of relationship CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-258 $issue.summary CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-262 Using local thread identification for concurrency CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-249 Internalizing roles-IDL optimization CORBA 2.1 CORBA 3.4 Deferred closed
CORBA34-250 Who is responsible for releasing locks in transaction? CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-252 Purpose of related LockSet CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-253 CosCompoundExternalization Service (3) CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-251 Which model should ConcurrencyControl support? CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-254 CosCompoundExternalization Service (2) CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-244 QueryCollection::Collection -- finding index CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-245 Query Collection::Collection -- Sharing State CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-248 Circular References in CosStream and CosCompoundExternalization CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-247 QueryCollection::Collection -- membership scoping CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-246 QueryCollection::Collection -- Adding multiple elements CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-237 Questions on CosQuery::QueryableCollection interfaces CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-240 QueryCollection::Collection -- reset() exceptions CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-238 QueryCollection::Collection -- keyed collections CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-239 QueryCollection::Collection -- next_n() CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-241 QueryCollection::Collection -- destroy methods CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-243 QueryCollection::Collection -- Iterator Position Invalid CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-242 QueryCollection::Collection -- iterator updating CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-229 Query language for operations CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-232 Definition of NULL in datafiles without NULL as a concept CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-230 Delegating iterator functionality to the RDBMS CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-233 Clarification request for section 11.1.5 CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-231 retrieve_element CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-234 How do iterators handle changing of the data they are pointing at CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-236 Use of MD5 on arguments CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-235 Updating information via query iterators CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-221 Inconsisten IDL in the Minimum CORBA chapter CORBA 2.4.2 CORBA 3.4 Deferred closed
CORBA34-223 TypedConsumerAdmin interface (4.9.2)) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-222 Correction of CORBA specification (page 18-51) CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-224 WWW Form output CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-227 interface QueryEvaluator { CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-225 Malformed PropertyName CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-228 OQS relation to POS CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-215 COM/CORBA keywords CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-220 CosExternaliazation Service (bug?) CORBA 2.4.2 CORBA 3.4 Deferred closed
CORBA34-218 ObjectCreationError and Nofactory exceptions in Externilazition CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-219 CosConsurrencyControl service bug or not? CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-216 Compiler being able to translate from OMG-IDL into ANSI CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-213 Unclear and possibly harmful consequences of mandatory annotation definitions CORBA 3.1.1 CORBA 3.4 Deferred closed
CORBA34-212 Section: 15.4.5.1 struct has to be updated CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-214 Fixed Types in COM CORBA 2.4.2 CORBA 3.4 Deferred closed
CORBA34-207 How does DynValue handle derived valuetypes? CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-205 Spec doesn't make clear what is valid mix of policies and what is invalid CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-206 messaging router issue CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-211 valuetypes and local interfaces CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-210 Section 22.2.4.6 interface RelativeRoundtripTimeoutPolicy CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-209 CORBA 3.02, page 11-25, section 11.3.6 CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-208 module SendingContext CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-199 rules for marshalling ValueBoxes CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-198 BNF changes CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-200 Problem with ServerRequestInterceptor::receive_request and DSI CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-201 restriction of where a valuetype chunk can end CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-202 Bad text in 22.6 mandates Routing for sendc/sendp CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-203 What is the RSC when using a PersistentPoller CORBA 3.0.1 CORBA 3.4 Deferred closed
CORBA34-204 Messaging Routing Protocol is broken for GIOP 1.0 & 1.1 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-195 Codec Interface Deficiencies CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-194 methods on the POA CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-193 Add a typedef for the POAManager id CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-196 An extension of IOR to protect target objects Nature CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-197 Mapping from -ORBxxx to Java properties does not work for -ORBInitRef CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-189 The POA state inactive is not used consistent. CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-188 CORBA 3.0.3 ch. 3.4 OMG IDL Grammar CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-191 argument of the set_servant call has a small typo CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-187 Section: 4.3.13 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-192 change in the POAManager CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-180 Issue: CSIv2 Identity Assertion CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-181 Polymorphic Valuetypes and the DII CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-182 DynValue & custom valuetypes CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-185 Code Set Conversion on Operations CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-184 Potential deadlock with POA::deactivate_object() CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-183 Custom Value Marshaling Issue CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-186 Appendix A CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-174 ForwardRequest is impossible to detect in clients CORBA 2.6.1 CORBA 3.4 Deferred closed
CORBA34-177 Avoiding RSC/TSC copy on server side CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-178 Implications of any/valuetype marshalling CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-176 Proposal for extension to CosNaming CORBA 2.6 CORBA 3.4 Deferred closed
CORBA34-175 New issue: ForwardRequest() CORBA 2.6 CORBA 3.4 Deferred closed
CORBA34-179 How does an ORB implement Object::get_policy for PI defined policies? CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-170 rule (85) is misplaced CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-173 processing TaggedComponents within an IOR CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-171 Bad quotes and imported dot CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-172 missing document title CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-162 Section: 4.8.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-163 move struct to IOP module CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-164 Add create_policy with just the type as argument CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-165 context should be local interface CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-169 Make anonymous types illegal CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-166 Redundant bullet CORBA 3.2 CORBA 3.4 Deferred closed
CORBA34-168 interface ORB should be local CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-156 There is lack of multiplex publisher port that would mimic functionality of multiplex receptacle CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-155 Section: 21.3.13 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-157 16.10 lists register_initial_reference CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-161 Section: 21.7.3 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-159 add CORBA::ORB::arg_list CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-158 add interface ORB { Object string_to_object ( in wstring str ); }; CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-160 Section 13.7 ServiceContext CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-147 Section: Part 2, Chapter 11 - MIOP CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-149 definition of Invalid Policies changed CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-148 mention of (deprecated) function get_implementation removed from text CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-152 Proposal to change PortableInterceptor::ReplyStatus to a real enum CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-151 Proposal to change PortableInterceptor::AdapterState to a real enum CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-153 Section: 15.4.2/16.4.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-150 Third line of 23.1.3.4, ACTIVE must be bold CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-154 Section: 13.6.10.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-142 Missing PolicyValue encoding instructions ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-143 Invalid IDL (2) ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-145 Two typo's in Annex A.4 CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-144 Invalid IDL ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-146 struct PolicyValue CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-137 Section: 7.4 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-140 Moving *Seq typedefs into ORB chapter CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-139 Minor code ambiguity CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-141 Missing size information for decompress() ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-138 Typo in sections 22.10.1.1 and 22.10.1.2 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-132 Section: 21.7 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-133 update the spec to not used anonymous types CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-131 Section: 21.9.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-130 Section: 21.4.3.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-134 Section: 4.2 (02) CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-135 Section: 4.2 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-136 Section: 13.6.2 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-124 FullInterfaceDescription and base_interfaces question CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-121 Allowing mutual recursion for IDL structs - clarification needed CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-122 CORBA Exceptions CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-123 Section: 11.3.9.16 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-129 Section: 11.3.9 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-128 Section: 22.16/ CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-126 Page: 21-43 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-127 Section: 22.11.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-115 Page: 7-7 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-116 Page: 9-1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-117 Page: 21-5 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-119 Section: 21.3.14.11 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-120 Section: 4.5.2 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-118 Section: Appendix A CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-110 69.8.2.8 The simple Element, page 69-538 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-111 Section: Chapter 9, Chapter 5 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-112 Section: Chapter 11 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-113 Allowing Mutual Recursion for IDL Structures CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-114 NVList Section: 7.5 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-103 69.3.2.15 The implementation Element, pages 69-478/479 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-104 69.3 Software Package Descriptor CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-105 Add the capability to define a component artifact property CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-107 69.8.2.9 The sequence Element CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-106 Test Property - add a test property definition to the properties DTD CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-108 69.8.2.3 The choices Element, page 69-537 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-109 69.8.2.7 The range Element, pages 69-537/538 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-96 Component Artifact Dependency CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-95 LWCCM issue - Section 1.5.3 Exclusion CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-100 69.3.2.25 The propertyfile Element, page 69-482 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-97 69.3.2.2 The author Element, page 69-474 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-99 69.3.2.14 The idl Element, page 69-478 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-98 Descriptor CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-102 69.8.2.7 The code Element, pages 69-474 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-101 69.3.2.15 The implementation Element, pages 69-478/479 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-89 lwCCM issues - abstract storage type CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-91 lwCCM issues - entity components CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-92 lwCCM issues - persistence CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-90 lwCCM issues - section 4.1.2 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-94 lwCCM issues - transaction CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-93 lwCCM issues - security CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-88 lwCCM issues - abstract storage home CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-87 lwCCM issues - CIDL CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-86 lwCCM issues - locator CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-85 lwCCM issues - segmentation CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-79 lwCCM issues - home finders and finder operations CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-80 lwCCM issues - proxy homes CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-78 lwCCM issues - invalid rows CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-83 lwCCM issues - primary key CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-84 lwCCM issues - get_all_facet, ... CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-82 lwCCM issues - Section 4.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-81 lwCCM issues - configurators CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-71 Checking XML DTD elements related to the trader service CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-72 Description for the impltype Element? CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-74 Uses Relationships CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-73 69.3 AssemblyFactory Interface CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-75 Device Artifact Dependency CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-76 Dependency on D+C FTF CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-77 lwCCM issues - Entity2Context CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-68 A new exception specification is needed for CCM2Context::req_passivate() CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-65 CCM IDL style inconsistency CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-66 Derived component supported interface restriction (formal/2002-06-65) CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-67 Issue on the description of the consumesidentifier element CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-70 Using Configurator on CCMHome or any CORBA objects? CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-69 [CCM] Interface Repository Metamodel CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-59 Section 6.4.5.26 and Section 6.4.5.30 should be moved to section 6.3 CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-60 Section 6.4.5.10 (page 6-26) CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-62 CCM spec: insufficient examples of component attributes CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-64 multiple lifetime policies declaration issue CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-63 3.2.7 Compositions with Managed Storage CCM 3.0 CORBA 3.4 Deferred closed
CORBA34-61 Section 6.4.5.52 (page 6-38) CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-56 'local executor mapping' CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-55 portability of CCM descriptors CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-54 EnterpriseComponent should have a get_servant method CCM 3.0 CORBA 3.4 Deferred closed
CORBA34-58 issue on component supporting abstract interfaces CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-57 CCM Spec: attributes are listed in the ports section? CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-48 EnterpriseComponent should have a set_persistent_object method CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-47 HomeExecutorBase should have a set_context method CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-49 Generic connectivity for Receptacles, Emitters, Publishers CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-50 HomeExecutorBase should have a get_servant method CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-51 EnterpriseComponent should have a get_servant method CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-52 The association of entity component primary key and PSS key is unclear CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-53 HomeExecutorBase should have a get_servant method CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-44 Contradictory sections in the CCM and Lightweight CCM specifications CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-41 spec should define how the base class of an executor is generated by the framework ZIOP 1.0b1 CORBA 3.4 Deferred closed
CORBA34-43 The D&C IDL part doesn't match 06-04-02. CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-42 add a sequence of CCMHome typedef sequence CCMHomes; CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-46 add some feature to let an assembly look like a monolithic compoment CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-45 "supports" keyword CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-36 two not used and document exceptions listed ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-38 Event mechanism proposal ZIOP 1.0b1 CORBA 3.4 Deferred closed
CORBA34-39 typedef CCMObjectSeq ZIOP 1.0b1 CORBA 3.4 Deferred closed
CORBA34-40 The spec mentions InvalidConfiguration as exception but there is no idl in this spec ZIOP 1.0b1 CORBA 3.4 Deferred closed
CORBA34-37 ResourceCommitmentManager lacking ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-31 CCMHome should have a get_components method CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-32 CCMHome should have a get_container method CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-33 Incorrect statement that implies that connect_consumer returns a cookie ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-34 HomeConfiguration::set_configuration_values should document exception ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-25 Interface Introspection CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-27 Generic port connections CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-26 LwCCM issue - Section 1.4.3.3 Exclusion CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-29 HomeConfigurator should not extend CCMHome CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-30 Session2Context interface CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-28 LwCCM issue - Section 1.6.8 Exclusion CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-19 page 1-20 and page 1-21 - editorial CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-23 Change new GIOP Negotiate Session Message to Firewall Specific CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-22 GIOP Conformance and Interceptors CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-21 context interface for home implementation CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-20 page 1-20 the description of the get_connection operation CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-24 CodeSet and CSIv2 Negotitaion CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-13 valuetype fragmentation ambiguous CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-14 Clarification on multi-threaded codeset negotiation CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-15 15.3.3 - codesets must be "explicitly defined" CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-16 [Components] Contradiction between IDL and Interface Repository concerning CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-17 Chapter/section: 15.4.2.2 "Request Body" CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-18 page 1-20 second bullet of the description of the disconnect operation CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-7 Duplicate union labels CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-6 COM Sequence changes CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-8 Changes to ForeignComplexType CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-9 Section 13A.5.2: Editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-10 Section 13A.2.3: editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-11 Capter 13C: Editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-12 Incorrect mappings for systems exceptions (part A) CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-5 Section 13C.1.3 Editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-4 Levels of Indirection for passing COM types CORBA 2.0 CORBA 3.4 Deferred closed
CORBARS_-1 Provide a simple sample application CORBA-REST 1.0b1 CORBA-REST 1.0 Resolved closed
CORBARS_-2 Provide example of authentication and security CORBA-REST 1.0b1 CORBA-REST 1.0 Resolved closed
CORBA34-2 Extract IDL details from CORBA spec CORBA 3.3 CORBA 3.4 Resolved closed
CORBA34-1 Valuetypes should be added to the list of scopes CORBA 3.3 CORBA 3.4 Closed; Out Of Scope closed
CORBA31-112 Section: 15.4.5.1 struct has to be updated CORBA 3.0.3 CORBA 3.1 Deferred closed
CORBA31-218 ZIOP has to be part of the core CORBA specification ZIOP 1.0 CORBA 3.1.1 Resolved closed
CORBA23-247 question re BiDir IIOP CORBA 2.2 CORBA 2.3.1 Resolved closed
CORBA23-246 New OBV "supports" keyword conflicts with CosLifeCycle CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-245 Abstract Interface issue (02) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA3-134 IDL keyword clash in CosNotification.idl CORBA 2.6 CORBA 3.0 Resolved closed
CORBA23-244 Query Service IDL code CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA25-57 CORBAservices IDL CORBA 2.2 CORBA 2.5 Resolved closed
CORBA23-243 OBV TypeCode problems CORBA 2.2 CORBA 2.3 Resolved closed
CORBA26-99 Include GIOP over Bluetooth into Wireless CORBA 1.1 CORBA 2.5 CORBA 2.6 Resolved closed
CORBA23-242 Module separator within repository IDs CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-241 DynAny::get_value collision CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-240 Problem with C++ language mapping for OBV CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-239 public static org.omg.CORBA.ValueDef get_value_def(); CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-238 Clarify semantics CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-237 Which exceptions should be raised? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-236 Grammar rule issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-235 "Syntax" for grammar rule [value_inheritance_spec] ::= ":" [ safe_token ] CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-234 CODESET_INCOMPATIBLE exception is not defined CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-232 Wide String (and String encoding) CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-231 IDL TypeExtension correction CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-233 IDL Type Extensions: DATA_CONVERSION exception CORBA 1.2 CORBA 2.3 Resolved closed
CORBA24-203 What should an ORB do when it does not find any profile in an IOR CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-202 Standard System Exception minor codes missing in Chapter 13 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-201 Component ids in 13.6.2.2 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA23-230 OBV chunk boundaries CORBA 2.2 CORBA 2.3 Resolved closed
CORBA24-200 Transmission of type codes across 2.2/2.3 boundaries CORBA 2.2 CORBA 2.4 Resolved closed
CORBA24-199 LOCATE_FORWARD_PERM and hash() CORBA 2.2 CORBA 2.4 Resolved closed
CORBA23-229 Clarification requested on GIOP 1.1 and wstring CORBA 2.2 CORBA 2.3 Resolved closed
CORBA31-217 Japan CORBA Part 2 PAS Ballot Comments - comment 12 CORBA 3.1 CORBA 3.1.1 Resolved closed
CORBA23-228 TypeCode constants for bounded strings? CORBA 2.2 CORBA 2.3.1 Resolved closed
CORBA23-227 DynValue::get_members/set_members CORBA 2.2 CORBA 2.3.1 Resolved closed
CORBA24-198 IDL constant declarations CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-197 Conflict between POA & Exceptions spec for OBJECT_NOT_EXIST CORBA 2.3.1 CORBA 2.4.2 Closed; No Change closed
CORBA25-56 SYNC_WITH_SERVER CORBA 2.4.2 CORBA 2.5 Closed; No Change closed
CORBA24-196 Changebars missing from POA chapter CORBA 2.3 CORBA 2.4 Resolved closed
CORBA23-226 Type code parameter ordering CORBA 2.2 CORBA 2.3 Resolved closed
CORBA21-113 RMI repository ID references to serial version UID CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-112 Second bit of response_flags CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-111 Issue: Problem with issue 2801 resolution CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-110 fragmentation broken with bi-dir giop CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-109 CODESET_INCOMPATIBLE exception CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-108 A Messaging related issue in GIOP 1.2 CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-107 IIOP 1.2 fragmentation presents an unrecoverable error situation CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-106 New IDL types CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-105 Narrow Interop CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-104 Contents of MultiComponent component an encapsulation? CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-103 Type any marshalling rules force slow implementation CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-102 Marshalling of union type codes CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-101 Typecode encoding is too long CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-100 Type code marshalling CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-97 CDR encoding of TypeCodes CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-99 Typecode indirection issue CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-98 No provision for numbering the fragments in fragmented IIOP messages CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-96 Correct CDR encoding of an empty string CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-95 Typecode equality CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-94 Wchar and Char can both be multibyte CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-91 GIOP Exception formatting description (12.4.2) CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-93 Issue about CDR encoding for wide characters CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-92 Query about GIOP and IIOP version numbers in 98-01-03 CORBA 2.0 CORBA 2.1 Resolved closed
CORBA31-216 Sections 8.1.1, 8.2.1: CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-212 Section 7.1, line1: CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-211 Figure 1 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-215 Section 8.1.1 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-214 7.2, sentence 3 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-213 - Figure 2 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-210 use the proper notation for expressing Profiles CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-209 Minor comments re Components FTF CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-208 Section 7.2 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-207 On Page 18 - Figure 11 Home mapping CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-206 Section 7, Overview CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-205 sections 1, 3, 4, 5 essentially empty CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA3-133 insufficient examples of component attributes CORBA 3.0.2 CORBA 3.0.3 Duplicate or Merged closed
CORBA3-132 Derived component supported interface restriction CORBA 3.0 CORBA 3.0.1 Resolved closed
CORBA24-192 Typo: "Wrongpolicy" CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-191 destroy on POA CORBA 2.3.1 CORBA 2.4 Duplicate or Merged closed
CORBA24-190 Valuetype "copying" semantics underspecified? CORBA 2.3.1 CORBA 2.4 Duplicate or Merged closed
CORBA24-189 Scope of inherited valuetype initializers CORBA 2.3.1 CORBA 2.4 Duplicate or Merged closed
CORBA24-188 Null valuetypes not supported by DynValue CORBA 2.3.1 CORBA 2.4 Duplicate or Merged closed
CORBA25-55 International Strings in Encapsulations CORBA 2.3.1 CORBA 2.5 Resolved closed
CORBA24-187 Expected behavior of POA configured with ServantLocator receiving LocateRe CORBA 2.3 CORBA 2.4 Resolved closed
CORBA23-225 The insert_dyn_any and get_dyn_any operations are barely documented CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-224 OBV, value-reference substitution, Multiple Inheritance CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-223 WRONG_TRANSACTION CORBA 2.2 CORBA 2.3 Duplicate or Merged closed
CORBA23-222 Proposal on floating point fixes CORBA 2.2 CORBA 2.3 Duplicate or Merged closed
CORBA24-186 Section 3.3.8.16:deactivate_object() operation CORBA 2.1 CORBA 2.4 Resolved closed
CORBA23-221 Object::is_a CORBA 2.0 CORBA 2.3 Resolved closed
CORBA23-220 DII operations "get_response and get_next_response CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-219 6.5.6. Repository Paragraph 2 - objection CORBA 1.2 CORBA 2.3 Closed; No Change closed
CORBAE-21 exception NoServant(); CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-20 Section: 8 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-19 Section: 5.2 and 5.7 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBA32-1 Typo in set_values CORBA 3.1.1 CORBA 3.2 Resolved closed
CORBA32-2 context:delete_values has type CORBA 3.1.1 CORBA 3.2 Resolved closed
CORBA31-204 Section: exceptions CORBA 3.0.3 CORBA 3.1 Closed; No Change closed
CORBA31-203 Codec Interface Deficiencies CORBA 3.0.3 CORBA 3.1 Duplicate or Merged closed
CORBA3-131 Error in Chapter 21 of CORBA 3.0 CORBA 3.0.2 CORBA 3.0.3 Resolved closed
CORBA3-130 Wrong minor code listed in POAManager::deactivate CORBA 3.0 CORBA 3.0.1 Resolved closed
CORBA3-129 DATA_CONVERSION minor code 2 not listed in Table 4-3 CORBA 2.6.1 CORBA 3.0 Resolved closed
CORBA26-96 New core issue: need UNKNOWN reply status CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-98 TypeCode interface issue CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-97 Valuetype initialzers need exceptions CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-95 Syntax error in CORBA IDL CORBA 2.5 CORBA 2.6 Resolved closed
CORBA25-54 Incorrect example for recursive definitions which can span multiple levels CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA24-185 Definition of TRANSIENT minor code 1 confusing CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-184 IDL format for RepositoryId CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-183 Valuetypes supporting local interfaces are local types? CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-180 DynUnion incomplete CORBA 2.4 CORBA 2.4.2 Resolved closed
CORBA24-182 #pragma version issue CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-181 Servant deactivation callback? CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-179 Format of RMI Hashed Format repid CORBA 2.4 CORBA 2.4.2 Resolved closed
CORBA24-178 Typo: "Wrongpolicy" CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-177 Minor typo CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-176 Section 4.3.7.1 get_client_policy? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-175 Typo on page 7-9 of 2.3.1 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-174 BAD_QOS system exception CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-173 attributes and system exceptions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-172 why was is_abstract added to structs in CORBA IR? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA23-218 Null Value semantics under specified CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-217 DynFactory or DynAnyFactory? CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-216 is_abstract parameter missing from create_interface() IDL CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-215 Destruction of ORB CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-214 OMG VMCID CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-213 New proposal for recursive TypeCode creation CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-211 Typo on pages 10-53, 10-55, and 10-70 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-212 deactivate_object page no: 9-35 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-210 Proposal for creating recursive TypeCodes CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-209 Types defined in the CORBA module? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-208 Missing orb.idl CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-206 Size of IDL char CORBA 2.2 CORBA 2.3 Closed; No Change closed
CORBA23-207 Incorrect LifeCycle IDL? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-205 Proposed change to IDL in section 3.10.2, page 3-32 "Parameter Declaration CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-204 CosObjectIdentity::ObjectIdentifiers can"t be UUIDs? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-203 Illegal IDL in CosTime module CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-202 TypeCode comparison proposal (02) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-201 TypeCode comparison proposal (01) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-200 Description of Wide String type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-199 name scoping issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-198 IDL struct issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-197 Type codes cannot describe all unions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-196 Type code operations under-specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-195 Type code typos (as only one issue) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-194 Typo in chapter 8 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-193 Does the DII support the standard object operations? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-192 Typos in IR IDL in Specification (050 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-191 Typos in IR IDL in Specification (04) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-190 Typos in IR IDL in Specification (03) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-189 Typos in IR IDL in Specification (02) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-188 Typos in IR IDL in spec (01) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-187 / in prefix pragma? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-186 Versioning by the back door? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-185 GIOP typo, section 4.2 (page 4.4) of CORBA 2.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-184 Domain Manager related specification shortcomings (03) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-183 Semantics and standard exceptions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-182 Forward declarations and inheritance CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-181 Indentation on page 4-4 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-180 Editorial issue, chapter 8 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-179 ORB_init CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-178 IDl "module" construct - IDL files CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-177 How to deal with object identity CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-176 Typo in type code section (13.3.4) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-174 Fixed point constants issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-173 Wide character and wide string literals CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-175 Type of fixed point quotients CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-172 Fixed point constant typo in 2.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-171 Marshalling is_equivalent CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-170 #pragma prefix issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-169 CORBA 2.2 - "native" and the interface repository CORBA 2.2 CORBA 2.3 Resolved closed
CORBA22-142 union typecode CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-141 CDR encoding of TypeCode names inconsistent with equal operation CORBA 2.1 CORBA 2.2 Resolved closed
CORBA21-90 OMG IDL prefix pragma CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-89 Description of constant expression semantics is unclear CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-88 Object terminal missing from IDL grammar CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-87 WRONG_TRANSACTION CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-86 OTS 1.1 specification changes CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-85 Interface Repository CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-84 CORBA::Bounds and CORBA::TypeCode::Bounds CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-83 3.10.3 Raises Expressions CORBA 1.2 CORBA 2.0 Duplicate or Merged closed
CORBA21-82 Do simple/anonymous types have repository IDs? CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-81 Exception as explicit parameter CORBA 1.2 CORBA 2.0 Resolved closed
CORBA26-87 Length of wstring in GIOP 1.1 CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-86 padding at the end of a non-fragmented 1.2 request message CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-83 IANA ports for IIOP need to be documented in Ch 13 and 15 CORBA 2.3 CORBA 2.6.1 Resolved closed
CORBA26-85 Interop, 15.7.3 unclear wording CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-84 Is GIOP 1.x sustainable any more? CORBA 2.3 CORBA 2.6.1 Resolved closed
CORBA26-82 Use of undefined "id" attribute CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-93 Question about corbaname URL CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-92 Incomplete grammar in section 15.3.4.8 CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-91 Indirections with chunking & fragmentation CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-89 In RMI rep Id, when is inclusion of SUID legal? CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-88 GIOP is silent about extra data in the Request or Reply body CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-90 GIOP issue : fragmented replies with exceptions CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-94 Changing VSCID prefix to 24 bits CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-72 Component port introspection CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-71 "supports" terminology issue for CCM CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-77 CCM: Definition of import declaration unclear CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-70 CCM: Chapter 66 should be removed CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-69 IDL out parameters can't map to EJB? CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-74 explicit definition of CCM exceptions mapped from EJB standard exceptions CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-73 Incorrect syntax in Components::Enumeration CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-81 minor IDL changes required in CCM API CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-80 Little problem with introspection API CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-79 CCM: Meaning of "exposed" scopes unclear. CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-68 CCM: usage of the MOF profile CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-76 CCM: Isolated scope tokens CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-75 Issue for Components: Missing language mapping CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-78 CCM: import and re-opening of modules CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-63 Extended Interface Repository CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-62 Problems with the Components Notification Event Interface CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-61 Component home interface inheritance CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-56 Components, Facets, and Object References Unclear CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-55 New component issue: connection failure recovery CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-65 Components FTF: TypeCodeFactory CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-64 ComponentIR Interface fixes CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-58 Component assemblies do not follow composition pattern CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-57 Inter-component type semantics unclear CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-54 Typo in assembly element paragraph heading CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-53 grammar rule for home_executor_body contradicts description CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-52 No Access to event filter form component CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-60 Component home polymorphism CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-59 Component assembly templates CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-67 CCM : Session2Context naming CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-66 CCM : Session2Context and Servants CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-51 No user access to filterable body in CCM spec. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-50 IDL question concerning CCM CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-49 CCM Events issue CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-48 typo in connections element definition CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-45 Deployment Object Life Cycles CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-44 Services available for a basic container CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-43 push() versus push_event() CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-41 An assembly is always mono-vendor ??? CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-40 Intent of Components::Events::(un)subscribe to bypass the notif. service ? CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-39 Channel Setup for Emits ports. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-38 exception raised by Components::Events::subscribe() CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-37 ExecutablePlacement definition CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-36 Local push() operation. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-47 repository element needed by softpkg DTD CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-46 description element need to be added to corbacomponent.dtd CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-42 equivalent interfaces issue CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA25-53 Urgent issue: Alignment of LocateReply body CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-52 Incorrect table in section 15.4 CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-48 Table 15-2 is missing entry for tk_local_interface CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-47 GIOP 1.2 AddressingDisposition processing on the client side CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-46 Fixed point marshalling CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-45 Null termination of strings CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-51 Incorrect text in 15.4.6.2 CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-50 GIOP 1.1 Fragment problem CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-49 tk_indirect CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA26-32 operation get_implementation() referenced but not declared CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-31 Pbl: Improper mapping rule from IDL3 to IDL2 when dealing with events. CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-30 Issue on Assemblies and descriptors CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-33 What about valuetype factories? CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-35 simple ELEMENT definition CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-34 range description in CPF files. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-23 Bridge Interoperability of the Java mapping with the EJB-to-CCM mapping CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-22 CCM issue chapter 69 ptc/99-10-04 CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-21 Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01 CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-20 EJB/CCM mappings for the IR CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-19 IFR backward compatibility broken CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-18 Missing Rights Combinator in Security deployment descriptor CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-13 Purpose of "name" element CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-12 CCM Issue: CIDL Syntax doesn't allow for modules CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-29 Issue On the use of typed home (or CCMHome subtypes) CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-28 Where is HomeExecutorBase interface defined? CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-27 In example p.615-86 CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-26 p.615-85 ToonTownImpl CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-25 Why does not CCMHome include the operation create_component() ? CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-24 operation CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-15 PACKAGING AND DEPLOYMENT METAMODEL CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-14 atribute not part of definition CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-11 Versioning needed for CORBA Core CORBA 2.2 CORBA 2.6.1 Resolved closed
CORBA26-17 Components: readonly_attr_declarator slightly ambiguous CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-16 Components: Relationship of CIDL and PSDL unclear CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA31-110 ValueMembersSeq CORBA 3.0.2 CORBA 3.1 Resolved closed
CORBA31-111 Make a typedef for the POA id new CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA26-10 section 7.1.1 claims to define the "NVList structure", but doesn't CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-9 Implied IDL for interfaces in modules CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-8 IDL for ORB::resolve_initial_references CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-7 set_length operation of the DynSequence interface CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-6 the IDL include directive should introduce declarations into the namespace CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-5 DynUnion operations CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-4 Problem with IDL Context interface CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-3 Chapter 11, section 11.3.8.19 (WrongPolicy)" CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-2 Support for is_a for local interfaces CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-1 Section 11.3.8.16 - ambiguity CORBA 2.5 CORBA 2.6 Resolved closed
CORBA25-44 Nil return from resolve_initial_references() CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-43 Interpretation of time field in UtcT? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-42 There is no mapping for fixed types in the COM/CORBA mapping CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-41 COBRA problem using pragma prefix for modules CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-40 CORBA 2.4.2 (01-02-01.pdf) 4.2.3.4 shutdown (relevant portion) CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-39 Local interface is-a Object? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-38 Wither pseudo-objects? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-37 Missing TypeCode identity CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-36 Problem with resolution to 4285 and 4306 CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-35 get_interface() underspecified CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-34 Typo in UML for POA CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-33 DII create_request CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-32 Ambiguity in non_existent CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-31 String literal definition incorrect. CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-30 Inconsistent minor code for MARSHAL CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-29 Minor code CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-28 Missing POAManager identity CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-27 BAD_OPERATION needs minor code and completion status CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-26 Cross-reference refers to wrong section CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-25 Issue: Error in section 4.5.3.2 ORBInitRef CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-24 Section 10.5.22.2 what happens when conditions not met CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-23 Restrictions on native types CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-22 Clarification about include files and IDL compiler behavior CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-21 Definition of NamingContextExt interface in IDL of Appendix A not consisten CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-20 3.7.4 Forward Declaration (for interfaces) doesn't mention local CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-19 What is the semantics of the DataInputStream::read_*_array() operations? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-13 Introduction of identifiers CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-12 Type redefinition in derived interface CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-11 PortableServer::ObjectId CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-10 core issue: unchecked narrow CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-18 #include issue CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-17 DynValueBox::set_boxed_value should also raise InvalidValue CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-16 misleading wording in 10.5.22.2 Write Interface CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-15 Inconsistent text for unknown system exception CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-14 ForwardRequest from normal operations CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-3 POAManager::deactivate should not mandate ORB::shutdown implementation CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-2 POAManager::deactivate does not specify behavior for "reject" CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-1 Can a valuetype support multiple non-abstract interfaces via inheritance? CORBA 2.4 CORBA 2.5 Resolved closed
CORBA25-6 CORBA::ORB::object_to_string() raising INV_OBJREF or BAD_PARAM CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-5 ServantLocator preinvoke/ postinvoke semantics CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-4 Minor code 2 description for OBJECT_NOT_EXIST not consistent w/ use CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-9 Container::lookup() ordering requirements CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-8 Section 2.1.7 of CORBA 2.3 and 2.4 CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-7 Legal IDL? CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA3-124 Issues related to CCM's XML descriptors: chapter 69.4.5.4 CCM 3.0 CORBA 3.0.2 Resolved closed
CORBA3-128 Creating IORs CORBA 2.4.2 CORBA 3.0.3 Resolved closed
CORBA3-127 There is no way to modify a POA's ORT and append to it CORBA 2.4.2 CORBA 3.0.3 Resolved closed
CORBA3-126 Interoperability of ObjectReferenceTemplate and Factory. CORBA 2.4.2 CORBA 3.0.3 Resolved closed
CORBA3-125 Object Adapter name problem in ORT CORBA 2.4.2 CORBA 3.0.3 Resolved closed
CORBA3-116 Productions 140, 141, 142 and 143 must be removed CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-115 paragraph 60.2.1 : There is two mistakes in keywords CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-123 Update Table 5-13 in the EJB Chapter of formal/02-06-65 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-122 Editorial issues in formal/02-06-65 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-120 Remove section 4.4.1.4 in formal/02-06-65 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-119 create operation of AssemblyFactory interface CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-114 CIDL Grammar problems: Productions must be renumbered : 134 -> 1, ... CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-118 69.8.2 Property File XML Elements CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-117 Typo (??) in chapter 61 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-121 Corrections in XML DTDs for packaging CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-106 components-ftf: connectevent element CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-105 components-ftf: registercomponent element CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-104 components-ftf: repository id in software package descriptor CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-103 IDL3 keyword "eventtype" conflicts with struct "CosNotification::EventType CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-113 Issues related to CCM's XML descriptors: chapter 695.4 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-112 Issues related to CCM's XML descriptors: chapter 69.7.2.38 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-107 Issue regarding language mapping for keyless homes CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-102 Generic operations for subscribing/unsubscribing at publishing ports CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-108 simple type element of the property file issue CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-111 Issues related to CCM's XML descriptors: chapter 69.7.2.25 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-110 Issues related to CCM's XML descriptors: chapter 69.4.5.16 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-109 Issues related to CCM's XML descriptors: chapter 69.4.4 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-95 add a ClientInterceptor then create_POA() in the post_init() method? CORBA 3.0.1 CORBA 3.0.2 Resolved closed
CORBA3-94 CORBA::WrongTransaction and Interceptors CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-93 How do Portable Interceptors interact with Messaging callbacks CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-92 What ORBInitInfo operations are legal during pre_init() and post_init()? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-91 ORBInitInfo::arguments() underspecified CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-90 Exception handling in Interceptor initialization CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-89 Derived component supported interface restriction (formal/2002-06-01) CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-88 Local types allowed as valuetype state? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-87 Why does PollableSet::number_left() return unsigned short? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-86 Pollable in more than one PollableSet? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-85 Oneway operations should not generate sendc_ and sendp_ variants CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-84 DII sendc reply delivery underspecified CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-83 Bad example code in 22.11.4.3 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-82 Messaging Poller generation is broken for interfaces with multiple inherite CORBA 1.1 CORBA 3.0.2 Resolved closed
CORBA3-81 name disambiguation for AMI interface & poller names is confusing CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-80 potential name clash with Messaging type-specific poller timeout argument CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-101 What ORBInitInfo operations are legal during pre_init() and post_init()? CORBA 3.0 CORBA 3.0.2 Duplicate or Merged closed
CORBA3-100 AMI vs abstract & local interfaces CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-99 Sending codeset context more than once? CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-98 Getting reply svc ctxts from PersistentRequests CPP 1.0 CORBA 3.0.2 Resolved closed
CORBA3-97 Type code creation CORBA 3.0.1 CORBA 3.0.2 Resolved closed
CORBA3-96 Unfortunate CDR Encapsulation of ASN.1 Encodings CORBA 3.0.1 CORBA 3.0.2 Resolved closed
CORBA3-79 Messaging type-specific poller valuetypes should be abstract CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-78 Errors in definition of Messaging poller types CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-77 Messaging: bad example code for type specific poller CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-76 SyncScope for oneway invocations CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-75 Messaging time based policy enforcement? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-74 determining TimeT or UtcT value CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-73 Is a router allowed to pick any value in the range for a priority? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-72 Who is responsible for generating the TIMEOUT exception CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-71 Object::validate_connection() CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-70 Sloppy text in CORBA 3.0, 4.3.8.1 get_policy CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-69 Object::get_client_policy problem CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-68 Inconsistent definition of semantics of RebindPolicy? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-63 pragma prefix syntax CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-62 Avoiding Interceptors for colocated method requests CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-61 Codeset negotiation and the CODESET_INCOMPATIBLE exception CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-60 Replace deprecated anonymous type declarations? CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-59 reference_to_servant CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-67 BAD_INV_ORDER minor code 5 and 10 mean the same thing? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-66 Serious backward compatibility issue in the PI CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-65 OpaqueValue/add_arg never mapped to languages CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-64 Minor codes in specified NO_IMPLEMENT exceptions incomplete/inconsistent CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-58 Valuetypes supporting forward declared interfaces CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-57 Inconsitent exception handling with find_POA & unknown_adapter CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-56 IOR processing performance CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-47 Wide string in reply before codeset was negotiated CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-46 conflict between CORBA specification and C++ mapping (_this method CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-51 Codeset negotiation requires clarification CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-50 The whole negotiation thing should be removed, Unicode should be mandated CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-53 discussion on the create_union_tc operation could use some clarifications CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-52 IDL inheritance issue CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-49 interaction of #pragma and typeid, typeprefix CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-48 IPv6 in corbaloc URLs CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-55 GIOP version in replies CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-54 definition of the TypeCode interface (4.11.1) CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-43 Issue with chunking CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-42 TypeCode indirections CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-41 Chapters 13.10.1.9, and 13.10.1.12 -- issue CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-38 Alignment for empty sequence? CORBA 2.5 CORBA 3.0.2 Resolved closed
CORBA3-37 CORBA 2.5 and Portable Interceptors mismerged CORBA 2.5 CORBA 3.0.2 Resolved closed
CORBA3-36 Detecting Recursion in Other Interceptors CORBA 2.5 CORBA 3.0.2 Resolved closed
CORBA3-27 X/Open Codeset registry is obsolete needs to be replaced CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-26 Clarify that each interception point executes in a distinct logical thread CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA3-45 11.3.2.1 Processing States (end of second paragraph and third paragraph CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-44 Potential problem using BiDir GIOP and codeset conversion service context CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-40 GIOP 1.2 encoding of wstring CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-39 ORBs using BOMs for UTF-16 (closely related to issue 4008) CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-29 Problem with CSIv2 and GIOP LocateRequest CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-28 21.8.1 register_initial_reference CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-33 rep_id() operation on Object? CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-32 Repository ID in nil references CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-31 Note on page 15-43, OBJECT_FORWARD_PERM CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-30 Interpretation of defined ServiceConfigurationSyntax constants is incomplet CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-35 CORBA components requires new GIOP version? CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-34 TypeCodes for custom marshaled valuetypes CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-25 Stateful boolean causes all CSI mechanisms to operate the same way. CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA21-80 Bug in C++ NVList mapping CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-79 OMG C++ Mapping: Implicit Conversion Operators CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-78 Persistent Any values CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-77 DII and DSI are useless with current Any CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-76 iterating over Any primitives CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-75 decompose Any into constituent primitives CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-69 Rethrowing exceptions CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-72 Return value of operator[] for array var CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-71 Taking T out of T_var CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-70 Freeing inaccessible storage for T_var as out parameter CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-74 RTTI vs. _narrow for exceptions CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-73 Implementation of parameter passing for T_var types CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-68 IDL grammar CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-67 8.1 Role of the Basic Object Adapter Para 1 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-66 7.4 ORB Initialization Last Paragraph - objection CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-65 7.4 ORB Initialization Last Paragraph - objection CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-64 7.2.5 Probing for Object Non-Existence Paragraph 2 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-63 7.2.4 Equivalence Checking Operation Paragraph 3 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-62 7.2.1 Determining the Object Implementation and Interface CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-61 7.1 Converting Object References to Strings Para 3 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-60 6.5.6 Repository Paragraph 4 - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-59 6.5.4 Container Last Paragraph - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-58 6.4.3 Interface Objects Paragraph 2 - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-57 6.4.3 Interface Objects Paragrapg 1 - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-56 6.3.1 Managing Interface Repositories CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-55 5.3.2 Registering Dynamic Implementation Routines Para 1- comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-54 5.2 Explicit Request State: ServerRequest Pseudo Object CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-53 4.6.5 delete_values Paragraph 1 - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-52 4.3.3 get_response CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-51 4.2.3 invoke CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-50 4.1.2 Memory usage, Para 1, editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-49 4.1 Overview, Paragraph 3, editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-48 3.15.2 Object Non-Existence, Para 1, editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-47 3.10.3 Raises Expressions CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-46 3.9 Exception Declaration CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-45 2.5 Structure of an Object Adapter CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-44 2.1 Structure of an Object Request Broker CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-43 1.2.2 Requests Paragraph last - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-42 CORBA2.0, 1.2.2 Paragraph 2 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-41 Scope of standard exceptions CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-40 Unions with enum as discriminator type CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-39 _is_a with CORBA::Object as input parameter CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-38 Unqualified names in scopes CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-37 Usage of standard exceptions CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-36 Ambiguity in DII and DSI CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-35 Request reuse CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-34 Whether unions carry exact discriminant information CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-33 Recusive Type Definitions CORBA 1.2 CORBA 2.0 Resolved closed
CORBA3-11 Detail lacking in when request interceptors are called CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-10 How correlate requests and replies when using pollable sets? CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-18 no way to register value factory from ORB initializer CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-17 ORB accessor on POA? CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-16 RoutingPolicy issue CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-24 ORB::shutdown vs. ORB::destroy CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA3-23 Encodings of Sequences of Certificates are not standard. CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA3-20 Portable interceptors and invocation timeouts CORBA 2.4 CORBA 3.0.2 Resolved closed
CORBA3-19 Missing minor codes in Messaging Chapter CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-22 wchar endianness CORBA 2.4 CORBA 3.0.2 Resolved closed
CORBA3-21 No portable way to turn IOR components into object-reference policies CORBA 2.4 CORBA 3.0.2 Resolved closed
CORBA3-15 Portable Interceptors / register_initial_reference() CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-14 Policy Management in Portable Interceptors CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-9 ORBInitInfo needs the ORB CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-8 PI needs the ORB to be available in IDL CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-7 Question about routing policies CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-6 Portable Interceptors: object_to_string, string_to_object CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-5 Implementing proper handling of CloseConnection CORBA 2.3.1 CORBA 3.0.2 Resolved closed
CORBA3-13 Overriding POA policies CPP 1.1 CORBA 3.0.3 Resolved closed
CORBA3-12 Portable Interceptors: 9.2.3 text describing `Arguments' CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-2 No way to detect that ORB has outstanding deferred synchronous requests CORBA 2.2 CORBA 3.0.2 Resolved closed
CORBA3-1 constant decls broken CORBA 2.2 CORBA 3.0.2 Resolved closed
CORBA3-4 scheme name for IORs CORBA 2.3 CORBA 3.0.2 Resolved closed
CORBA3-3 issue with ForwardRequest exception in POA CORBA 2.2 CORBA 3.0.2 Resolved closed
CORBA21-31 Page 13C-36: Editorials CORBA 2.0 CORBA 2.1 Resolved closed
CORBAE-17 More wrong references in chapetr 11 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-16 Wrong references in chapter 11 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-13 CORBA/e and get_interface CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-12 Section: 9.2.1.1 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-18 Section: 8.2 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-15 Section: 11.4.1 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-14 Section: 18.2.2 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-11 Section: 6.2.12 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-10 The removal of static any from micro CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-9 Servant_to_id clarification CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-8 Section: 11.2.3 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-7 document style and use of headings CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-6 Section: 6.2 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-5 Add table that captures the features that are in/out of CORBA/e CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-4 state machine diagram CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBA24-150 Validity of object references CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-149 An ORB should not accept an IOR with no usable profiles CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-148 Should an ORB be allowed to drop non-standard profiles CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-163 selected_profile_index origin CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-162 Absence of Wide Character Code Set CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-161 ORB throwing exception if it finds unknown service context CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-160 Wrong minor code specified in Chapter 13 CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-144 Table 13-1 needs update for valuetypes & abstract interfaces CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-143 marshalling of null values unclear CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-142 CDR Encapsulation Issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-152 Preserving unencapsulated information CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-151 Indirection for value types CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-147 chunked value encoding: CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-146 CORBA 2.3.1 missing text describing the response_expected field CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-145 Supporting TAG_MULTIPLE_COMPONENTS CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-157 GIOP version and CloseConnection CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-156 Valuetype in anys. Unmarshaling problem? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-153 Transferring Java exception reason string across the wire CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-159 Nesting depth in valuetype end tags CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-158 Valuetype encoding grammar in 15.3.4.7 is wrong CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-155 Marshaling fixed-point decimal types CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-154 IIOP 1.2 Early Reply message in presence of fragmented Request CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-141 Minor code allocation inconsistency CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-139 .Passing the interface repository ID of the method in IIOP CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-138 Chunked GIOP marshalling for variable-length types CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-137 TAG_ENDPOINT_ID_POSITION and TAG_LOCATION_POLICY CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-136 Optimization of LOCATION_FORWARD replies CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-135 Compacting GIOP Requests by hashing down operation names CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-140 GIOP encoding of nil Abstract Interface is unspecified CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-134 Compacting GIOP Messages by using templates CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-133 Compacting GIOP messages by using indirections CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-132 Use of the type ComponentHome CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-131 USING Components::Enumeration CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-130 destroy() for local objects CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-129 New IDL keywords CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-128 Implementation of get_component CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-127 CORBA IR METAMODEL CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-126 Is the ccm_home method shown in Table 8-1 a typo? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-125 How is CCMHome::get_home_def mapped to EJB operations? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-124 What's the return type of CCM mappings of EJB finder and creator methods? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-123 Do EJB-mapped attributes go to the ComponentDefault interface? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-122 CCM Issue: Is CCMObject::remove intended to be available to the CCM client? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-168 Small optimization for the GIOP header CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-167 interop issue: CodeSets service context in GIOP 1.0 request CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-166 Version and byte order changes when fragmenting messages (interop) CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-165 Issue 2 -- resulting from UK comment UK-5: CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-164 Issue 1 -- resulting from Japanese comment JPN-009E: CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-171 wchar alignment in GIOP 1.2 CORBA 2.4 CORBA 2.4.2 Resolved closed
CORBA24-170 Is padding necessary for empty Reply body? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-169 GIOP _get_domain_managers ambiguous CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-121 CCM Issue: How are standard EJB exceptions mapped into the CCM View CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-120 Should Components::Enumeration be an IDL interface or an IDL abstract value CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-119 CCM Issue: Is a home needed? CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-118 Components Issues - Interface Repository ptc/99-10-03 CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-117 Components Issues - Chapter 61 ptc/99-10-04 CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-116 implementing import for C++ CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-115 Policies not locality-constrained? CPP 1.0 CORBA 2.4 Resolved closed
CORBA24-114 Locality-constrained objects CORBA 2.2 CORBA 2.4 Resolved closed
CORBA24-113 Locality constrained objects + externalization CORBA 2.2 CORBA 2.4 Closed; No Change closed
CORBA24-104 Nested Recursive Structs Legal in 2.3.x? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-103 incomplete rules for forward declaration of structs/unions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-107 read_fixed() and write_fixed() methods missing CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-106 Initializers and user exceptions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-105 IDL: Clashes with inherited identifiers CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-112 Should POA spec examples use string_to_ObjectId? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-111 Values for CORBA::ARG_IN,... not defined CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-110 module IOP_N needs a real name CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-109 "omg.org" prefix missing from interceptor specification and its reference CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-108 ORB ID accessor CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-85 ValueMemberDef section omitted from CORBA 2.3.1 spec CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-84 Inheritance description incorrect CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-83 ORB mediation for servant managers, references for servant managers? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-92 Policy Management in the ORB core CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-91 Some problems CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-90 ORB shutdown vs destroy CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-102 With reference to forward declarations of structs and unions. CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-101 There is inconsistency in the POA.IDL and description in section 11.3.8.19 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-100 description of unknown_adapter CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-99 reference_to_servant raises ObjectNotActive, WrongAdapter, and WrongPolicy CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-98 Missing exception for activation CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-97 AbstractBase not declared. CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-82 POA deactivate_object description is ambiguous CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-81 how are valid ORBids determined CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-80 POA namespace and ORB ID CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-94 servant_to_id versus servant_to_reference CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-93 ORB::shutdown underspecified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-87 Incorrect use of negative fixed scale CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-86 is_equivalent and policies CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-89 POA servant_to_id inconsistent with servant_to_reference CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-88 Valuetypes with multiple interfaces CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-96 Pragma version 2.3 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-95 Non-escaped keywords in published IDL CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-79 return type of TypeCode::fixed_scale() CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-78 POA status during destruction is unclear CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-77 Problem with valuetype parameter copying CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-64 Ordering issues in the DII CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-63 Efficient construction of Any types w/o DynamicAny CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-68 Does a value in a valuebox make sense? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-67 Semantics for DynAny::equal underspecified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-73 Definition of COMPLETED_NO needs to be clarified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-72 Minor glitch about forward declared things CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-70 Editorial mistake in IDL chapter CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-69 Can native be used in constructed IDL types? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-76 response_flags in interop draft CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-75 symbolic constants for minor exception codes CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-66 Inheritence table 3-10 wrong? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-65 poll_response() CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-71 #pragma rules are too restrictive CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-74 valuetype factory inheritence? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-62 special-casing TypeCode is unnecessary CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA23-165 CDR encoding for fixed CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-166 LocateRequest and LocateReply messages CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-167 profile ids & component ids CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-168 Need clarification on GIOP::TargetAddress CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA24-51 Errors in published IDL for CORBA module CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-50 Non-standard system exceptions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-49 Use of Principal in GIOP Module erroneous CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-56 valuebox and DynAny CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-55 OMG wchar <-> COM WCHAR in CORBA 2.3 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-61 local interfaces and the DII CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-60 servant_to_id CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-54 What is the TypeCode for ValueBase? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-53 Do valueboxes have factories? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-52 DynAny & abstract interfaces don't mix! CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-48 create_POA and inactive state? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-47 value type substitutability CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-46 OMG IDL Syntax and Semantics issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-45 TypeCode issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-59 IDL scoping rules CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-57 null & void TCs and DynAny CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-58 Bug in 11.3.7.6 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-37 Problem with the "Special scoping" rules in 3.15.3 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-36 Meaningless sentence on page 3-11? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-32 Type Code Section issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-31 Minor codes for Standard System Exceptions in Chapter 8 missing CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-30 Minor codes for Standard System Exceptions in Chapter 5 missing CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-34 IDL and C++ relationship CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-33 PIDL vs Local CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-40 Missing "abstract" in forward declaration CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-39 The algorithm for TypeCode::equivalent in 10.7.1 was not updated CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-44 Editorial glitch in DynAny::destroy, section 9.2.3.6 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-43 What is the NO_RESPONSE exception good for? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-29 General Exception Question CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-28 Exception section issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-42 Section 7.6: IDL context housecleaning CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-41 Question about IDL \uxxxx escape format CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-35 Preprocessing of IDL CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-38 Codeset conversions and unions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-17 Use of incomplete recursive TypeCodes underspecified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-16 Semantics of DynAny with alias TypeCodes CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-15 URLs interact poorly with code set selection CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-12 DataInputStream specification is inefficient for Java CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-11 POA exception minor codes CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-10 Wchar as discriminator in union CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-23 Problem with text of POAManager::deactivate() CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-22 CORBA 2.3 spec hasn't been updated with corrections in COM-CORBA Part B CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-19 creation of arguments to TypeCode creation ops CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-18 DynFixed editorial issue CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-27 CORBA 2.3 Editorial issue for TypeCodes & abstract_interface CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-26 Editorial issue for CORBA 2.3, 1.3.8.20 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-9 CORBA 2.3: minor editorial issue CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-8 chapter 3 and recursion CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-25 Component ids in 13.6.2.2 CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-24 (CORBA Core) Data streams missing arrays of long double CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-14 Why are Standard Exceptions defined in IDL chapter? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-13 What is the RepId of Object? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-21 formal/99-08-01.txt missing pragmas CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-20 CORBA::ORB::RequestSeq definition obsolete CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA23-84 Incorrect IDL is section 5.5.3 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-83 RMI style repository ID hash code CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-82 forward declaration in ptc/98-10-04 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA24-4 $issue.summary CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-3 mixing giop versions CORBA 2.3 CORBA 2.4 Resolved closed
CORBA23-92 UNIQUE_ID and ServantActivator issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-91 Clarification on IdUniquenessPolicy CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-95 New "opaque" data type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-94 DynAny::equal operator issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-93 sharing valuetypes across Anys CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-86 DynAny.insert_valuetype shoud be insert_val CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-85 confusing rules for operations on Object CORBA 2.2 CORBA 2.3 Resolved closed
CORBA24-7 ambiguity in wstrings having a Unicode escape sequence CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-6 POA: false placement of paragraph CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-5 OBV interface support inconsistencies CORBA 2.3 CORBA 2.4 Resolved closed
CORBA23-88 activate_object_with_id and exceptions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-87 Repository ID for Object CORBA 2.2 CORBA 2.3 Resolved closed
CORBA24-2 interop issue: what system exceptions may be raised on GIOP 1.0? CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-1 The syntax for stringified IORs in section 13.6.6 CORBA 2.3 CORBA 2.4 Resolved closed
CORBA23-90 deactivate_object asymmetry CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-89 ORB::shutdown again CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-70 Inconsistent spellings of "policy" related identifiers: CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-69 IR Changes in 2.3 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-63 Interceptors broken CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-62 clarification and bug in InterfaceDef::FullInterfaceDescription CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-61 Try to define obligatory and optional parts of the CORBA specification. CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-60 Application Interface issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-59 Use UNICODE Character set CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-81 LocateReply body alignment issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-80 POA issue, section 11.3.8.10 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-79 POA that has IdAssignmentPolicy=SYSTEM--portability problem CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-76 Scope of SendingContextRunTime service context CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-75 Need to specify exception for abstract interface error CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-74 Error in IRObject definition in 98-12-04 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-73 What use is CORBA::exception_type? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-72 Inconsistent Definition of Flags type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-71 CORBA::Object::ping ? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-78 Can an any with a tk_null or tk_void TypeCode be encoded with CDR? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-77 omg.org prefix not well specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-68 What value type does ValueDef"s base_value() return? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-67 Inheritance of value types CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-66 Problems in Chapter 5 IDL CORBA 2.2 CORBA 2.3 Closed; No Change closed
CORBA23-65 POA Construction Policy. CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-64 another problem with IDL specification section 3.9.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-58 Issue - no PIDL, just language bindings CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-57 Grammar section 3.9.2 missing "float" rules, and other problems CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-45 No description for NativeDef CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-44 Errors in figure 10-2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-43 Signature of unmarshal method is wrong CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-54 Value base and the IFR CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-53 Clarifications needed in section 5.2.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-42 Clarify meaning of no IDL initializers CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-41 Misleading text in section 3.2.5.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-56 Calling get_response twice? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-55 Forward-Declared Interfaces CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-47 No description for ValueBoxDef CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-46 is_a description is wrong CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-50 RMI Repository ID missing from section 10.6 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-49 Text was inserted in wrong place CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-52 Clarify text in section 15.3.7 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-51 Error in text describing TypeCode interface CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-48 Error in ValueDef IDL CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-28 Core uses both "standard" and "system" exception terminology CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-27 create_policy specification needs to be completed CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-26 Need namespace for Policy Type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-40 Codebases with multiple URLs CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-39 Supporting multiple abstract interfaces CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-38 Names of Data*Stream methods CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-25 Scoping resolution for member names CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-24 Typo in POA CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-23 void * in DII Chapter CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-30 is_a underspecified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-29 Local operations on CORBA::Object CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-31 uses of recursive_tc CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-37 Custom Marshaling clarification CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-36 Missing minor code CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-33 Custom marshalling & AbstractBase CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-32 Sequences of recursive structs/unions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-35 POA SINGLE_THREAD_MODEL description ambiguous CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-34 POA threading policies CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-22 Exception for abstract interface inheritance CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-21 long double problem? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-6 Lifetime of ORB and validity of ORB pointe CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-5 Semantics of system exception completion_status CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-17 What does interface substitutability mean in CORBA? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-16 Which OBV initialiser to run is under-specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-12 Handling of minor codes for standard exceptions underspecified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-11 page 3-47: Identifiers CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-14 Missing equality for DynAny CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-13 set_servant_manager CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-10 Nested scopes CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-9 Multiple paths to a recursive sequence typecode CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-8 Change to IDL for anonymous types CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-7 DynStruct::get_members needs exception CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-20 Recursive exceptions? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-19 InconsistentTypeCode exception in CORBA 2.3 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-18 Recursive IDL types CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-15 DynUnion::member() CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-4 resolve_initial_references under-specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-3 Domain Manager related specification shortcoming (02)-ConstructionPolicy CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-2 Domain manager related specification shortcoming(s) (01) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-1 Operation to add to CORBA::ORB pseudo-object CORBA 2.2 CORBA 2.3 Resolved closed
CORBA22-133 marshalling service context CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-132 Alignment and offsets in the presence of fragmentation CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-131 Changes to and strategy for 1.2 CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-107 Type ids in OBJECT_FORWARD return message CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-111 Use of dynamic ports CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-110 CORBA::Object::non_existent CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-109 Correct IIOP marshalling of union TypeCodes CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-108 LOCATION_FORWARD byte alignment CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-140 Typos in PIDL to C++ mappings CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-139 Typo in C++ mapping CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-138 C mapping for list_initial_services is incorrect CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-137 Defintion of Any CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-136 Any extractor signature problem CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-135 Missing Any inserter CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-134 IIOP object pointer resetting CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-128 Additional enumeration to the ReplyStatusType CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-127 Additional Requirement for GIOP 1.2 CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-126 Clarification on IIOP2.1 12.3.2 fixed point type representation needed CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-130 Section 12.7.2 type IIOP::ProfileBody_1_0 not compatible CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-129 IIOP marshalling of empty strings CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-115 Problem with GIOP CancelRequest when fragments are used CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-114 Transport Level Bridge CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-119 IDL Type Extensions: wstring CDR encoding issue CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-118 IDL Type Extensions: wchar and wstring CDR encoding CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-123 1.0 backward compat (2) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-122 1.0 backward compat (1) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-113 IORs and identifying Object Keys CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-112 Callbacks in IIOP CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-121 Fragment improvements (2) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-120 Fragment improvements (1) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-117 Type extensions char code set negotiation CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-116 Type Extensions and code set negotiation CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-125 Issue with service context CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-124 CloseConnection messages CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-96 union typecode (02) CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-95 locally constrained CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-94 IDL types are ambiguous with inheritance CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-100 Question about typecode creation CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-99 #pragma processing CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-106 CORBA::Contained::describe() underspecified CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-98 Ambiguity in non_existent() specification CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-97 Appendix B lists incorrect CORBA Components IDs CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-103 Trader constraint language and international characters CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-102 defined_in member of ModuleDescription for top-level module CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-101 Inheritance of Exceptions CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-93 RIDs CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-92 Containers CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-105 Incorrect definition of "object type" CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-104 Resetting #pragma prefix? CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-91 Proposed IFR exceptions CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-90 TypedefDef issue CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-89 CORBA 2.1 IR Structdef typo CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-85 Issue with ObjectId_to_string and string_to_ObjectId CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-84 Bug in the 2.1.spec for IDL unions CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-83 Figure 2-2 in CORBA 2.0 and CORBA 2.1 CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-82 Octet and enum constants CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-81 Non ASCII alphabetics in IDL identifiers CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-80 Native types with respect to typecodes, DII, DSI,Interface Reposit. CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-79 TypeCode equality CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-88 Minor bug in 2.1 spec CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-87 Inheriting exceptions in IDL CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-86 Inclusion of standard exception CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-75 Syntax for basic types must be updated CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-74 create_exception() is declared outside any interface scope CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-73 TCKind enum should be updated CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-78 Do identifiers and keywords clash if they differ in case? CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-77 Section 3.7.2: take new IDL type extensions into account CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-76 Section 7.8: editorial CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-70 sec 17.7.1: IDL for interface request doesn"t match C++ mapping CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-69 Sequence parameter specified is ignored CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-68 request() should be added to IDL (section 17.13.2) CORBA 2.0 CORBA 2.2 Closed; No Change closed
CORBA22-67 Section 16.7: only C++ mapping defines string_free and string_dup CORBA 2.0 CORBA 2.2 Closed; No Change closed
CORBA22-72 No defined value for OBJECT_NIL CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-71 Section 7.2: get_implementation function CORBA 2.0 CORBA 2.2 Closed; No Change closed
CORBA22-64 "service"~~operation or interface? CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-63 What exactly is a request CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-61 Scope and use of prefix pragma in IDL-style repository IDs CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-60 Terminology consistency CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-52 6.6.4 Pragma Directives for RepositoryId Para 1 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-51 6.6.1 OMG IDL Format Paragraph 5 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-56 6.7.2 TypeCode Constants Last Paragraph - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-55 6.7.1 The Type Code Interface Paragraph 4 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-59 Enums and enumerators CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-58 Internationalization CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-54 6.7.1 The TypeCode Interface All Paragraphs - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-53 6.7 TypeCodes Paragraph 3 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-66 limited-length strings CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-65 Question about IDL grammar CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-57 CORE spec reference CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-62 inherit vs. include CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-50 6.5.22 InterfaceDef Paragraphs 7 and 8 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-49 6.5.22 InterfaceDef Paragraph 6 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-48 6.5.20 AttributeDef Paragraph 2 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-38 6.5.4 Container Paragraph 6 - editorial CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-37 6.5.4 Container Paragraph 5 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-36 6.5.4 Container Paragraph 2 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-35 6.5.3 Contained Paragraph 10 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-43 6.5.4 Container Paragraph 15 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-42 6.5.4 Container Paragraph 12 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-46 6.5.10 StructDef Last paragraph - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-45 6.5.8 ConstantDef Interface Paragraph 2 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-40 6.5.4 Container Paragraph 10 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-39 6.5.4 Container Paragraph 8 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-44 6.5.6 Repository Paragraph 4 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-47 6.5.11 UnionDef Last Paragraph - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-41 6.5.4 Container Paragraph 11 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-34 6.5.3 Contained - Paragraph 7 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-33 6.5.3 Contained Paragraph 2 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-32 6.5.2 IRObject Paragraph 3 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-22 4.6 Context Object Operations, Para 2 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-21 4.2.2 add_arg Paragraph 5-comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-24 4.6.2 set_on_value Paragraph 2 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-23 4.3.1 sen3 - comment 23 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-28 4.6.4 get_values Paragraph 5 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-27 4.6.4 get_values Paragraph 4 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-26 4.6.4 get_values Paragraph 2 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-25 4.6.3 set_values CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-18 4.1.1 Common Data Structures, Paragraph 6, comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-17 Interface for managing interceptors is missing CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-31 6.4.3 Interface Objects Paragraph 3 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-30 4.6.7 delete Paragraph 4 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-20 4.2.1 create_request Paragraph 8 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-19 4.1.3 Return Status and Exceptions CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-29 4.6.5 delete_values Paragraph 3 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-4 Do typecodes need literal constant representations in all mappings? CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-3 Missing info about the semantics of ORB_init and OA_init CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-14 Similar structure to IR::Identifier CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-13 Pseudo-IDL identifiers differ by case only CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-8 Typecodes for recursive sequences CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-7 lookup() questions CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-10 DSI and oneway operations CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-9 ServerRequest::op_def() CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-6 Interface Repository Error Handling CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-5 CORBA::InterfaceDef name collision CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-12 Apparent error in CORBA 2.0 Interoperability CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-11 Repository IDs CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-16 Portability and the #include directive CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-15 Recursive sequence TypeCodes CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-2 IFR: union elements associated with case labels CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-1 Inheritance of describe_contents() CORBA 1.2 CORBA 2.2 Resolved closed

Issues Descriptions

Ordering of user exception and return values

  • Legacy Issue Number: 16
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The COM/CORBA Part A spec states that user exceptions go after return values in one place, and before return values in another. (3.2.10.3 and 4.1.3.1)

  • Reported: CORBA 1.2 — Fri, 14 Jun 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Standard uuid for interfaces (COM/CORBA Part A)

  • Legacy Issue Number: 680
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: (D)IForeignComplexType,(D)ICORBAStruct,(D)ICORBAUnion,(D)IForeignException,(D)ICORBAUserException should have standard UUIDs and UUID identifiers

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

CORBA section 11 struct PortableGroup::GroupInfo

  • Legacy Issue Number: 12512
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Steve Osselton)
  • Summary:

    In chapter 11 'Unreliable Mulicast Inter-ORB Protocol' the struct PortableGroup::GroupInfo is discussed. However in the consolidated IDL and the IDL available from the OMG web site, this struct has been replaced by PortableGroup::TagGroupTaggedComponent. Which is correct?

  • Reported: CORBAe 1.0b1 — Tue, 27 May 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred Automatically

    This proposal was generated automatically.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

What should Automation View accept in bounded sequences?

  • Legacy Issue Number: 683
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When mapping bounded sequences, should the Automation View accept as an in-parameter a Safearray whose upper bound is less than the maximum lenght of the mapped sequence?

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred Automatically

    This proposal was generated automatically.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 4.1.12: DICORBA TypeCode::kind

  • Legacy Issue Number: 685
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 4.1.12: DICORBAtypeCode::kind has one parameter of type TCKind. It should be of type CORBATCKind

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Standard ProgramId

  • Legacy Issue Number: 684
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There should be a standard ProgramId for the class which exposes D(I)CORBAAny

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 4.1.18.5 enum should be named CORBA_CompletionStatus

  • Legacy Issue Number: 681
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The enum should be named CORBA_CompletionStatus instead of CORBA_ExceptionType

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

VB cannot handle array out-parameters

  • Legacy Issue Number: 682
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The VB cannt handle array out-parameters. Must use in-outs.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Add CORBATCKind to end of enum list

  • Legacy Issue Number: 687
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Enum CORBATCKind omits the boolean kind (p.4-123, section 4.1.12) I recommend adding it to the end of list to preserve backward compatibility. Also missing tk_char.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Return value type of DICORBATypeCode::member_type should be changed

  • Legacy Issue Number: 688
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The return value type should be DICORBATypeCode*, not IDispatch. The return value of member_label should be a DICORBAAny* rather than VARIANT

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

page 2-25 contradicts first sentence of 3rd full para on p 4-106

  • Legacy Issue Number: 690
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I suggest that the automation chapter be changed to align with the architecture chapter

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

uuid for DForeignException has an extra 0

  • Legacy Issue Number: 689
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The uuid for DForeignException has an extra 0. It should be E977F907-3B75-11cf-BBFC-444553540000

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Remove EX_repositoryID readonly property from IForeignException

  • Legacy Issue Number: 686
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This property should be removed because the INSTANCE_repositoryId property in IForeignComplexType provides this functionality

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

boundary violations should cause View to propagate DISP_E_OVERFLOW

  • Legacy Issue Number: 695
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When translating a BSTR to a CORBA bounded string, boundary violations should cause the View to propagate DISP_E_OVERFLOW

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

page 4-129, section 4.1.17: change term "CORBA proxy"

  • Legacy Issue Number: 697
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Second to last paragraph of the section contains the term "CORBA proxy" which should be changed to Automation View Interface.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

page 4-129, section 4.1.17.1: retval attribute

  • Legacy Issue Number: 696
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The "retval" attribute should be removed from the second argument in both methods. MIDL does not have a retval attribute

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

INSTANCE_Clone does not need an in-parameter

  • Legacy Issue Number: 698
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: INSTANCE_Clone does not need an in-parameter to specify the instance to be cloned.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

ODL is erroneous

  • Legacy Issue Number: 691
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: ODL which shows an extra, optional parameter for exception information on property-get or property-set method is erroneous, since MKTYPLIB doesn"t allow extra parameter on property accessor

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Page 2-41, section 2.9.7.2 Add name for Automation View interface

  • Legacy Issue Number: 692
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There should be a standard name for the Automation View interface.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

page 2-30: There is a label "Examples", but no examples

  • Legacy Issue Number: 693
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 2-30, top of page, end of section 2.7.1: There is a label "Examples:" but no example follows

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

page 4-109, section 4.1.5.3: editorial

  • Legacy Issue Number: 694
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: "..maximum value of an Automation short" should read "..maximum value of a CORBA::UShort

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

"Safe" keyword identifier issue

  • Legacy Issue Number: 1251
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Which TypeCode operations apply to Value and ValueBox?

  • Legacy Issue Number: 1140
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 5.5 Interface repository (02)

  • Legacy Issue Number: 1065
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Can Value type inherit from Value Box type?

  • Legacy Issue Number: 1252
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Can value type inherit from Value Box type

  • Legacy Issue Number: 1055
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Automation View should generate HRESULT DISP_E_TYPEMISMATCH

  • Legacy Issue Number: 700
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If number of dimensions of an input SAFEARRAY does not match the mapped CORBA type, the Automation View should generate the HRESULT DISP_E_TYPEMISMATCH

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 5.5 Interface repository (01)

  • Legacy Issue Number: 1064
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Dispatch versions of DCORBAObject and DORBObject

  • Legacy Issue Number: 699
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There should be straight dispatch versions of DCORBAObject and DORBObject

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

describe_value() operation issue

  • Legacy Issue Number: 1258
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Missing member_kind and member_tc

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

    Summary: Missing member_kind and member_tc

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

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

  • Legacy Issue Number: 1256
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

New lexical type - Keyword Identifie

  • Legacy Issue Number: 1253
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 5.3.3: can value inherit from a boxed value?

  • Legacy Issue Number: 1255
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Value type ansd Value Box"s single data member name

  • Legacy Issue Number: 1257
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Semantics of computing the hash code..

  • Legacy Issue Number: 1267
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Concrete value class

  • Legacy Issue Number: 1268
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 5.6.3 Hashing Algorythm

  • Legacy Issue Number: 1266
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Repository Id (02)

  • Legacy Issue Number: 1264
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 5.6.2 Repository Id

  • Legacy Issue Number: 1263
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Repository Id (03)

  • Legacy Issue Number: 1265
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Type code issue

  • Legacy Issue Number: 1261
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Clarify the hash code algorithm

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

    Summary: Clarify the hash code algorithm

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 7.3.10 Value Factories

  • Legacy Issue Number: 1273
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 7 C++ Language mapping

  • Legacy Issue Number: 1271
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Java mapping example and C++ mapping example

  • Legacy Issue Number: 1272
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Why is ValueBase a value and not a native type?

  • Legacy Issue Number: 1274
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 7.3.6 Reference Counting Mix-in Classes

  • Legacy Issue Number: 1270
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 7.3.5 ValueBase and Reference Counting

  • Legacy Issue Number: 1269
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

p 5-50 2nd paragraph of 5.6.2.1

  • Legacy Issue Number: 1283
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Editorial: p 5-50

  • Legacy Issue Number: 1282
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

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

  • Legacy Issue Number: 1280
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

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

  • Legacy Issue Number: 1275
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

p 5-24, first paragraph of 5.3.1.3

  • Legacy Issue Number: 1279
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Editorial page 8-107

  • Legacy Issue Number: 1277
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Keyword identifiers (01)

  • Legacy Issue Number: 1310
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Can public modifier be applied to value operations?

  • Legacy Issue Number: 1284
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Reconcile RMI/IIOP upcall and helper class

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

    Summary: Reconcile RMI/IIOP upcall and helper class

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

No portable way to obtain list of type safe repository IDs

  • Legacy Issue Number: 1352
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Keyword Identifiers(03)

  • Legacy Issue Number: 1312
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Keyword identifiers (04)

  • Legacy Issue Number: 1313
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Keyword identifiers (02)

  • Legacy Issue Number: 1311
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OBV "chunking"

  • Legacy Issue Number: 1522
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 1419
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Can "public" mofifier be applied to value operations?

  • Legacy Issue Number: 1421
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Typo on page 8-107 of OBV specification

  • Legacy Issue Number: 1420
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Narrowing from abstract interfaces

  • Legacy Issue Number: 1382
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 1380
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Marshaling engine issue

  • Legacy Issue Number: 1353
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OBV spec inefficient for dending large number of small objects

  • Legacy Issue Number: 1614
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Some explicit semantics seem to be missing in section5.8.6

  • Legacy Issue Number: 1615
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Forward declaration of value boxes

  • Legacy Issue Number: 1624
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

TypeCodes for values

  • Legacy Issue Number: 1625
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OBV C++ problem with "supports"

  • Legacy Issue Number: 1539
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

TypeCodes defined in section 5.8.2

  • Legacy Issue Number: 1527
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 1528
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CDR Streams

  • Legacy Issue Number: 1523
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

P 5-44: use of base type

  • Legacy Issue Number: 1697
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OBV TypeCode parameters wrong

  • Legacy Issue Number: 1676
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

No typecodes for abstract interfaces

  • Legacy Issue Number: 1719
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Abstract Interface issue (write_Abstract/read_Abstract)(01)

  • Legacy Issue Number: 1699
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Custom marshalling support for IDL fixed type

  • Legacy Issue Number: 1673
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Default constructor for Java values

  • Legacy Issue Number: 1654
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

C++ boxed value member clashes

  • Legacy Issue Number: 1674
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Boxed values need extension to write_Value call

  • Legacy Issue Number: 1650
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Status of hashed repository IDs

  • Legacy Issue Number: 1817
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

"Tool" issue for IDL compilers too complex

  • Legacy Issue Number: 1932
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

ValueHelper Interface issue

  • Legacy Issue Number: 1934
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

TypeCode complexity for value types

  • Legacy Issue Number: 1726
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Memory Management for Value Factories Unspecified

  • Legacy Issue Number: 1748
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OBV init

  • Legacy Issue Number: 1816
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeBase interface uses undefined type

  • Legacy Issue Number: 1771
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Issue for Firewall RTF - HTTP tunnelling.

  • Legacy Issue Number: 2455
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 3.3.4 and elsewhere

  • Legacy Issue Number: 2584
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Problem: There is a general problem on how to specify sending an empty
    Transaction PDU, such as an empty BEGIN, or an empty CONTINUE. "Empty"
    means just the Transaction portion without ROS components. This problem has
    to be addressed for sending an empty Transaction PDU from the CORBA side,
    as well as what to do when such a PDU is received from the legacy domain.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Title does not cover the use of SS7 as signaling transpor

  • Legacy Issue Number: 2583
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Problem: Title does not cover the use of SS7 as signaling transport. This case is
    not a TC interworking.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

passthrough connection

  • Legacy Issue Number: 2261
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

issue with TCPfirewallMechanism

  • Legacy Issue Number: 2304
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Issue for Firewall RTF - Chapter 5 needs clarification

  • Legacy Issue Number: 2240
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The values of these tags need to be assigned

  • Legacy Issue Number: 1996
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Minimum CORBA and POA

  • Legacy Issue Number: 2676
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Minimum CORBA submission describes exactly what should
    be present in minimum CORBA (basically CORBA 2.2 including
    the POA) in IDL/PIDL.

    However, the Java language mapping in CORBA 2.2
    does not include the POA -> just the APIs for registering
    transient objects.

    One cannot even take recourse to CORBA 2.3 to get the
    language mapping, since much stuff (OBV, Java to IDL etc.)
    was added in the intervening time. There does not seem to be
    any existing document which documents a Java language mapping
    of CORBA 2.2 including POA without lots of other stuff.

  • Reported: CORBA 2.3 — Mon, 31 May 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 4.2.1

  • Legacy Issue Number: 2591
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Problem: It is not necessary to have uniqueness of Invoke Ids within a dialog.
    The invoke id can be reused as soon as it is no longer active.

    Proposed solution: Put in text following the discussion of management of invoke
    ids in the TC spec.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Sec.: 3.5.1.1, item 4 plus appropriate section of interaction translation

  • Legacy Issue Number: 2586
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 3.5.1.1, item 4 plus appropriate section of interaction translation

    Problem: How to handle the sending of an empty RESULT and the reception of
    such a component.

    Proposed solution: Obviously no way to change the IDL from void. Need
    something in the TC Repository for use by a gateway in deciding what to do.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 3.5.1.1, item 3

  • Legacy Issue Number: 2588
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: 5

    Section number: 3.5.1.1, item 3

    Problem: We have mistakenly associated TcLinkedContext with the operation
    which has the LINKED keyword rather than the actual linked operation, i.e., the
    operations appearing following the LINKED keyword

  • Reported: CORBA 2.3 — Mon, 12 Apr 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How can we bound the range of invoke ids in the IDL?

  • Legacy Issue Number: 2589
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.2.1

    Problem: How can we bound the range of invoke ids in the IDL? Q773 requires
    invoke ids in the range -128 to 127. ROS has no limits.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

It should be possible to have negative invoke ids

  • Legacy Issue Number: 2590
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It should be possible to have negative invoke ids.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 3.3.4 make factory creation operations conform to the IDL

  • Legacy Issue Number: 2585
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Problem: make factory creation operations conform to the IDL style guide

    Proposed solution: change the capitalization and put in underscores between
    words

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 4.3.2.1 Title and text should be changed

  • Legacy Issue Number: 2595
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.3.1.2

    Problem: Title and text should be changed to reflect that it is dealing with creating
    an association rather than initiating a dialog.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 4.7.1: RelativeRoundTripPolicy

  • Legacy Issue Number: 2596
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.7.1

    Problem: Is it necessary to indicate that RelativeRoundTripPolicy is not
    propogated to the server? Also does TC interworking require the support of the
    priority policies?

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Problem: Why is AssociationId a string?

  • Legacy Issue Number: 2592
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.2.1

    Problem: Why is AssociationId a string? Should one explore the possibility of
    using a combination of values supplied by both the initator and responder.
    Strings do not seem to be the most scalable solution.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

There is a difference between the responder and initiator interfaces

  • Legacy Issue Number: 2594
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.2.2

    Problem: There is a difference between the responder and initiator interfaces
    because the initator cannot support the new association operations.

  • Reported: CORBA 2.3 — Mon, 12 Apr 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The current text for DialogFlowCtr is for outgoing only

  • Legacy Issue Number: 2593
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.2.1

    Problem: The current text for DialogFlowCtr is for outgoing only. It should be
    updated to reflect incoming messages from the legacy domain.

  • Reported: CORBA 2.3 — Mon, 12 Apr 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 5.4.1

  • Legacy Issue Number: 2599
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 5.4.1

    Problem: DialogPortion should be a union rather than a struct. The complete IDL
    is correct.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

ShouldnÂ’t it be typedef string CORBA::ScopedName?

  • Legacy Issue Number: 2600
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 7.1, page 108

    Problem: Shouldn’t it be typedef string CORBA::ScopedName?

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: Fig. 27

  • Legacy Issue Number: 2601
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: Fig. 27

    Problem: Shouldn’t GwTcPduHandler be replaced by GwTcPduProvider?

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

ShouldnÂ’t this section really be called TC Service Interface?

  • Legacy Issue Number: 2597
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 5

    Problem: Shouldn’t this section really be called TC Service Interface because it
    really provides an IDL version of Q.771? Note that this requires changing the
    names of various interfaces by removing the word Pdu, which should be
    reasonably simple.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 5.2 and other sub-sections

  • Legacy Issue Number: 2598
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 5.2 and other sub-sections

    Problem: The encapsulation BerData could potentially hold ASN.1 encoded via
    other rules like PER. So is this name misleading, or too restrictive?

    Proposed solution: One choice is EncodedData.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bi-Directional GIOP: which connections may be used?

  • Legacy Issue Number: 2633
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In ptc/98-10-11 15.8 from the end of the fourth paragraph "any
    requests from the server on an objects exported by the client to the
    server via this connection will be sent back to the client on this
    same connection." to the eleventh paragraph "If the client initiates a
    new connection it is not foreseen here that the server can use that
    connection for requests on the object exported previously." it seems
    to be implied that a reference must be passed via a connection if that
    connection is to be used to invoke the referenced object with
    Bi-Directional GIOP.

  • Reported: CORBA 2.3 — Wed, 5 May 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 2.3

  • Legacy Issue Number: 2607
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Problem: Use UML to express relationship of interfaces.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Should SIOP version number start with 1.2?

  • Legacy Issue Number: 2603
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 6.1

    Problem: Should SIOP version number start with 1.2?

    Proposed solution:

    Rationale: This would allow a quick recognition of the highest GIOP version supported by
    this version of SIOP.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Problem: There is no way to send dialogue data in a continue confirm.

  • Legacy Issue Number: 2605
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 5.4.4

    Problem: There is no way to send dialogue data in a continue confirm.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 6.2.2

  • Legacy Issue Number: 2604
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 6.2.2

    Problem: sccp_version should be changed to SIOP_version. Also the word
    "agent" should be changed to "server."

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 5

  • Legacy Issue Number: 2606
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 5

    Problem: There is no way to associate more than one instance of a TcPduUser
    with a GT/AC pair for incoming SS7 messages.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Could SIOP be changed to 7IOP, pronounced "seven-up"?

  • Legacy Issue Number: 2602
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 6

    Problem: Could SIOP be changed to 7IOP, pronounced "seven-up"?

    Proposed solution:

    Rationale: The S in SIOP may be mistaken for Security.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall POA Policy does not control access

  • Legacy Issue Number: 2639
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In orbos/98-07-03 4.9 it says "However, it is desirable to provide a
    portable means by which the object implementor can decide whether an
    object could be accessible through a firewall. The following POA
    policy is defined for this purpose:" but this policy can at most
    control what components are included in references created by the
    POA. Since the references do not have any mechanism to defend against
    forgery, exclusion of a FirewallMechanism component does not prevent
    access through a firewall. If an attacker obtains some other reference
    with the FirewallMechanism component(s), it can convert a reference
    created under NO_EXPORT into the reference that would have been
    created under EXPORT.

    The description of the policy needs to be changed to make it clear
    that the policy does not imply any access control enforcement. The
    ability of an attacker to forge references, either by combining parts
    of other references, or otherwise, should be explicitly stated as a
    security issue that must be addressed by means outside this
    specification.

  • Reported: CORBA 2.3 — Thu, 6 May 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

new_target

  • Legacy Issue Number: 2648
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 4.7.4 - description of new_target operation.

    The first para states:

    "The new_target operation informs the firewall that it should prepare itself
    to
    receive requests destined for the specified target. The object returned
    from this
    operation is the destination on the firewall to which a request on the
    target should be
    sent i.e. the object_key in the return object should be used in the GIOP
    request header."

    and the last para says:

    "The object returned by the new_target operation must contain an object key
    which
    allows the proxy to uniquely identify the target. A client is not required
    to open a new
    connection to the proxy server, even when the target object(s) are located
    in different
    servers."

    The last sentence implies that the IOR returned from the new_target has the
    same host/port number as the GIOPProxy. This may not be true. For example if
    a firewall is load balancing across ports and network interfaces, the
    host/ports may be differnt, and in this situation a new connection is
    required.

  • Reported: CORBA 2.3 — Mon, 10 May 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

new_callback

  • Legacy Issue Number: 2651
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OMG document orbos/98-07-03, section 4.7.4 under new_callback page 4-16,
    the first paragraph reads

    When the client side object adapter creates the object reference for the
    callback object, it may invoke the
    new_callback operation on the outermost inbound GIOP Proxy on the server
    side and pass the callback object as the argument.

    Say, there are no client-side firewalls and there is only one
    server-side GIOPproxy firewall.

    1. how does the object adapter or the client orb get access to the IOR
    of the GIOPProxy object ???
    2. how does the object adpater know that the object that is being
    created/instantiated will be used as a callback
    object ??

    Does POA provide any m

  • Reported: CORBA 2.3 — Thu, 13 May 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall Traversal algorithm

  • Legacy Issue Number: 2641
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The description of firewall traversal in orbos/98-07-03 4.11 has some
    significant unstated assumptions, and prescribes an algorithm that has
    several flaws.

    In orbos/98-07-03 4.11 it says: "A client will determine if it needs
    to go through a firewall to make a request on the target object. If
    the client is in the same domain a direct invocation can be made. The
    client can determine this be examining the host address information in
    the target IOR." This assumes that the enclave structure maps to host
    addresses in some way known to all clients. This needs to be made more
    explicit.

  • Reported: CORBA 2.3 — Fri, 7 May 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bi-Directional GIOP: Masquerade security issue needs to be more explicit

  • Legacy Issue Number: 2634
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The remark about masquerade at the end of ptc/98-10-11 15.8 is not
    explicit enough. This is an important security issue and it needs to
    be made explicit that a malicious client may claim that its connection
    is Bi-Directional for use with any host and port it chooses, in particular
    it may specifiy the host and port of security sensitive objects.

    In general, a server that has accepted an incoming connection has no
    way to discover the identity or verify the integrity of the client
    that initiated the connection.

  • Reported: CORBA 2.3 — Wed, 5 May 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Outgoing local port in Bi-directional IIOP

  • Legacy Issue Number: 2638
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In ptc/98-10-11 5.8.1 it says "If a client has not set up any mechanism for
    traditional-style callbacks using a listening socket, then the port entry
    in its IOR must be set to the outgoing connection"s local port (as
    retrieved using the getsockname() sockets API call)". At IOR creation time
    there may be no connection, or there may be many, so the mandated local
    port may be non-existent or ambiguous.

    This topic was discussed on the firewall-rtf list during Feb-Mar 1999 but
    was not raised as an issue.

  • Reported: CORBA 2.3 — Thu, 6 May 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Proxified object references

  • Legacy Issue Number: 2865
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Proxified object references obtained by invoking
    new_target() should not be passed between ORBs. Instead the original IOR
    containing the target and firewall information should be passed. The reason
    for this is that the IOR does not contain enough information to inform the
    second ORB whether or not it is a reference for a NORMAL or PASSTHRU
    connection, or whether it is a proxified reference at all. This issue is
    very tightly related to issue 2, so we will describe how it fails for each
    of the possible solutions to the PASSTHRU establishment problem outlined in
    issue 2.
    One solution for which this is not an issue is the solution
    of using a port per target. However, this is not a viable solution because
    it is restrictive and will fail under moderate load. For solution 1 we
    don"t have a problem because no object reference is returned by
    set_target(), therefore it cannot be passed to other ORBs. For solution 2
    we have a problem because the second ORB won"t know whether it is supposed
    to first invoke start_passthru() or simply start making requests. Therefore
    it may get a connection type that it wasn"t expecting. For solution 3 we
    have a problem because once the original connection has been made, the
    reference is invalid. This occurs because the firewall does not have
    knowledge of how many clients are expected to try to connect to that target,
    and it may attempt to claim that port for reuse before another client has
    connected.

    Proposed Solution:
    The passing of object references obtained by invoking
    new_target() should be expressly prohibited by the specification. One
    example is, "The object reference returned by new_target() may not be passed
    to another client. Instead the original reference that was passed as the
    argument to new_target() must be passed to the second client, and the second
    client will follow the rules of the traversal algorithm to reach the desired
    target."

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Clarification is needed on the passing of credentials

  • Legacy Issue Number: 2867
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Description:
    Clarification is needed on the passing of credentials.
    Section 4.7.3 states that "Since all proxies will have access to the IOR of
    the target object, and the certificate of the client, they can judge whether
    this client may use a pass-through connection or not." Section 4.12 states
    that "When a client establishes a normal connection to a target via a
    trusted proxy and uses a secure transport (e.g. IIOP/SSL), in order to
    achieve end-to-end authentication, the proxy will have to forward the
    client"s certificate/identity to the server." Section 4.12 implies that the
    ForwardedIdentity service context will only be used when using a secure
    transport, but section 4.7.3 implies that the client certificate will always
    be available. In fact, the ForwardedIdentity service context should only be
    used in the case of a NORMAL connection using a secure transport because
    those are the only conditions under which there is a notion of trust between
    a requestor and the recipient of that request. This means that the only
    mechanism upon which to base a decision of whether or not to allow a
    PASSTHRU connection is the source host address/port.

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Reusing PASSTHRU

  • Legacy Issue Number: 2866
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Description:
    Reusing PASSTHRU connections by the firewall should be
    expressly disallowed by the specification. With the current wording of the
    specification, a vendor may attempt to reuse PASSTHRU connections. While
    this will work in some cases, it is not interoperable because there are
    cases when reusing PASSTHRU connections will not work. For example,
    connection reuse when SSL is in use will not work because all of the
    information that distinguishes data streams is contained within the
    encrypted portion of SSL packets. If two SSL connections try to share a
    single connection, there will be an SSL protocol failure because the server
    will not be able to separate the data streams before it processes the SSL
    packet.

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How to obtain initial reference to the GIOPProxy object

  • Legacy Issue Number: 2864
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Description:
    The specification does not outline a specific method by
    which to obtain the initial reference to the GIOPProxy object. We believe
    that an interoperable solution for obtaining this initial reference is
    needed in order to insure that all implementations will be able to be
    correctly configured to contact all other implementations.

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

TcPdu User and Provider interfaces

  • Legacy Issue Number: 2919
  • Status: closed  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    As the interfaces currently stand, there is a minimum of 5 CORBA calls
    per transaction
    1. either TcPduProvider::get_dialog_id
    or TcPduProviderFactory::create_tc_pdu_provider
    2. TcPduProvider::invoke_req
    3. TcPduProvider::begin_req
    4. TcPduUser::end_ind
    5. TcPduUser::result_l_ind

    Given that a CORBA call is about 1 millisecond on average,
    this makes for a highly inefficient interface from a high-performance
    perspective,
    and renders the distribution of these interfaces undesirable, and the
    use of the TcPduProvider/User interfaces unlikely in a real system.

    Ideally this should be reduced to a minimum of 2 CORBA calls, one for a call
    going out, and one for the reply.

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Why one to one association between a TcPduUser and TcPduProvider interface?

  • Legacy Issue Number: 2917
  • Status: closed  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    There is an assumption in the design that there is a one to one
    association between a TcPduUser and a TcPduProvider
    during a TC Session. This is enforced in the IDL through the
    call

    TcPduProvider::get_dialog_id()

    and the factory call

    TcPduProvider create_tc_pdu_provider(
    in TcPduUser user,
    out DialogId d_id)
    raises(NoMoreDialogs);

    Since the TcPduUser reference (or some sort of reference)
    is not passed over in get_dialog_id(), the only conclusion
    is that the reference has to be the one passed over in the
    create, and therefore that each TcPduProvider is tied to
    one and only one TcPduUser.

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Specification Translation from ASN to IDL issue

  • Legacy Issue Number: 2918
  • Status: closed  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    The Specification Translation from ASN to IDL does not appear to
    require that each OPERATION carries a NoMoreAssociations exception.

    This is necessary if the use of DialogFlowCtr can implicitly create a new
    association during a call on an object that supports multiple associations.

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Traversal algorithm not sufficient

  • Legacy Issue Number: 2869
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Description:
    There may be some network topologies where the traversal
    algorithm is not sufficient for a firewall to find a server. This is due to
    an unstated assumption that all addresses within the outermost inbound
    firewall are addressable from the outermost inbound firewall. Consider for
    example the following topology:

    -----*Firewall
    B*-----Network B
    Internet -----Firewall A---------
    -----*Firewall
    C*-----Network C

    Service Network (DMZ)

    Assume that the addresses on the service network are
    globally routable addresses, Network B uses RFC 1597 addresses and Network C
    uses RFC 1597 addresses. This topology could be possible, say for a
    government agency that has sub-agencies that share some resources (service
    network) but maintain separately administrated networks. In this case the
    outermost inbound firewall for a server on Network B or C is Firewall A.
    However, when new target is invoked on Firewall A, it won"t know from the
    host address whether to open a connection to Firewall B or Firewall C.

    Proposed Solution:
    There are several possible solutions to this problem:
    1) Explicitly state the assumption described in the
    description section
    2) Mandate that implementations allow for the
    configuration of the next inbound firewalls
    3) Mandate that servers on Network B or C in such
    configurations use Firewall B or C as the outermost inbound firewall.

    There may be other solutions to this problem. These were
    the ones that immediately presented themselves.

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Problems with routing and/or traversal of firewalls.

  • Legacy Issue Number: 2868
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issues 7-9 refer to problems with routing and/or traversal of firewalls.
    These problems arise due to a lack of required information about firewall
    topology in the IOR. Most of these problems could be eliminated if it were
    required that the servers place the entire chain of server-side firewalls
    that must be traversed into the IOR. Specifically, the first paragraph in
    section 4.8 should be modified so that the entire chain of firewalls is
    always required, or those situations in which it should be required should
    be stated. Some of those situations are outlined in the following issues.
    Specifically, it is incorrect to state that "strictly it is only necessary
    to convey information on the outermost inbound firewall."

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

When does a multiassociation TcUse know that it has been finished with?

  • Legacy Issue Number: 2916
  • Status: closed  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    The creation of a TcUser interface with multiple associations does not have
    a standardised way for destruction.

    Proposed solutions

    1. Add a destroy() method to TcUser
    2. Explicitly state in the RFP that the CosLifeCycle::destroy() method should
    be called once the object is no longer required.

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Use of InvokeId as the type name for both invoke id and link id.

  • Legacy Issue Number: 2915
  • Status: closed  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    The idl is

    struct TcLinkedContext

    { DialogFlowCtr ctr; InvokeId ivk_id; InvokeId lnk_id; AssociationId a_id; }

    ;

    While it is correct that these are both of the same type, the name of the type
    could be confusing.

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

BiDir GIOP Policy Clarification

  • Legacy Issue Number: 4115
  • Status: closed  
  • Source: Network Associates ( Brian Niebuhr)
  • Summary:

    I am a little confused as to the scope of the BiDirPolicy in the 2.4.1
    specification. Is the BiDirPolicy a POA policy, an ORB policy, or both? In
    section 15.8 paragraph 5 on page 15-55, the specification states:

    "If the client ORB policy permits bi-directional use
    of a connection, a Request message should contain an IOP::ServiceContext
    structure in its Request header, which indicates that this GIOP connection
    is bi-directional."

    but then in section 15.9 paragraph 4 on page 15-59, the specification
    states:

    "In the absence of a BidirectionalPolicy being passed in the
    PortableServer::POA::create_POA operation, a POA will assume a policy value
    of
    NORMAL."

    but then again in the next sentence the specification states:

    "A client and a server ORB must each have a BidirectionalPolicy with a value
    of
    BOTH for bi-directional communication to take place."

    Could someone clarify for me what the intent for the scope of the policy was
    here, and what the rationale behind that decision was? We are currently
    reviewing how to use/fix BiDirIIOP in our submission to the firewall RFP,
    and I would like to understand the issues regarding the scope of the BiDir
    policy.

  • Reported: CORBA 2.4.1 — Tue, 19 Dec 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Use of PolicyType id

  • Legacy Issue Number: 3363
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    While editing the changes from the Firewall RTF into Core Chapter 15 I noticed a
    curious thing in the Firewall RTF report. It seems that the RTF chose to re-use
    a PolicyType id for a new and different policy while obsoleting a published one.
    The PolicyType Id in question is 37, which used to be BIDIRECTIONAL_POLICY_TYPE
    associated with the structure BiDirPolicy::BidirectionalPolicy

    and is now proposed to be BIDIRECTIONAL_INVOKE_POLICY associated with structure
    BiDirPolicy::InvokeMode.

    This appears to me to be a dangerous practice, since the fact that the published
    standard may have been implemented by someone using the obsolete definition.

    I would like to suggest that the recommendation of the Firewall RTF be modified
    leaving the published policy type and policy as is with a note stating that it
    is obsolete, and a new policy type id be allocated for
    BIDIRECTIONAL_INVOKE_POLICY.

  • Reported: CORBA 2.3.1 — Fri, 25 Feb 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Allow GIOP 1.3 messages to be transported.

  • Legacy Issue Number: 3184
  • Status: closed  
  • Source: Siemens AG ( Nils Fischbeck)
  • Summary:

    Align SIOP definition with GIOP 1.3 of CORBA2.3.1.

    Problem: SIOP is currently defined to carry GIOP messages with version 1.2
    and lower.

    Proposed Solution: Allow GIOP 1.3 messages to be transported.

  • Reported: CORBA 2.3.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Missing definition on security tags in the SIOP

  • Legacy Issue Number: 3314
  • Status: closed  
  • Source: Dublin City University ( Robert Brennan)
  • Summary:

    There are security tags mentioned in the SIOP
    document but no definition of how to use them is ever given.

  • Reported: CORBA 2.3.1 — Thu, 10 Feb 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

There is currently no valuetype support in SIOP.

  • Legacy Issue Number: 3313
  • Status: closed  
  • Source: Dublin City University ( Robert Brennan)
  • Summary:
  • Reported: CORBA 2.3.1 — Thu, 10 Feb 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

use of the SSN number in the 1988 TCAP version

  • Legacy Issue Number: 2982
  • Status: closed  
  • Source: Anonymous
  • Summary:

    As far as I can see when using the 1988 TCAP version the submission
    does not seems to handle the case where the subsystem number (SSN) is
    used to seperate between several TC-User protcols per GT (typically
    protocols from different vendors). The naming tree proposed for the
    1988 TCAP protocol can only store one TC-User protocol per GT, that is
    only one DefAc per GT can be stored (see section 4.3.1.1 in the
    proposal).

    The use of the SSN number for this purpose is explained in chapter
    4.2.3 in the second paragraph in the ITU Recommendation Q.775.

    It should be easy to fix this as one only have to use the same naming
    tree structure proposed for the 1993 TCAP version in these cases.

  • Reported: CORBA 2.3.1 — Mon, 8 Nov 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Discrepancy in the changes proposed to CSIIOP and CSI modules

  • Legacy Issue Number: 7167
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    There seems to be a discrepancy in the changes proposed to CSIIOP and CSI modules. The draft document has identical changes to both. I think the intent of the Errata was to have only one, just switch them from CSIIOP to CSI. However, Brian's convience document doesn't show the change. Now, the draft document ptc/2004-01-01 that we are voting on has both. What to do? Should that be represented by another document, namely CSI, with it's changes, just like 2004-01-02 is? Cheers, -Polar

    Yeah, I see the problem. Yet another consequence of the adopted spec changing existing spec without calling out the change in the section meant to identify changes to existing specs. So it looks like the fix involves: 1. Section 1.9.2 and 1.9.3 in ptc/04-01-01 [henceforth referred to as document A] should disappear. 2. The first half of section of document A starting from the second para of the section and upto and including the last but one paragraph on page 1-20, should be appended to Section 24.2.5 "Identity Token Format" of Chapter 24 of Core with the title (that is the CSIv2 Chapter)[henceforth referred to as document B]. Also append a row to table 24-2 with info about ITTCompundToken. 3. The IDL in section 1.9.3 of document A should be merged properly into the IDL for the CSI module that appears in section 24.9.2 document B. 4. The addition to CSIIOP IDL as it appears in Section 1.5.2 of document A should be merged appropriately into the IDL for CSIIOP in section 24.9.3 of document B. 5. In document B insert a section 24.5.1.6 "TAG_IIOP_SEC_TRANS" with a two liner explanation of what this tag is together with the IDL for it from section 1.5.2 of document A. I'd suggest that we file this as an issue and resolve it in the FTF roughly along the lines suggested above.

  • Reported: CORBA 2.5 — Fri, 19 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

GIOP version 2.0 issue

  • Legacy Issue Number: 7168
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    The following paragraph raises an interesting issue. If we follow this to the letter

    • since it says that the new version of GIOP is not backward compatible with the
      earlier versions of GIOP, it implicitly appears to make this new GIOP version a
      new "major" version of GIOP. Clearly we need to figure out a way to avoid doing
      this, since creating GIOP version 2.0 in this way raises all sorts of other issues.

    From the second paragraph on page 1-30 of the Firewall Final Adopted Spec (ptc/04-04-01):

    This document supercedes the previously adopted CORBA firewall specification. In
    addition, the changes to bi-directional GIOP, specified in Chapter 15, supercede the
    adopted specification for bi-directional GIOP. These specifications are not backwards
    compatible with the previous specifications and they are intended to make it possible
    to create a functional protocol for the interoperation of ORBs and firewalls.

  • Reported: CORBA 2.5 — Fri, 19 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bidirectional Policy insufficient for persistent objects

  • Legacy Issue Number: 6313
  • Status: closed  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    The BidirectionalPolicy insufficient for persistent objects.

    The BidirectinoalExport Policy is a POA policy and it only has two values
    of ALLOW and DENY. If it is ALLOW, then a TAG_BI_DIR_GIOP componenet
    should be placed in the IOR. It is stated that the ORB must generate a
    random identifier when the POA is created. However, that will not work for
    persistent objects in which the BiDirectional Offer must remain constant.

    Also, there is no default specified if this policy is not placed on a POA,
    and no default for the RootPOA.

  • Reported: CORBA 2.5 — Thu, 9 Oct 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Server Authentication

  • Legacy Issue Number: 6312
  • Status: closed  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    As I understood it, the Firewall Traversal specification was to use new
    CSIv2 Compound Identity types to give the target server the complex
    principal composed of the client and the authenticating firewall traversal
    path. The server was to be authenticated to the client in much the same
    way. This functionality appears to be missing in the specification. It is
    easily fixed by returning a CSIv2 IdentityTokenSeq from a successful
    firewall negotiation, specifying the backwards firewall authentication
    trail from the server to the client.

  • Reported: CORBA 2.5 — Tue, 7 Oct 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

MAIN_THREAD_MODEL questions

  • Legacy Issue Number: 4155
  • Status: closed  
  • Source: Borland Software Corporation ( Andy Cutright)
  • Summary:

    i have a few questions about the POA ThreadPolicy type
    MAIN_THREAD_MODEL.

    first, the 2.4.1 spec (00-11-03), sec 4.2.3.2 , 'perform_work' states,
    "If called by the main thread, this operation performs an
    implementation-defined unit of work; otherwise it does nothing."

    how is a distinguished main thread supposed to be reliably determined?
    i'm not sure we really need to define this. i'd think what we're trying
    to say is that the thread that calls perform_work() is the thread that
    will be used to do the work, and it is up to the application to make
    sure this happens. in section 4.2.3.3, the spec states,
    "For maximum portability an application should call either run or
    perform_work on its main thread."

    to me it seems the intent is to let the application determine what the
    'main thread' is.

    second, what happens if an application calls both run & perform_work?
    and what happens if the application calls run from multiple threads? it
    isn't really clear what the difference in request handling with regard
    to the thread used is between run() & perform_work().

    right now the spec seems to imply through the use of the message loop
    example in section 4.2.3.2 that perform_work is really intended to be
    used to handle situations where a single thread must be used for all
    application activity. now add to that the note on pg 11-12 about using
    the main thread model:
    "Note - Not all environments have such a special requirement. If
    not, while requests will be processessed sequentially, they may not all
    be processed on the same thread."

    my interpretation is that ORB::run would be used in cases where you
    simply want the POAs to be accessed sequentially, but the application
    doesn't care about which thread the implementation uses, but you would
    need to call perform_work to specifically hand the application defined
    main thread to process requests.

    my suggestion (finally ;^) is that we should state perform_work should
    be called, on whichever thread the application likes, if it wants to
    hand a specific thread to the ORB to do work. otherwise, calling
    ORB::run from any thread simply means the implementation is free to
    handle requests for servants associated with main thread model POAs on
    whatever thread the implementation may choose (including a new one), in
    keeping
    with the requirement that the requests be processed on each POA's
    servants sequentially..

    one more question: does it make sense to state that a callback type of
    architecture won't work when using this threading model?

  • Reported: CORBA 2.4.1 — Wed, 17 Jan 2001 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Negotiate Session Message Orientation

  • Legacy Issue Number: 6284
  • Status: closed  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    The NegotiateSession message is a single typed GIOP message that is sent
    between both Client and Server to negotiation service contexts, and
    further to initiate and negotiate bidirectional GIOP.

    Having a single message is problematic in that a connection, once
    negotiated bidirectional may have different requirements for such things
    like Codesets, etc. Getting a NegotiateSession message after a
    bidrectional set up, the endpoints will have difficulty discerning the
    orientation of the NegotiateSession message.

    At the very least NegotateSession messages should have an orientation,
    much like the GIOP Request and Reply messages do.

    I'm not so sure they must be correlated with a "request id", but different
    message types would help. I would suggest two messages,
    NegotiateSessionRequest and NegotiateSessionReply to maintain the
    client-server orientation, respectively.

  • Reported: CORBA 2.5 — Thu, 2 Oct 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Negotiation Session message is unwieldy

  • Legacy Issue Number: 6311
  • Status: closed  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    The Negotiate Session message is unwieldy in that if it is used to send
    service contexts, there are no general ways to govern its use other than
    by special rules, all of which special cases are not accounted for in the
    specification.

    For example, when do you sent Bidirectional service contexts as ooposed to
    firewall contexts? Can you send transaction contexts? Codesets? Codebase?
    CSIv2? Can you send BiDir service contexts while firewall contexts are
    being processed?

  • Reported: CORBA 2.5 — Tue, 7 Oct 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Implications about BiDirIds

  • Legacy Issue Number: 7225
  • Status: closed  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    I'll use the following example to explain the implications that I derive from my understanding about the spec. I hope that it makes sense to you. If I'm wrong, please let me know.

    Suppose I set up a client that has some POAs with BI_DIR_EXPORT policy ALLOW. The client wants to invoke a server that accepts bi-directional GIOP. This invocation will cause callbacks to a few objects on the client using bi-directional GIOP. The server is not allowed to create new connections to the client.

    In the code of my client application, I can simply use the following statement to invoke the target object. And I would expect that the target object will call back some of the objects on the client ORB during this invocation.

    obj = ...; // target
    obj.invoke_target(...);

    In order for the above scenario to work, I derive the following implications from the spec.

    1. This invocation requires the target to call back on some of the objects on the client ORB. Because the client ORB has no knowledge about what objects might be called back, the client ORB has to ensure that the BiDirIds on all of its POAs that have EXPORT policy ALLOW must be available at the server side.

    This conclusion also implies that the client ORB may have to track what BiDirIds that have been sent (and accepted) over every connection that allows bi-directional GIOP in order to figure out what BiDirIds have not yet been sent, assuming that you don't want to send all BiDirIds in every request. Furthermore, when someone creates a new POA with the EXPORT policy ALLOW later on the client ORB, the next new invocation on each bi-directional connection will also have to transmit the BiDirId for this new POA to the server side.

    2. When the server receives a GIOP Request with BI_DIR_GIOP_OFFER service context, the server cannot dispatch the request to the target object implementation until this connection becomes bi-directional. Why? If the server dispatches the request before this connection becomes bi-directional, this request may fail because the target is not able to call back objects on the client ORB. In the case of Strong BiDirIds, the server may even have to send CHALLENGE and wait for RESPONSE before the server can dispatch the request.

    If we put both implications together in the case of Strong BiDirIds, when someone creates a new POA with EXPORT policy ALLOW on a client ORB, a longer delay will be expected in the next request on every bi-directional connection because the server has to verify the BiDirId of this new POA no matter whether this new BiDirId will be used for callbacks on that connection or not. To me this overhead is not acceptable if it is the only way to implement bi-directional GIOP according to the spec. I hope the spec can be written in a way that allows efficient implementation, though efficiency is not always a concern for everyone.

  • Reported: CORBA 2.5 — Thu, 8 Apr 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

paragraph limits use of BiDirOfferContext

  • Legacy Issue Number: 7224
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The second paragraph on page 15-60 of the revised GIOP chapter only allows a BiDirOfferContext to be sent to a server if the ORB-level policy permits it:

    "If the client ORB policy permits bi-directional use of a connection, a Request or
    NegotiateSession (see MARS/04-01-01) message can be sent to the server that
    contains a BI_DIR_GIOP_OFFER IOP::ServiceContext structure in the header that
    indicates that this GIOP connection is bi-directional. The BiDirOfferContext
    indicates to the server that the objects with the supplied BiDirIds are available for
    invocation over that connection. To determine whether an ORB may support bidirectional
    GIOP, the BidirectionalOfferPolicy has been defined (see Section 15.9,
    "Bi-directional GIOP policy," on page 65)."

    This, however, contradicts the rest of the document, which allows the ORB-level policy to be overriden at the object level. ("A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden
    for specific object references received by the client ORB." - Section 15-9, page 15-66).

    Additionally, the first sentence of the above paragraph is worded in such a way that it defines a connection as bidirectional before it has accepted as such by a server.

    Finally, a spurious reference to the submission document is included in the first sentence ("see MARS/04-01-01").

    RECOMMENDATION:
    Rephrase the paragraph as follows:

    If the effective BidirectionalOfferPolicy of an object in the client is set to ALLOW, a Request or NegotiateSession message that contains a BI_DIR_GIOP_OFFER IOP::ServiceContext structure in the header can be sent to the server, offering bi-directional use of the connection. The BiDirOfferContext indicates to the server that the objects with the supplied BiDirIds are available for invocation over that connection. To determine if bidirectional GIOP may be supported, the BidirectionalOfferPolicy has been defined (see Section 15.9, "Bi-directional GIOP policy," on page 65).

  • Reported: CORBA 2.5 — Tue, 6 Apr 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Negotiate Session Message Issues

  • Legacy Issue Number: 7202
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    If a service context negotiation fails by way of the NegotiateSession
    message in either direction. how does the sender (client or servers side)
    get an indication back to the sender?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet issue (05)

  • Legacy Issue Number: 7201
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Does Codeset come before/with/after BiDir negotiation?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet issue (02)

  • Legacy Issue Number: 7198
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Does Codeset get negotiated in only the other direction?
    If so, will that happen in Negotiate Session meesages orRequest Messages?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet issue (03)

  • Legacy Issue Number: 7199
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    On a connection in which BiDir is negotiated, but no Codeset
    is negotiated, will the reverse direction be able to negotiate
    code set?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet issue (01)

  • Legacy Issue Number: 7197
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Does the CodeSet get negotiated in Negotiate Session?
    If so, does Codeset continue to get negotiated in Requests?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet issue (04)

  • Legacy Issue Number: 7200
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Can Codeset come before/with Firewall Traversal in Negotiate Session
    meesages?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

What BiDirIds shall be sent over what bidirectional connections?

  • Legacy Issue Number: 7312
  • Status: closed  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The new BiDir spec is not clean about what BiDirIds shall be send to what connections. Because the BidirectionalOfferPolicy is either ALLOW or DENY, the only way to make bi-directional GIOP possible is to send all BiDirIds on an ORB to every connection that is used by an object reference that has effective BidirectionalOfferPolicy ALLOW. Besides, when a new POA with BidirectionalExportPolicy ALLOW is created, the BiDirId of this new POA must be transmitted to the server side of every existing bi-directional connections (before or in the next request).

    The above implication derived from the spec is very inefficient. Consider an ORB with n bi-directional connections and m BiDirIds. The communication overhead for sending these BiDirIds is (m * n), while, in the ideal case, the communication overhead for sending BiDirIds is (c * n) where c is the average number of BiDirIds needed on each bi-directional connection. This ideal case can be easily achieved by allowing the BidirectionalOfferPolicy to specify a list of POAs whose BiDirIds shall be transmitted.

    Proposed resolution:
    1. Extend the choices of the value field of the BidirectionalOfferPolicy:
    ALLOW_ALL – same as ALLOW now, but the implication shall be explicitely stated in the spec
    ALLOW_LISTED – a list of POAs being provided in the policy
    DENY – same as it now
    2. Add a field to the policy to allow a sequence of POAs being specified.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Interplay of Contexts allowed in NegotiateSession messages too ill-defined

  • Legacy Issue Number: 7311
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP document allows all of the contexts that can be found in a GIOP query or response message to be also allowed in a NegotiateSession message. However, the interplay among these contexts is undefined. An example is the use in NegotiateSession messages of both CodeSet negotiation and BiDir connection setup. What can be used in what order is not defined.

    RECOMMENDATION:
    Only bi-directional GIOP and firewall contexts may be used in a NegotiateSession message in this version of GIOP. The contexts are the following:

    · BI_DIR_GIOP_OFFER
    · BI_DIR_GIOP_CHALLENGE
    · BI_DIR_GIOP_RESPONSE
    · BI_DIR_GIOP_ACCEPT
    · FIREWALL_PATH
    · FIREWALL_PATH_RESP

    Further contexts may be added to new versions of the BiDir GIOP spec as their interplay with the existing set and the order of their use is carefully analyzed and documented. This effectively limits the scope of the problem to the bidir protocol and use by the firewall. The order and stage of processing the above contexts is discussed in another Firewall issue.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall FTF Issue: No ene-to-end security for firewall traversal

  • Legacy Issue Number: 7313
  • Status: closed  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The title of Section 1.7, End-to-End Secure Connection, is misleading. There is no end-to-end security in the firewall traversal spec. All security mechanisms described in this spec are essentially mechanisms between a client, firewalls, and a server, not end-to-end. Thus, it is susceptible to the man-in-the-middle attack.

    I'm saying we should fix the problem, but the title of this section and the caption of Figure 1-4 is certainly misleading. Besids, if the firewall traversal scheme described in the spec is actually susceptible to the man-in-the-middle attack, we may want to consider stating it somewhere in the spec rather than making people have a wrong impression that it is secure

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall Issue: Random BiDirIds can't be used for persistent POAs

  • Legacy Issue Number: 7310
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP document specifies that all BiDirIds must be randomly generated. However, persistent POAs must use the same BiDirId across sessions since they are stored in the IOR.

    RECOMMENDATION:
    A new policy is created (BiDirIdGenerationPolicy) that contains two fields:
    field 1, the ID generation method, will take the value 'RANDOM' or the value 'REPEATABLE'
    field 2, the ID type, will take the value 'STRONG' or the value 'WEAK'

    The random generation method is adequately documented. The repeatable method will always generate the same BiDirId for a given POA. This effectively makes the ID a constant, but without the concern for storage. It also results in the end-user not having to deal with BiDirIds - they are handled entirely by the infrastructure.

    The values for the ID type indicate whether the type of BiDirId generated is strong or weak.

    This policy is placed on the client ORB and/or the POA in question.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall Issue: Connection over which BiDir offers are sent is unspecified

  • Legacy Issue Number: 7309
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP document does not specify the connections over which a BI_DIR_GIOP_OFFER should be sent.

    RECOMMENDATION:
    A BI_DIR_GIOP_OFFER will be sent over all existing bi-directional connections. If there are none, then a new connection will be established and its bidirectionality initiated.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall Issue: Response to failed BiDir challenge is unclear

  • Legacy Issue Number: 7308
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The actions that result from the failure of a BiDir challenge are unclear.

    RECOMMENDATION:
    The client has proven itself untrustworthy. A BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is returned to the client and all bi-directional connections to the client are closed.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall issue - Number of BiDirIds in a BiDirOffer

  • Legacy Issue Number: 7307
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP document does not specify which BiDirIds and how many of them are sent in a BI_DIR_GIOP_OFFER.

    RECOMMENDATION:
    All unoffered BiDirIds are supplied in a BI_DIR_GIOP_OFFER.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous

  • Legacy Issue Number: 7353
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Dave Stringer)
  • Summary:

    ptc/04-04-06 section 15.9.1 (top of page 15-67) states:
    When the server receives a BI_DIR_GIOP_OFFER context it must send back a
    BI_DIR_GIOP_ACCEPT context in both the strong and weak identification cases.

    What happens if an ACCEPT service context is not returned? Either immediately
    or ever?

    Can a connection initiator, having sent an OFFER SC, send any further GIOP
    messages over that connection prior to receiving the ACCEPT SC?

    Should a connection initiator, having sent an OFFER SC but not having received
    an ACCEPT SC, accept a Request (i.e in the reverse direction) on that connection?
    a) for an object whose POA's BiDirId has been offered and accepted?
    b) for an object whose POA's BiDirId has been offered but a corresponding
    ACCEPT has not yet been received?
    c) for an object whose POA's BiDirId has been offered and accepted only over a
    different connection (to that over which the Request arrives)?
    d) for an object whose POA has a BiDirId but it hasn't yet been offered?
    e) for any object (e.g. one whose POA doesn't have a BiDirId)?

    If an OFFER SC is sent on a Request message, can the corresponding ACCEPT
    SC be carried on any GIOP message from the connection acceptor?
    a) the associated Response
    b) a Response not associated with the Request
    c) a NegotiateSession message
    d) a Request message for an object whose POA's BiDirId has already been
    negotiated

    If an OFFER SC is sent on a NegotiateSession message, can the corresponding
    ACCEPT SC come piggy-backed on any GIOP message (that can carry SCs) or
    must it come over a NegotiateSession message?

    If two POAs (with EXPORT policy) are created and their BiDirIds are sent separately
    in OFFER SCs on separate messages over a given connection, is a subsequently
    received ACCEPT SC deemed to relate to one or to both of the offered BiDirIds?

    Since I assume that a connection is effectively promoted to BiDir once the first
    ACCEPT SC (indicating no error) is received. What is the point of insisting that
    the connection acceptor "must" send additional ACCEPT SC?

    In fact, even wthout any ACCEPT(no error) SCs, the occurrence of a GIOP Request
    message from the connection acceptor would imply that the connection acceptor
    has accepted the BiDirId. It would seem that the ACCEPT(no error variant) SC is
    completely superfluous.

    Given the ambiguities in the protocol, it seems likely that an implementation may
    find the real-world interactions to have broken its model of the protocol. What should
    a GIOP protocol machine do in such a situation?

    If the connection initiator deems that the OFFER-ACCEPT protocol has gone wrong
    should it be required to close the connection?

    As there is no correlation between OFFER SCs and ACCEPT SCs, on a given
    connection, does an ACCEPT (indicating an error) imply that the connection is
    in an indeterminate state and should be closed?

    If a connection is to be closed due to an error in the OFFER-ACCEPT protocol do
    the normal rules regarding outstanding invocations apply? Do they apply for both
    directions?

  • Reported: CORBA 2.5 — Thu, 13 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY

  • Legacy Issue Number: 7351
  • Status: closed  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    Part of this issue has been surfaced in the discussions over the mail list. I now file it as an issue.

    The Bi-directional GIOP spec says, "An object reference with a BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional
    connection." Satisfying this policy requirement does not close some potential limitation and ambiguity when other policies or policy instances are around.

    For example, at the connection initiator side, we may have two object references one of which has BidirectionalOfferPolicy of DENY and the other has BidirectionalOfferPolicy of ALLOW. If these two object references point to the same server, according to spec, we need two connections to the server: one is bi-directional and one is not. However, having a non-bi-directional connection doesn't mean much. For invocations on the object reference with the DENY policy, the server side can always callback using the other bi-directional connection.

    There is an argument (by Brian Niebuhr) saying that it's not realistic to both trust and not trust the same server. However, in practice, it's not always possible to tell whether two object references point to the same server or not. Furthermore, the client may decide whether or not to trust the server of an object reference depending on reasons other than the information about the server. For example, the client may decide to use BidirectionalOfferPolicy of ALLOW or DENY according to the source of an object reference.

    On the other hand, at the connection acceptor side, things become a little more interesting. For an object reference with BidirectionalAcceptPolicy of ALLOW and effective BidirectionalOfferPolicy of DENY (e.g., the default policy on that ORB), what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has offered as bi-directional." However, shall we let the BidirectionalOfferPolicy of DENY prohibits the use of such a bi-directional connection? Or shall we allow the use of such a bi-directional connection because it's in the "reverse" direction?

  • Reported: CORBA 2.5 — Tue, 11 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bi-directional connections considered volatile at connection acceptor side

  • Legacy Issue Number: 7352
  • Status: closed  
  • Source: Syracuse University ( C. Joncheng Kuo)
  • Summary:

    This issue was mentioned by Dave Stringer. I now file it as an issue.

    When a bi-directional connection is established between a connection initiator and a connection acceptor, the connection acceptor may have to consider this bi-directional connection is volatile, i.e., the connection acceptor may lose (and is not able to resume) its capability of making invocations on such a connection anytime. For example, the connection may be lost due to network problems or the client may close a connection due to an idle time-out. These situations are not a problem for uni-directional GIOP because the ORB who wants to make an invocation can always initiate a new connection when the old connection is not available.

    This problem may be less serious when bi-directional communication occurs only during the period of an invocation from the connection initiator. In other words, if the connection is lost and results in the failure of bi-directional "callback", the connection initiator may retry, effectively resuming the bi-directional connection.

    On the other hand, for the use case in which a connection initiator "registers" an object reference to the connection acceptor, there is no guarantee that "callbacks" from the connection acceptor to the connection initiator will eventually succeed, assuming the network is not always down.

    If this issue is a limitation that cannot be solved easily, we should spell it out in the spec.

  • Reported: CORBA 2.5 — Tue, 11 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

connection_complete field of the FirewallPathRespContext is under specified

  • Legacy Issue Number: 7317
  • Status: closed  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The connection_complete field of the FirewallPathRespContext is under specified.

    The fourth paragraph (including IDL) from the end of Section 1.5.4, Firewall Service Context, says,

    “Once the connection has been established, the last intelligent firewall in the FirewallPath sends a FIREWALL_PATH_RESP service context in another NegotiateSession message.”

    However, the last paragraph of this section says that, when the connection is not completely established, a FIREWALL_PATH_RESP service context with the connection_complete field of false is sent.

    Furthermore, when the connection_complete field is false, the spec does not explain what are the situations that may cause incomplete connection establishment and what the client shall do for “further processing”. Shall the FIREWALL_PATH_RESP service context also contains information indicating what the client shall do?

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How many BI_DIR_GIOP_OFFER service contexts are allowed

  • Legacy Issue Number: 7318
  • Status: closed  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The Bidirectional GIOP spec does not specify how many BI_DIR_GIOP_OFFER service contexts are allowed in a NegotiateSession or Request.

    If only one such service context is allowed, it shall be stated clearly. Besides, because each BI_DIR_GIOP_OFFER service context can contain only either strong or weak BiDirIds (but not both), if there are both strong and weak BiDirIds on the ORB, the ORB has to use at least two GIOP messages to send them all.

    If we allow multiple BI_DIR_GIOP_OFFER service contexts in one message, we'll have a problem in matching BI_DIR_GIOP_ACCEPT service contexts to these offers because there is no sequencing on offers and accepts.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Targets of Export and Offer Policies incompletely specified

  • Legacy Issue Number: 7315
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The target (ORB, POA, object, thread) of the Export and Offer policies and the side of the connection involved is incompletely specified.

    RECOMMENDATION:
    Define the two sides of a connection as the connection 'Initiator' and connection 'Acceptor'. The usual terms of 'client' (Initiator) and 'server' (Acceptor) become confusing in a bi-directional situation. Given those terms for each side, specify that the Export and Offer policies are used on the Initiator side. Specify that the Export policy may be applied to the ORB, the POA and/or to the thread. Specify that the Offer policy can be applied to the Initiator ORB, to a reference in the Initiator for an object in the Acceptor, or to a thread in the Initiator ORB.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Expected behavior of a non-conformant implementation

  • Legacy Issue Number: 7316
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    It is not defined what happens if a non-conformant implementation receives a BiDir offer.

    RECOMMENDATION:
    State that a non-conformant implementation need not do anything - it may simply ignore the offer.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Processing of NegotiateSession messages at various stages of connection set

  • Legacy Issue Number: 7314
  • Status: closed  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP Document discusses three stages of connection setup, but it is unclear when each stage begins and when it ends. It is also unclear what NegotiateSession or Firewall activity can take place in each stage and what the order of processing may be.

    RECOMMENDATION:
    Rewrite the relevant portions of the document to specify the following (excerpted without edit from Brian Niebuhr's discussion of NegotiateSession contexts and the stages of setup):

    "...during connection setup, only firewall contexts can be in the negotiate session message, NOTHING ELSE. After the connection is setup, there is a period before the first request or locate request where we can do session setup items. I think that in that period, only Bidir contexts can be sent, NOTHING ELSE. The first request or locate request indicates the connection_established period. Again, during that period I think only the Bidir contexts should be legal. This makes things very simple. There are no conflicts between firewall and bidir, and nothing else can go in a negotiate session message."

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Multiple objects on a stream

  • Legacy Issue Number: 22
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What happens when multiple calls are made to Stream::externalize() at the top level? Does the stream contain all those objects, and how does a client discover this?

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Definition of stream portability

  • Legacy Issue Number: 21
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The standard stream format should specify that it is portable across different ORBs and hardware, but not across streamable object implementations whch use different semantic content.

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Lifecycle Key type definition

  • Legacy Issue Number: 18
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Several LifeCycle methods take a "key" argument, but do not clarify whether multiple NameComponents are allowed in a key, if ordering matters, etc.

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Stream contexts and internalization

  • Legacy Issue Number: 19
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Externalization spec does not state how a stream implementation is to discover that a context exists when internalizing an object.

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Start and end of context tags

  • Legacy Issue Number: 20
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The standard stream data format does not define tags to be used to identify the beginning and end of a context.

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

when is a connection a "bi-directional connection"?

  • Legacy Issue Number: 7356
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Dave Stringer)
  • Summary:

    The discussion on when to send BiDirIds over connections is floundering.
    In part, I think this is due to a lack of precision in our thinking (and more
    importantly in the adopted firewall spec we are working from).

    When does a GIOP connection become bi-directional? The implementation
    of the connection-initiator protocol engine must know this. Before this
    event it has to treat a GIOP Request message as a protocol error and after
    the event it has to dispatch the request.

    There seems to be an assumption (or more than one) that there is a
    relationship between an Object Reference (i.e. the programming language
    artefact representing CORBA::Object) and a GIOP connection.

    Whilst it is true that an implementation of the CORBA spec will provide a
    relationship (else an invocation cannot result in a GIOP Request message)
    the particular relationship was left to ORB implementers to provide for
    flexibility of implementation. Specifically, such a relationship is not prescribed
    in the CORBA specification (nor should it be).

    I suggest it would be dangerous to define a GIOP connection to change state
    when an Object Reference that (in some ill-defined way) "points to" a server
    that is the target of that connection, undergoes a policy change (i.e. its BiDir
    Offer policy is set to Allow).

    Instead, a GIOP connection presumably becomes bi-directional when an
    invocation on an Object Reference, with an effective Offer Policy of Allow, results
    in a Request message being sent over that connection.

    The specification must be explicit over which event causes the connection to
    become bi-directional.

    Also, can a connection cease to be bi-directional? For example if either the
    Object Reference invoked above or the POA with "Export = Allow" are destroyed.
    Again this would appear to be fraught with problems, leading to the assumption
    that the GIOP connection, once bi-directional, remains bi-directional until it is
    closed.

    Lastly, the closing of idle connections and the subsequent re-connection has
    hitherto been a matter for ORB implementers (Messaging::RebindPolicy not
    withstanding). This is unfortunate as an application won't be aware of the ORB
    having conserved resources in this way and the ORB should not be expected to
    provide session semantics that span multiple tcp connections (this is currently
    stated in the description of NegotiateSession).

  • Reported: UML 2.0 — Tue, 18 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Coordinator remembering LockCoordinator

  • Legacy Issue Number: 59
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CosTransactions Coordinator does not have any IDL method to remember LockCoordinator. How does it know what Lock Coordinators should be informed to drop locks?

  • Reported: CORBA 1.2 — Wed, 24 Jul 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Input values for "which" arg of non-trans. LockCoordinator

  • Legacy Issue Number: 60
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For a non-transactional client who wants to get a LockCoordinator, what input values should one use for the "which argument?

  • Reported: CORBA 1.2 — Wed, 24 Jul 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Freeing of locks at the end of a transaction

  • Legacy Issue Number: 58
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is not clear whether CosTransactions::Coordinator is responsible for freeing locks at the end of a transaction.

  • Reported: CORBA 1.2 — Wed, 24 Jul 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Getting the thread ID in a non-transactional lock request

  • Legacy Issue Number: 57
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In a non-transactional lock request, the lock identity is supposedly based on thread ID. How can the server code get the client thread ID when they may be on different machines?

  • Reported: CORBA 1.2 — Wed, 24 Jul 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Communication failure issue

  • Legacy Issue Number: 56
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If the ORB suffered a communication failure while LockSet::lock() is being called, how does the client know if the lock was granted or not?

  • Reported: CORBA 1.2 — Tue, 23 Jul 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Timeout while locking

  • Legacy Issue Number: 47
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If the ORB times out while LockSet::lock() is being called, how does the client know if the lock was granted or not?

  • Reported: CORBA 1.2 — Tue, 2 Jul 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosCompoundExternalization Service

  • Legacy Issue Number: 476
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When Node::externalize_node is called, is node responsible for externalizing related object? What happens, if related object isn"t a CosStream::Streamable?

  • Reported: CORBA 1.2 — Tue, 21 Jan 1997 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

${issue.summary}

  • Legacy Issue Number: 473
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: CORBA 1.2 — Wed, 8 Jan 1997 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

${issue.summary}

  • Legacy Issue Number: 472
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: CORBA 1.2 — Wed, 8 Jan 1997 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosGraphs::deep

  • Legacy Issue Number: 469
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If CosGraphs::deep propagation value is encountered, is the Node"s related object supposed to get copied, too. What if LifeCycleObject delegates to CosCompoundLifeCycle::Operations?

  • Reported: CORBA 1.2 — Fri, 3 Jan 1997 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Common format on stream

  • Legacy Issue Number: 466
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When reading a stream, there is no way of telling where context (limited to calls to begin_context and end_context) end and a new one starts.. Resolved problem with new "tag-byte" 0xFF.

  • Reported: CORBA 1.2 — Thu, 19 Dec 1996 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

performing a compound copy of relationship

  • Legacy Issue Number: 470
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The second pass of operation is to "cause the node and all of its roles" to be copied. How do you get related object of the NEW roles to be the New Node?

  • Reported: CORBA 1.2 — Fri, 3 Jan 1997 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

${issue.summary}

  • Legacy Issue Number: 471
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: CORBA 1.2 — Thu, 9 Jan 1997 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Using local thread identification for concurrency

  • Legacy Issue Number: 61
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It seemed more useful for the concurrency service to be non-IDL, and just based on local thread identification.

  • Reported: CORBA 1.2 — Wed, 24 Jul 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Internalizing roles-IDL optimization

  • Legacy Issue Number: 706
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL for internalizing roles could be optimized to reduce the size of the externalized data as well as simplifying the implementation

  • Reported: CORBA 2.1 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Who is responsible for releasing locks in transaction?

  • Legacy Issue Number: 578
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In lock duration of Section 7.1 there are two descriptions. The role of the clients is vague to me

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Purpose of related LockSet

  • Legacy Issue Number: 576
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the specification, "Related lock sets" appears only in "create_related()" and create_transaction_related()" Where do I use these methods

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosCompoundExternalization Service (3)

  • Legacy Issue Number: 478
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When internalizing a relationships, how do the "shallow" nodes and roles get included?

  • Reported: CORBA 1.2 — Tue, 21 Jan 1997 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Which model should ConcurrencyControl support?

  • Legacy Issue Number: 577
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is inconsistency regarding which model ConcurrencyControl needs to support

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosCompoundExternalization Service (2)

  • Legacy Issue Number: 477
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Role in new node are disconnected It"s role of read_graph to correctly establish new relationships. How is that accomplished?

  • Reported: CORBA 1.2 — Tue, 21 Jan 1997 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- finding index

  • Legacy Issue Number: 6
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On CollectionObj->remove_element_at(IteratorRef), how does the collection "know" the index?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Query Collection::Collection -- Sharing State

  • Legacy Issue Number: 5
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: How do IteratorObjs and CollectionObjs share state?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Circular References in CosStream and CosCompoundExternalization

  • Legacy Issue Number: 1401
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- membership scoping

  • Legacy Issue Number: 3
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I assume that we are allowed to scope membership in a collection via an interface test (e.g, must be rooted off of Collection) and throw an InvalidElement exception?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- Adding multiple elements

  • Legacy Issue Number: 4
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Using collection factories, can you add multiple elements at once, and/or add new create methods?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Questions on CosQuery::QueryableCollection interfaces

  • Legacy Issue Number: 13
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Clarifications on interfaces which support QueryableCollection.

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- reset() exceptions

  • Legacy Issue Number: 10
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Can an iterator "reset()" throw an exception such as IteratorPositionInvalid if it is wrapping a db cursor which has no facility for reset?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- keyed collections

  • Legacy Issue Number: 12
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is it correct to offer the vanilla collection methods and add a new set for keyed access?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- next_n()

  • Legacy Issue Number: 11
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Can an interator have a next_n()? Or is this supposed to be via subtyping the interface?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- destroy methods

  • Legacy Issue Number: 9
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Where are the destroy methods on the Iterator or on the Collection?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- Iterator Position Invalid

  • Legacy Issue Number: 7
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What does the IteratorPositionInvalid exception mean? Is it only that the user has cycled through the list elements and that no reset() has been issued?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- iterator updating

  • Legacy Issue Number: 8
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: How does the Iterator know to become invalid when the Collection is altered?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Query language for operations

  • Legacy Issue Number: 83
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Need all operations on the Collection be made using the SQL-92/QOL-93? If so, how is it possible to handle flat file datastores?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Definition of NULL in datafiles without NULL as a concept

  • Legacy Issue Number: 80
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 11.4.2 para. 3 says that FieldValues may be NULL. What if my datastore is a flat file without a concept of NULL. Does NULL take on the value of empty string for flat files?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Delegating iterator functionality to the RDBMS

  • Legacy Issue Number: 82
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is there a way that I can delegate the functionality of the Iterators to the RDBMS itself?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Clarification request for section 11.1.5

  • Legacy Issue Number: 79
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Several of the bullets in section 11.1.5 are unclear.

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

retrieve_element

  • Legacy Issue Number: 81
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: How does this operation work?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How do iterators handle changing of the data they are pointing at

  • Legacy Issue Number: 78
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is it not possible that objects in a collection could have changed in between calls to the iterator accessing them?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Use of MD5 on arguments

  • Legacy Issue Number: 23
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Appendix D states that a challenge structure consists of the MD5 of the arguments, but does not specify how the arguments are laid into a stream of octets for the MD5 algorithm.

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Updating information via query iterators

  • Legacy Issue Number: 69
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When using iterator operations like adding, inserting, etc., how are changes reflected back to the datastores?

  • Reported: CORBA 1.2 — Tue, 13 Aug 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Inconsisten IDL in the Minimum CORBA chapter

  • Legacy Issue Number: 4216
  • Status: closed  
  • Source: University of California, Irvine ( Carlos O'Ryan)
  • Summary:

    Section 23.14 of the CORBA/IIOP 2.4.1 specification lists the
    complete IDL for a minimumCORBA implementation. However, the text in
    the chapter and the IDL are inconsistent, for example, section 23.4.2
    reads:

    ------------------------------------------------------------------------
    ---------------
    The is_a operation is omitted so as not to introduce a requirement
    either for holding

    detailed type information in the object reference or for getting type
    information over

    the wire. Instead, minimumCORBA relies on design time resolution of type
    checking

    issues.

    The non_existent operation is omitted, because of the design philosophy
    of making

    more decisions statically at design time.

    The create_request operation is omitted, as the Dynamic Invocation
    Interface is

    omitted.

  • Reported: CORBA 2.4.2 — Sat, 3 Mar 2001 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

TypedConsumerAdmin interface (4.9.2))

  • Legacy Issue Number: 961
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Correction of CORBA specification (page 18-51)

  • Legacy Issue Number: 3342
  • Status: closed  
  • Source: Anonymous
  • Summary:

    >You write on page 18-51:
    >In COM V2.0, interfaces can have single inheritance. However, as opposed to
    >CORBA,
    >there is a standard mechanism by which an object can have multiple interfaces
    >(without
    >an inheritance relationship between those interfaces) and by which clients can
    >query
    >for these at run-time. (It defines no common way to determine if two interface
    >references refer to the same object, or to enumerate all the interfaces
    >supported by an
    >entity.)
    >
    >It's not right, that there's no common way to determine if two interface
    >references refer to the same object. The IUnknown-Pointer of two different
    >interfaces of the same object must be the same (object identity in COM).

  • Reported: CORBA 2.3.1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

WWW Form output

  • Legacy Issue Number: 535
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue regarding implementation of the Query IDL specifications on a Java ORB. Issue involves implementing following idl definition from the CosQueryCollection module

  • Reported: CORBA 1.2 — Thu, 6 Mar 1997 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

interface QueryEvaluator {

  • Legacy Issue Number: 575
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I understand the params to be name value pairs of columns and the values for the
    selection, update, delete, insert criteria
    what is in the query? I would think if this is the whole query why would you
    need the params??

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Malformed PropertyName

  • Legacy Issue Number: 284
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is not believed that the spec ever defines what a "malformed" PropertyName is. The closest definition is in para on page 26, section 5.1.1.2 and is not much help

  • Reported: CORBA 1.2 — Sat, 19 Oct 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OQS relation to POS

  • Legacy Issue Number: 84
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Need the OQS have any interface with the POS? I don"t see how the two can be interfaced.

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

COM/CORBA keywords

  • Legacy Issue Number: 2009
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosExternaliazation Service (bug?)

  • Legacy Issue Number: 4188
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Page 2-7 of the CosExternalization Service Specification (April 2000)
    defines the following interfaces:
    CosStream::Node
    CosStream::Role
    CosStream::Relationship

    A CosStream::Node inherits from the CosStream::Streamable interface and
    therefore is a streamable object – it has an external_form_id attribute
    that enables a FactoryFinder to recreate the object using the
    create_uninitialized operation.

    Unfortunately, the CosStream::Role and CosStream::Relationship interfaces do
    not support the CosStream::Streamable interface and therefore are not
    "streamable;" in particular, there is no standard method to obtain a KEY for
    them when it is time to internalize them.

    Perhaps, I am missing something (it wouldn't be the first time , but
    having them support the Streamable interface would certainly make
    implementation much easier. Might I suggest the following:

    interface Role: CosGraphs::Role, CosStream::Streamable

    { ... }
    interface Relationship: CosGraphs::Relationship, CosStream::Streamable { ... }

    at a minimum this would permit the CosStream::Node internalize_node()
    operation and the CosStream::StreamIO read_graph() operation to use a KEY
    value in the FactoryFinder to instantiate the object, before it is
    internalized.

  • Reported: CORBA 2.4.2 — Mon, 5 Feb 2001 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

ObjectCreationError and Nofactory exceptions in Externilazition

  • Legacy Issue Number: 1293
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosConsurrencyControl service bug or not?

  • Legacy Issue Number: 3522
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I develop CosConcurrencyControl service for JacORB, but I don't
    understud from specification how client can destroy LockSet.
    When I create Object which allow concurrency access, I create LockSet.
    When I destroy this Object I must destroy LockSet, because it's garbage,
    bu no way for this does not exists.

    As solution of this problem, I add in CosConcurrencyControl.idl next
    changes:
    exception LockExists{};

    and method
    void destroy raises (LockExists);

    in interface LockSet.

    As I undestand this changes is wrong, but have you idea about desigion
    this problem.

  • Reported: CORBA 2.3.1 — Tue, 28 Mar 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Compiler being able to translate from OMG-IDL into ANSI

  • Legacy Issue Number: 184
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Existing software based on messages with ASNI format description and a future version based on IDL. Does anybody know something about such a compiler?

  • Reported: CORBA 1.2 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Unclear and possibly harmful consequences of mandatory annotation definitions

  • Legacy Issue Number: 19738
  • Status: closed  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    The current mandatory annotation definitions (7.4.15.4.1) will cause problems when IDL specifications are attempted to be reused between profiles applying different requirements concerning annotations (for example a profile with annotations and a profile without annotations or two or more profiles with different sets of annotations).

    As the IDL 4 specification has removed the support for the commented form of annotations there is no possibility anymore to declare annotations in a form that has semantic meaning in one profile and does not cause parsing errors in another profile not supporting (these) annotations.
    Even with the commented form supported the mandatory specification of annotation definitions for applied annotations would cause similar kind of problems as it is likely that the definitions for the standard set of annotations from one profile would not be available in another profile not supporting those annotations.

    Personally I do not see any use for annotation definitions (and in fact I cannot find any commentaries regarding that in the spec) but I would suggest that at the very least IDL compilers should be allowed to ignore any annotations not known to the profile for which the IDL compiler is configured.
    Ideally I would like to see a specification without any mandatory annotation definitions leaving it up to the tool supplier to enforce annotation definitions or implement implicit (embedded) definitions.

  • Reported: CORBA 3.1.1 — Tue, 31 Mar 2015 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 15.4.5.1 struct has to be updated

  • Legacy Issue Number: 12858
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    this section says: // GIOP 1.0 struct LocateRequestHeader_1_0

    { // Renamed LocationRequestHeader unsigned long request_id; sequence <octet> object_key; }

    ; Anonymous types are deprecated so this struct has to be updated

  • Reported: CORBA 3.0.3 — Tue, 23 Sep 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Fixed Types in COM

  • Legacy Issue Number: 4507
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There is currently no specification for fixed-point types in the COM/CORBA mapping. I'm interested in getting this changed: how can we proceed? better still, is this work already under way??

  • Reported: CORBA 2.4.2 — Fri, 17 Aug 2001 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How does DynValue handle derived valuetypes?

  • Legacy Issue Number: 5467
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    I just noticed that the description of DynValue is totally silent on the
    issue of derived valuetypes.

    Here's an example to set things up:

    // IDL

    valuetype A

    { public short s; }

    ;

    valuetype B

    { public long l; }

    ;

    struct S

    { A an_a; }

    ;

    // C++

    DynamicAny::DynFactory df = ...;
    B *b = ...;
    S my_s;
    CORBA::Any my_any;

    s.an_a = b;
    my_any <<= s;

    DynamicAny::DynAny_var da = df->create_dyn_any(my_any);
    DynamicAny::DynStruct_var ds = DynamicAny::DynStruct::_narrow(da);

    ds->seek(0);
    da = ds->current_component();

    DynamicAny::DynValue_var dv = DynamicAny::DynValue::_narrow(da);
    CORBA::TypeCode_var tc = dv->type();

    cout << tc->id() << endl;

    -----------

    Now some questions:

    1. What is printed by the above C++ code? "IDL:A:1.0" or "IDL:B:1.0"?

    2. If the typecode is for valuetype A, what happens to the members
    defined in valuetype B? Seems they must be inaccessable yet still
    recoverable if I convert the DynValue back to an any and extract the
    value, because I can't truncate a B to an A.

    3. If the typecode is for valuetype B, we now have the interesting case
    where:

    tc->equivalent(ds->type()->member_type(0))

    is false. Is this going to confuse programmers or programs? I think it
    will, since it means that if I try to insert dv into another DynStruct
    via assign() or the like, it will fail, since the TypeCodes are no
    longer equivalent.

    4. Do the answers change if B is truncatable and the program can find
    the TypeCode for B (perhaps via SendingContextRunTime)? How about if it
    can't find the TypeCode?

  • Reported: CORBA 3.0 — Tue, 16 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Spec doesn't make clear what is valid mix of policies and what is invalid

  • Legacy Issue Number: 5624
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The spec doesn't make it clear what is a valid mix of policies and what
    is invalid. For example, should it be legal to set a
    RequestPriorityPolicy, MaxHopsPolicy or QueueOrderingPolicy value if the
    RoutingPolicy is ROUTE_NONE?

    Also, should setting both RequestEndTimePolicy and
    RelativeRequestTimeoutPolicy be illegal? Or must the client/server pick
    which ever one expires first?

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

messaging router issue

  • Legacy Issue Number: 5621
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    What is a messaging router supposed to do if it receives multiple
    requests from a client with more than one type of QueueOrderingPolicy
    value? (Is this legal? Is it legal to have more than one QueueOrdering
    bit set in a single request?) How can it sort on priority, FIFO, and
    deadline simultaneously?

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

valuetypes and local interfaces

  • Legacy Issue Number: 6318
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    The spec appears silent as to whether valuetypes are allowed to support local interfaces. Table 3-10, for example, says nothing at all about local interfaces.

    There's a couple ways to look at this. First, valuetypes are not CORBA objects. Servants for local interfaces are direct CORBA object instances, i.e., the "local" declaration on an interface effectively removes the distinction between a CORBA object and its servant. If a valuetype were used as a servant for a local object, then the valuetype would itself also be a CORBA object. By this analysis, valuetypes should not be allowed to support local interfaces.

    Another way to look at it is that the valuetype should just inherit the local interface's operations and attributes without having any subtype/subclass relationship with the base local interface. This would be a rather pointless approach to take, is there would be no possibility of using the valuetype polymorphically with respect to the base local interface.

  • Reported: CORBA 3.0.2 — Thu, 16 Oct 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 22.2.4.6 interface RelativeRoundtripTimeoutPolicy

  • Legacy Issue Number: 6424
  • Status: closed  
  • Source: Borland Software Corporation ( Wolfgang Haefelinger)
  • Summary:

    [..] It is used to indicate the relative amount
    of time for which a Request or its corresponding
    Reply may be delivered. After this amount of
    time, the Request is cancelled (if a response
    has not yet been received from the target) or
    the Reply is discarded (if the Request had
    already been delivered and a Reply returned from
    the target) [..]
    ---------------------------------------------------------
    Question:

    • What is the precise meaning of "Request is
      cancelled"?

    Does it mean that client ORB just gives up or
    does it mean that client tries, in kind of best
    effort semantics, to cancel request on server?

    If this cancellation fails, how will client user
    be informed about this? By a minor code in
    thrown Timeout exception?

    Is it possible to clarify this?

  • Reported: CORBA 3.0.2 — Wed, 29 Oct 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CORBA 3.02, page 11-25, section 11.3.6

  • Legacy Issue Number: 6899
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    Fifth bullet near the beginning of this section states:

    Incarnations of a particular object may not overlap; that is, incarnate shall not be invoked with a particular ObjectId while, within the same POA, that ObjectId is in use as the ObjectId of an activated object or as the argument of a call to incarnate or etherealize that has not completed.

    Unfortunately, I do not see anywhere where the exception to be thrown from activate_object_with_id() for this case is specified. According to this text, if incarnate() is executing for a particular ObjectId, any calls to activate_object_with_id() should be rejected by the POA. This came up in comp.object.corba, where someone posted a question as to why Orbix 2000 throws the ObjectAlreadyActive exception for this case.

  • Reported: CORBA 3.0.2 — Mon, 12 Jan 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

module SendingContext

  • Legacy Issue Number: 7340
  • Status: closed  
  • Source: MetroApp Entertainment ( Keith Allyn Baker)
  • Summary:

    The CORBA specification has module SendingContext { //... interface CodeBase

    { //... CORBA::FullValueDescription meta(in CORBA::RepositoryId x); //... }

    ; //... }; but there is no CORBA::FullValueDescription defined in the specification, yet the supplied <SendingContext.idl> file declares module SendingContext { //... interface CodeBase

    { //... CORBA::ValueDef::FullValueDescription meta(in CORBA::RepositoryId x); //... }

    ; //... };

  • Reported: CORBA 3.0.3 — Sat, 15 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

rules for marshalling ValueBoxes

  • Legacy Issue Number: 5899
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    The GIOP specification does not say anything at all about the rules for marshalling ValueBoxes.

    I believe the expected format is to marshal ValueBoxes as if they were a normal Value with a single member, and that they follow the normal rules about indirections and chunking. The spec should clearly state this.

  • Reported: CORBA 3.0.2 — Wed, 16 Apr 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

BNF changes

  • Legacy Issue Number: 5952
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    BTW I think the twiddle is incomplete because it is not reflected
    in the BNF for Identifier. I think it is better if the BNF always
    reflects the ultimate specification of a language's lexical
    definition. Otherwise compiler writers are apt to miss the
    subtleties.
    I'll propose some BNF changes if others agree

  • Reported: CORBA 3.0.2 — Wed, 25 Jun 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Problem with ServerRequestInterceptor::receive_request and DSI

  • Legacy Issue Number: 5895
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    21.3.9.2 states:

    "In the DSI model, since the parameters are first available when the user code calls arguments, receive_request is called from within arguments. It is possible that arguments is not called in the DSI model. The target may call set_exception before calling arguments. The ORB shall guarantee that receive_request is called once, either through arguments or through set_exception."

    The problem here, is that the DSI servant has already been invoked at this point, and the DSI implementation will be unaware that the server interceptor may have cancelled the invocation via raising a system exception or ForwardRequest user exception. So the DSI implementation will carry on, creating all sorts of wonderful havoc as it continues to interact with the ServerRequest PO.

    Any vendors want to comment on what their PI implementation does now?

    Proposed fix:

    First, we should define a new system exception minor code that the servant implementation can detect so that it can clean up and get out of the way as expeditiously as possible when raised by arguments or set_exception. Perhaps a minor code for OBJ_ADAPTER? Should there be two minor codes, to distinguish a system exception from ForwardRequest as the reason for cancelling the invocation?

    Second, we need some more text either in chapter 8 or 21 that states that any calls by the DSI implementation to ServerRequest::set_result or ServerRequest::set_exception will be ignored (or perhaps reraise the exception defined in the previous paragraph) if ServerRequestInterceptor::receive_request raises an exception.

  • Reported: CORBA 3.0.2 — Wed, 2 Apr 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

restriction of where a valuetype chunk can end

  • Legacy Issue Number: 5892
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    There is a small issue with the restriction of where a valuetype chunk can end. The spec says

    "The data may be split into multiple chunks at arbitrary points except within primitive CDR types, arrays of primitive types, strings, and wstrings, or between the tag and offset of indirections. It is never necessary to end a chunk within one of these types as the length of these types is known before starting to marshal them so they can be added to the length of the currently open chunk."

    However, in the case of array of wchar, the length is not known before starting to marshal, since each char (in GIOP 1.2 and 1.3) is marshalled as a (sort-of) sequence of octets. I think it should be legal to end a valuetype chunk in the middle of an array of char.

  • Reported: CORBA 3.0.2 — Wed, 26 Mar 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bad text in 22.6 mandates Routing for sendc/sendp

  • Legacy Issue Number: 5856
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There is a sentence in the first paragraph of 22.6 that should be fixed:

    "The implementation of these methods must generate a method invocation
    as described in Section 22.14, Message Routing, on page 22-50."

    However, 22.2.5.3 allows asynchronous invocations to be delivered via
    synchronous protocols if the RoutingPolicy is ROUTE_NONE.

    This sentence should be changed to:

    "The implementation of these methods may generate a method invocation as
    described in Section 22.14, Message Routing, on page 22-50, depending
    on the effective RoutingPolicy for the invocation."

  • Reported: CORBA 3.0.2 — Tue, 11 Feb 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

What is the RSC when using a PersistentPoller

  • Legacy Issue Number: 5781
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    What is the RSC when
    > using a PersistentPoller? Since it is a valuetype that can be passed
    > from one process to another, the RSC obviously can't be the same in the
    > other process as at the original invocation point.
    >
    > Anybody have any bright ideas for this one? Should it be empty? A copy
    > of the TSC at the poll point? Change MessageRouting:PersistentRequest
    > to have an attribute that provides access to a copy of the RSC, and
    > PersistentRequestRouter::create_persistent_request to have the RSC as an
    > "in" argument?

  • Reported: CORBA 3.0.1 — Mon, 25 Nov 2002 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Messaging Routing Protocol is broken for GIOP 1.0 & 1.1

  • Legacy Issue Number: 5662
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    It is impossible to use the routing protocol to communicate with servers
    that only support GIOP 1.0 or 1.1, because the information contained in
    struct MessageBody does not contain enough information to determine the
    alignment requirements of the contents of body member. The GIOP 1.0 &
    1.1 RequestHeader struct contain an octet sequence for principle as the
    last member, and specify no alignment requirements for the message
    body. Thus, it is impossible for the final router to determine the
    proper alignment for the message body when marshalling a GIOP Request
    message for delivery to the target object.

    The same problem applies to the Response message.

  • Reported: CORBA 3.0 — Thu, 26 Sep 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Codec Interface Deficiencies

  • Legacy Issue Number: 7730
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    CORBA 3, chapter 13.8, defines the Codec interface to encode
    arbitrary data values into CORBA::OctetSeq "blobs" and vice
    versa. This interface can be used, e.g., to supply and retrieve
    ServiceContext data using the PortableInterceptor interfaces.

    In practice, the Codec interface is also being used for data
    serialization, i.e., to store and retrieve arbitrary values in
    files or other databases.

    However, the interface is deficient in that it does not consider
    all possible variables that are needed for interoperability.
    It supports setting the CDR version that is to be used, but
    neglects byteorder and codeset settings.

    Consequently, the encoded values are platform-specific. If a
    value was encoded on a little-endian system, it will not decode,
    or worse, decode erroneously, on a big-endian system. The same
    caveats apply to codesets, e.g., when an ISO-8859-1 encoded
    blob is decoded using UTF-8 or Windows-1252.

    To support interoperability, the Codec interface needs to be
    extended.

    My recommendation is to extend the CodecFactory interface,
    so that it supports creating CDR version-, byteorder-, and
    codeset-specific Codec instances, either supplying user-
    provided values for each, or informing the user about chosen
    defaults.

    Example:

    module IOP {
    const EncodingFormat ENCODING_DEFAULT = -1;

    typedef short ByteorderFormat;
    const ByteorderFormat BYTEORDER_DEFAULT = -1;
    const ByteorderFormat BYTEORDER_BIGENDIAN = 0;
    const ByteorderFormat BYTEORDER_LITTLEENDIAN = 1;

    struct EncodingExt

    { EncodingFormat format; octet major_version; // set to 0 for default octet minor_version; ByteorderFormat byteorder; CONV_FRAME::CodeSetId char_data; // set to 0 for default CONV_FRAME::CodeSetId wchar_data; // set to 0 for default }

    ;

    local interface CodecFactory

    { // create_codec remains as before Codec create_codec_ext (inout EncodingExt enc) raises (UnknownEncoding); }

    ;
    };

    The create_codec_ext operation would create an appropriate
    Codec instance, if available; it will then set all "default"
    members of the EncodingExt structure to their actual values,
    so that the application can store this information along
    with any encoded values.

    One potential criticism of the above is that the encoding
    format's parameters depend on the encoding format. For example,
    there may be encoding formats that are byteorder-independent,
    or that consistently use UTF-32 for strings, thus not needing
    codeset parameters. Also, they may use wildly different
    versioning. So a "better" solution might involve passing
    the EncodingFormat, and an Any with a format-specific data
    type.

    That could look like:

    module GIOP {
    typedef short ByteorderFormat;
    const ByteorderFormat BYTEORDER_DEFAULT = -1;
    const ByteorderFormat BYTEORDER_BIGENDIAN = 0;
    const ByteorderFormat BYTEORDER_LITTLEENDIAN = 1;

    struct CDREncodingParameters

    { octet major_version; // set to 0 for default octet minor_version; ByteorderFormat byteorder; CONV_FRAME::CodeSetId char_data; // set to 0 for default CONV_FRAME::CodeSetId wchar_data; // set to 0 for default }

    ;
    };

    module IOP {
    const EncodingFormat ENCODING_DEFAULT = -1;

    local interface CodecFactory

    { // create_codec remains as before Codec create_codec_ext (inout EncodingFormat format, inout Any parameters) raises (UnknownEncoding); }

    ;
    };

    Once we have consensus on the approach, I will gladly volunteer
    to come up with a full set of editing instructions

  • Reported: CORBA 3.0.3 — Thu, 9 Sep 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

methods on the POA

  • Legacy Issue Number: 7890
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    A lot of the methods on the POA which have USE_DEFAULT_SERVANT or USE_SERVANT_MANAGER as policies don't describe in detail what should happen when one of these policies is set, but no default servant/servant manager is set. For example reference_to_servant, when USE_DEFAULT_SERVANT is set and default servant is registered we return the default servant, but what when no default servant is set, is then the ObjectNotActive the correct exception? Shouldn't this be something like a system exception (bad inv order, obj adapter or something like that?)

  • Reported: CORBA 3.0.3 — Mon, 1 Nov 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Add a typedef for the POAManager id

  • Legacy Issue Number: 7892
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Add a typedef for the POAManager id and use this throughout the spec for POAManager, POAManagerFactory and IORInterceptor add typedef string POAManagerId change in POAManager string get_id(); to POAManagerId get_id(); Or better (see other issue). readonly attribute POAManagerId the_id;

  • Reported: CORBA 3.0.3 — Mon, 1 Nov 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

An extension of IOR to protect target objects Nature

  • Legacy Issue Number: 7592
  • Status: closed  
  • Source: Computer Science Department, National University of Defence Technology ( jack_nudt)
  • Summary:

    Related Specification: CommonObject Request Broker Architecture: Core Specification November 2002 Version 3.0 - Editorial edit to cover formal/02-11-03 Nature: Revision Subject: An extension of IOR to protect target objects Nature: Enhancement Issue Summary: IOR (Interoperable Object Reference) is the distributed reference of a CORBA object. The IOR of a target object is distributed to client applications that want to access the target object. Clients can easily connect to the target objects based on the location information in IOR. As a kind of object discovery scheme, IOR publishes some attributes related to target object, such as IP address, port number, internal object id, etc. As we know, many kinds of attacks can be performed to a target server when the IP address and port number of the target is exposed. The exposition of internal object id may also leads to security problems. We use Abstract IOR (AIOR) to make the originate IOR (we call it regular IOR) transparent to client applications, thus the target objects is protected from potential attacks. Proposed solution: We use proxy technology to protect target servers, following is the architecture of a typical scenario. Service Proxy (SP) acts as a portal for all background servers. SP will handle all requests from clients to background servers. So background servers are transparent to clients. ------------ ----------- | Client | Abstract IORs | Service | | application ---------------+ Proxy | | | | | ----------- --+ BS1's IORs | | | ------------------------- | | | BS2's IORs | | + ------------ | -------+ + BS3's IORs | Background | --------+ + | Server 1 | | Background | -------+ ---------- | Server 2 | | Background | ---------- | Server 2 | ----------- The core concept of the above architecture is Abstract IOR (AIOR). AIOR can be described by a simple equation: AIOR = SP's regular IOR + logical name Logical name is uniquely corresponding to an IOR of an object running on background server. So the SP should set up the mapping before corresponding request comes, and map the logical name in the AIOR to the regular IOR of the target object at background server for a coming request. The structure of AIOR is compatible to regular IOR. Firstly let's have a look at the structure of regular IOR defined at page 13-15. Then we will discuss how to support AIOR based on existing IOR data structures and what interfaces and methods will be defined. module IOP { // IDL // Standard Protocol Profile tag values typedef unsigned long ProfileId; struct TaggedProfile

    { ProfileId tag; sequence <octet> profile_data; }

    ; typedef sequence <TaggedProfile> TaggedProfileSeq ; // an Interoperable Object Reference is a sequence of // object-specific protocol profiles, plus a type ID. struct IOR

    { string type_id; sequence <TaggedProfile> profiles; }

    ; // Standard way of representing multicomponent profiles. // This would be encapsulated in a TaggedProfile. typedef unsigned long ComponentId; struct TaggedComponent

    { ComponentId tag; sequence <octet> component_data; }

    ; typedef sequence<TaggedComponent> TaggedComponentSeq; }; CORBA specification defines 3 standard IOR profiles (at page 13-17): module IOP

    { const ProfileId TAG_INTERNET_IOP = 0; const ProfileId TAG_MULTIPLE_COMPONENTS = 1; const ProfileId TAG_SCCP_IOP = 2; typedef sequence <TaggedComponent> MultipleComponentProfile; }

    ; The following are standard IOR components that can be included in TAG_INTERNET_IOP and TAG_MULTIPLE_COMPONENTS profiles, and may apply to IIOP, other GIOPs, ESIOPs, or other protocols. An ORB must not drop these components from an existing IOR (at page 13-19). module IOP

    { const ComponentId TAG_ORB_TYPE = 0; const ComponentId TAG_CODE_SETS = 1; const ComponentId TAG_POLICIES = 2; const ComponentId TAG_ALTERNATE_IIOP_ADDRESS = 3; const ComponentId TAG_ASSOCIATION_OPTIONS = 13; const ComponentId TAG_SEC_NAME = 14; const ComponentId TAG_SPKM_1_SEC_MECH = 15; const ComponentId TAG_SPKM_2_SEC_MECH = 16; const ComponentId TAG_KerberosV5_SEC_MECH = 17; const ComponentId TAG_CSI_ECMA_Secret_SEC_MECH = 18; const ComponentId TAG_CSI_ECMA_Hybrid_SEC_MECH = 19; const ComponentId TAG_SSL_SEC_TRANS = 20; const ComponentId TAG_CSI_ECMA_Public_SEC_MECH = 21; const ComponentId TAG_ GENERIC_SEC_MECH = 22; const ComponentId TAG_FIREWALL_TRANS = 23; const ComponentId TAG_SCCP_CONTACT_INFO = 24; const ComponentId TAG_JAVA_CODEBASE = 25; const ComponentId TAG_TRANSACTION_POLICY = 26; const ComponentId TAG_MESSAGE_ROUTERS = 30; const ComponentId TAG_OTS_POLICY = 31; const ComponentId TAG_INV_POLICY = 32; const ComponentId TAG_CSI_SEC_MECH_LIST = 33; const ComponentId TAG_NULL_TAG = 34; const ComponentId TAG_SECIOP_SEC_TRANS = 35; const ComponentId TAG_TLS_SEC_TRANS = 36; const ComponentId TAG_ACTIVITY_POLICY = 37; const ComponentId TAG_INET_SEC_TRANS = 123; }

    ; The following additional components that can be used by other protocols are specified in the DCE ESIOP chapter of this document and CORBAServices, Security Service, in the Security Service for DCE ESIOP section (at page 13-19, 13-20): const ComponentId TAG_COMPLETE_OBJECT_KEY = 5; const ComponentId TAG_ENDPOINT_ID_POSITION = 6; const ComponentId TAG_LOCATION_POLICY = 12; const ComponentId TAG_DCE_STRING_BINDING = 100; const ComponentId TAG_DCE_BINDING_NAME = 101; const ComponentId TAG_DCE_NO_PIPES = 102; const ComponentId TAG_DCE_SEC_MECH = 103; // Security Service The following is the description of our proposed supplement to CORBA core specification. We add one component into module IOP: const ComponentId TAG_AIOR_LOGICALNAME = XXX; // XXX is an undetermined ComponentId. The TAG_AIOR_LOGICALNAME component has an associated value of type string encoded as a CDR encapsulation. We have not defined the interface of mapping logical names to regular IOR because now this function is local and its interoperability is not necessary. But if two or more SPs want to exchange their mapping items to provide more intelegent services, we may need to define the coresponding interfaces.

  • Reported: CORBA 3.0.3 — Thu, 15 Jul 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Mapping from -ORBxxx to Java properties does not work for -ORBInitRef

  • Legacy Issue Number: 6007
  • Status: closed  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The CORBA 3.0 spec adds the following note in Section 4.5.1: ORB Initialization.

    "Whenever an ORB_init argument of the form -ORBxxx is specified, it is understood that the argument may be represented in different ways in different languages. For example, in Java -ORBxxx is equivalent to a property named org.omg.CORBA.ORBxxx."

    The approach stated in the above note does not work for -ORBInitRef. For example, if you have
    -ORBInitRef NameService=URL,
    you cannot translate the above arguments into a property named "org.omg.CORBA.ORBInitRef" because there can be only one property of this name and there may be many different services. This issue was slightly cover by Issue 3643 (java-rtf), which was not resolved. This issue becomes obvious and important because the note added in the CORBA 3.0 spec.

    Proposed solution: Arguments like "-ORBInitRef id=url" should be equivalent to a property named "org.omg.CORBA.ORBInitRef.id" with value "url".

  • Reported: CORBA 3.0.2 — Sat, 19 Jul 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The POA state inactive is not used consistent.

  • Legacy Issue Number: 7955
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The POA state inactive is not used consistent. On several places it is called deactivated instead of inactive. For example in 11.3.8.2, in the transient bullet, it mentions: "Once the POA's POAManager enters the dactivated state". Chapter 11.3.2.1 describes clearly the states are: active, inactive, holding and discarding. I would propose to scan the complete spec for these incorrect POA Manager state.

  • Reported: CORBA 3.0.3 — Wed, 1 Dec 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CORBA 3.0.3 ch. 3.4 OMG IDL Grammar

  • Legacy Issue Number: 7978
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    The grammar definition for valuetype <state_member> via the rule
    <declarators> includes <complex_declarator>.

    It should be clarified whether valuetype state members are intended
    to include <array_declarator>.

    IMHO clarification is needed as state members are usually mapped
    to accessor methods in programming languages. If permissible,
    the accessor methods would return a complex type.

  • Reported: CORBA 3.0.3 — Wed, 15 Dec 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

argument of the set_servant call has a small typo

  • Legacy Issue Number: 7896
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The argument of the set_servant call has a small typo, it must be p_servant to match the full IDL spec some pages further

  • Reported: CORBA 3.0.3 — Tue, 2 Nov 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 4.3.13

  • Legacy Issue Number: 8221
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec describes respository_id which should be repository_id. Is on two places, in 4.3.14 and 4.3

  • Reported: CORBA 3.0.3 — Thu, 3 Feb 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

change in the POAManager

  • Legacy Issue Number: 7893
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    I would propose to change in the POAManager the following: State get_state(); string get_id(); to readonly attribute State the_state; readonly attribute string the_id; The get method just hide the fact that this are readonly attributes

  • Reported: CORBA 3.0.3 — Mon, 1 Nov 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Issue: CSIv2 Identity Assertion

  • Legacy Issue Number: 3907
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Issue on Document orbos/2000-08-04, CSIv2 Joint Submission

    Document: orbos/2000-08-04, CSIv2 Joint Submission
    Subject: Identity Assertion of X.501 Distinguished Name is not good enough
    Severity: Critical

    Summary:

    The Identity Token union contains a branch that is labled
    X501DistinguishedName. A single DN is insufficient to identify an entity.
    A path of X501Distinguished Names is needed instead. Also, other concerns
    about naming types are raised.

    Discussion:

    An X.501 Distinguished Name is insufficient to identify a single entity.
    The name must be accompanied by the name of its defining authority. In the
    case of public key certificates, the names certificate authority must be
    included.

    The chain of DNs in this manner must be included up to a root authority
    to have any definitive meaning.

    This approach will be consistent with the client sending a X.509
    Certificate Chain. A DN path is actually defined by the certificate chain.

    Furthermore, the DN path should only come from an authority that is
    acceptable to the server, whether it be a DN path, or an X.509
    Certificate Chain.

    The IOR should list the acceptable authorities and their name types.

    It is becoming more an more evident that we must invent GSS_NT_Export_Name
    types for X.509 Certificate Chain and X.501 DN path.

    The SAS_ContextSec structure should list, instead of the naming types,
    the naming authorities!

    We shall assume that the name types of the asserted identities shall be
    the same as the name types of listed naming authorities in the IOR.

    This is the only way this procedure can work Interoperable and without
    the client Guessing what it should do.

    Suggestions:

    An OID for an X.509 Public Key Certificate Chain shall be defined for a
    GSS Export Name, and its encoding will be a ASN1 sequence of and X.509
    certificate with the least significant certificate first.

    An OID for an X.501 Distinguished Name Path shall be defined for a GSS
    Exported Name, and its encoding shall be an ASN1 sequence of an X.501
    Distinguished Name with the least significant name first.

    To avoid having the target put a whole certificate chain in its IOR,
    a new OID shall be allocated in which its GSS Exported Name encoding is a
    X.501 DN path, but stipulates that the client should send a certificate
    chain from that named authority. This GSS Exported Name shall only be
    used in IORs and not for transmission in the Identity Token.

    typedef Security::GSS_NT_ExportedName NamingAuthority;

    struct CompoundSecMech

    { Security::AssociationOptions target_requires; IOP::TaggedComponent transport_mech; sequence<ServiceConfiguration> privilege_authorities; sequence<NamingAuthority> naming_authorities; }

    ;

  • Reported: CORBA 2.3.1 — Wed, 20 Sep 2000 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Polymorphic Valuetypes and the DII

  • Legacy Issue Number: 3674
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    Using the static invocation interfaces, it is possible to receive a
    valuetype that derives from the one declared in an operation, as long
    as a valuetype factory is known in the receiver (truncation is not the
    issue here).

    The same is not possible at the DII: When creating the request, the
    caller must indicate what type it expects, by forming a named value.
    Conceptually, the typecode in the named value should be the typecode
    of the base of all acceptable value types. However, if the ORB
    receives a derived type, it has no means of unmarshalling it - even if
    the application has knowledge about the derived type.

    What is missing is an interface to make typecodes of value types known
    to the ORB; with those, the ORB could then understand the CDR of the
    valuetype, and create a DynAny when asked to.

  • Reported: CORBA 2.3.1 — Wed, 7 Jun 2000 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

DynValue & custom valuetypes

  • Legacy Issue Number: 3459
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3.1 specification does not cover the interaction between the
    DynValue interface and custom valuetypes.

    I frankly don't see any way that the DynValue interface can possibly
    correctly handle a custom valuetype when the ORB does not have a factory
    for the type. It is theoretically possible for DynValue to properly
    work with a known custom type, but the implementation strategy could not
    be based on parsing the marshalled form of the valuetype.

    So, there are two issues that need to be addressed:

    1. Should DynValue handle custom valuetypes at all?

    2. For the set of custom valuetypes that it cannot handle, what
    exceptions should be raised by each operations?

  • Reported: CORBA 2.3.1 — Sat, 25 Mar 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Code Set Conversion on Operations

  • Legacy Issue Number: 8244
  • Status: closed  
  • Source: Motorola ( Gary Duzan)
  • Summary:

    The "operation" field in the RequestHeader_1_2 struct is a string,
    which implies that it should be subject to code set conversion. However,
    existing practice seem to be that it is not converted, and there are other
    factors which could make it difficult for implementations to convert it.
    In addition, since the operation name is based on IDL/ASCII, conversion
    doesn't necessarily make sense.

    The easiest remedy would be to specify this as an exception in the
    text of the spec. The "correct" remedy would probably be to change the
    operation field from "string" to "sequence<octet>". This could cause
    problems at some point, but it might not break too much since the CDR
    encodings are the same.

  • Reported: CORBA 3.0.3 — Mon, 7 Feb 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Potential deadlock with POA::deactivate_object()

  • Legacy Issue Number: 2772
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The draft CORBA 2.3 spec (ptc/99-03-07) does not deal with a potential deadlock situation. If an object is explicitly deactivated with POA::deactivate_object(), the object remains in the active object map until all operations pending on the object have completed. Any attempts to reactivate the object (implicitly via a ServantActivator, or explicitly via activate_object_with_id()) must block until the pending invocations have completed. However, if a servant's implementation of an object deactivates the object and then (directly or indirectly through a call to another collocated object) reactivates the object, the invocation will deadlock.

  • Reported: CORBA 2.3 — Mon, 28 Jun 1999 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Custom Value Marshaling Issue

  • Legacy Issue Number: 3097
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

    Due to the way that custom values are marshaled it is
    nearly impossible for a bridge (or other process) to
    process/forward GIOP messages which contain custom
    marshaled values (which the bridge has no compile/run-time
    knowledge of).

    The main issue is that the "alignment" of the
    custom marshaled data is unknown, other than the
    data will always start on a four byte boundry due
    to the presence of chunking.

    Should/could the value encoding format be changed to
    enforce eight byte alignment for all custom marshaled
    data (chunks)? This would allow bridges and other
    tools to process->[store]->forward messages containing
    custom values.

  • Reported: CORBA 2.3.1 — Tue, 7 Dec 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Appendix A

  • Legacy Issue Number: 8230
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The overview of all system exceptions is missing several ones which seem to be availalble in http://www.omg.org/docs/omg/03-01-04 For example NO_IMPLEMENT_TABLE minor code 8 is missing

  • Reported: CORBA 3.0.3 — Fri, 4 Feb 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

ForwardRequest is impossible to detect in clients

  • Legacy Issue Number: 5266
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    REQUIREMENT

    To be able to use interceptors, and in particular ForwardRequest, in a client to perform active, per-request, load-balancing.

    PROBLEM

    It is not possible to detect in an interceptor whether ForwardRequest has previously been thrown for the same client request. Thus it is possible for a client to go into an infinite loop throwing ForwardRequest.

    DISCUSSION

    The basic problem is that although for a single client request the request-scoped PICurrent is shared across across interceptor invocations - even when ForwardRequest is thrown - it is not possible to modify this information in an interceptor to indicate to a future invocation that the invocation has been seen. The two relevant parts of the spec here are:

    21.3.6.5

    For retries, depending on the policies in effect, a new request may or may not follow
    when a retry has been indicated. If a new request does follow, while this request is a
    new request, with respect to Interceptors, there is one point of correlation between the
    original request and the retry: because control has not returned to the client, the request
    scoped PortableInterceptor::Current for both the original request and the retrying
    request is the same (see Chapter 21, Portable Interceptors on page 21-32).

    21.4.2

    Before an invocation is made, PICurrent is obtained via a call to
    ORB::resolve_initial_references ("PICurrent")
    From within the interception points, the data on PICurrent that has moved from the
    thread scope to the request scope is available via the get_slot operation on the
    RequestInfo object. A PICurrent can still be obtained via
    resolve_initial_references, but that is the Interceptor's thread scope PICurrent.
    See section 21.4.4.4, Request Scope vs Thread Scope on page 21-36 for a detailed
    discussion of the scope of PICurrent.

    Thus modifications to the thread's PICurrent are lost on retries and modifications to the request's PICurrent are not possible.

    PROPOSED RESOLUTION

    I have made several different attempts at coming up with a portable way of solving this problem without changing the spec, but have failed. It seems to me that it really should be possible for the interceptor to know that a retry is in effect and I can think of a number of different solutions to this:

    1. add:
    void set_slot (in SlotId id, in any data) raises (InvalidSlot);
    to RequestInfo. This would allow interceptors to transfer information between invokes of the same client request and thus a retry could be detected.

    2. Add a new function to RequestInfo to indicate that a forward is in operation. The minimalist fix here would be to allow forward_reference() to be accessed in send_request() as well as in receive_other(). i.e. returning the object from the previous ForwardRequest if that has been thrown.

    I'm ambivalent about which of these is best but for the sake of simplicity I'm going to plump for (1) because this is already allowed in ServerRequestInfo.

    So:

    • Change the IDL in 21.3.12 to include
      void set_slot (in SlotId id, in any data) raises (InvalidSlot);
    • After 21.3.12.12 move in the text from 21.3.14.6
    • Change the IDL in 21.3.14 to remove set_slot()
  • Reported: CORBA 2.6.1 — Thu, 2 May 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Avoiding RSC/TSC copy on server side

  • Legacy Issue Number: 4169
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    During the interceptor FTF we changed the server-side threading
    requirements such that all server-side points run in the same thread
    as the ServantManager and servant except receive_request_service_contexts.

    We attempted to update 21.4.4.4 "Request Scope vs Thread Scope"
    accordingly but knew we screwed the picture and wording up. So we
    punted to the RTF.

    The main problem with the current wording is that is forces a copy of
    of TSC/RSC before the servant manager and then receive_request are
    called. This is necessary because 21.4.4.5 item 5 says: "The
    receive_request points may modify the RSC, but this no longer affects
    the TSC."

    The only way to make RSC identical to TSC in receive_request with
    respect to reading but also have them be independent with respect to
    writing is to make a copy (which could be optimized to copy-on-write,
    but why?).

    I suggest we just state they are equivalent after
    receive_request_service_contexts.

    Here is a proposed revision to ptc/00-08-06 along these lines.

    Comments?
    Harold

    21.4.4.4 Request Scope vs Thread Scope

    ... On the server-side, the request scope PICurrent is attached to
    the ServerRequestInfo and follows the request processing. It is
    logically equivalent to the thread scope PICurrent after the list of
    receive_request_service_contexts interception points are processed.

    21.4.4.5 Flow of PICurrent between Scopes

    5. The ORB logically makes the RSC equivalent to the server-side TSC
    after the receive_request_service_contexts points are processed and
    before the servant manager is called. This TSC is within the context
    for both the receive_request points, the invocation of the servant
    manager, and the invocation of the target operation.

    The receive_request points are called. These points have access to the
    RSC. Modifying the RSC at this point makes corresponding
    modifications on the TSC. Since these points execute in the same
    thread as the target operation invocation, these points may modify the
    server-side TSC which makes corresponding modifications on the RSC.

    6. After the receive_request points are called, control transfers to
    the server threads which may also read and write this server-side TSC.
    Any modifications to the TSC makes corresponding modifications on the
    RSC.

    7. <No change>

    8. <DELETE THIS ITEM>

    9. The send interception points have access to the RSC (and the
    equivalent TSC) from which they may populate the reply service context
    list. After the invocation result is sent back to the client, the
    server-side RSC is logically destroyed.

    ...

    The picture would also need updating, but let's agree on wording first.

  • Reported: CORBA 2.4.1 — Tue, 23 Jan 2001 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Implications of any/valuetype marshalling

  • Legacy Issue Number: 4137
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    RE: CCM chapters document [orbrev] 99-10-04, section 61.6.2, page 61-45.
    The document citation indicates that the integrity of the valuetype –
    that is, the received marshalled state – is to be preserved in an
    ORB-mediated operation, even if that valuetype cannot be unmarshalled,
    either partially (truncated) or at all. If this value is then passed to
    another operation, the original marshalled state is to be transmitted.
    This preserves the transmitted object in its entirety, regardless of
    local implementation concerns. This is obviously necessary for bridges
    or event processing, such as through the notification service.

    So the question arises, what happens if you have a partial (truncated)
    unmarshall and the recipient application changes the local state of the
    valuetype through its attributes or local operations? How can/will you
    even know the state was changed? Do you ignore the changes and send the
    originally received marshalled stream, send only the new valuetype even
    though it is a truncation of the original, or "merge" the new values for
    the unmarshalled part followed by the original appended data for the
    truncated part? Should this third option be possible through an
    explicit ORB call – that is, the application is responsible to identify
    the change in state to the ORB? I assume that the semantics of
    "truncatable" must come to include the understanding that data in the
    truncatable portions may not be contextually dependent on the inherited
    parent of the valuetype.

    As a further question, is there a reason why this semantic
    interpretation should not be extended to be a general requirement rather
    than only with respect to transmission of anys? My experience has found
    that passing anys tends to be expensive and is avoided where it can be.
    A more general interpretation permits transmission of a comprehensive
    data structure among intermediate agents that only use (unmarshall) the
    information they need.

  • Reported: CORBA 2.4.1 — Fri, 5 Jan 2001 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Proposal for extension to CosNaming

  • Legacy Issue Number: 5214
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    Since there doesn't appear to be a CosNaming mailing list this seems like as good a forum as any this discussion.

    It has long struck me that the use of CosNaming for JNDI in J2EE applications creates a significant outage in being able to bind and retrieve objects that are not remote (see the EJB 2.0 spec for details). In JNDI you can bind pretty much anything that is Remote (aka an Object reference) or Serializable (aka a valuetype), however CosNaming only allows you to do the former.

    One easy way to solve this would be to create a new NamingContext extension that allows one to bind and resolve Any's. This is in keeping with the Java-to-IDL spec's treatment of untyped Java objects and at the same time would not compromise non-java implementations. For JNDI it would only be necessary to support Any's containing:

    1. Object references
    2. valuetypes
    3. valueboxes

    An exception could be thrown for any other types. The candidate interface might look something like this:

    module CosNaming {
    interface NamingContextAny : NamingContextExt {
    exception TypeNotSupported {};

    void bind_any(in Name n, in any obj)
    raises (NotFound, CannotProceed,
    InvalidName, AlreadyBound, TypeNotSupported);

    void rebind_any(in Name n, in any obj)
    raises(NotFound, CannotProceed, InvalidName, TypeNotSupported);

    any resolve_any (in Name n)
    raises (NotFound, CannotProceed, InvalidName);

    any resolve_str_any(in StringName n)
    raises (NotFound, CannotProceed,
    InvalidName, AlreadyBound);
    };
    };

    The implementation of this interface in Java is trivial, although perhaps less so in other languages. Whether or not that matters is open to question.

  • Reported: CORBA 2.6 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

New issue: ForwardRequest()

  • Legacy Issue Number: 5231
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    The Portable Object Adapter and Portable Interceptors both are able to
    raise a ForwardRequest exception to allow redirection to another
    object.

    What happens if the ForwardRequest is to a local object?

    Is this even possible?

    Should it be allowed?

    I suggest we change the specification to make this illegal.

  • Reported: CORBA 2.6 — Thu, 25 Apr 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How does an ORB implement Object::get_policy for PI defined policies?

  • Legacy Issue Number: 4065
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The description for Object::get_policy (in the Core, section 4.3.7.1)
    states:

    "The get_policy operation returns the policy object of the specified
    type (see Policy Object on page 4-32), which applies to this object. It
    returns the effective Policy for the object reference. The effective
    Policy is the one that would be used if a request were made."

    For a policy defined by PI, I don't see anyway for the ORB to implement
    this operation correctly, since there isn't any way for it to know how
    to properly resolve any client override policies with the policy
    information stored in the IOR.

    When a invocation is actually in process, the ClientRequestInterceptor
    can use the information available in the ClientRequestInfo interface to
    get the client override and the IOR policy data and do the correct
    resolution before continuing with the request. However,
    Object::get_policy() needs to do the same type of thing, but it has no
    invocation context to do it in.

    I think the same problem also applies to the implementation of
    ClientRequestInfo::get_request_policy().

    I think we need a new interception point to do this work. Something
    like:

    local interface PolicyInterceptor

    { any determine_effective_policy(in PolicyInfo pi); }

    ;

    local interface PolicyInfo

    { readonly attribute Object target; readonly attribute Object effective_target; readonly attribute IOP::TaggedProfile effective_profile; IOR::TaggedComponent get_effective_component (in IOP::ComponentId id); IOP_N::TaggedComponentSeq get_effective_components (in IOP::ComponentId id); }

    ;

    If this turns out to be an acceptable solution, then we should also
    change ClientRequestInfo to:

    local interface ClientRequestInfo : RequestInfo, PolicyInfo

    { ... }

    ;

    and remove the redundant operations.

  • Reported: CORBA 2.4.1 — Sat, 18 Nov 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

rule (85) is misplaced

  • Legacy Issue Number: 15715
  • Status: closed  
  • Source: stegny.2a.pl ( Christopher Yeleighton)
  • Summary:

    The rule number (85) is indented, the rule number is not aligned with other rule numbers.

  • Reported: CORBA 3.1 — Thu, 30 Sep 2010 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

processing TaggedComponents within an IOR

  • Legacy Issue Number: 5439
  • Status: closed  
  • Source: International Business Machines ( Ann Collins)
  • Summary:

    The overhead of processing TaggedComponents within an IOR becomes
    significant when done many times, as in the case of J2EE
    implementations where multiple interceptors are used.

    The definition of IORs in the IOP module is intended to support
    transmission and interoperability, rather than efficient access to the
    local, ORB specific, internal structure.

    I would like to propose that an abstract model of an IOR is introduced
    which recognises that many of the constituent parts of IOR profiles are
    identical for different objects, along the following lines:-

    • an IOR has a type ID string, and contains TaggedProfile instances
    • a TaggedProfile has an ID and data
    • an IIOPProfile is a TaggedProfile; it is composed of an
      IIOPProfileTemplate and an object ID.
    • an IIOPProfileTemplate has IIOP addressing information, and contains
      TaggedComponents.
    • a TaggedComponent has an ID and data
    • a TaggedComponentFactory creates a TaggedComponent
    • a TaggedProfileFactory creates a TaggedProfile

    with corresponding IDL definitions that allow the language bindings
    to optimise conversion between transmission and internal IOR formats
    to provide a performant and natural interface for IOR access.

    Rationale:
    In Java, for example, it should be possible to manipulate IOR
    TaggedProfiles and IIOPProfileTemplate TaggedComponents using the
    facilities of the Java collections framework, or at least some
    equivalent facility that is a natural Java idiom.

    Templates can be used to create IIOPProfiles because the basic object
    adapter model for object creation is to establish many of the properties
    of an IOR when the object adapter is created.

    • This has been present for the POA essentially from the beginning, since
      policies can only be passed to create_POA, and cannot be changed on an
      existing POA.
    • The Portable Interceptors work has also made this clear, since the IOR
      interceptor establish_components method, which is the only time that
      user code can add tagged components to an IOR, is only guaranteed to
      be called once for each distinct set of server policies i.e need only
      be run when an object adapter is created.
    • It is also likely that more than one object within an adapter will
      map to a TCP endpoint.

    TaggedProfile and TaggedComponent are intended as frameworks that may be
    extended to support application defined tagged profiles and components.
    To support this it is necessary to be able to register TaggedProfile and
    TaggedComponentFactory instances with an ORB, in which case any IOR
    unmarshalled by that ORB instance will use the registered factory
    to unmarshal the tagged profile or component.

    Since there has already been quite a bit of discussion about this in the
    Java RTF, here is a proposal for review:-

    Proposal:

    • add the following sections after the IOR Interceptor Overview:-

    21.5.2 An Abstract Model for IORs

    To support efficient access to IORs, avoiding repeated marshaling and
    demarshaling of IOR components, it is helpful to have an abstract model
    of the, ORB specific, local representation of an IOR.

    Recognising that many of the constituent parts of IOR profiles are
    identical for different objects allows the following model to be
    defined:-

    • an IOR has a type ID string, and contains TaggedProfile instances
    • a TaggedProfile has an ID and data
    • an IIOPProfile is a TaggedProfile; it is composed of an
      IIOPProfileTemplate and an object ID.
    • an IIOPProfileTemplate has IIOP addressing information, and contains
      TaggedComponents.
    • a TaggedComponent has an ID and data
    • a TaggedComponentFactory creates a TaggedComponent
    • a TaggedProfileFactory creates a TaggedProfile

    21.5.3 Local IOR Interfaces

    The following interfaces provide access to the data within a local IOR
    using this model.

    TaggedProfile and TaggedComponent are generic interfaces. Users of the ORB
    may create implementations of them. Corresponding factories may be
    registered with the IORFactory.

    The IORFactory is obtained through a call to
    ORB::resolve_initial_references ("IORFactory") and may also be used to
    obtain an IOR for an Object.

    An ORB must return all tagged profiles in an IOR through the IOR
    getProfiles operations. The ProfileIterator interface allows a client
    to iterate through the TaggedProfiles using the next operation.
    Those profiles whose ids have a registered TaggedProfileFactory will
    be made available in the form returned by the registered factory's
    TaggedProfileFactory create operation, which must return a subtype of
    TaggedProfile.

    An ORB will provide a TaggedProfileFactory implementation for the
    IIOPProfile.

    Profiles with ids for which no TaggedProfileFactory has been registered
    will be made available as instances of a generic ORB implementation of
    TaggedProfile.

    Similarly, an ORB must return all tagged components in an IIOP profile
    through the IIOPProfile().getTemplate().getComponents() operations.
    The ComponentIterator interface allows a client to iterate through the
    TaggedComponents using the next operation.
    Those components whose ids have a registered TaggedComponentFactory
    will be made available in the form returned by the registered factory's
    TaggedComponentFactory create operation, which must return a subtype of
    TaggedComponent.
    Components with ids for which no TaggedComponentFactory has been
    registered will be made available as instances of a generic ORB
    implementation of TaggedComponent.

    module PortableInterceptor {

    local interface TaggedComponent

    { readonly attribute IOP::ComponentId component_id; readonly attribute CORBA::OctetSeq component_data; IOP::TaggedComponent convert(); }

    ;

    local interface ComponentIterator

    { TaggedComponent next(); boolean has_next(); }

    ;

    local interface TaggedProfile

    { readonly attribute IOP::ProfileId profile_id; readonly attribute CORBA::OctetSeq profile_data; IOP::TaggedProfile convert(); }

    ;

    local interface ProfileIterator

    { TaggedProfile next(); boolean has_next(); }

    ;

    local interface IOR

    { readonly attribute string type_id; ProfileIterator get_profiles (); ProfileIterator get_profiles_by_id (in IOP::ProfileId profile_id); }

    ;

    local interface IIOPProfileTemplate

    { readonly attribute IIOP::Version iiop_version; readonly attribute string host; readonly attribute unsigned short port; ComponentIterator get_components(); ComponentIterator get_components_by_id (in IOP::ComponentId id); }

    ;

    local interface IIOPProfile:TaggedProfile

    { readonly attribute CORBA::OctetSeq object_key; readonly attribute IIOPProfileTemplate profile_template; }

    ;

    local interface TaggedComponentFactory

    { readonly attribute IOP::ComponentId factory_id; TaggedComponent create_tagged_component (in CORBA::OctetSeq component_data); }

    ;

    local interface TaggedProfileFactory

    { readonly attribute IOP::ProfileId factory_id; TaggedProfile create_tagged_profile (in CORBA::OctetSeq profile_data); }

    ;

    local interface IORFactory

    { IOR create_ior (in Object obj); void register_tagged_profile_factory (in TaggedProfileFactory tpf); void register_tagged_component_factory (in TaggedComponentFactory tcf); }

    ;

    };

    21.5.3.1 IOR Factory Interface

    create_ior
    Return an IOR relating to the given Object.

    If create_ior is invoked when the object reference is not bound,
    standard system exception BAD_INV_ORDER with minor code n will be
    raised.

    register_tagged_profile_factory
    Register a TaggedProfileFactory to create TaggedProfiles with the id
    returned by the given factory's getId method. If a TaggedProfileFactory
    already exists for the given id, standard system exception
    BAD_INV_ORDER is raised with a standard minor code of n+1.
    Instances of this interface may be defined by users to support custom
    tagged profiles.

    register_tagged_component_factory
    Register a TaggedComponentFactory to read TaggedComponents with the id
    returned by the given factory's getId method. If a
    TaggedComponentFactory already exists for the given id, standard system
    exception BAD_INV_ORDER is raised with a standard minor code of n+2.
    Instances of this interface may be defined by users to support custom
    tagged components.

    21.5.3.2 IOR Interface

    This interface gives access to a local representation of an
    IOP::IOR.

    type_id
    The type id string from the IOR.

    get_profiles
    Returns an iterator over the TaggedProfiles within the IOR.

    get_profiles_by_id
    Returns an iterator over the TaggedProfiles with the given
    Profileid.

    21.5.3.3 TaggedProfile Interface

    This interface gives access to a local representation of an
    IOP::TaggedProfile.

    profile_id
    This attribute is the identifier for this TaggedProfile.

    profile_data
    This attribute is the data from the TaggedProfile. It is
    normally a CDR encapsulation.

    convert
    Create an IOP representation of this TaggedProfile

    21.5.3.4 TaggedComponent Interface

    This interface gives access to a local representation of an
    IOP::TaggedComponent.

    component_id
    This attribute is the identifier for this TaggedComponent.

    component_data
    This attribute is the data from the TaggedComponent. It is
    normally a CDR encapsulation.

    convert
    Create an IOP representation of this TaggedComponent.

    21.5.3.5 TaggedProfileFactory Interface

    factory_id
    This attribute is the identifier of profiles created by this
    TaggedProfileFactory.

    create
    Create a TaggedProfile from the given profile_data.

    21.5.3.6 TaggedComponentFactory Interface

    factory_id
    This attribute is the identifier of components created by this
    TaggedComponentFactory.

    create
    Create a TaggedComponent from the given component_data.

    21.5.3.7 ProfileIterator Interface

    next
    Returns the next TaggedProfile in the iteration. If next is called
    after the last TaggedProfile has been returned, BAD_INV_ORDER will
    be raised with a standard minor code of n+3.

    If an IOR is modified in between calls to next, the behavior of
    further calls to next is implementation dependent.

    has_next
    Returns true if the iteration has more elements. In other words,
    returns true if next would return an element rather than throwing
    an exception.

    21.5.3.8 ComponentIterator Interface

    next
    Returns the next TaggedComponent in the iteration. If next is called
    after the last TaggedComponent has been returned, BAD_INV_ORDER will
    be raised with a standard minor code of n+3.

    If a profile is modified in between calls to next, the behavior of
    further calls to next is implementation dependent.

    has_next
    Returns true if the iteration has more elements. In other words,
    returns true if next would return an element rather than throwing
    an exception.

    21.5.3.9 IIOPProfile Interface

    object_key
    This attribute is the Object key contained in this IIOPProfile.

    profile_template
    This attribute is the IIOPProfileTemplate associated with this
    IIOPProfile.

    21.5.3.10 IIOPProfileTemplate Interface

    iiop_version
    This attribute is the GIOP version of this profile. If the major
    value is 1 and the minor value is 0, this profile cannot contain
    any TaggedComponents.

    host
    This attribute is the host name string of this IIOPProfileTemplate.

    port
    This attribute is the port number of this IIOPProfileTemplate.

    get_components
    Return an iterator over the TaggedComponents within the
    IIOPProfileTemplate.

    get_components_by_id
    Returns an iterator over the TaggedComponents with the given
    ComponentId.

    In current Section 21.5.3:

    • add the following after the ORBInfo Interface

    local interface IORInfo_3_n:IORInfo

    { ProfileIterator get_profiles (); ProfileIterator get_profiles_by_id (in IOP::ProfileId profile_id); }

    ;

    • add the following sections:

    21.5.3.4 get_profiles
    Returns an iterator over the TaggedProfiles within the IOR.

    21.5.3.5 get_profiles_by_id
    Returns an iterator over the TaggedProfiles within the IOR with the
    given Profileid.

    Parameter Description
    profile_id The IOP::ProfileId of the profiles in the iteration
    to be returned.

    • add the IORFactory to the list of reserved ObjectIds for
      resolve_initial_references in section 4.5.2
  • Reported: CORBA 3.0 — Tue, 25 Jun 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bad quotes and imported dot

  • Legacy Issue Number: 15714
  • Status: closed  
  • Source: stegny.2a.pl ( Christopher Yeleighton)
  • Summary:

    Is:
    A character literal is one or more characters enclosed in single quotes, as in ’x.’
    Should be:
    A character literal is one or more characters enclosed in single quotes, as in 'x'.

    (note that the present version uses curly quotes and the dot is probably misplaced)

  • Reported: CORBA 3.1 — Thu, 30 Sep 2010 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

missing document title

  • Legacy Issue Number: 15713
  • Status: closed  
  • Source: stegny.2a.pl ( Christopher Yeleighton)
  • Summary:

    The document title in PDF metadata
    is "untitled",
    should be
    "Common Object Request Broker Architecture (CORBA)
    Specification"

  • Reported: CORBA 3.1 — Thu, 30 Sep 2010 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 4.8.1

  • Legacy Issue Number: 12551
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The corba spec defines a lot of policies. In 4.8.5 client exposed policies are listed. We do have several of them, also policies could be applied at several levels, but some of them can't be applied to each level. To our idea the scope at which policies can be applied should not only be in the possible, but also part of the policy itself. That way application code and the corba orb could check this. Maybe add this to policy typedef unsigned long PolicyScope; const PolicyScope POLICY_SCOPE_OBJECT = 0x01; const PolicyScope POLICY_SCOPE_CURRENT = 0x02; const PolicyScope POLICY_SCOPE_SCOPE = 0x04; const PolicyScope POLICY_SCOPE_POA = 0x08; const PolicyScore POLICY_SCOPE_CLIENT_EXPOSED = 0x10; Then add to the interface Policy readonly attribute PolicyScope policy_scope; This attribute can then be set in the policy with the values above as bitmask. This can be documented clearly in the documentation, orbs can check this, etc.

  • Reported: CORBA 3.0.3 — Wed, 25 Jun 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

move struct to IOP module

  • Legacy Issue Number: 12550
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The CORBA spec defines the following types to proposage messaging qos. This is really nothing more then propagating policies values. struct PolicyValue

    { CORBA::PolicyType ptype; sequence<octet> pvalue; }

    ; typedef sequence<PolicyValue> PolicyValueSeq; This is now in the Messaging module, but the propagation of policy values is something that we want to use for ZIOP but also seems usable for other libraries. Instead of duplicating this struct to different modules I propose to move this to the IOP module.

  • Reported: CORBA 3.0.3 — Tue, 24 Jun 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Add create_policy with just the type as argument

  • Legacy Issue Number: 17208
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For several cases it would be helpful to have a:

    Policy create_policy(
    in PolicyType type) raises(PolicyError);

    The name of the method has to change, to not conflict with the existing method

  • Reported: CORBA 3.1 — Thu, 1 Mar 2012 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

context should be local interface

  • Legacy Issue Number: 16996
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The context has to be define as local interface instead of a regular interface

  • Reported: CORBA 3.1 — Thu, 12 Jan 2012 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Make anonymous types illegal

  • Legacy Issue Number: 16047
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    the specification already deprecated anonymous types, but to our idea it would be time to update the specification to say that anonymous types are illegal and remove all references to them

  • Reported: CORBA 3.0.3 — Wed, 2 Mar 2011 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Redundant bullet

  • Legacy Issue Number: 16942
  • Status: closed  
  • Source: Kestrel Institute ( Alessandro Coglio)
  • Summary:

    It seems that the last and 4th-to-last bullets both describe the Wstring type. Thus, one should suffice.

  • Reported: CORBA 3.2 — Fri, 30 Dec 2011 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

interface ORB should be local

  • Legacy Issue Number: 16315
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The ORB is intended to be a local object, it is not to be used outside of the process, so it should be a local interface

  • Reported: CORBA 3.0.3 — Tue, 7 Jun 2011 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

There is lack of multiplex publisher port that would mimic functionality of multiplex receptacle

  • Legacy Issue Number: 13105
  • Status: closed  
  • Source: cs.agh.edu.pl ( Jacek Cala)
  • Summary:

    There is lack of multiplex publisher port that would mimic functionality of multiplex receptacle. Having multiplex publisher port it would be easier to connect with dynamically created event consumers such that each consumer would have its own private communication channel with the publisher. In case of dynamically created consumers it is not possible to foresee the number of publisher ports required. For synchronous communication the elegant solution is a component with a multiplex receptacle for which we have separate communication channels.

  • Reported: CORBA 3.1 — Mon, 24 Nov 2008 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.3.13

  • Legacy Issue Number: 10817
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Table 21-1 has the following note: When ClientRequestInfo is passed to send_request, there is an entry in the list for every argument, whether in, inout, or out. But only the in and inout arguments will be available. What is the behaviour when I request an out value? It says only that in/inout are available, but when I have an argument that is of out and I do get the value, do I then get an empty value (which could lead to a crash when using it), do I get an exception? That must be clearly specified by the spec

  • Reported: CORBA 3.0.3 — Tue, 13 Mar 2007 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

16.10 lists register_initial_reference

  • Legacy Issue Number: 13056
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    16.10 lists register_initial_reference. It would be usefull for dynamic systems to also have a unregister_initial_reference (in ObjectId id).

  • Reported: CORBA 3.1 — Mon, 3 Nov 2008 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.7.3

  • Legacy Issue Number: 12555
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    This chapter defines register_orb_initializer. This itself is ok, but at the moment we have a 24*7 system and we get a new ORBInitializer shipped in for example a DLL we maybe want to get rid of a certain orbinitializer that we registered earlier. This is currently not possible, we propose to add an unregister_orb_initializer which makes it possible to unregister an orbinitializer again

  • Reported: CORBA 3.0.3 — Wed, 25 Jun 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

add CORBA::ORB::arg_list

  • Legacy Issue Number: 12773
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For a 24x7 system that doesn't shutdown and gets reconfigured it would be useful if we could for example change "-ORBDefaultInitRef" after the ORB has been initialized. That then would be used for any objects resolved after that. Maybe we could add CORBA::ORB::arg_list (inout arg_list argv); Which would change the arglist

  • Reported: CORBA 3.0.3 — Mon, 11 Aug 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

add interface ORB { Object string_to_object ( in wstring str ); };

  • Legacy Issue Number: 12857
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We see more and more use of unicode. It happens more and more that users have code that gets unicode (wchar) commandline arguments. In order to smoothen corba usage for these users we propose to add interface ORB

    { Object string_to_object ( in wstring str ); }

    ;

  • Reported: CORBA 3.0.3 — Sun, 21 Sep 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 13.7 ServiceContext

  • Legacy Issue Number: 12559
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    ServiceContext is defined as: struct ServiceContext

    { ServiceId context_id; sequence <octet> context_data; }

    ; Anonymous types are deprecated, this should be struct ServiceContext

    { ServiceId context_id; CORBA::OctetSeq context_data; }

    ;

  • Reported: CORBA 3.0.3 — Wed, 25 Jun 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: Part 2, Chapter 11 - MIOP

  • Legacy Issue Number: 12376
  • Status: closed  
  • Source: Lockheed Martin ( Kenton Waller)
  • Summary:

    The MIOP does not provide an analogous operation to PortableServer::POA::create_POA() for the GOA (i.e. there is no PortableGroup::GOA::create_GOA). The lack of an operation of this nature prevents the ability for an interface (i.e. servant) to subscribe to multiple (i.e. more than one) multicast group. To specify to a POA to allow multiple entries in its Active Object Map, the POAs IdUniquenessPolicy would have to be set to MULTIPLE_ID. This can only be done via the POAs create_POA operation. Since there is no GOA create_GOA operation, a GOAs IdUniquenessPolicy cannot be set to MULTIPLE_ID, which prevents a servant from being able to be subscribed to more than one multicast group. I don't know if the OMG explicitly wants to prevent this capability, thus purposely leaving it out of the MIOP specification, or if this is simply an overlooked issue.

  • Reported: CORBA 3.1 — Tue, 8 Apr 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

definition of Invalid Policies changed

  • Legacy Issue Number: 12229
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    The CORBA/e FTF slightly changed the definition of Invalid Policies to: exception InvalidPolicies

    { UShortSeq indices; }

    ; since this avoids the use of an anonymous sequence type, consider changing it (also for consistency).

  • Reported: CORBA 3.1 — Fri, 15 Feb 2008 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

mention of (deprecated) function get_implementation removed from text

  • Legacy Issue Number: 12230
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    CORBA/e FTF (issue 11331): removed mention of (deprecated) function get_implementation from text. Consider making same change for consistency

  • Reported: CORBA 3.1 — Fri, 15 Feb 2008 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Proposal to change PortableInterceptor::ReplyStatus to a real enum

  • Legacy Issue Number: 11514
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Proposal to change PortableInterceptor::ReplyStatus to a real enum. Now it is a short with constant values, but this means there is no real relationship between the type and the possible values as possible with an enum. With for example C++ we then can let the compiler check if we don't use incorrect values. module PortableInterceptor { enum ReplyStatus

    { SUCCESSFUL, SYSTEM_EXCEPTION, USER_EXCEPTION, LOCATION_FORWARD, TRANSPORT_RETRY, UNKNOWN }

    ; };

  • Reported: CORBA 3.0.3 — Tue, 25 Sep 2007 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Proposal to change PortableInterceptor::AdapterState to a real enum

  • Legacy Issue Number: 11515
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Proposal to change PortableInterceptor::AdapterState to a real enum. Now it is a short with constant values, but this means there is no real relationship between the type and the possible values as possible with an enum. With for example C++ we then can let the compiler check if we don't use incorrect values. module PortableInterceptor { enum AdapterState

    { HOLDING, ACTIVE, DISCARDING, INACTIVE, NON_EXISTENT }

    ; };

  • Reported: CORBA 3.0.3 — Tue, 25 Sep 2007 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 15.4.2/16.4.1

  • Legacy Issue Number: 11332
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 15.4.2 and 16.4.1 get_implementation is mentioned, but this method is nowhere else in the spec. Should this method be there? So far as I can see this is deprecated and should be removed.

  • Reported: CORBA 3.0.3 — Fri, 7 Sep 2007 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Third line of 23.1.3.4, ACTIVE must be bold

  • Legacy Issue Number: 11525
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Third line of 23.1.3.4, ACTIVE must be bold

  • Reported: CORBA 3.0.3 — Sun, 30 Sep 2007 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 13.6.10.1

  • Legacy Issue Number: 11161
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Steve Osselton)
  • Summary:

    The use of the '/' character to identify the object key component of a corbaloc URL is ambiguous where a protocol address also contains the character. Example: corbaloc:uiop:/tmp/uiop/xx/steve This could represent either a uiop address '/tmp/uiop' and an object key 'xx/steve/ or a uiop address '/tmp/uiop/xx' and an object key 'steve'. Suggest removing the '/' character from the list of non excaped object key characters (bottom of page 13-26)to resolve this ambiguity. The corbaloc would then become: corbaloc:uiop:/tmp/uiop/xx%27steve

  • Reported: CORBA 3.0.3 — Wed, 18 Jul 2007 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Missing PolicyValue encoding instructions

  • Legacy Issue Number: 18152
  • Status: closed  
  • Source: grisby.org ( Duncan Grisby)
  • Summary:

    Section 17.3.1 of CORBA 3.1 / 3.2 says:

    17.3.1 Structures

    PolicyValue

    This structure contains the value corresponding to a Policy of the
    PolicyType indicated by its ptype. This representation allows the
    compact transmission of QoS policies within IORs and Service
    Contexts. **The format of pvalue for each type is given in the
    specification of that Policy.**

    When the ZIOP 1.0 specification describes the ZIOP policies, it does not
    give the format for pvalue.

  • Reported: ZIOP 1.0 — Wed, 10 Oct 2012 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Invalid IDL (2)

  • Legacy Issue Number: 18151
  • Status: closed  
  • Source: grisby.org ( Duncan Grisby)
  • Summary:

    In the ZIOP 1.0 specification, Annex A has:

    Compressor get_compressor(
    in CompressorId compressor_id,
    in CompressorLevel compression_level)
    raises (UnknownCompressorId);

    CompressorLevel should be CompressionLevel.

  • Reported: ZIOP 1.0 — Wed, 10 Oct 2012 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Two typo's in Annex A.4

  • Legacy Issue Number: 17273
  • Status: closed  
  • Source: Remedy IT ( Marcel Smit)
  • Summary:

    There are two typo's in section A.4 on page 495.
    1
    SERVENT_RETENTION_POLICY_ID should be SERVANT_RETENTION_POLICY_ID
    2
    PortableServer::ServentRetentionPolicy should be PortableServer::ServantRetentionPolicy

  • Reported: CORBA 3.1 — Tue, 27 Mar 2012 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Invalid IDL

  • Legacy Issue Number: 18150
  • Status: closed  
  • Source: grisby.org ( Duncan Grisby)
  • Summary:

    In the ZIOP 1.0 specification, the IDL in Annex A has:

    typedef unsigned short CompressorId { };

    The braces are invalid and should be removed.

  • Reported: ZIOP 1.0 — Wed, 10 Oct 2012 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

struct PolicyValue

  • Legacy Issue Number: 12549
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    This section defines struct PolicyValue

    { CORBA::PolicyType ptype; sequence<octet> pvalue; }

    ; Which should be as below because anonymous types are deprecated struct PolicyValue

    { CORBA::PolicyType ptype; CORBA::OctetSeq pvalue; }

    ;

  • Reported: CORBA 3.0.3 — Tue, 24 Jun 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 7.4

  • Legacy Issue Number: 8630
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Minor formatting issue in: abstract valuetype Pollable

    { boolean is_ready( in unsigned long timeout ); PollableSet create_pollable_set( ); }

    ; boolean is_ready is in the wrong font in the idl overview

  • Reported: CORBA 3.0.3 — Fri, 25 Mar 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Moving *Seq typedefs into ORB chapter

  • Legacy Issue Number: 8586
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In the CORBA specification, chapter 5 (Value Type
    Semantics), section 5.5 (Custom Marshalling), defines
    sequences of primitive types in the CORBA module,
    i.e., CORBA::StringSeq et al. Some of these types are
    then used by the DynamicAny and Portable Interceptor
    chapters.

    The presence of these typedefs in section 5.5 seems
    to imply that they only need to be defined if the ORB
    implements custom marshalling – a feature still
    lacking in some open-source and commercial ORBs.

    In my experience, having worked with multiple ORBs,
    many of them do not provide the complete set of
    typedefs in their "orb.idl" file. Many ORBs only
    provide a limited set, usually, the set that is
    exercised by the other ORB features (such as PI).
    This implies that most ORBs added these typedefs
    on an "as needed" basis instead of simply referring
    to section 5.5.

    I suggest to move these typedefs from section 5.5
    into chapter 4 (ORB interface), e.g., into section
    4.2 (ORB operations) to highlight that these types
    should be present even if custom marshalling is not
    implemented by the ORB.

    Proposed resolution:

    In section 5.5.2 (Marshalling Streams), cut the
    type definitions, starting with AnySeq, up to and
    including WStringSeq.

    In section 4.2, in the IDL code fragment, at the
    beginning of the CORBA module, paste the type
    definitions cut above.

  • Reported: CORBA 3.0.3 — Thu, 17 Mar 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Minor code ambiguity

  • Legacy Issue Number: 8618
  • Status: closed  
  • Source: International Business Machines ( Mr. Neil Richards)
  • Summary:

    In the CORBA specification dated 04-03-12, the last two paragraphs on page 15-33 (section 15.4.1) describe the use of MARSHAL minor codes 7 and 8.
    However, this use of these minor codes is not reflected in the table of minor codes on page A-11 (appendix A).

    Furthermore, MARSHAL minor code 7 has also been assigned (at an earlier date?) to an issue resolved in the Java to IDL specification dated 03-09-04 (see page 1-50 / end of section 1.5.1.5).
    This use of minor code 7 is reflected in the table in the CORBA specification.
    However minor code 10, which is also specified in the same section in the Java to IDL specification, is not documented in the CORBA specification.

    In summary, MARSHAL minor code 7 is double-booked, whilst minor codes 8 (used in the CORBA specification) and 10 (used by the Java to IDL specification) are not documented in the table of codes.

    Proposed solution:

    Change section 15.4.1 to define the use of MARSHAL minor code 9 (in addition to minor code 8), instead of MARSHAL minor code 7.

    Update the table of minor codes on page A-11 with the definitions of MARSHAL minor codes 8, 9 and 10.

  • Reported: CORBA 3.0.3 — Mon, 21 Mar 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Missing size information for decompress()

  • Legacy Issue Number: 18153
  • Status: closed  
  • Source: grisby.org ( Duncan Grisby)
  • Summary:

    The ZIOP body format contains the original length of the compressed
    data, which is important because it allows the compressor to efficiently
    allocate a buffer to uncompress it. Unfortunately, the
    Compressor::decompress() operation is not given that size, meaning that
    it has to guess how big the uncompressed data will be.

    The original data size should be given to the decompress() operation.
    One way to do that without changing the operation signature would be to
    specify that the inout Buffer target sequence should have its length
    pre-populated to the expected size.

  • Reported: ZIOP 1.0 — Wed, 10 Oct 2012 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Typo in sections 22.10.1.1 and 22.10.1.2

  • Legacy Issue Number: 8629
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In section 2.10.1.1, page 22-26 (my copy is formal/04-03-01),
    enumerated item 3, second bullet, the text reads "232-1 - the
    maximum value for unsigned long [...]". The "32" needs to be
    in superscript, i.e., to indicate "2 to the power of 32 minus
    1".

    The same typo exists in section 2.10.1.2, page 22-28, fourth
    paragraph, second bullet (at the top of the page).

  • Reported: CORBA 3.0.3 — Thu, 24 Mar 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.7

  • Legacy Issue Number: 8843
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the draft 3.1 spec chapter 21.7 says the following: An Interceptor's behaviour may itself be modified by one or more Interceptor Policies. These Policy objects are created using a call to ORB::create_policy and are associated with an Interceptor during registration (see Section 21.7.2, ORBInitInfo Interface). All Policy interfaces defined in this section are local. The ORB can be accesed via the implicit get_orb operation of ORBInitInfo. The ORBInitInfo is passed on the pre_init and post_init call of the ORBInitializer but what should be the orb in the pre_init call? The orb is not initialized at that moment? Shouldn't it say that calling get_orb on the ORBInitInfo in the pre_init call gives the default exception that is given when get_orb is called on a local object?

  • Reported: CORBA 3.0.3 — Wed, 1 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

update the spec to not used anonymous types

  • Legacy Issue Number: 8783
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec describes that anonymous types are deprecated and will be removed in the future (as below), but this is used throughout the spec. Before deprecating this fully, update the spec to not used anonymous types: >From 3.11.6 IDL currently permits the use of anonymous types in a number of places. For example: struct Foo

    { long value; sequence<Foo> chain; // Legal (but deprecated) }

    Anonymous types cause a number of problems for language mappings and are therefore deprecated by this specification. Anonymous types will be removed in a future version, so new IDL should avoid use of anonymous types and use a typedef to name such types instead. Compilers need not issue a warning if a deprecated construct is encountered.

  • Reported: CORBA 3.0.3 — Wed, 18 May 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.9.1

  • Legacy Issue Number: 8844
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The draft document says the following in 21.9.1. The description about the type of exceptions sounds very vague. Shouldn't the spec be more detailed, which type of exceptions should be ignored specifically? Any exceptional return from the invocation of any operation of the ORBInitializer interface other than those resulting from the failure to instantiate a portable interceptor object shall result in the abandonment of the ORB initialization and destruction of the ORB. Any ORBInitializer implementation that needs the ORB to ignore any thrown exceptions can simply catch and discard them itself.

  • Reported: CORBA 3.0.3 — Wed, 1 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.4.3.1

  • Legacy Issue Number: 8856
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In case get_slot is called from withing an ORB itializer chapter 21.4.3.1 says a BAD_INV_ORDER with minor code 10 is thrown, this should be 14 as mentioned also in 21.7.2.11

  • Reported: CORBA 3.0.3 — Mon, 6 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 4.2 (02)

  • Legacy Issue Number: 8633
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Struct ServiceInformation is wrong, the sequence<> lines should be removed. struct ServiceInformation

    { sequence <ServiceOption> service_options; ServiceOptionSeq service_options; sequence <ServiceDetail> service_details; ServiceDetailSeq service_details; }

    ;

  • Reported: CORBA 3.0.3 — Fri, 25 Mar 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 4.2

  • Legacy Issue Number: 8632
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The is an error in the ServiceDetail struct. service_detail is listed twice, the first one should be removed. struct ServiceDetail

    { ServiceDetailType service_detail_type; sequence <octet> service_detail; ServiceDetailData service_detail; }

    ;

  • Reported: CORBA 3.0.3 — Fri, 25 Mar 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 13.6.2

  • Legacy Issue Number: 8631
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Update: struct IOR

    { string type_id; sequence <TaggedProfile> profiles; }

    ; to struct IOR

    { string type_id; TaggedProfileSeq profiles; }

    ; And also use CORBA::OctectSeq instead of sequence<octet>

  • Reported: CORBA 3.0.3 — Fri, 25 Mar 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

FullInterfaceDescription and base_interfaces question

  • Legacy Issue Number: 9140
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    Regarding the base_interfaces attribute of the Interface Repository
    (IFR) InterfaceDef and the ExtInterfaceDef interfaces, the CORBA spec
    has only this to say:

    "The base_interfaces attribute lists all the interfaces from which
    this interface inherits."

    Does that sentence mean that the base_interfaces attribute lists only
    immediate base interfaces, or does it list all base interfaces,
    i.e., the transitive closure of the inheritance graph (minus the
    implied Object interface at the root)? I believe it is supposed to be
    a list of only immediate interfaces, as one can make further calls on
    the IFR to obtain more information about those bases, including
    their bases.

    However, both the FullInterfaceDescription and the
    ExtFullInterfaceDescription structures also have a base_interfaces
    member, which is specified as a sequence of repository IDs.
    Unfortunately, the specification contains no description whatsoever
    for this member. I argue that unlike the base_interfaces attribute
    described above, this member can't list only the immediate base
    interfaces.

    I believe that the base_interfaces member of the
    FullInterfaceDescription and the ExtFullInterfaceDescription
    structures should contain the transitive closure of all base
    interfaces. These structures are intended to supply full interface
    descriptions, after all. Specifying the base_interfaces as I suggest
    would match the operations and attributes fields of the same structs,
    which are already explicitly specified to contain all operations and
    attributes respectively from the transitive closure of the
    inheritance graph. Note also that if base_interfaces does not contain
    the transitive closure of all base interfaces, there's no way to
    obtain the information from TypeCodes, since names do not appear in
    TypeCodes in minimum CORBA.

    I therefore propose that the third paragraph of section 10.5.24.1 of
    CORBA 3.0.2 be changed from this:

    "The describe_interface operation returns a FullInterfaceDescription
    describing the interface, including its operations and attributes.
    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 add a sentence defining the base_interfaces member, like this:

    "The describe_interface operation returns a FullInterfaceDescription
    describing the interface, including its operations and attributes.
    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 base_interfaces field of the
    FullInterfaceDescription structure includes the repository IDs of all
    the base interfaces in the transitive closure of the inheritance
    graph of the interface being described, except for the repository ID
    of the implied Object base interface."

    Note that even if this change is made, the base_interfaces attribute
    of InterfaceDef and ExtInterfaceDef can (and should) remain as
    listing only immediate bases, assuming that's what the spec's
    original intent was.

  • Reported: CORBA 3.0.3 — Mon, 7 Nov 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Allowing mutual recursion for IDL structs - clarification needed

  • Legacy Issue Number: 10558
  • Status: closed  
  • Source: Borland Software Corporation ( Naveed Shaikh)
  • Summary:

    There was an issue 8969 (Allowing mutual recursion for IDL structures) posted sometime back on CORBA RTF (www.omg.org/issues/issue8969.txt). I am looking for a clarification in the proposed resolution, which allows for the mutual recursion between non-nested structures (CORBA 3.0 specification, section 3.11.2.3). The proposal essentially extends the definition of incompleteness of a struct/union as follows:

    The original definition was:
    o A struct/union is termed incomplete until its full definition is provided; that is, until the scope of the struct/union definition is closed by a terminating "}"

    The introduced proposal added to the original definition:
    o If a sequence member of a structure or union refers to an incomplete type, the structure or union itself remains incomplete until the member's definition is completed

    Section 3.11.2.3 also says that "an incomplete type can only appear as the element type of a sequence definition".

    Question 1:
    Is following legal under the new scheme?

    struct Foo;
    typedef sequence<Foo> FooSeq;

    struct Bar

    { FooSeq fs; }

    ; // Bar remains incomplete since it is holding an incomplete sequence type

    struct FooX

    { Bar b; // Is this valid with Bar marked incomplete here? }

    ;

    struct Foo

    { Bar b; }

    ; // According to the proposal, Foo and Bar are complete now

    Use of Bar under FooX apparently conflicts with the condition that incomplete type can only appear in a sequence definition.

    Question 2:
    Also is it must that there is a mutual recursion between non-nested structures? Consider the following:

    struct Foo;
    typedef sequence<Foo> FooSeq;

    struct Bar

    { FooSeq fs; }

    ; // Bar remains incomplete

    struct Foo

    { long a; }

    ; // Is Bar also complete here when Foo is complete even though Foo doesn't recurse on Bar?

    Is the above IDL valid under the new proposal? There is no constraint in section 3.11.2.3, which doesn't allow for this so it stands valid as per spec. Was issue 8969 also intended to make such cases valid?

  • Reported: CORBA 3.0.3 — Fri, 1 Dec 2006 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CORBA Exceptions

  • Legacy Issue Number: 9618
  • Status: closed  
  • Source: condor networks ( ramesh babu boya)
  • Summary:

    I implemented CORBA functionality, in that implementation I got some exceptions. I am sending that exceptions list in the below. omniORB: ERROR – the application attempted to invoke an operation on a nil reference. terminate called after throwing an instance of 'CORBA::INV_OBJREF' Aborted (core dumped) I have some doubts on these exceptions. What is the cause for this exception? How can I solve this exception? Please clarify my doubts.

  • Reported: CORBA 3.0.3 — Thu, 4 May 2006 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 11.3.9.16

  • Legacy Issue Number: 9460
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For activate_object_with_id it is described that when SYSTEM_ID has been set and the object id was not generated by this system or tis POA we throw a BAD_PARAM, but the minor code is not described. Shouldn't this have an unique minor code?

  • Reported: CORBA 3.0.3 — Thu, 16 Mar 2006 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 11.3.9

  • Legacy Issue Number: 9016
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The CORBA spec describes the following about the wait_for_completion parameter of the POA::destroy call: The wait_for_completion parameter is handled as follows: • If wait_for_completion is TRUE and the current thread is not in an invocation context dispatched from some POA belonging to the same ORB as this POA, the destroy operation returns only after all active requests have completed and all invocations of etherealize have completed. • If wait_for_completion is TRUE and the current thread is in an invocation context dispatched from some POA belonging to the same ORB as this POA, the BAD_INV_ORDER system exception with standard minor code 3 is raised and POA destruction does not occur. We have a use case where we have an ORB with two POA's, A1 and B1, each POA again has a child A2 and B2. In case we get a request for a servant of A2 to destroy POA B2 and we specify TRUE for wait_for_completion then we get an exception back, but this doesn't seem locally. We understand that when we want to destroy A1 when handling a request using a servant of A2 that we get an exception at that moment. We propose the change the description as following: The wait_for_completion parameter is handled as follows: • If wait_for_completion is TRUE and the current thread is not in an invocation context dispatched from some POA that is a child of this POA or from this POA itself, the destroy operation returns only after all active requests have completed and all invocations of etherealize have completed. • If wait_for_completion is TRUE and the current thread is in an invocation context dispatched from some POA that is a child of this POA or from the POA itself, the BAD_INV_ORDER system exception with standard minor code 3 is raised and POA destruction does not occur.

  • Reported: CORBA 3.0.3 — Mon, 26 Sep 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 22.16/

  • Legacy Issue Number: 9075
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    There are some issues with the definition of ExceptionHolder. In 22.16 it is as below, see the raise_exception_with_list, this seems to have two arguments here, in 22.7 there is just one argument. The same problem also appears in the draft 3.1 spec. Also, there is no CORBA::ExceptionList defined in the spec at all, there is Dynamic::ExceptionList but no CORBA::ExceptionList. valuetype ExceptionHolder { void raise_exception() raises (UserExceptionBase); void raise_exception_with_list( in CORBA::ExceptionList exc_list) in Dynamic::ExceptionList exc_list) raises (UserExceptionBase); private boolean is_system_exception; private boolean byte_order;

  • Reported: CORBA 3.0.3 — Wed, 5 Oct 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Page: 21-43

  • Legacy Issue Number: 9112
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The following methods are not described in this chapter: Object make_object (in string repository_id, in ObjectId id); IOP::TaggedProfileSeq make_profiles (in string repository_id, in ObjectId id); These are mentioned in 21.10.3

  • Reported: CORBA 3.0.3 — Tue, 25 Oct 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 22.11.1

  • Legacy Issue Number: 9082
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the C++ example code of 22.11.3 Messaging::ExceptionHolder_ptr is used, for valuetypes there is no _ptr, the could should read Messaging::ExceptionHolder *

  • Reported: CORBA 3.0.3 — Mon, 17 Oct 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Page: 7-7

  • Legacy Issue Number: 8881
  • Status: closed  
  • Source: Office613, S6, NUDT ( DingBo)
  • Summary:

    CORBA3.0.2(formal/02-12-02), chapter 7.2.1, says "The implicit object reference operations non_existent, is_a, repository_id and get_interface may be invoked using DII. No other implicit object reference operations may be invoked via DII." However, I think we should add "get_component" to this list of allowable operations. Or else we can't use some features of CCM via DII, because the implementation of get_component resides on the server side.

  • Reported: CORBA 3.0.3 — Tue, 28 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Page: 9-1

  • Legacy Issue Number: 8879
  • Status: closed  
  • Source: nudt ( cyberdb)
  • Summary:

    There are some inconsistent idl declarations in CORBA3.0.2 Chapter 9(with editorial update version) 1?page 9-10: the idl declaration of DynAnyFactory is not the same as the idl declared earlier(page 9-9). It seems that three new fuctions have been left out. 2?Page 9-5: DynUnion should have a member fuction is_set_to_default_member, which is declared on page 9-20

  • Reported: CORBA 3.0.3 — Mon, 27 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Page: 21-5

  • Legacy Issue Number: 8874
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the Interceptor interface there is a destroy method which can throw a system exception just like all other corba calls. What is the behaviour when the orb shutdown is done and an Interceptor::destroy() call throws an exception? Should the ORB ignore this exception and continue the shutdown or should it return the exception to the caller. I would except ignore the exception and continue but the spec doesn't describe the behaviour.

  • Reported: CORBA 3.0.3 — Tue, 21 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.3.14.11

  • Legacy Issue Number: 8862
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The minor code for add_reply_service_context is not correct. The spec says: Indicates the behavior of this operation when a service context already exists with the given ID. If false, then BAD_INV_ORDER with a standard minor code of 11 is raised. If true, then the existing service context is replaced by the new one. The minor code should be 15.

  • Reported: CORBA 3.0.3 — Wed, 8 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 4.5.2

  • Legacy Issue Number: 8860
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    This corba spec describes POAManagerFactory. I have been searching on the web and it seems for example Orbacus has the possibility to do a resolve_initial_references ("POAManager"). This seems not possible with the latest corba spec. This seems an usefull extension. The only option there is now is to get the RootPOA, get from there the POAManagerFactory and use that again.

  • Reported: CORBA 3.0.3 — Tue, 7 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: Appendix A

  • Legacy Issue Number: 8864
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The tags for unreliable multicast are missing. // The following are defined in 03-01-11 const ProfileId TAG_UIPMC = 3; const ComponentId TAG_GROUP = 39; const ComponentId TAG_GROUP_IIOP = 40;

  • Reported: CORBA 3.0.3 — Wed, 8 Jun 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.8 The simple Element, page 69-538

  • Legacy Issue Number: 5508
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    2. 69.8.2.8 The simple Element, page 69-538
    Simple Extensions and Changes
    a) Enumerations - Add an optional enumerations element to the simple
    definition.
    This allows a simple enumeration property to be defined. Each enumeration
    label
    has an associated value. The values are all of the same simple type.

    Change simple element to:

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , enumerations?
    , defaultvalue?
    ) >

    Define new enumerations element

    <!ELEMENT enumerations
    ( enumeration+
    )>
    <!ELEMENT enumeration EMPTY>
    <!ATTLIST enumeration
    label CDATA #REQUIRED
    value CDATA #IMPLIED>

    b) Short appears twice in the simple type attribute definition. Remove
    second
    occurrence.
    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , defaultvalue?
    ) >
    <!ATTLIST simple
    name CDATA #IMPLIED
    type ( boolean

    char
    double
    float
    short – 1st occurrence
    long
    objref
    octet
    short – 2nd occurrence
    string
    ulong
    ushort
    ) #REQUIRED >

    c) Units - add an optional units element to indicate the units of
    measurement for
    a simple property.

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , units?
    , defaultvalue?
    ) >

    <!ELEMENT units (#PCDATA)>

    d) Property Kind - The properties file for a component should not be
    restricted to
    only initial configuration properties. A component has many different types
    of
    properties and when defining a component one should be able to define these
    types of properties in a generic way. Add a kind element or attribute for a
    property definition. A component has readonly, writeonly, and readwrite
    properties. Simple properties can also be used for a component factory's
    create
    options parameter (home) or executable parameters/arguments. Only simple
    properties can be used for executable parameters.

    New simplekind element

    <!ELEMENT simplekind EMPTY>
    <!ATTLIST simplekind
    kindtype (configure_writeonly | configure_readwrite | execparam |
    query_readonly | factoryparam) "configure_readwrite">

    Change simple definition to:

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , simplekind*
    , defaultvalue?
    ) >

    The propertykind can be an optional element or attribute for the stuct and
    sequence elements.

    New propertykind element

    <!ELEMENT propertykind EMPTY>
    <!ATTLIST propertykind
    kindtype (configure_writeonly | configure_readwrite |
    query_readonly | factoryparam) "configure">

    Change Struct and Sequence to

    <!ELEMENT struct
    ( description?
    , ( simple

    sequence
    struct
    valuetype
    )*
    , propertykind?
    ) >
    <!ATTLIST struct
    name CDATA #IMPLIED
    type CDATA #REQUIRED >

    <!ELEMENT sequence
    ( description?
    , ( simple*

    struct*
    sequence*
    valuetype*
    )
    , propertykind?
    ) >
    <!ATTLIST sequence
    name CDATA #IMPLIED
    type CDATA #REQUIRED >
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: Chapter 9, Chapter 5

  • Legacy Issue Number: 8986
  • Status: closed  
  • Source: Office613, S6, NUDT ( DingBo)
  • Summary:

    Section 9.2.9 says "A reference to a DynValueCommon interface (and interfaces derived from it) exhibit the same sharing semantics as the underlying valuetype that it represents.", which defines the sharing semantics of DynAny. However, I think its precondition is that valuetype's sharing semantics can be preserved in Any. DynAny is usually used with Any, converted from or to Any. If Any can't preserve sharing semantics, there is no necessary for DynAny to keep them. Suppose we use a struct which consists of several valuetypes to store a graph. In order to ensure the correctness of an application based on DII/DSI, converting this struct to Any and then to DynAny should produce an identical graph. However, if Any can't preserve sharing semantics, this goal is impossible. Any's sharing semantics focuses on valuetype conversion, because we don't concern the concrete internal implementation of Any. It means that when we extracting valuetypes from an Any or converting an Any contains valuetypes into a DynAny, sharing semantics should be preserved. For example, different Anys contain same valuetype only produce one valuetype instance when their contents are extracted. We can implement this by the help of a global valuetype manager. To sum up, the sharing semantics of valuetype can be divided into three layers: valuetype itself, Any and DynAny. All of them constitute a complete hierarchy. Only after each layer has been implemented, we are able to ensure that applications that use the DII and DSI can correctly view and preserve the semantics of the valuetype graph. Because Any's sharing semantics is very fundamental, it is necessary for us to clarify it in the specification, though we haven't special chapter/section on Any. We can add it to Chapter 5 "Value Type Semantics". Section 5.2.4.2 only defined sharing semantics in the layer of valuetype itself. We should say something about sharing semantics in the other two layers at the end of this section.

  • Reported: CORBA 3.0.3 — Mon, 5 Sep 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: Chapter 11

  • Legacy Issue Number: 8985
  • Status: closed  
  • Source: Office613, S6, NUDT ( DingBo)
  • Summary:

    Section 11.3.1 "The Servant IDL Type" defines the default implementations of get_interface, is_a, and non_existent. However, we should define the default implementation of "get_component" as well because this fuction is also an ORB-mediated implicit object reference operation. By default, this function returns a nil reference. When the object is a component or a facet, as other default implementations, this operation can be overridden by the servant's implementation.

  • Reported: CORBA 3.0.3 — Sun, 4 Sep 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Allowing Mutual Recursion for IDL Structures

  • Legacy Issue Number: 8969
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    CORBA 2.4 introduced forward declarations for IDL structures
    and unions in support of recursive structures, deprecating the
    prior practice of anonymous types.

    Also allowed were sequences of forward-declared structures
    ("incomplete types"), which could then be used as members in
    defining the structure. Currently, it is only allowed to use
    incomplete types in the actual definition of the type itself.

    As an example in section 3.11.2.3 demonstrates, this does
    allow indirect recursion – but only if the incomplete types
    are nested, as in [first example]

    struct Foo;
    typedef sequence<Foo> FooSeq;

    struct Foo {
    struct Bar

    { FooSeq fs; }

    b;
    };

    Specifically not allowed – and this is the point of this
    issue – is the seemingly more intuitive definition of
    [second example]

    struct Foo;
    typedef sequence<Foo> FooSeq;

    struct Bar

    { FooSeq fs; }

    ;

    struct Foo

    { Bar b; }

    ;

    Currently, the spec says that, "sequence members that are
    recursive must refer to an incomplete type currently under
    definition," and thus Bar is not allowed to use FooSeq as
    a member.

    However, the second example is, in effect, no different than
    the first. In the first example, "Foo::Bar" is a well-defined
    stand-alone type that can be used elsewhere (e.g., as a
    structure member or operation parameter).

    If a developer intends to use both structures, the second
    example makes this much clearer, as it syntactically elevates
    "Foo::Bar" from a mere sub-type to an "independent" structure.

    Therefore, I would like to change the current wording of
    section 3.11.2.3 to allow the second example. A proposed
    update is below.

    This issue is all the more urgent because another available
    specification, the "Deployment and Configuration of
    Component-based Distributed Applications," depends on it,
    by using two IDL structures that mutually and indirectly
    recurse, effectively using [third example]

    struct Package;
    typedef sequence<Package> PackageSeq;

    struct Assembly;
    typedef sequence<Assembly> AssemblySeq;

    struct Package

    { AssemblySeq as; }

    ;

    struct Assembly

    { PackageSeq ps; }

    ;

    In reality, the IDL in question is a bit more complicated,
    using some intermediate structures, which makes rewriting
    the IDL without this mutual recursion impractical and
    non-intuitive – also because both "Package" and "Assembly"
    are meant to be potentially top-level, stand-alone items.

    Some might argue that the IDL restriction existed before
    the "Deployment" specification was adopted, and that CORBA
    should not be changed just because some later spec
    willingly (or rather, naively) used buggy IDL.

    So let me make some more arguments in favor of my request.

    First, as explained above, IDL already allows for indirect
    recursion. It just requires nesting.

    Second, defining structures as a "side-effect" of a member
    declaration is ugly, only marginally better than anonymous
    types. Allowing the type definition of a member to stand
    by itself is, in my opinion, much cleaner.

    Third, indirect recursion between non-nested types is no
    more difficult to implement in an ORB than indirect recursion
    between nested types.

    In fact, some existing ORB products already have no problem
    with indirect recursion, and are able to compile the IDL
    from the third example, resulting in correct code. The code
    works fine with Mico, TAO, JacORB and Combat, all of which
    apparently neglect to implement the check that "sequence
    members that are recursive must refer to an incomplete type
    currently under definition."

    OmniORB does issue a diagnostic, but simply removing the
    check, and making another trivial change to its IDL compiler,
    results in correct C++ code.

    Four, the existing IDL syntax, TypeCodes, CDR marshalling
    rules, and Interface Repository all allow indirect recursion
    to exist. In fact, it is already possible to create the
    above data types using the Interface Repository and
    TypeCode interfaces – as well as to create instances
    using DynamicAny, and to marshal them.

    With this background, I suggest to remove the statement
    that prevents indirect recursion between non-nested
    structures and unions.

    Proposed resolution:

    In section 3.12.2.3, change paragraphs (counting each IDL
    code example as a single paragraph) 10 to 12 (page 3-42)
    from

    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

    struct Foo;
    typedef sequence<Foo> FooSeq;
    struct Bar

    { long value; FooSeq chain; // Illegal, Foo is not an enclosing }

    ; // struct or union.

    Compilers shall issue a diagnostic if this rule is
    violated.

    to

    If a sequence member of a structure or union refers
    to an incomplete type, the structure or union itself
    remains incomplete until the member's definition is
    completed. For example

    struct Foo;
    typedef sequence<Foo> FooSeq;
    struct Bar

    { long value; FooSeq chain; // Use of incomplete type }

    ; // Bar itself remains incomplete
    struct Foo

    { // ... }

    ; // Foo and Bar are complete

    Thank you for listening. Also thanks to Jeff Parsons
    and Boris Kolpakov from Vanderbilt University for
    researching this issue.

    We, the submitters of the "Deployment" specification,
    genuinely believe that indirect recursion is useful,
    and its lack (and having to work around) would take
    considerable value from the specification.

    I am uncomfortable arguing to change another spec
    to fix ours. But one spec has to change, and I believe
    that indirect recursion is a useful feature that already
    (unwillingly) exists in many ORBs, that it is no more
    problematic to implement than the existing means of
    recursion, and that the resulting data types are already
    valid when obtained from the TypeCode or Interface
    Repository interfaces.

    Considering the conflict of available specifications,
    I am tempted to flag this issue as urgent. Andrew, is
    that even possible, given that there is no active Core
    RTF?

  • Reported: CORBA 3.0.3 — Wed, 17 Aug 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

NVList Section: 7.5

  • Legacy Issue Number: 8929
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The NVList has a count, which is defined as long, it would be better to make this an unsigned long. This has impact on ORB::create_list, change the type of argumetn count to unsigned long. Also update NVList::get_count to have an unsigned long argument.

  • Reported: CORBA 3.0.3 — Fri, 15 Jul 2005 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.15 The implementation Element, pages 69-478/479

  • Legacy Issue Number: 5515
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Implementation Element Cardinality. Why does it make sense to have an empty
    implementation or to allow multiple elements such as code, description,
    humanlanguage, or to have no code? Suggested changes are to place the
    correct
    cardinality on the implementation elements. The suggested elements
    cardinality
    changes will make parsing the XML much simpler and reduce code footprint,
    and the
    XML more understandable.

    Current Format

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    Suggested New Format for implementation

    • Zero or one description, the CAD and CORBA Components DTDs define the
      description this way.
    • Zero or one property file reference. Why are multiple property files
      needed?
    • One code element is required for a given implementation
    • Zero or one complier element. A given source code element is compiled
      by a
      specific compiler. Specifying the compiler is optional.
    • Zero or one programminglanguage element. Specifying the
      programminglanguage is optional.
    • Zero or one humanlanguage element. Specifying the humanlanguage is
      optional.
    • Zero or more dependencies for a specific implementation.
    • Zero or more descriptors for a specific implementation. An
      implementation
      may contain multiple different components.
    • Zero or more runtimes. A given code element may be compatible with
      multiple runtime environments.
    • Zero or more os. A given code element may be compatible with multiple
      operating systems.
    • Zero or more processors. A given code element may be compatible with
      multiple processors.
    • Zero or more extensions.

    <!ELEMENT implementation
    ( description?
    , code
    , compiler?
    , humanlanguage?
    , programminglanguage?
    , propertyfile?
    , ( dependency

    descriptor
    extension
    os
    processor
    runtime
    usescomponent
    )*
    )>
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >
  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3 Software Package Descriptor

  • Legacy Issue Number: 5514
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    69.3.2.1 The softpkg Root Element, page 69-473
    Softpkg Element Cardinality. Why does it make sense to have an empty
    softpkg
    file or to allow multiple elements such as title, pkgtype, description,
    license, or to
    have no implementations? Suggested changes are to place the correct
    cardinality
    on the softpkg elements to be similar to the CORBA Component and Component
    Assembly Descriptor definitions. The suggested elements cardinality changes
    will
    make parsing the XML much simpler and reduce code footprint, and the XML
    more understandable.

    Current Format

    <!ELEMENT softpkg
    ( title

    pkgtype
    author
    description
    license
    idl
    propertyfile
    dependency
    descriptor
    implementation
    extension
    )* >
    <!ATTLIST softpkg
    name ID #REQUIRED
    version CDATA #OPTIONAL >

    Suggested New Format for Softpkg

    • Zero or one title ? for example, a book only has one title, not
      multiple titles.
    • One or more authors ? for example, a book can have multiple authors,
      but at
      least one.
    • Zero or one description, the CAD and CORBA Components DTDs define the
      description this way.
    • Zero or one package type.
    • Zero or one property file reference. Why are multiple property files
      needed?
    • One or more implementations, since the softpkg is an implementation
      for a
      component definition then it must have at least one implementation.
    • Zero or more dependencies for all implementations.
    • Zero or more descriptors for all implementations. An implementation
      may
      contain multiple different components.
    • Zero or more IDL files for all implementations.
    • Zero or more extensions.

    <!ELEMENT softpkg
    ( title?
    , author+
    , description?
    , propertyfile?
    , license?
    , pkgtype?
    , implementation+
    , ( idl

    dependency
    descriptor
    extension
    )*
    )>
    <!ATTLIST softpkg
    name ID #REQUIRED
    version CDATA #IMPLIED >
  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Add the capability to define a component artifact property

  • Legacy Issue Number: 5513
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    7. Component Artifact - Add the capability to define a component artifact
    property. For
    example, a logical device component artifact could be used to specify the
    capacity for
    a device or the characteristic of a device. The artifacts for a component
    are referenced
    by a component's implementation dependency for using or deployed on
    relationships.
    The component artifact property could be defined in two ways: 1) a new
    element
    called artifact or modifying the simple definition with optional new
    artifact element.

    Artifacts are simple types. The action element defines the action that can
    be
    performed on an artifact. When a dependency references an artifact with a
    specified value this is the action that can be performed against a
    component's
    artifact. The ID is a DCE UUID to guarantee uniqueness of the artifact
    within the
    system; so 2 different artifacts, which are different, are not viewed to be
    the same
    artifact when they are not. The action denoted as external indicates the
    artifact is
    managed by the component. A referenced value for an artifact would have to
    be
    applied against the component.

    Example 1 of New Artifact Element

    <!ELEMENT artifact
    ( description?
    , simple
    , action
    )>
    <!ATTLIST artifact
    id ID #REQUIRED>

    <!ELEMENT action EMPTY>
    <!ATTLIST action
    type ( eq | ne | gt | lt | ge | le | external ) "external">

    Change properties element to

    <!ELEMENT properties
    ( description?
    , ( simple

    sequence
    struct
    artifact
    valuetype
    )+
    ) >

    Example 2 of Modified Simple Element with new Artifact element

    <!ELEMENT simplekind EMPTY>
    <!ATTLIST simplekind
    kindtype (configure_writeonly | configure_readwrite | execparam |
    query_readonly | factoryparam | artifact) "configure_readwrite">

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , simplekind*
    , artifact?
    , defaultvalue?
    ) >

    <!ELEMENT artifact
    ( action
    )>
    <!ATTLIST artifact
    id ID #REQUIRED
    action ( eq | ne | gt | lt | ge | le | external ) "external">

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.9 The sequence Element

  • Legacy Issue Number: 5511
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Simple Sequence -The current definitions for sequence allow invalid
    definitions to be
    built but be syntactically correct. A better definition for a simple
    sequence would be as
    follows:

    Current sequence element

    <!ELEMENT sequence
    ( description?
    , ( simple*

    struct*
    sequence*
    valuetype*
    )
    ) >
    <!ATTLIST sequence
    name CDATA #IMPLIED
    type CDATA #REQUIRED >

    Change to

    Add a new simplesequence element:

    <!ELEMENT simplesequence
    ( description?,
    , values?
    , choices?
    , range?
    , enumerations?
    , units?
    )>
    <!ATTLIST simplesequence
    name CDATA #IMPLIED
    type ( boolean | char | double | float | short | long | objref |
    octet | string | ulong

    ushort ) #REQUIRED

    <!ELEMENT values
    ( value+
    )>

    Change sequence to:

    <!ELEMENT sequence
    ( description?
    , ( simplesequence

    struct*
    sequence*
    valuetype*
    )
    ) >
    <!ATTLIST sequence
    name CDATA #IMPLIED
    type CDATA #REQUIRED >

    One does not have to keep repeating the same simple definition. This
    definition
    then has the added advantage where simple name attribute can now be made
    mandatory.
    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , defaultvalue?
    ) >
    <!ATTLIST simple
    name CDATA #REQUIRED
    type ( boolean

    char
    double
    float
    short
    long
    objref
    octet
    string
    ulong
    ushort
    ) #REQUIRED >
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Test Property - add a test property definition to the properties DTD

  • Legacy Issue Number: 5512
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    This allows one
    to define test properties for a component in a generic way. The Test
    property is based upon simple
    element.

    Add new test element

    <!ELEMENT test
    ( description
    , inputvalue?
    , resultvalue )>
    <!ATTLIST test
    name CDATA #REQUIRED>

    <!ELEMENT inputvalue
    ( simple+ )>

    <!ELEMENT resultvalue
    ( simple+ )>

    Change properties element to:

    <!ELEMENT properties
    ( description?
    , ( simple

    sequence
    struct
    test
    valuetype
    )+
    ) >
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.3 The choices Element, page 69-537

  • Legacy Issue Number: 5510
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Choices Element - It appears multiple ranges do not make sense for a simple
    definition. If so, then remove the range element from the choices element
    definition
    and make range an optional element for a simple.

    Current definition
    <!ELEMENT choices ( choice | range )+

    Change to

    <!ELEMENT choices ( choice )+

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , range?
    , defaultvalue?
    ) >

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.7 The range Element, pages 69-537/538

  • Legacy Issue Number: 5509
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Range Element - why is the min and max order not specified?
    <!ELEMENT range (value, value) >

    I understand the software logic can do a compare to determine the min and
    max values, but it seems the following definition would be easier to
    understand from human reader.

    Change Range to

    <!ELEMENT range EMPTY>
    <!ATTLIST range
    min CDATA #REQUIRED
    max CDATA #REQUIRED>

  • Reported: CORBA 3.0 — Wed, 24 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Component Artifact Dependency

  • Key: CORBA34-96
  • Legacy Issue Number: 5522
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    An implementation may request a dependency on a specific component based
    upon
    its artifacts. Add artifactdependency to the dependency element.

    Current Format

    <!ELEMENT dependency
    ( softpkgref

    codebase
    fileinarchive
    localfile
    name
    valuetypefactory
    ) >
    <!ATTLIST dependency
    type CDATA #IMPLIED
    action (assert
    install)"assert">

    New Format

    <!ELEMENT dependency
    ( softpkgref

    codebase
    fileinarchive
    localfile
    name
    valuetypefactory
    )
    , artifactdependency*
    >
    <!ATTLIST dependency
    type CDATA #IMPLIED
    action (assert
    install)"assert">

    <!ELEMENT artifactdependency EMPTY>
    <!ATTLIST artifactdependency
    artifactrefid CDATA #REQUIRED
    artifactvalue CDATA #REQUIRED>

    Note: This concept is tied to the concept of component artifact property
    issue. The
    artifactrefid is a reference to a component's artifact property defined in
    a
    component's property file. The artifactvalue is the dependency value being
    requested
    or needed.

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

LWCCM issue - Section 1.5.3 Exclusion

  • Key: CORBA34-95
  • Legacy Issue Number: 6254
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    On page 11: The Normative Impact "Disable get_connections, get_all_receptacles, get_named_receptacles operations in the Receptacles interface" does not match the Document Impact: "Section 1.5.3: remove". Removal of section 1.5.3 removes the Receptacles interface in it entirety, including the description of the generic connect and disconnect operations, which are referred to by comment in the previous item. The Document Impact needs to be narrowed.

  • Reported: CORBA 3.0.2 — Tue, 16 Sep 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.25 The propertyfile Element, page 69-482

  • Legacy Issue Number: 5518
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Propertyfile clarification is needed for consistent behavior.
    The only statement made about propertyfile is that the implementation's
    propertyfile
    has precedence over the same propertyfile types at the softpkg level. Why
    are
    multiple property files needed at the softpkg and implementation levels? If
    more than
    one propertfile exist at any level, which property file has precedence in
    the list? If
    multiple property files exists are they merged together? Are the softpkg's
    descriptor
    element property files merge with the softpkg property files and which one
    has
    precedence? Are the implementation's descriptor property files merge with
    the
    implementation property files, and which one has precedence? Are
    implementation
    property files merge with the softpkg property files?

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.2 The author Element, page 69-474

  • Key: CORBA34-97
  • Legacy Issue Number: 5521
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Change the format of author to group related authors together from a
    company. One
    does not need the capability to list multiple companies and web sites
    together in the
    author element, since there can be many authors listed in the softpkg
    element. The
    suggested elements cardinality changes will make parsing the XML much
    simpler
    and reduce code footprint, and the XML more understandable.
    Current format

    <!ELEMENT author
    ( name

    company
    webpage
    )* >

    New format

    <!ELEMENT author
    ( name*
    , company?
    , webpage?
    )>

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.14 The idl Element, page 69-478

  • Key: CORBA34-99
  • Legacy Issue Number: 5519
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    a) Add idl element to implementation element. Why is idl only at the
    softpkg level?
    This is saying that all implementations use the same IDL. This is
    inconsistent with
    descriptor element. An implementation can specify a descriptor, why not
    idl? Cannot
    an implementation use a specific IDL for its implementation?

    b) Why is IDL defined in the software package descriptor instead of the
    CORBA
    Component descriptor?

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Descriptor

  • Key: CORBA34-98
  • Legacy Issue Number: 5520
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    How does the Assembly Descriptor support multiple components within an
    implementation?

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.7 The code Element, pages 69-474

  • Legacy Issue Number: 5516
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    a) Add the optional stacksize and priority elements to code element
    definition. The
    stack size and priority are options parameters for an operating system's
    execute()
    operation. The stack size is the memory space needed by the executable and
    the OS
    priority for the executable. Data types for the values of these options are
    unsigned
    long. Priority number should be based upon industry standard such as POSIX.

    Current Format

    <!ELEMENT code
    ( ( codebase

    fileinarchive
    link
    )
    , entrypoint?
    , usage?
    ) >
    <!ATTLIST code
    type CDATA #IMPLIED >

    New Format for code

    <!ELEMENT code
    ( ( codebase

    fileinarchive
    link
    )
    , entrypoint?
    , stacksize?
    , priority?
    , usage?
    ) >
    <!ATTLIST code
    type CDATA #IMPLIED >

    <!ELEMENT stacksize (#PCDATA)>

    <!ELEMENT priority (#PCDATA)>

    b) Other valid values for type attribute
    Additional valid values for the type attribute are: "KernelModule",
    "SharedLibrary", and "Driver".

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.15 The implementation Element, pages 69-478/479

  • Legacy Issue Number: 5517
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Add license element to implementation element. Why is the license element
    restricted
    to the softpkg level only? This is saying all implementations have the same
    license.
    Cannot each implementation have its own different license? Suggest adding
    license
    element to implementation element.

    Current Format

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    New Format

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    license
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >
  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - abstract storage type

  • Key: CORBA34-89
  • Legacy Issue Number: 7131
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 4;
    there are still references to abstract storage type in the following
    sections:
    3.2.2 (§2), 3.2.6, 3.2.9 (point 4)

    Proposed resolution:

    Row 4 in the table 4.1, add in the "Document Impact" column :
    Section 3.2.2, paragraph 2: remove references to abstract storage type
    Section 3.2.6: remove references to abstract storage type
    Section 3.2.9, point 4: remove references to abstract storage type

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - entity components

  • Key: CORBA34-91
  • Legacy Issue Number: 7129
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 7;
    there are still references to entity components in the following sections:
    3.3.3.3, 4.5.1.3 (§1), 4.5.2.3 (point 3)

    Proposed resolution:

    Row 7 in the table 4.1, add in the "Document Impact" column :
    Section 3.3.3.3: remove references to entity components
    Section 4.5.1.3, paragraph 1: remove references to entity components
    Section 4.5.2.3, point 3: remove references to entity components

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - persistence

  • Key: CORBA34-92
  • Legacy Issue Number: 7128
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence"; there
    are still references to persistence in the following sections:
    4.2 §1, 4.2.1 §1, 4.2.12

    Proposed resolution:

    Add a row in the table 4.1 with :
    "Normative Exclusion" column : Exclude support for persistence
    "Document Impact" column : Section 4.2, paragraph 1: remove reference to
    persistence
    Section 4.2.1, paragraph 1: remove reference to persistence
    Section 4.2.12: remove reference to persistence

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - section 4.1.2

  • Key: CORBA34-90
  • Legacy Issue Number: 7130
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 7;
    the section 4.1.2 doesn't have to be fully removed. Only the references to
    entiy container have to.

    Proposed resolution:

    Row 7 in the table 4.1, add in the "Document Impact" column, replace
    "Section 4.1.2: remove" by "Section 4.1.2: remove reference to entity
    container API types".

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - transaction

  • Key: CORBA34-94
  • Legacy Issue Number: 7126
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.4 "exluding support for transaction", there
    are still references to the transaction feature in the following sections:
    4.2 (§1), 4.2.1, 4.2.12 (basic), 4.5.1.1 (point 2), 4.5.1.4, 4.5.2.4

    Proposed resolution:

    Add a row in the table 4.4 with :
    "Normative Exclusion" column : Exclude support for transaction
    "Document Impact" column : Section 4.2, paragraph 1: remove reference to
    transaction
    Section 4.2.1, paragraph 1: remove reference to transaction
    Section 4.2.12: remove reference to transaction
    Section 4.5.1.1, point 2: remove reference to transaction
    Section 4.5.1.4: remove reference to transaction
    Section 4.5.2.4: remove reference to transaction

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - security

  • Key: CORBA34-93
  • Legacy Issue Number: 7127
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.5 "exluding support for security", there are
    still references to the security feature in the following sections:
    4.2 (§1), 4.2.1, 4.2.12 (basic), 4.5.1.1 , 4.5.1.5, 4.5.2.5

    Proposed resolution:

    Add a row in the table 4.5 with :
    "Normative Exclusion" column : Exclude support for security
    "Document Impact" column : Section 4.2, paragraph 1: remove reference to
    security
    Section 4.2.1, paragraph 1: remove reference to security
    Section 4.2.12: remove reference to security
    Section 4.5.1.1: remove reference to security
    Section 4.5.1.5: remove reference to security
    Section 4.5.2.5: remove reference to security

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - abstract storage home

  • Key: CORBA34-88
  • Legacy Issue Number: 7132
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 3;
    there are still references to abstract storage homes in the following
    sections:
    1.7.4, 3.2.5 (§4), 3.2.6

    Proposed resolution:

    Row 3 in the table 4.1, add in the "Document Impact" column :
    Section 1.7.4: remove references to storage home
    Section 3.2.5, paragraph 4: remove references to abstract storage home
    Section 3.2.6: remove references to abstract storage home

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - CIDL

  • Key: CORBA34-87
  • Legacy Issue Number: 7133
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 2;
    and the table 4.3 "exluding support for segmentation", row 1: there are
    still references to CIDL in the following sections:
    1.5.2.1 (§1), 3.1 (§1)

    Proposed resolution:

    Row 2 in the table 4.1 and Row 1 in the table 4.3, add in the "Document
    Impact" column :
    Section 1.2.2.1, paragraph 1: remove references to CIDL
    Section 3.1, paragraph 1: remove references to CIDL

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - locator

  • Key: CORBA34-86
  • Legacy Issue Number: 7141
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.3 "exluding support for segmentation", row
    3; there are still references to locator in the following sections:
    3.3.3.5, paragraph 4 and last paragraph

    Proposed resolution:

    Row 3 in the table 4.3, in the "Document Impact", add:
    Section 3.3.3.5, paragraph 4 and last paragraph: remove references to
    locator

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - segmentation

  • Key: CORBA34-85
  • Legacy Issue Number: 7142
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.3 "exluding support for segmentation", there
    are still references to segmentation in the following sections:
    : 3.2.1.6 (§1), 3.2.11 (§1), 3.2.9 (point 2), 4.2.12 (extended)

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - home finders and finder operations

  • Key: CORBA34-79
  • Legacy Issue Number: 7148
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.8 "exluding support for home finders" there
    are still references to finder operations and home finders in the following
    sections:
    1.7.1 (§2), 1.7.1.1, 1.7.3, 1.7.3.3, 1.7.4 (§1), 1.7.5 (heterodox), 3.3.6
    (point 5), 4.3.2.1 (get_CCM_home), 4.5, 4.5.1 (point 4, last §), 4.5.1.1
    (last point), 4.5.1.2
    The following sections have to be removed:
    1.7.3.2, 4.5.1.3, 4.5.2.3

    Proposed resolution:

    Add a row in the table 4.8 with :
    "Normative Exclusion" column : Exclude support for home finders and finder
    operations
    "Document Impact" column :
    Section 1.7.1, paragraph 2: remove reference to home finders and
    finder operations.
    Section 1.7.1.1: remove reference to home finders and finder
    operations.
    Section 1.7.3: remove reference to home finders and finder
    operations.
    Section 1.7.3.3: remove reference to home finders and finder
    operations.
    Section 1.7.4 paragraph 1: remove reference to home finders and
    finder operations.
    Section 1.7.5 (heterodox): remove reference to home finders and
    finder operations.
    Section 3.3.6, point 5: remove reference to home finders and finder
    operations.
    Section 4.3.2.1 (get_CCM_home): remove reference to home finders and
    finder operations.
    Section 4.5: remove reference to home finders and finder operations.
    Section 4.5.1, point 4 and last paragraph: remove reference to home
    finders and finder operations.
    Section 4.5.1.1, last point: remove reference to home finders and
    finder operations.
    Section 4.5.1.2: remove reference to home finders and finder
    operations.
    Section 1.7.3.2: remove
    Section 4.5.1.3: remove
    Section 4.5.2.3: remove

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - proxy homes

  • Key: CORBA34-80
  • Legacy Issue Number: 7147
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.7 "exluding support for proxy homes", row 1;
    in section 3.2.5, the last paragraph should be removed.

    Proposed resolution:

    Row 1 in the table 4.7, in the "Document Impact", add:
    Section 3.2.5 last paragraph:remove

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - invalid rows

  • Key: CORBA34-78
  • Legacy Issue Number: 7149
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.7 "exluding support for proxy homes", row 2
    and 3 are not valid

    Proposed resolution:

    remove the rows 2 and 3 of the table 4.7

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - primary key

  • Key: CORBA34-83
  • Legacy Issue Number: 7144
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 1;
    there are still references to primary key in the following sections:
    1.7.1 (§1 & §3), 1.7.4, 1.7.5.1 (§1, §2), 1.7.5.2 (§1, §2)

    Proposed resolution:

    Row 1 in the table 4.1, add in the "Document Impact" column :
    Section 1.7.1, paragraph 1 and 3: remove references to primary key
    Section 1.7.4: remove references to primary key
    Section 1.7.5.1, paragraph 1and 2: remove references to primary key
    Section 1.7.5.2, paragraph 1and 2: remove references to primary key

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - get_all_facet, ...

  • Key: CORBA34-84
  • Legacy Issue Number: 7143
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.2 "exluding support introspection,
    navigation, ...", row 2; there are still references to these operations in
    the following sections:
    1.4.3, point 3 and 4, section 1.4.3.4, paragraph 1

    Proposed resolution:

    Row 2 in the table 4.2, in the "Document Impact", add:
    Section 1.4.3, point 3 and 4: remove references to these operations
    Section 1.4.3.4, paragraph 1: remove references to these operations

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - Section 4.1

  • Key: CORBA34-82
  • Legacy Issue Number: 7145
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence"; in the
    "Document Impact" column, row 1, the § 3 doesn't exist in the section 1.1.4.

    Proposed resolution:
    Table 4.1, row 1, column "Document Impact": replace "Section 1.1.4,
    paragraph 3: remove" by "Section 1.1.4, paragraph 2: remove"

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - configurators

  • Key: CORBA34-81
  • Legacy Issue Number: 7146
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.6 "exluding support for configurators";
    there are still references to configurators in the following sections:
    1.10.2 (second point), 1.10.2.1 (§2), 1.11.1 (configuration_complete)

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Checking XML DTD elements related to the trader service

  • Key: CORBA34-71
  • Legacy Issue Number: 5590
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In ptc/01-11-03, page 69-533, there is the following note

    Issue The trader elements have to be reviewed to make
    sure that they serve the purpose intended.
    Also, consider using a property file.

    XML DTD elements related to the trader service would be checked

  • Reported: CORBA 3.0 — Thu, 22 Aug 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Description for the impltype Element?

  • Key: CORBA34-72
  • Legacy Issue Number: 5589
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In formal/02-06-65, page 6-54, there is the following text

    Placeholder for future version.

    The section 6.7.2.33 would be written.

  • Reported: CORBA 3.0 — Thu, 22 Aug 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Uses Relationships

  • Key: CORBA34-74
  • Legacy Issue Number: 5524
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    The softpkg element only deals with deployed on and library load dependency
    relationships for implementations. Component implementations may also have
    specific using relationships with another component, such as a device
    within the
    system. This relationship can be stated at the softpkg or implementation
    level.

    Current Format

    <!ELEMENT softpkg
    ( title

    pkgtype
    author
    description
    license
    idl
    propertyfile
    dependency
    descriptor
    implementation
    extension
    )* >
    <!ATTLIST softpkg
    name ID #REQUIRED
    version CDATA #IMPLIED >

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    New Format

    <!ELEMENT softpkg
    ( title

    pkgtype
    author
    description
    license
    idl
    propertyfile
    dependency
    descriptor
    implementation
    extension
    usescomponent
    )* >
    <!ATTLIST softpkg
    name ID #REQUIRED
    version CDATA #IMPLIED >

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    usescomponent
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    <!ELEMENT usescomponent
    ( artifactdependency+
    )>
    <!ATTLIST usescomponent
    id ID #REQUIRED
    type CDATA #REQUIRED>

    <!ELEMENT artifactdependency EMPTY>
    <!ATTLIST artifactdependency
    artifactrefid CDATA #REQUIRED
    artifactvalue CDATA #REQUIRED>

    Note: This concept is tied to the concept of component artifact property
    issue. The
    artifactrefid is a reference to a component's artifact property defined in
    a
    component's property file. The artifactvalue is the dependency value being
    requested or needed.

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3 AssemblyFactory Interface

  • Key: CORBA34-73
  • Legacy Issue Number: 5576
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Suggested changes to the AssemblyFactory interface.

    AssemblyFactory Issues.

    1. Ease of use Issue. After the create operation is performed, one is
    force to call lookup to get the Assembly that just got just created. Why is
    a cookie returned by the create operation instead of an Assembly? Is the
    reason because of security? If the interface were more open this would
    still allow a secure implementation to be implemented.
    Suggested change is to return an Assembly instead of a Cookie. Change
    destroy operation to take in an Assembly parameter instead of Cookie.
    Change lookup operation to take in a name parameter. These changes
    make it consistent with the other CCM interfaces, such as Container,
    KeyLessCCMHome, ComponentServer, and ServerActivator.
    2. Multiple users Issue. For multiple users, how does a client know what
    assemblies are created. Add a get_assemblies operation that returns a list
    of assemblies. These changes make it consistent with other CCM interfaces,
    such as Container, ComponentServer, and ServerActivator.
    3. User-friendly identifier for Assembly Instance issue. Add an input
    name parameter that can be assigned to the Assembly instance that gets
    created. Add a read only name or label attribute to the Assembly interface.

  • Reported: CORBA 3.0 — Thu, 8 Aug 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Device Artifact Dependency

  • Key: CORBA34-75
  • Legacy Issue Number: 5523
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    A component's implementation may have additional dependencies on a device's
    artifacts (e.g., capacity and/or characteristics) to ensure the right type
    of device is
    chosen for deployment and/or the device has sufficient capacities for
    deployment. To
    allow for this capability add a deviceartifactdependency element to the
    implementation element.

    Current Format

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    New Format

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    deviceartifactdependency
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    <!ELEMENT deviceartifactdependency EMPTY>
    <!ATTLIST deviceartifactdependency
    artifactrefid CDATA #REQUIRED
    artifactvalue CDATA #REQUIRED>

    Note: This concept is tied to the concept of component artifact property
    issue. The
    artifactrefid is a reference to a component's artifact property defined in
    a
    component's property file. The artifactvalue is the dependency value being
    requested or needed.

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Dependency on D+C FTF

  • Key: CORBA34-76
  • Legacy Issue Number: 7363
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    Lightweight CCM replaces CCM's Packaging and Deployment chapter
    with the "Deployment and Configuration of Component-based Distributed
    Applications" (D+C) specification, and thus Lightweight CCM cannot be
    finalized before D+C.

    I propose to defer this issue to a second FTF, to be resolved by the
    availability of D+C.

  • Reported: CORBA 3.0.3 — Wed, 19 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - Entity2Context

  • Key: CORBA34-77
  • Legacy Issue Number: 7150
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 7;
    there are still references to Entity2Context in the following sections:
    3.2.11 (§2)

    Proposed resolution:

    Row 7 in the table 4.1, in the "Document Impact", add:
    Section 3.2.11, paragraph 2:remove reference to the Entity2Context
    interface.

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

A new exception specification is needed for CCM2Context::req_passivate()

  • Key: CORBA34-68
  • Legacy Issue Number: 5639
  • Status: closed  
  • Source: THALES ( Hakim Souami)
  • Summary:

    Document ptc/2001-11-03, CORBA Component Model
    ----------------------------------------------
    62.4.1.1 The CCM2Context Interface
    ....
    local interface CCM2Context : CCMContext

    { HomeRegistration get_home_registration (); void req_passivate () raises (PolicyMismatch); CatalogBase get_persistence (in _TypeId catalog_type_id) raises (PersistenceNotAvailable); }

    ;

    ....
    req_passivate
    The req_passivate operation is used by the component to inform the container
    that it wishes to be passivated when its current operation completes. To be
    valid, the component must have a servant lifetime policy of component or
    container. If not, the PolicyMismatch exception shall be raised.
    ----------------------------------------------

    What happens if req_passivate() operation is not called in the scope of a
    callback operation?
    I think that req_passivate() can only make sense if called in the context of
    a callback operation. The IllegalState exception is appropriate for this
    case.

    The IDL might then look like this :
    void req_passivate () raises (IllegalState,PolicyMismatch);

    and the following sentence might be appended to the paragraph above:
    "If this operation is issued outside of the scope of a callback operation,
    the IllegalState exception is returned."

    This addition will ease implementation of CCM2Context objects based on
    POACurrent : implementing container and component servant lifetime policies
    on a POA with RETAIN servant retention policy and the other servant lifetime
    policies on a POA with NON_RETAIN servant retention policy can rely entirely
    on the POACurrent.

  • Reported: CORBA 3.0 — Fri, 6 Sep 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CCM IDL style inconsistency

  • Key: CORBA34-65
  • Legacy Issue Number: 5858
  • Status: closed  
  • Source: Anonymous
  • Summary:
    • document : formal/02-06-65
    • chapter : 1.5.2.4
    • text in question :

    module Components
    {
    valuetype Cookie

    { private CORBA::OctetSeq cookieValue; }

    ;
    };

    • Issues :

    1. Naming style used in this definition violates rules defined in
    "OMG IDL Style Guide" (ab/98-06-03).

    2. Naming style used in this definition is inconsistent with other parts
    of the CCM IDL, for example:

    module Components
    {
    valuetype PortDescription

    { public FeatureName name; public CORBA::RepositoryId type_id; }

    ;

    valuetype FacetDescription : PortDescription

    { public Object facet_ref; }

    ;
    }

    • suggested resolution : replace `cookieValue' with `cookie_value'
  • Reported: CORBA 3.0.2 — Wed, 12 Feb 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Derived component supported interface restriction (formal/2002-06-65)

  • Key: CORBA34-66
  • Legacy Issue Number: 5688
  • Status: closed  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    Both the CORBA spec (formal/02-06-01 page 3-61) and the CCM spec (formal/02-06-65 page 1-51) state that "A derived component type may not directly support an interface." Moreover the sentence you depicted is a contradiction with the formal/02-06-65 section 1.3.2.4 page 1-7.

    Resolution:

    In formal/02-06-65 page 1-51 and formal/02-06-01 page 3-61 replace the sentence

    "A derived component type may not directly support an interface."

    with

    "If a derived component type directly supports one or more IDL interfaces, the component interface is derived from both the interface of its base component type and the supported interfaces."

  • Reported: CORBA 3.0 — Thu, 10 Oct 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Issue on the description of the consumesidentifier element

  • Key: CORBA34-67
  • Legacy Issue Number: 5684
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    Proposed resolution:

    In the Adopted CORBA Components Specification (formal/02-06-65),
    section 6.7.2.15, page 6-50, replace 'consumingcomponent' by
    'consumesport'.

    Proposed revised text:

    In formal/02-06-65 page 6-50, replace
    A child of consumingcomponent
    by
    A child of consumesport

  • Reported: CORBA 3.0 — Mon, 14 Oct 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Using Configurator on CCMHome or any CORBA objects?

  • Key: CORBA34-70
  • Legacy Issue Number: 5591
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In ptc/01-11-03, page 69-545, there is the following note

    Issue The Configurator interface takes an argument of type
    CCMObject and therefore cannot be used to configure component
    homes. I see no reason not to widen the type to CORBA::Object
    so that the Configurator can be used for objects other than
    CCMObjects. The StandardConfigurator is after all a basic name
    value pair configurator that simply executes calls on mutator
    operations resulting from attribute declarations. J.S.E.

    The Configurator interface could be updated to allow configuration
    of any CORBA objects.

  • Reported: CORBA 3.0 — Thu, 22 Aug 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

[CCM] Interface Repository Metamodel

  • Key: CORBA34-69
  • Legacy Issue Number: 5594
  • Status: closed  
  • Source: Anonymous
  • Summary:

    in the BaseIDL there is a class StructDef which has the Attribute members of
    Type Field. How can I model a IDL struct with more than one entry?
    I think there should be a aggregation from StructDef (1<>----->*) to the Field
    class (Page 8-10 of the CCM Spec).

    *) With EnumDef there is the same problem, I guess a assotiation from EnumDef to
    string (1<>----->*) would solve it (Page 8-10 of the CCM Spec).

    *) Also with ExceptionDif and its attribute members (Page 8-11 of the CCM Spec).

  • Reported: CORBA 3.0 — Mon, 26 Aug 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 6.4.5.26 and Section 6.4.5.30 should be moved to section 6.3

  • Key: CORBA34-59
  • Legacy Issue Number: 5903
  • Status: closed  
  • Source: Tech-X ( Nanbor Wang)
  • Summary:

    To maintain a consistent style and to provide a detailed
    description in an XML element's first appearance, Section 6.4.5.26
    and Section 6.4.5.30 should be moved under Section 6.3 and changed
    to referring them back to the corresponding subsections like
    Section 6.4.5.29 does.

  • Reported: CORBA 3.0.2 — Fri, 18 Apr 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 6.4.5.10 (page 6-26)

  • Key: CORBA34-60
  • Legacy Issue Number: 5902
  • Status: closed  
  • Source: Tech-X ( Nanbor Wang)
  • Summary:

    Section 6.4.5.10 (page 6-26): one of the child elements of the
    "containermanagedpersistence" element is "psstransactionpolicy" where
    it should have been "psstransaction" instead (see Section 6.4.5.40
    on page 6-34 and Section 7.2 on page 7-6 and 7-7).

  • Reported: CORBA 3.0.2 — Fri, 18 Apr 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CCM spec: insufficient examples of component attributes

  • Key: CORBA34-62
  • Legacy Issue Number: 5898
  • Status: closed  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

    In OMG document formal/02-06-65, in section "1.3.3 Component Body", there
    is this text:

    "Declarations for facets, receptacles, event sources, event sinks,
    and attributes all map onto operations on the component's equivalent
    interface. These declarations and their meanings are described in
    detail below."

    In the following sections, I see facets, receptacles, event sources,
    and event sinks described, but I see no mention of attributes.
    It would be usefult to have an example of attributes in an appropriate
    place, as outlined by section 1.3.3.

    In section "1.10 Configuration with Attributes", I see that configurators
    are described, but I see no example of using attributes directly
    to configure a component.

    It would be very useful to include a small example to illustrate
    how to configure a component directly by using attributes.

    Diego Sevilla Ruiz <dsevilla@ditec.um.es> gave this
    C++ example on the CCM mailing list ( http://moriarty.dif.um.es/mailman/listinfo/ccm ):

    ======================================================

    component Whatever

    { attribute long cacheMaxKb; }

    ;

    home WhateverHome manages Whatever
    {
    };

    // C++
    WhateverHome_var weh = // obtain ref
    Whatever_var we = weh->create();

    we->cacheMaxKb(200);

    we->configuration_complete();

    ======================================================

    I don't suggest that this example be used verbatim,
    but a similar example would be useful to have in the
    CCM spec.

  • Reported: CORBA 3.0.2 — Thu, 10 Apr 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

multiple lifetime policies declaration issue

  • Key: CORBA34-64
  • Legacy Issue Number: 5870
  • Status: closed  
  • Source: INRIA ( Nawel Sabri)
  • Summary:

    In section 4.2.5 of the CCM spec formal/02-06-65, it is said that "Servant lifetime policies may be defined for each segment within a component", but there is no way to do it. Lifetime policy is declared in the CCD descriptor of the component, as an attribute of the "servant" XML element, and is implicitly applied on all the segments of the component(when it is segmented) !

    Suggested resolution: to leave the servant element as it is, expressing a DEFAULT lifetime policy, and to add the same servant element as an optional child of the segment element. This will specify the lifetime policy of the segment and override the defautl one. DTD has to be changed as follows :

    <!ELEMENT segment
    ( segmentmember+
    , containermanagedpersistence?
    , extension*
    >
    <!ATTLIST segment
    name CDATA #REQUIRED
    segmenttag CDATA #REQUIRED >

    becomes:

    <!ELEMENT segment
    ( segmentmember+
    , servant?
    , containermanagedpersistence?
    , extension*
    >
    <!ATTLIST segment
    name CDATA #REQUIRED
    segmenttag CDATA #REQUIRED >

  • Reported: CORBA 3.0.2 — Tue, 25 Feb 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

3.2.7 Compositions with Managed Storage

  • Key: CORBA34-63
  • Legacy Issue Number: 5871
  • Status: closed  
  • Source: Opus Software ( Alexandre Ricardo Nardi)
  • Summary:

    Need to reflect the change in the PSS specification, in which the catalog is not user-defined anymore. The example and the cidl syntax (chapter 2) need to be changed too.

  • Reported: CCM 3.0 — Tue, 25 Feb 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 6.4.5.52 (page 6-38)

  • Key: CORBA34-61
  • Legacy Issue Number: 5900
  • Status: closed  
  • Source: Tech-X ( Nanbor Wang)
  • Summary:

    1. Section 6.4.5.52 (page 6-38): It says the the "storagehome" element
    is a child element of "segment" where it should really say it is a
    child element of "containermanagedpersistence" instead.

  • Reported: CORBA 3.0.2 — Fri, 18 Apr 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

'local executor mapping'

  • Key: CORBA34-56
  • Legacy Issue Number: 5937
  • Status: closed  
  • Source: Anonymous
  • Summary:

    @@ It seems to me that generating 'local executor mapping' for supported
    by a component interfaces is not needed. Even though spec doesn't say
    directly that it's needed or not there are plenty of examples where it is
    shown generated.

    @@ According to the spec the following IDL is valid

    interface I;
    component C

    { provides I i; };


    while this is not:


    interface I;
    component C
    { uses I i; };


    Any reason for that?


    @@ According to the spec Home cannot be forward-declared. Any reason
    for that?



    @@ The following CIDL is legal according to the spec:


    interface I;
    component C
    { provides I i; }

    ;

    home H manages C
    {
    };

    composition session Impl
    {
    home executor H_Exec

    { implements H; manages C_Exec; };
    };


    However there is no way to generate valid local executor mapping for this
    CIDL. The resolution would be to require all forward-declared interfaces
    used by component's provides declarations to be defined before composition
    for this component is seen. I.e. the following CIDL would be a corrected
    version:


    interface I;
    component C
    { provides I i; };


    home H manages C
    {
    };


    interface I {};


    composition session Impl
    {
    home executor H_Exec
    { implements H; manages C_Exec; }

    ;
    };

    @@ The following legal according to the spec IDL:

    module M
    {
    module Components
    {
    struct EnterpriseComponent {};
    };

    component C {};
    };

    would result in local executor mapping that looks something like this:

    module M
    {
    module Components
    {
    struct EnterpriseComponent {};
    };

    component C {};
    };

    module M
    {
    local interface C : Components::EnterpriseComponent {};
    };

    which is illegal IDL. The resolution would be to require names like
    Components::EnterpriseComponent to be fully qualified e.g.
    ::Components::EnterpriseComponent.

  • Reported: CORBA 3.0.2 — Wed, 7 May 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

portability of CCM descriptors

  • Key: CORBA34-55
  • Legacy Issue Number: 6286
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Sylvain Leblanc)
  • Summary:

    Identifier (FPI).

    These FPIs are required for the CAD, CSD, CCD and CPF DTDs.

    Proposed resolution:

    Adds the CCM DTDs on the OMG web site and adds the following text in the specification:

    • section 6.3, before subsection 6.3.1 :

    The CORBA Software Descriptor must refer to the DTD using the following statement: <!DOCTYPE softpkg PUBLIC "-//OMG//DTD CORBA Software Descriptor 3.0//EN" "http://www.omg.org/dtd/softpkg_3_0.dtd" />

    • section 6.4, before subsection 6.4.1 :

    The CORBA Component Descriptor must refer to the DTD using the following statement: <!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "http://www.omg.org/dtd/corbacomponent_3_0.dtd" />

    • section 6.4.4:

    replace

    <!DOCTYPE corbacomponent SYSTEM "corbacomponen.tdtd">

    with

    <!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "http://www.omg.org/dtd/corbacomponent_3_0.dtd" />

    • section 6.7, before subsection 6.7.1 :

    The Component Assembly Descriptor must refer to the DTD using the following statement: <!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "http://www.omg.org/dtd/componentassembly_3_0.dtd" />

    • section 6.7.1:

    replace

    <!DOCTYPE componentassembly SYSTEM "componentassembly.dtd">

    with

    <!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "http://www.omg.org/dtd/componentassembly_3_0.dtd" />

    • section 6.8, before subsection 6.8.1 :

    The Component Property File must refer to the DTD using the following statement: <!DOCTYPE properties PUBLIC "-//OMG//DTD Component Property File 3.0//EN" "http://www.omg.org/dtd/properties_3_0.dtd" />

  • Reported: CORBA 3.0.2 — Wed, 1 Oct 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

EnterpriseComponent should have a get_servant method

  • Key: CORBA34-54
  • Legacy Issue Number: 6672
  • Status: closed  
  • Source: National Lab. on Distributed Processing of P.R.China ( Deng Bo)
  • Summary:

    The EnterpriseComponent should have a get_servant method. When creating component or facet reference of service or session component, the first step is creating the object reference and associating its PortableServer::ObjectId with servant. Currently, the container manages executor, but the EnterpriseComponent interface does not provide a mechanism to get servant. The method would be very useful as it means the container can use executor to get servant, which is not possible now.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-39

    module Components { local interface EnterpriseComponent {}; };

    with

    module Components { local interface EnterpriseComponent

    { Servant get_servant() raises (CCMException); }

    ; };

    and add the operation description

    get_servant

    The get_servant operation returns a reference to the servant.

  • Reported: CCM 3.0 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

issue on component supporting abstract interfaces

  • Key: CORBA34-58
  • Legacy Issue Number: 5910
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    The following information is sent in order for the specification to
    clearly state if components and local interfaces can support abstract
    interfaces (the specification is confusing on this point).

    CORBA 3.0.1 does not explicitely states if a component can support an
    abstract interface, thus it can be considered that it is possible. If so
    a big problem arises as local interfaces inheriting abstract ones is
    confusing in the specification.

    In addition, it is neither explicitely stated that provides and uses
    declarations can or cannot be of types defined through abstract
    interfaces. It does not seem to make sense for a port to be an abstract
    type. Facets will never be used by value, and an operation cannot
    (should not) return the reference of a facet or a valuetype (which would
    be in favor of provides to be defined using abstract interfaces).

      • Problem

    Consider the following definitions which are correct regarding
    formal/02-12-06:

    /* omg idl3 */

    abstract interface I

    { void foo () ; } ;


    component C supports I {
    } ;


    The mapping to OMG IDL2 of these definitions is not correct right now as
    they become:


    /* omg idl2 */


    abstract interface I { void foo () ; }

    ;

    interface C : Components::CCMObject, I { } ;

    local interface CCM_C : I { } ;

    According to formal/02-12-06, the last line may not be correct. Local
    interfaces may not inherit abstract interfaces (section 10.5.28). (I use
    may as it is confusing and can lead to various understanding of the
    spec.)

      • Potential solutions:

    1. State in the CORBA 3.0.1 that components cannot support abstract
    interfaces. In favor: Could ne considered as a minor change. Against: a
    component reference cannot be returned by an operation that can return
    an object by value or by reference. This solution looks cleaner that the
    second one from a software engineering point of view.

    2. Clearly state that components and local interfaces can support
    abstract interfaces. This use may be surprising from a software
    engineering point of view, but may be important for some users. This
    bring back the debate "quality vs powerfulness".

    In any case, I think it should be clearly stated if local interfaces may
    or may not inherit abstract ones.

  • Reported: CORBA 3.0.2 — Wed, 23 Apr 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CCM Spec: attributes are listed in the ports section?

  • Key: CORBA34-57
  • Legacy Issue Number: 5918
  • Status: closed  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

    In section 1.1.2 of the CCM specification:

    1.1.2 Ports
    ===========
    ..... The component model supports four basic kinds of ports:

    • Facets
    • Receptacles
    • Event sources
    • Event sinks
    • Attributes

    Well, that list includes five things, not four.

    So, is an attribute considered a port or not?

    The wording in this section needs to be clarified in the CCM
    specification, because it is not clear if an attribute
    is a port or not.

  • Reported: CORBA 3.0.2 — Mon, 28 Apr 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

EnterpriseComponent should have a set_persistent_object method

  • Key: CORBA34-48
  • Legacy Issue Number: 7732
  • Status: closed  
  • Source: National Lab, Distributed Process, China ( Deng Bo)
  • Summary:

    There is no standard way for container to intercept component state management.
    By which container can implement O/R mapping and management component states.

    Resolution:

    Container can intercept state management by provide a storage object for executor segment.
    Replace the following text in formal/02-06-05 on page 3-39

    module Components
    {
    local interface EnterpriseComponent
    {

    };
    };

    with

    module Components
    {
    local interface EnterpriseComponent

    { void set_persistent_object(in StorageObjectBase); }

    ;
    };

    and add the operation description

    set_persistent_object

    Set context object for executors

  • Reported: CORBA 3.0.3 — Fri, 10 Sep 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeExecutorBase should have a set_context method

  • Key: CORBA34-47
  • Legacy Issue Number: 7733
  • Status: closed  
  • Source: National Lab, Distributed Process, China ( Deng Bo)
  • Summary:

    Home executor cann't access context object. Thus some features like SMP(Self-Management Persistence) are not enabled.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-40

    module Components {
    local interface HomeExecutorBase {};
    };

    with

    module Components {
    local interface HomeExecutorBase

    { void set_context(in CCMContext con); }

    ;
    };

    and add the operation description

    set_context

    Set context object for home executor.

  • Reported: CORBA 3.0.3 — Fri, 10 Sep 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Generic connectivity for Receptacles, Emitters, Publishers

  • Key: CORBA34-49
  • Legacy Issue Number: 7556
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The CCMObject interface contains numerous operations for generic
    connection management (in addition to the type-specific operations
    defined by equivalent IDL for a component).

    However, there's a separate set of "connect" and "disconnect"
    operations for each kind of port, i.e., receptacles, emitters and
    publishers. This is inconvenient for generic software that treats
    ports generically, such as the deployment infrastructure in an
    implementation of the Deployment and Configuration specification.

    The set of operations might even get larger in the future, when
    Streams for CCM becomes available.

    I thus propose to add generic "connect_feature" and "disconnect_
    feature" operations that is able to interconnect compatible ports
    regardless of the type of port.

    Proposed resolution:

    In section 1.11.1, "CCMObject Interface," add the following two
    operations to the CCMObject interface:

    module Components {
    interface CCMObject : Navigation, Receptacles, Events

    { Cookie connect_feature (in FeatureName name, in Object connection) raises (InvalidName, InvalidConnection, AlreadyConnected, ExceededConnectionLimit); void disconnect_feature (in FeatureName name, in Cookie ck) raises (InvalidName, InvalidConnection, CookieRequired, NoConnection); /* other operations as before */ }

    ;
    };

    Add the following explanation to the same section:

    connect_feature

    The connect_feature operation connects the object reference
    specified by the connection parameter to the component feature
    specified by the name parameter. The feature must be either a
    receptacle, emitter or publisher port.

    If the feature identified by the name parameter is a receptacle
    port, the connect_feature operation acts equivalent to calling
    the connect operation on the Receptacles interface.

    If the feature identified by the name parameter is an emitter
    port, the connect_feature operation acts equivalent to calling
    the connect_consumer operation on the Events interface. A nil
    "cookie" value is returned.

    If the feature identified by the name parameter is a publisher
    port, the connect_feature operation acts equivalent to calling
    the subscribe operation on the Events interface.

    If the feature identified by the name parameter is neither
    receptacle, emitter or publisher port, or if the component does
    not have any feature by that name, the InvalidName exception is
    raised.

    disconnect_feature

    The disconnect_feature operation dissolves the connection
    identified by the ck cookie to the component feature specified
    by the name parameter.

    If the feature identified by the name parameter is a receptacle
    port, the disconnect_feature operation acts equivalent to calling
    the disconnect operation on the Receptacles interface.

    If the feature identified by the name parameter is an emitter
    port, the disconnect_feature operation raises the InvalidConnection
    exception if a non-nil cookie is passed as the ck parameter;
    otherwise, it acts equivalent to calling the disconnect_consumer
    operation on the Events interface.

    If the feature identified by the name parameter is a publisher
    port, the disconnect_feature operation acts equivalent to calling
    the unsubscribe operation on the Events interface.

    If the feature identified by the name parameter is neither
    receptacle, emitter or publisher port, or if the component does
    not have any feature by that name, the InvalidName exception is
    raised.

  • Reported: CORBA 3.0.3 — Thu, 1 Jul 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeExecutorBase should have a get_servant method

  • Key: CORBA34-50
  • Legacy Issue Number: 6689
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This question is similar to the first one. When creating component or
    facet reference of service or session component, the first step is
    creating the object reference and associating its
    PortableServer::ObjectId with servant. Currently, the container manages
    executor, but the HomeExecutorBase interface does not provide a
    mechanism to get servant. The method would be very useful as it means
    the container can use executor to get servant, which is not possible now.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-40

    module Components {
    local interface HomeExecutorBase {};
    };

    with

    module Components {
    local interface HomeExecutorBase

    { Servant get_servant() raises (CCMException); }

    ;
    };

    and add the operation description

    get_servant

    The get_servant operation returns a reference to the servant.

  • Reported: CORBA 3.0.2 — Fri, 5 Dec 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

EnterpriseComponent should have a get_servant method

  • Key: CORBA34-51
  • Legacy Issue Number: 6688
  • Status: closed  
  • Source: Anonymous
  • Summary:

    When creating component or facet reference of service or session
    component, the first step is creating the object reference and
    associating its PortableServer::ObjectId with servant. Currently, the
    container manages executor, but the EnterpriseComponent interface does
    not provide a mechanism to get servant. The method would be very useful
    as it means the container can use executor to get servant, which is not
    possible now.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-39

    module Components {
    local interface EnterpriseComponent {};
    };

    with

    module Components {
    local interface EnterpriseComponent

    { Servant get_servant() raises (CCMException); }

    ;
    };

    and add the operation description

    get_servant

    The get_servant operation returns a reference to the servant.

  • Reported: CORBA 3.0.2 — Fri, 5 Dec 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The association of entity component primary key and PSS key is unclear

  • Key: CORBA34-52
  • Legacy Issue Number: 6684
  • Status: closed  
  • Source: National Lab, Distributed Process, China ( Deng Bo)
  • Summary:

    Issue: The association of entity component primary key and PSS key is unclear. There is only one attribute as the primary key in the CCM entity component, PSS has no primary key. An entity can be identified uniquely by the PSS key, but currently PSS permits several keys, and each PSS key can be composed of several attributes. Consequently, it is difficult to establish association between entity component primary key and PSS key, and the create and find methods can not to be mapped to the corresponding methods of PSS.

  • Reported: CORBA 3.0.2 — Sat, 6 Dec 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeExecutorBase should have a get_servant method

  • Key: CORBA34-53
  • Legacy Issue Number: 6673
  • Status: closed  
  • Source: National Lab. on Distributed Processing of P.R.China ( Deng Bo)
  • Summary:

    The HomeExecutorBase should have a get_servant method. When creating component or facet reference of service or session component, the first step is creating the object reference and associating its PortableServer::ObjectId with servant. Currently, the container manages executor, but the HomeExecutorBase interface does not provide a mechanism to get servant. The method would be very useful as it means the container can use executor to get servant, which is not possible now.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-40

    module Components { local interface HomeExecutorBase {}; };

    with

    module Components { local interface HomeExecutorBase

    { Servant get_servant() raises (CCMException); }

    ; };

    and add the operation description

    get_servant

    The get_servant operation returns a reference to the servant.

  • Reported: CORBA 3.0.2 — Thu, 4 Dec 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Contradictory sections in the CCM and Lightweight CCM specifications

  • Key: CORBA34-44
  • Legacy Issue Number: 10142
  • Status: closed  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    I'd like to report an issue that exists in both the CORBA Component Model Specification (formal/06-04-01) and also the Lightweight CORBA Component Model specification (ptc/04-06-10) please.

    In section "6.11 Component Inheritance" of formal/06-04-01 there is the statement : "A derived component type may not directly support an interface."

    This same statement is made in "1.11 Component Inheritance" of ptc/04-06-10 and in "3.17.2.3 Component Inheritance" of the CORBA 3.0.3 spec (04-03-02).

    But, in both "6.3.2.4 Inheritance and supported interfaces" of formal/06-04-01 and "1.3.2.4 Inheritance and supported interfaces" of ptc/04-06-10 there is the following:

    "For a component declaration with the following form:

    component <component_name> : <base_name>
    supports <interface_name_1>, <interface_name_2>

    { Â… };


    the equivalent interface shall have the following form:
    interface <component_name>
    : <base_name>, <interface_name_1>, <interface_name_2> { Â… }

    ;"

    The above example is giving equivalent IDL for a declaration that the preceding statements regarding component inheritance say is not permitted. It should presumably be removed.

  • Reported: CORBA 3.0.3 — Fri, 25 Aug 2006 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

spec should define how the base class of an executor is generated by the framework

  • Key: CORBA34-41
  • Legacy Issue Number: 14026
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The LwCCM removes the usage of cidl from CCM, but this looses also the fixed name of the base class of the executor. The spec should define how the base class of an executor is generated by the framework, so that the implementor of the executor can write a portable executor

  • Reported: ZIOP 1.0b1 — Tue, 23 Jun 2009 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The D&C IDL part doesn't match 06-04-02.

  • Key: CORBA34-43
  • Legacy Issue Number: 10582
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The D&C IDL part doesn't match 06-04-02. For example TargetManager is not correctly in 06-04-01 and has its errors in 06-04-02

  • Reported: CORBA 3.0.3 — Tue, 9 Jan 2007 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

add a sequence of CCMHome typedef sequence CCMHomes;

  • Key: CORBA34-42
  • Legacy Issue Number: 13151
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We would like to add a request to add the following IDL type. Just add a sequence of CCMHome typedef sequence<CCMHome> CCMHomes;

  • Reported: CORBA 3.1 — Wed, 10 Dec 2008 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

add some feature to let an assembly look like a monolithic compoment

  • Key: CORBA34-46
  • Legacy Issue Number: 9173
  • Status: closed  
  • Source: nudt ( jhuang)
  • Summary:

    It is better to add some feature to let an assembly look like a monolithic compoment. For example, add some discriptions in CAD(compoment assembly discription) file to identify the external interface of an assembly. There exists an delegate compoment behaving like the assembly. It can navigate one external interface of an assembly to another. This delegate compoment can be created by main component server automatically according to the CAD file.

  • Reported: CORBA 3.0.3 — Fri, 18 Nov 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

"supports" keyword

  • Key: CORBA34-45
  • Legacy Issue Number: 9174
  • Status: closed  
  • Source: nudt ( jhuang)
  • Summary:

    Issue: It is good to let CCM component definition can have operations directly, but not indirectly by "supports" keyword. The "supports" adds too much complexity when defining a compoment and compiler implementation

  • Reported: CORBA 3.0.3 — Fri, 18 Nov 2005 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

two not used and document exceptions listed

  • Key: CORBA34-36
  • Legacy Issue Number: 15052
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL file 07-02-01 related to CCM we have the following exceptions

    exception LastConfiguration {
    };

    exception InvalidReference {
    };

    LastCOnfiguration is not listed at all in 06-04-01 and 06-04-02

    InvalidReference is listed in 06-04-02 in text and diagrams, but not in idl at all

  • Reported: ZIOP 1.0 — Tue, 16 Feb 2010 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Event mechanism proposal

  • Key: CORBA34-38
  • Legacy Issue Number: 14087
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The CCM spec describes the event mechanism default part of CCM. We want to propose to change this event machine to a connector based model as part of the DDS4CCM specification. Then there would be an event connector and the container then is much more light weight and easier to use. People that don't want to use CORBA event machinisms don't pull in all the dependent code

  • Reported: ZIOP 1.0b1 — Tue, 21 Jul 2009 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

typedef CCMObjectSeq

  • Key: CORBA34-39
  • Legacy Issue Number: 14064
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In section 10.3.1.2 the typedef CCMObjectSeq is listed, we propose to move it to Section 6.11.1 just after the definition of CCMObject

  • Reported: ZIOP 1.0b1 — Wed, 8 Jul 2009 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The spec mentions InvalidConfiguration as exception but there is no idl in this spec

  • Key: CORBA34-40
  • Legacy Issue Number: 14061
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec mentions InvalidConfiguration as exception but there is no idl in this spec that describes this exception and its members

  • Reported: ZIOP 1.0b1 — Wed, 8 Jul 2009 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

ResourceCommitmentManager lacking

  • Key: CORBA34-37
  • Legacy Issue Number: 15051
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL file 07-02-01 related to CCM is lacking ResourceCommitmentManager

  • Reported: ZIOP 1.0 — Tue, 16 Feb 2010 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CCMHome should have a get_components method

  • Key: CORBA34-31
  • Legacy Issue Number: 6438
  • Status: closed  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    The CCMHome interface does not provide a mechanism for obtaining references to all CCMObjects that the home has created (those that have not been removed). The lack of a method to get all the components created by a home is inconsistent with other sections of the CCM model (specifically the deployment module APIs). Furthermore, this method would be very useful as it would provide a mechanism for querying a Container for all existent components.

    Resolution:

    Replace the following text in formal/02-06-05 on page 1-41

    interface CCMHome

    { CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); }

    ;

    with

    typedef sequence<CCMObject> CCMObjects;

    interface CCMHome

    { CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); CCMObjects get_components(); }

    ;

    and add the operation description

    get_components

    The get_components operation returns a sequence of all existent CCMObject references (i.e. those that have not been removed) created by this CCMHome.

  • Reported: CORBA 3.0.2 — Wed, 5 Nov 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CCMHome should have a get_container method

  • Key: CORBA34-32
  • Legacy Issue Number: 6001
  • Status: closed  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    The CCMHome interface does not provide a mechanism for locating the container that created a home. The lack of a method to get a home's container is inconsistent with the rest of the CCM model. Furthermore, this method would be very useful as it would provide a means to navigate from a component to its ServerActivator, which is currently not possible.

    Resolution:

    Replace the following text in formal/02-06-05 on page 1-41

    interface CCMHome

    { CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); }

    ;

    with

    interface CCMHome

    { CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); Container get_container(); }

    ;

    and add the operation description

    get_container

    The get_container operation returns a reference to the Container object that created this CCMHome

  • Reported: CORBA 3.0.2 — Thu, 17 Jul 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Incorrect statement that implies that connect_consumer returns a cookie

  • Key: CORBA34-33
  • Legacy Issue Number: 15960
  • Status: closed  
  • Source: Remedy IT ( Marcel Smit)
  • Summary:

    In chapter 6.6.8, sub paragraph "connect_consumer" the following statement is given:

    The cookie return value can be used to disconnect from the source.

    I think that this sentence should be removed from the specification since connect_consumer is declared as follows:

    void connect_consumer (
    in FeatureName emitter_name,
    in EventConsumerBase consumer)
    raises (InvalidName, AlreadyConnected,
    InvalidConnection);

    Also, disconnect_consumer doesn't provide a cookie as input parameter.

  • Reported: ZIOP 1.0 — Fri, 14 Jan 2011 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeConfiguration::set_configuration_values should document exception

  • Key: CORBA34-34
  • Legacy Issue Number: 15164
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    HomeConfiguration::set_configuration_values documentation should mention which exception to thrown when an any/name value pair has a not supported name or when the any can't be extracted

  • Reported: ZIOP 1.0 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Interface Introspection

  • Key: CORBA34-25
  • Legacy Issue Number: 6391
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    Inspired by a recent paper by Doug Schmidt and Steve Vinoski
    and the resulting newsgroup discussion on comp.object.corba,
    I have a feature request to introduce a better reflection
    mechanism into CORBA.

    At the moment, there is the CORBA::Object::get_interface()
    operation to access a matching InterfaceDef entry in an
    Interface Repository. Since an Interface Repository is
    seldomly deployed, using this operation is pretty much
    futile and will either return a nil reference or throw
    an exception.

    Therefore, I propose to add a new get_interface_def()
    operation to the Object interface that returns a FullInter-
    faceDef structure, as defined by the Interface Repository.
    This structure contains all that a dynamic client (such as
    the ones proposed by Schmidt&Vinoski, or software like
    CorbaScript or Combat) needs to know about an interface.

    A new _interface_def pseudo-operation then needs to be added
    to GIOP. This could probably be done without a version change,
    as no marshalling changes or new messages are involved, it's
    just another operation.

    On the server side, the IDL compiler would generate a suitable
    implementation as part of the skeleton. This implementation
    could just contain a binary representation of the FullInterface-
    Description structure (just like a "precompiled" TypeCode) that
    is dumped to the GIOP stream. (So that you don't need the
    Interface Repository IDL around.)

    Proposed resolution:

    In chapter 4.3, "Object Reference Operations," add the following
    operation to the Object interface:

    module CORBA {
    interface Object

    { // PIDL ... other operations ... FullInterfaceDescription get_interface_def (); }

    ;
    };

    Add the following explanation to 4.3.1, "Determining the Object
    Interface"

    4.3.1.2 get_interface_def

    FullInterfaceDescription get_interface_def ();

    The get_interface_def operation returns a data structure
    describing the most derived type of the object addressed by
    the reference. The FullInterfaceDescription structure includes
    descriptions of all the operations and attributes in the
    transitive closure of the inheritance graph of the interface
    being described. See the Interface Repository chapter for the
    contents of the data structure. Note that if an Interface
    Repository is not available, object references contained in
    this structure may be nil or inaccessible.

    In chapter 15.4.2, "Request Message", update the text that
    reads

    In the case of CORBA::Object operations that are defined in
    the CORBA Core (Section 4.2, "Object Reference Operations,"
    on page 4-12) and that correspond to GIOP request messages,
    the operation names are _interface, _is_a, _non_existent,
    _domain_managers and _component.

    to read

    In the case of CORBA::Object operations that are defined in
    the CORBA Core (Section 4.2, "Object Reference Operations,"
    on page 4-12) and that correspond to GIOP request messages,
    the operation names are _interface, _is_a, _non_existent,
    _domain_managers, _component or _interface_def.

    In the C++ language mapping, section 1.37.1, "Mapping of
    PortableServer::Servant", add the following operation to
    class ServantBase:

    namespace PortableServer { // C++
    class ServantBase

    { ... other operations ... virtual CORBA::FullInterfaceDescription_ptr _get_interface_def (); }

    ;
    }

    Update the paragraph that reads,

    ServantBase provides default implementations of the
    _get_interface, _is_a and _non_existent object reference
    operations [...]

    to read

    ServantBase provides default implementations of the
    _get_interface, _is_a, _non_existent and _get_interface_def
    object reference operations [...]

    Add a new paragraph,

    For static skeletons, the default implementation of the
    _get_interface_def function returns information about the
    interface associated with the skeleton class. For dynamic
    skeletons, the default implementation uses the
    _get_interface function to determine its return value.

    Other language mappings might need similar updates.

    By the way, since FullInterfaceDescription is only used as
    a return value, only a pointer to FullInterfaceDescription
    is needed. Therefore, you don't need the full Interface
    Repository interface descriptions but only a pointer to an
    incomplete type.

    On the client side, you only need to pull in the Interface
    Repository IDL if you are actually calling _get_interface_def.

    On the server side, the skeleton can do some ORB-dependent
    magic to push a precompiled binary data structure into the
    result.

  • Reported: CORBA 3.0.2 — Mon, 27 Oct 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Generic port connections

  • Key: CORBA34-27
  • Legacy Issue Number: 5852
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    I propose to introduce generic operations that allow
    interconnecting ports regardless of their type. This
    would ease generic programming.

    The first part of the proposal is to allow generic
    usage of the "connect" and "disconnect" operations
    that are (currently) in the Receptacles interface,
    i.e. to extend the functionality to not only work
    on receptacles, but also on event source ports
    (emits and publishes keywords).

    The names "connect" and "disconnect" are appropriate
    for any kind of port, and their signatures are the
    same as "subscribe" and "unsubscribe" in the Events
    interface.

    The second part of the proposal is to introduce a
    new operation "get_port" into the CCMObject interface.
    This operation would take a FeatureName parameter and
    return the object reference associated with that
    facet or event sink.

    So I propose the following steps:

    1.) Allow connect, disconnect and get_connections to
    operate on event source ports, and introduce a
    get_port operation.
    This change would be backwards compatible.

    2.) Move connect, disconnect and get_connections from
    the now inappropriate Receptacles interface into
    the CCMObject interface. This step might cause
    minor, easily fixable breakage for software that
    widens an object reference to Receptacles instead
    of CCMObject. (I don't think any such software
    exists, it's more of a theoretical issue.)

    3.) Discourage, then remove the "subscribe" and
    "unsubscribe" operations in the Events interface.
    They don't offer any more type safety than connect
    and disconnect.

    I believe that these changes would also be of interest
    for slimming down CCM for the Lightweight CCM RFP, and
    in light of the Streams for CCM RFP (which will likely
    add another port type that needs interconnecting).

    This change does not have any impact on component
    implementations. The change to CCM implementations
    (ORBs) is neglegible (I would expect a day to make
    these changes in MicoCCM, another day to test them).

    If there is general agreement on this issue, I will
    draft the text updates.

  • Reported: CORBA 3.0.2 — Thu, 6 Feb 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

LwCCM issue - Section 1.4.3.3 Exclusion

  • Key: CORBA34-26
  • Legacy Issue Number: 7027
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    While reviewing Victor's issue on section 1.5.3, I noticed
    that a similar problem exists with respect to the Navigation
    interface.

    While the normative exclusion "disable get_all_facets, get_
    named_facets, same_component operations in Navigation
    interface" retains the generic provide_facet operation,
    removing section 1.4.3.3 would remove the entire Navigation
    interface.

    On the other hand, the still-present section 1.4.3.4 references
    the disabled operations.

    Proposed resolution:

    In section 10.3, in the "Document Impact" column of the second
    row, replace the text

    1.4.3.3: remove

    with

    1.4.3.3: remove these operations from the Navigation
    interface. Also remove the PortDescription, FacetDescription
    and FacetDescriptions types.

    1.4.3.4: remove

  • Reported: CORBA 3.0.2 — Wed, 25 Feb 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeConfigurator should not extend CCMHome

  • Key: CORBA34-29
  • Legacy Issue Number: 5769
  • Status: closed  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    Document formal/02-06-05 on page 1-49 states the following:

    "The implementation of a component type's home object may optionally support the
    HomeConfiguration interface. The HomeConfiguration interface is derived from
    Components::CCMHome. In general, the HomeConfiguration interface is
    intended for use by an agent deploying a component implementation into a container,
    or an agent deploying an assembly."

    The first statement does not offer a clear interpretation when considering the language mapping for homes. If the implementation of a component type's home optionally supports HomeConfigurator how is this information defined in IDL? Should the component type's home definition support HomeConfiguration? This would seem to be the proper interpretation but that leads to problems in the language mapping of the defined home. In section 3.3.3.6 on page 3-45

    Home Explicit Executor Interface

    The home explicit executor callback interface is defined by the following rules:

    1. For each home <home name>, a local explicit executor interface with the same
    name as the home, but with a prefix of "CCM_" and a postfix of "Explicit" is
    defined.

    2. The explicit executor interface contains all attributes and operations declared by the
    home.

    3. If the home has a base with a name of <base name>, the explicit executor
    interface inherits CCM_<base name>Explicit. If the home does not have a base,
    the explicit executor interface inherits Components::HomeExecutorBase.

    4. If the home has supported interfaces, they are inherited by the explicit executor
    interface.

    5. Additional operations are added to the explicit executor interface for factories and
    finders, see below.

    Item 4 would imply that the home explicit executor must include operations defined in both HomeConfigurator and CCMHome since HomeConfigurator extends CCMHome. This is clearly not the intended behavior of the home explicit executor since it specifically excludes any direct inheritance of CCMHome.

    Resolution

    The inheritance of CCMHome by HomeConfiguration should be removed since it is implied that every home will extend CCMHome and home definitions in IDL would then be able to explicitly support HomeConfiguration without the extra baggage of the CCMHome interface. Furthermore, the language mapping does not properly handle a component home that supports HomeConfiguration (if it extends CCMHome) since the component executor would include all CCMHome operations. The language mapping would work fine if HomeConfiguration did not extend CCMHome.

    Replace text in formal/02-06-05 on page 1-49

    The implementation of a component type's home object may optionally support the
    HomeConfiguration interface. The HomeConfiguration interface is derived from
    Components::CCMHome. In general, the HomeConfiguration interface is
    intended for use by an agent deploying a component implementation into a container,
    or an agent deploying an assembly.

    with

    The implementation of a component type's home object may optionally support the
    HomeConfiguration interface. In general, the HomeConfiguration interface is
    intended for use by an agent deploying a component implementation into a container,
    or an agent deploying an assembly.

    Replace IDL in formal/02-06-05 on page 1-49

    module Components {
    interface HomeConfiguration : CCMHome

    { void set_configurator (in Configurator cfg); void set_configuration_values ( in ConfigValues config); void complete_component_configuration (in boolean b); void disable_home_configuration(); };
    };


    with


    module Components {
    interface HomeConfiguration { void set_configurator (in Configurator cfg); void set_configuration_values ( in ConfigValues config); void complete_component_configuration (in boolean b); void disable_home_configuration(); }

    ;
    };

  • Reported: CORBA 3.0.2 — Mon, 2 Dec 2002 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Session2Context interface

  • Key: CORBA34-30
  • Legacy Issue Number: 5909
  • Status: closed  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    The Session2Context interface allows developers to create an object reference from an octet sequence (object id). The the Entity2Context allows developers to create an object reference from a ComponentId. Neither the Session2Context nor the the Entity2Context allows the developer to infer the octet sequence or ComponentId that is associated with an operation invocation on a component. In other words, a developer may use a context to create multiple references that are subsequently invoked by a client. When the client invokes an operation on the reference the component code will be required to satisfy the operation invocation (either through the monolithic or the locator language mapping strategy). There is no information, however, as to which of the created references is being invoked by a client. To resolve the ambiguity the component developer must be able to use the context to provide the current octet sequence or ComponentId corresponding to the reference that is currently being invoked.

    Resolution:

    Replace the following text in formal/02-06-05 on page 4-37

    local interface Session2Context : SessionContext, CCM2Context

    { Object create_ref (in CORBA::RepositoryId repid); Object create_ref_from_oid ( in PortableServer::ObjectIdCORBA::OctetSeq oid, in CORBA::RepositoryId repid); PortableServer::ObjectId CORBA::OctetSeq get_oid_from_ref (in Object objref) raises (IllegalState, BadComponentReference); }

    ;

    with

    local interface Session2Context : SessionContext, CCM2Context

    { Object create_ref (in CORBA::RepositoryId repid); Object create_ref_from_oid ( in PortableServer::ObjectIdCORBA::OctetSeq oid, in CORBA::RepositoryId repid); PortableServer::ObjectId CORBA::OctetSeq get_oid_from_ref (in Object objref) raises (IllegalState, BadComponentReference); CORBA::OctetSeq get_current_oid () raises (IllegalState); }

    ;

    and add the operation description

    get_current_oid

    The get_current_oid operation is used by the component to extract the oid
    associated with the current operation invocation. This operation must be called
    within an operation invocation. If not, the IllegalState exception shall be raised.

    Also, replace the following text in formal/02-06-05 on page 4-44

    local interface Entity2Context : EntityContext, CCM2Context

    { ComponentId get_component_id () raises (IllegalState); ComponentId create_component_id ( in FacetId target_facet, in SegmentId target_segment, in SegmentDescrSeq seq_descrs); ComponentId create_monolithic_component_id ( in FacetId target_facet, in StateIdValue sid); Object create_ref_from_cid ( in CORBA::RepositoryId repid, in ComponentId cid); ComponentId get_cid_from_ref ( in Object objref) raises (BadComponentReference); }

    ;

    with

    local interface Entity2Context : EntityContext, CCM2Context

    { ComponentId get_component_id () raises (IllegalState); ComponentId create_component_id ( in FacetId target_facet, in SegmentId target_segment, in SegmentDescrSeq seq_descrs); ComponentId create_monolithic_component_id ( in FacetId target_facet, in StateIdValue sid); Object create_ref_from_cid ( in CORBA::RepositoryId repid, in ComponentId cid); ComponentId get_cid_from_ref ( in Object objref) raises (BadComponentReference); ComponentId get_current_cid () raises (IllegalState); }

    ;

    and add the operation description

    get_current_cid

    The get_current_cid operation is used by a persistent component to retrieve the
    ComponentId associated with the current operation invocation. This operation must be called
    within an operation invocation. If not, the IllegalState exception shall be raised.

  • Reported: CORBA 3.0.2 — Tue, 22 Apr 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

LwCCM issue - Section 1.6.8 Exclusion

  • Key: CORBA34-28
  • Legacy Issue Number: 7028
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    While reviewing Victor's issue on section 1.5.3, I noticed
    that a similar problem exists with respect to the Events
    interface.

    While the normative exclusion "disable get_all_consumers
    [...]" (8th row of section 10.3) retains the generic
    get_consumer, subscribe, unsubscribe, connect_consumer
    and disconnect_consumer operations, removing section 1.6.8
    would remove the entire Events interface.

    Proposed resolution:

    In section 10.3, in the "Document Impact" column of the
    8th row, replace the text

    Section 1.6.8: remove

    with

    Section 1.6.8: remove these operations from the Events
    interface. Also remove the ConsumerDescription,
    EmitterDescription, SubscriberDescription and
    PublisherDescription types.

  • Reported: CORBA 3.0.2 — Wed, 25 Feb 2004 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

page 1-20 and page 1-21 - editorial

  • Key: CORBA34-19
  • Legacy Issue Number: 5945
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    -page 1-20 and page 1-21 the names of the operations get_all_receptacles get_named_receptacles are written with italic font. This seems to be a mistake.

  • Reported: CORBA 3.0.2 — Thu, 29 May 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Change new GIOP Negotiate Session Message to Firewall Specific

  • Key: CORBA34-23
  • Legacy Issue Number: 6285
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Here is a small proposal for GIOP 1.4 with Firewall and Bidirectional. We
    would get rid of all the weird nasty service contexts and make it
    simplistic. The FireWall messages are only allowed before any other GIOP
    messages. BiDir messages can happen at any time according to their
    protocol.

    What do you think? Asside from some problems I see with BiDir
    offer/challenge/response correlation, it is essentially equivalent to the
    solution proposed in the adopted spec.

    module GIOP {
    enum MsgType_1_4

    { Request, Reply, CancelRequest, LocateRequest, LocateReply, CloseConnection, MessageError, Fragment, // GIOP 1.1 addition // GIOP 1.4 additions FirewallPathRequest, // 8 FirewallPathRepsonse, // 9 BiDirOffer, // 10 BiDirChallenge, // 11 BiDirResponse // 12 }

    ;

    // Firewall Traversal GIOP 1.4

    struct FirewallSpec

    { boolean is_intelligent; IOP::TaggedComponentSeq endpoints; }

    ;
    typedef sequence<FirewallSpec> FirewallPath;

    struct FirewallPathRequestHeader

    { unsigned long host_index; FirewallPath path; }

    ;
    // No body follows.

    enum FirewallPathResponseStatusType

    { NO_EXCEPTION, SYSTEM_EXCEPTION }

    ;

    struct FirewallPathResponseHeader

    { FirewallPathResponseStatusType status; boolean connection_complete; }

    ;
    // Marshalled body immediately follows

    // Bidirectional GIOP 1.4

    // To keep this file uncomplicated we can introduce the
    // headers and put the marshalled bodies in a separate BiDir module
    // Due due some issue about the challege/response protocol for this,
    // there may be a need of an offer_id to correlate them.

    struct BiDirOfferHeader

    { unsigned long offer_id; };
    // Marshalled body immediately follows.


    struct BiDirChallengeHeader { unsigned long offer_id; }

    ;
    // Marshalled body immediately follows.

    struct BiDirResponseHeader

    { unsigned long offer_id; }

    ;
    // Marshalled body immediately follows.
    };

  • Reported: CORBA 3.0.2 — Thu, 2 Oct 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

GIOP Conformance and Interceptors

  • Key: CORBA34-22
  • Legacy Issue Number: 6314
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    GIOP Conformance and Interceptor don't play well together.

    GIOP minor version conformance mandates two things.

    1. That standard service contexts that are considered optional
    can be ignored should the implementation not understand them.

    2. That certain service contexts get processed according to the
    specification of where they are defined.

    This requirement works well for GIOP 1.2 where a lot of them are optional,
    since (1) will apply. An implementation can claim 1.2 conformance and not
    process any of them.

    However, 1.3 and upcoming 1.4 will mandate the processing of them
    according to their specification. In many cases, this means that some
    default response may be required, which means that a GIOP 1.3, or later
    engine must have a "default" response for these service contexts.

    In an ORB that uses interceptors and has a generic GIOP messaging engine
    there is no way for the engine to "know" when or not to process a
    particular service context. It requires strict processing by the GIOP
    engine, or it requires "default" interceptors to be installed to maintain
    the level of conformance.

    However, interceptors have no way of "declaring" which service contexts
    they handle, and whether they they are overriding already installed
    (default) interceptors for processing those particular service contexts.

    For example, an non-transactional ORB that is GIOP 1.2 compliant must
    process the Transaction Service Context by raising a
    TRANSACTION_UNAVAILABLE exception, because by default the ORB is in the
    OTS_NOT_CONNECTED state. It cannot be ignored to comply with GIOP 1.2 (but
    by certain in implementations it ALWAYS is). A default interceptor is
    needed in the ORB implementation to do this. However, for an ORB
    configuration that wants to process this, there is no way for an
    interceptor to "override" default processing.

  • Reported: CORBA 3.0.2 — Wed, 8 Oct 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

context interface for home implementation

  • Key: CORBA34-21
  • Legacy Issue Number: 5936
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    The home interface could have freely defined operations or can support an
    interface with such operations. A home context interface may help to implement
    such operations. E.g. a home implementation needs this context interface to
    determine its own object reference.

    suggestion:

    Add a home context interface that is similar to the component context interface.
    Add a set_context operation at the HomeExecutorBase interface.

  • Reported: CORBA 3.0.2 — Wed, 7 May 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

page 1-20 the description of the get_connection operation

  • Key: CORBA34-20
  • Legacy Issue Number: 5944
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    page 1-20 the description of the get_connection operation refers to a ConnectionDescription struct. In fact it is a ConnectionDescription valuetype

  • Reported: CORBA 3.0.2 — Thu, 29 May 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet and CSIv2 Negotitaion

  • Key: CORBA34-24
  • Legacy Issue Number: 6283
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    I believe that we send CSIv2 stuff in a GIOP Request until a corresponding
    GIOP reply has been containing corresponding CSIv2 context ids is sent.

    For Codeset, I think the policy is to send the service context in each
    GIOP request until a corresponding GIOP Reply is received, thereby saying
    that the "negotiation" is completed and excepted (otherwise an exception
    will be raised.

    We should probably look at the fact that multiple NSReq messages can be
    sent, and there are no corresponding reply messages depending on the
    service contexts.

    I think that these messages should be intercepted since they are
    delivering service contexts.

  • Reported: CORBA 3.0.2 — Thu, 2 Oct 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

valuetype fragmentation ambiguous

  • Key: CORBA34-13
  • Legacy Issue Number: 5941
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    Although I now think I know the intent of the spec, its is ambiguous if not plain wrong with respect to valuetype fragmentation.

    In particular 15.3.4.6:

    Bullet 1 says:

    "End tags, chunk size tags, and value tags are encoded using non-overlapping ranges
    so that the unmarshaling code can tell after reading each chunk whether:
    • another chunk follows (positive tag).
    • one or multiple value types are ending at a given point in the stream (negative
    tag).
    • a nested value follows (special large positive tag)."

    Bullet 3 says:

    "• For the purposes of chunking, values encoded as indirections or null are treated as
    non-value data."

    And the pseudo-BNF says:

    "(1) <value> ::= <value_tag> [ <codebase_URL> ]
    [ <type_info> ] <state>

    <value_ref>
    (2) <value_ref> ::= <indirection_tag> <indirection>
    <null_tag>
    (3) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
    (4) <type_info> ::= <rep_ids>
    <repository_id>
    (5) <state> ::= <octets>
    <value_data>* [ <end_tag> ]
    (6) <value_data> ::= <value_chunk>
    <value>"

    Now clearly the implication of bullet 1 is that an indirection or null must appear inside a chunk in a chunked encoding, otherwise you would be able to see the value 0 or -1 after a chunk and the -1 in particular could mean an end tag or an indirection. However the possible implication of bullet 3 and the BNF (note the use of "value data") is that nulls and indirections are values and thus must appear outside of chunks. Clearly the former interpretation is the correct one otherwise anarchy ensues.

    So I propose that we change the 3rd bullet to say:

    "For the purposes of chunking, values encoded as indirections or null are treated as
    if they were not values and therefore must always appear inside a chunk when a chunked encoding is in effect."

    and then change the BNF to say:

    "(1) <value> ::= <concrete_value> | <value_ref>
    (2) <concrete_value> ::= <value_tag> [ <codebase_URL> ]
    [ <type_info> ] <state>
    (3) <value_ref> ::= <indirection_tag> <indirection> | <null_tag>
    (4) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
    (5) <type_info> ::= <rep_ids> | <repository_id>
    (6) <state> ::= <octets> |<value_data>* [ <end_tag> ]
    (7) <value_data> ::= <value_chunk> | <concrete_value>"

    etc

  • Reported: CORBA 3.0.2 — Fri, 23 May 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Clarification on multi-threaded codeset negotiation

  • Key: CORBA34-14
  • Legacy Issue Number: 5880
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    We recently ran into a problem with a foreign Vendor's ORB and it appears the spec is unclear on this issue.

    The problem occurs when a multi-threaded client is connecting to a server. The spec says (13.10.2.6):

    "Codeset 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."

    but is silent on what is supposed to happen if the client has multiple threads all trying to connect at the same time. The issue is that priority inversion can occur - either because the client sends out a request without the negotiated codeset before the one with the negotiated codeset, or because the server processes the request without the negotiated codeset before the one with the negotiated codeset (even if the latter was sent first). The problem we encountered was the latter.

    There are two possible approaches to solving this:

    a) Require the server to serialize connection establishment requests until the codeset (and other connection information) is negotiated. This requires that the client impose appropriate ordering on connection requests.

    b) Require that the client keep sending codeset (and other connection information) until it is sure that the server has received the information (by getting a reply back). This works ok unless you are exclusively using oneways. In this instance you have to keep sending codeset information forever (somewhat costly, and very costly for codebase information).

    CSIv2 (26.2.2.3) explicitly calls out (b) but I prefer (a). Do we have any guidance on what is supposed to happen?

  • Reported: CORBA 3.0.2 — Tue, 11 Mar 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

15.3.3 - codesets must be "explicitly defined"

  • Key: CORBA34-15
  • Legacy Issue Number: 6050
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    For codesets in encapsulations we have:

    15.3.3 - codesets must be "explicitly defined"

    Issue 4824 - "it is an error for a Service Context to depend on information that is not contained within the encapsulation to determine the codeset used within it"

    But in 13.8 there is no prescribed way of "explicitly defining" the codeset.

    Please, please can we simply define that the fallbacks in 13.10.2.6 apply everywhere that the codeset is not known (whether negotiated or not) and be done with it.

    Another alternative would be to add codeset parameters to the encode() and decode() functions of 13.8.

  • Reported: CORBA 3.0.2 — Tue, 26 Aug 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

[Components] Contradiction between IDL and Interface Repository concerning

  • Key: CORBA34-16
  • Legacy Issue Number: 6671
  • Status: closed  
  • Source: Humboldt-Universitaet ( Bertram Neubauer)
  • Summary:

    According to the IDL language it is allowed to define a facet/receptacle on a component with type of Object. The text says:

    A facet is declared with the following syntax:
    (120) <provides_dcl> ::= “provides” <interface_type> <identifier>
    (121) <interface_type> ::= <scoped_name>

    “Object”
    The interface type shall be either the keyword Object, or a scoped name that denotes
    a previously-declared interface type which is not a component interface, ...

    In contradiction to that the Interface Repository element for a component, the ComponentDef, does only allow the creation of facets/receptacles with type of InterfaceDef. The according operations are:

    // write interface
    ProvidesDef create_provides (
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    in InterfaceDef interface_type
    );
    UsesDef create_uses (
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    in InterfaceDef interface_type,
    in boolean is_multiple
    );

    Thus the ComponentDef can not be used to create a facet/receptacle that is of type Object, since Object is no InterfaceDef but a PrimitiveDef.
    One solution would be to use IDLType instead of InterfaceDef since PrimitiveDef and InterfaceDef inherit from that interface. My proposal is to change the Interface Repository IDL in the following way.

    1) replace in ComponentDef:

    // write interface
    ProvidesDef create_provides (
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    in IDLType interface_type
    );
    UsesDef create_uses (
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    in IDLType interface_type,
    in boolean is_multiple
    );

    2) replace ProvidesDef, ProvidesDecsription, UsesDef, UsesDescription with

    interface ProvidesDef : Contained

    { // read interface readonly attribute IDLType interface_type; }

    ;

    struct ProvidesDescription

    { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; IDLType interface_type; }

    ;

    interface UsesDef : Contained

    { // read interface readonly attribute IDLType interface_type; readonly attribute boolean is_multiple; }

    ;

    struct UsesDescription

    { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; IDLType interface_type; boolean is_multiple; }

    ;

  • Reported: CORBA 3.0.2 — Wed, 3 Dec 2003 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Chapter/section: 15.4.2.2 "Request Body"

  • Key: CORBA34-17
  • Legacy Issue Number: 6287
  • Status: closed  
  • Source: 2AB ( Carol Burt)
  • Summary:

    Suppose you are sending a request (GIOP 1.2 or 1.3) and the request will
    be fragmented into two segments. The first segment is a Request message
    that has the GIOP Header and part of the Request Header. The second
    segment is a Fragment message that has a GIOP Header, a Fragment Header,
    and the body is the remainder of the Request Header and the Request Body.
    Section 15.4.2.2 of CORBA 3.0 states that the Request Body (in a Request
    Message) should always be aligned on an 8 octet boundary.

    My question is, in the above scenario, where the Request Body begins in
    the Fragment message, should the Request Body be aligned on an 8 octet
    boundary or not? I have not found anything in the specification that
    explicitly says what to do.

  • Reported: CORBA 3.0.2 — Wed, 1 Oct 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

page 1-20 second bullet of the description of the disconnect operation

  • Key: CORBA34-18
  • Legacy Issue Number: 5943
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    I found some minor editorial issues in the spec (referring to the document 02-06-65).

    • page 1-20 second bullet of the description of the disconnect operation. An 'and' is missing. This bullet should look like: "If the receptacle is a simplex receptacle and there is no current connection, then the NoConnection exception is raised."
  • Reported: CORBA 3.0.2 — Thu, 29 May 2003 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Duplicate union labels

  • Key: CORBA34-7
  • Legacy Issue Number: 704
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: When multiple union labels resolve to the same union member, the property accessor for that union member has an additional (optional) argument

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

COM Sequence changes

  • Key: CORBA34-6
  • Legacy Issue Number: 703
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: Change the layout of both bounded and unbounded sequences to be the same

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Changes to ForeignComplexType

  • Key: CORBA34-8
  • Legacy Issue Number: 701
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: The following methods should be added to DIForeignComplexType, IID should be changed: string type_name(); string scoped_name(); string_repository_id(); more details in corresponding archive file

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Section 13A.5.2: Editorial

  • Key: CORBA34-9
  • Legacy Issue Number: 708
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: Third bullet should read:"...are sorted based upon interface name.." Last bullet should read "..the operations introduced in the current interface are mapped last and ordered.."

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Section 13A.2.3: editorial

  • Key: CORBA34-10
  • Legacy Issue Number: 707
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: Example of "on both machines" does nor correspond to the diagrams. Add "on an intermediate machine" to sentence

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Capter 13C: Editorial

  • Key: CORBA34-11
  • Legacy Issue Number: 709
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: There are a bunch of code samples that use a different font than the rest of the document

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Incorrect mappings for systems exceptions (part A)

  • Key: CORBA34-12
  • Legacy Issue Number: 679
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: Section 4.1.18.6 Table 4-14: A few of these mappings don"t seem to make sense (i.e. the meaning of the different exceptions in each object system is much different

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Section 13C.1.3 Editorial

  • Key: CORBA34-5
  • Legacy Issue Number: 710
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: On page 9, paragraph beginning with "Within an interface...." should read "..attributes should appear after operations..."

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Levels of Indirection for passing COM types

  • Key: CORBA34-4
  • Legacy Issue Number: 702
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary:

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Provide a simple sample application

  • Key: CORBARS_-1
  • Status: closed  
  • Source: OpenText Inc. ( Mr. Matteo Vescovi)
  • Summary:

    It would be good to show a sample simple application that shows use of the REST mapping as proof of concept of use of the spec.

    While there are fragments sprinkled in the specification document, a simple application would be useful and ease adoption.

  • Reported: CORBA-REST 1.0b1 — Fri, 11 Jun 2021 09:47 GMT
  • Disposition: Resolved — CORBA-REST 1.0
  • Disposition Summary:

    Add sample application walkthrough in Appendix A

    Add non-normative appendix A.

    The appendix walks through the steps involved in exposing a REST API to a sample CORBA application using the IDL-RS annotations.

  • Updated: Tue, 27 Sep 2022 12:47 GMT
  • Attachments:

Provide example of authentication and security

  • Key: CORBARS_-2
  • Status: closed  
  • Source: OpenText Inc. ( Mr. Matteo Vescovi)
  • Summary:

    It would be nice to have some discussion/example in the document for REST authentication and security.

    I think this would help with adoption.

  • Reported: CORBA-REST 1.0b1 — Fri, 11 Jun 2021 09:50 GMT
  • Disposition: Resolved — CORBA-REST 1.0
  • Disposition Summary:

    Add example showing how to secure an application in appendix B.

    Add non-normative appendix B.

    Appendix B illustrates how security might be added to the example REST for CORBA application described in Appendix A.

  • Updated: Tue, 27 Sep 2022 12:47 GMT
  • Attachments:

Extract IDL details from CORBA spec

  • Key: CORBA34-2
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    IDL is now in its own OMG spec. Remove content from the CORBA spec that repeats what's in the IDL spec. Add a Normative Reference to the IDL spec.

    It may be preferable to keep a "skeleton" of the Part 1 - Chapter 7 outline in the revised document so that existing cross-references (those in the document and especially those not in the document) still resolve. The skeletal sections (such as "7.2.5 Literals") can contain references to the corresponding section in IDL4.

  • Reported: CORBA 3.3 — Thu, 14 Feb 2019 23:23 GMT
  • Disposition: Resolved — CORBA 3.4
  • Disposition Summary:

    Refer to IDL 4.2

    Instead of containing a verbatim copy of key specification details, refer to the standalone IDL 4.2 spec document (formal/2018-01-05).

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Valuetypes should be added to the list of scopes

  • Key: CORBA34-1
  • Status: closed  
  • Source: Self ( Jonathan Biggar)
  • Summary:

    In this section, there are two places where the list of IDL constructs that have scopes is given:

    "interface, struct, union, or exception"

    valuetype should be added to this list to be consistent with the rest of the specification.

  • Reported: CORBA 3.3 — Wed, 18 Oct 2017 23:48 GMT
  • Disposition: Closed; Out Of Scope — CORBA 3.4
  • Disposition Summary:

    Should be revised in the IDL specification

    With the upcoming version of the CORBA specification, all IDL details will be removed and replaced with references to the IDL specification.
    I will create a linked issue for the IDL revision task force to consider.

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Section: 15.4.5.1 struct has to be updated

  • Legacy Issue Number: 12858
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    this section says: // GIOP 1.0 struct LocateRequestHeader_1_0

    { // Renamed LocationRequestHeader unsigned long request_id; sequence <octet> object_key; }

    ; Anonymous types are deprecated so this struct has to be updated

  • Reported: CORBA 3.0.3 — Tue, 23 Sep 2008 04:00 GMT
  • Disposition: Deferred — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 18 Feb 2019 00:01 GMT

ZIOP has to be part of the core CORBA specification

  • Legacy Issue Number: 16922
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The ZIOP specification is an addition to CORBA and should be merged into the main CORBA specification instead of being a stand alone specification

  • Reported: ZIOP 1.0 — Tue, 20 Dec 2011 05:00 GMT
  • Disposition: Resolved — CORBA 3.1.1
  • Disposition Summary:

    Move the ZIOP Compression module to CORBA Part 1, section 18
    Move the ZIOP Module to CORBA Part 2, section 12

  • Updated: Thu, 12 Mar 2015 02:25 GMT

question re BiDir IIOP

  • Legacy Issue Number: 2461
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I am having difficulty understanding the intended use of
    BiDirPolicy::BidirectionalPolicy. This is described (in section 15.9) as
    a POA policy to be passed to create_POA. That section also says that
    both client and server must have the policy with the value of BOTH for
    bi-directional communication to take place.

    My problem is that I don"t see how this policy applies to a particular
    POA. Once bi-directional communication has been negotiated on a
    connection, it applies to any request targetted at the negotiated
    address(es), regardless of what POA is the recipient of the request. Nor
    is it tied to the lifetime of a particular POA. And, what is supposed to
    happen if one POA has the policy with value BOTH, and another POA has
    the policy with value NORMAL?

  • Reported: CORBA 2.2 — Fri, 19 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    :BidirectionalPolicy. This is described (in section 15.9) as

  • Updated: Wed, 11 Mar 2015 04:29 GMT

New OBV "supports" keyword conflicts with CosLifeCycle

  • Legacy Issue Number: 1782
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The new OBV keyword "supports" collides with the operation "supports"
    defined in CosLifeCycle::GenericFactory.

  • Reported: CORBA 2.2 — Fri, 7 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    :GenericFactory.

  • Updated: Wed, 11 Mar 2015 04:26 GMT

Abstract Interface issue (02)

  • Legacy Issue Number: 1720
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If we accept 2 above, we may want to revisit the following:
    – 8.8.2, page 8-104, bullet 4:
    "Inserting an abstract interface reference into a CORBA::Any
    operates polymorphically. Either the object reference or value to
    which the abstract interface reference refers is what actually gets
    inserted into the Any. This is because there is no TypeCode for
    abstract interfaces. Since abstract interfaces can not be inserted into
    an Any, there is no need for abstract interface extraction operators."

  • Reported: CORBA 2.2 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Wed, 11 Mar 2015 04:24 GMT

IDL keyword clash in CosNotification.idl

  • Key: CORBA3-134
  • Legacy Issue Number: 4901
  • Status: closed  
  • Source: Memorial University of Newfoundland ( Jeffrey Parsons)
  • Summary:

    CosNotification.idl contains a struct named 'EventType', which
    clashes with the new CCM-related keyword 'eventtype'.

  • Reported: CORBA 2.6 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0
  • Disposition Summary:

    purely editorial issue

  • Updated: Wed, 11 Mar 2015 04:16 GMT

Query Service IDL code

  • Legacy Issue Number: 2488
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Query Service IDL code (document 97-12-18) has multiple syntax
    errors. I have checked it with Orbix, OrbixWeb and Visibroker IDl
    compiler.

  • Reported: CORBA 2.3 — Thu, 25 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 04:16 GMT

CORBAservices IDL

  • Key: CORBA25-57
  • Legacy Issue Number: 959
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In CosStream Module the CompoundExternaliztion.idl is included
    > (needed for CosCompoundExternalization::Node), and in the
    > CosCompoundExternalization Module the Stream.idl is included (needed
    > for CosStream::Streamable and CosStream::StreamIO). Now correct me
    > if I am wrong but isn"t this self-referential loop going to cause
    > problems with the IDL compiler, in that either CosStream will not
    > know about CosCompoundExternalization or vice-versa causing a
    > compiler error.

  • Reported: CORBA 2.2 — Tue, 24 Feb 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    refer to formal/98-12-16

  • Updated: Wed, 11 Mar 2015 04:16 GMT

OBV TypeCode problems

  • Legacy Issue Number: 1685
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For valuetypes that inherit from concrete valuetypes, the
    ORB::create_value_tc operation is insufficient. In particular, it does not
    allow the TypeCode for the base valuetype to be supplied. This means that
    if a valuetype with a concrete base valuetype is passed in an Any to a
    process that has no compile-time information concerning that valuetype, the
    receiving process will be unable to marshal it. Having the RepositoryId of
    the concrete base in the TypeCode does not solve the problem because the
    two processes might not have an Interface Repository (IFR) in common, or
    the concrete base RepositoryId may not be in the IFR known to the receiving
    process. Also, never in CORBA should unmarshaling require lookups in the
    IFR (this in fact should be an absolute ORB Core rule).

    Proposal: change create_value_tc to

    TypeCode create_value_tc(
    in RepositoryId id,
    in Identifier name,
    in boolean is_custom,
    in TypeCode concrete_base,
    in ValueMembersSeq members
    );

    If the valuetype has no concrete valuetype base, the concrete_base argument
    shall be a nil TypeCode reference.

  • Reported: CORBA 2.2 — Wed, 15 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    :create_value_tc operation is insufficient. In particular, it does not

  • Updated: Sun, 8 Mar 2015 21:52 GMT

Include GIOP over Bluetooth into Wireless CORBA 1.1

  • Key: CORBA26-99
  • Legacy Issue Number: 5994
  • Status: closed  
  • Source: Nokia ( Kimmo Raatikainen)
  • Summary:

    Include GIOP over Bluetooth into Wireless CORBA 1.1

  • Reported: CORBA 2.5 — Mon, 14 Jul 2003 04:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see below

  • Updated: Sun, 8 Mar 2015 21:43 GMT

Module separator within repository IDs

  • Legacy Issue Number: 1727
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The module separator within "IDL: style" repository IDs is a "/".
    The module separator within "H: style" repository IDs is a "::".
    Was this difference intentional? If so, why? It seems confusing
    to treat scoped names differently in the two kinds of IDs.

  • Reported: CORBA 2.2 — Thu, 23 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    style" repository IDs is a "::".

  • Updated: Sun, 8 Mar 2015 21:43 GMT

DynAny::get_value collision

  • Legacy Issue Number: 1529
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OBV specifies a DynAny::get_value operation to retrieve a value from a
    DynAny, but this operation breaks the existing DynFixed::get_value
    operation. I suggest renaming the DynAny::get_value to avoid the collision
    (gee, if we didn"t use "value" as one of those funny keyword identifiers,
    this wouldn"t be a problem).

  • Reported: CORBA 2.2 — Thu, 18 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    :get_value

  • Updated: Sun, 8 Mar 2015 21:42 GMT

Problem with C++ language mapping for OBV

  • Legacy Issue Number: 1526
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. The following IDL cannot be translated into C++ code by an IDL
    compiler for a C++ environment that does not support namespaces:

    // IDL
    module M {
    struct S

    { boolean b; }

    ;

    interface I

    { void op(in S arg); }

    ;

    value V supports A {
    };
    };

    The reason for this is that module M maps to a C++ class when namespaces
    are not available, and you end up with the following definition loop:

    POA_M::I must be defined before M::V, since M::V inherits from it
    M must be defined before POA_M, because POA_M::I depends on M::S
    but defining M also defines M::V

  • Reported: CORBA 2.2 — Tue, 16 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 21:42 GMT

public static org.omg.CORBA.ValueDef get_value_def();

  • Legacy Issue Number: 1321
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On p. 6-63 of orbos/98-01-18, the get_value_def() method is defined in
    the helper class as:

    public static org.omg.CORBA.ValueDef get_value_def();

    Currently, there is no portable way to implement this method for all
    vendor ORB"s. One suggestion is to pass an ORB implementation instance
    as parameter:

    get_value_def(org.omg.CORBA.ORB orb);

    and then add a method to the ORB class such as:

    get_value_def(String idl_name);

    Thus a portable implementation could be

    public static org.omg.CORBA.ValueDef get_value_def(org.omg.CORBA.ORB
    orb)

    { return orb.get_value_def(id()); }
  • Reported: CORBA 2.2 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 21:42 GMT

Clarify semantics

  • Legacy Issue Number: 1285
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    issue was missing information, no action

  • Updated: Sun, 8 Mar 2015 21:42 GMT

Which exceptions should be raised?

  • Legacy Issue Number: 1281
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Clarify which exception should be raised when no local class is
    available to support an incoming value:
    p 5-29, item 3 says it should be NO_IMPLEMENT
    p 5-34, 3rd paragraph says it should be MARSHAL
    p 5-34, last paragraph says it should be BAD_PARAM
    p 6-67, last item says it should be MARSHAL
    p 7-93, first paragraph of 7.3.10.2 says it should be MARSHAL

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 21:42 GMT

Grammar rule issue

  • Legacy Issue Number: 1254
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The new grammar rule:
    <state_member> ::= <public_token> <type_spec> <declarators> ";"

    <type_spec> <declarators> ";"
    seems to open up another large hole for making the grammar non-LALR(1), which may
    or may not have been intentional. This becomes clear as you work your way back
    through the set of grammar rules. For example, according to the way I read the rules,
    the following is legal "new" IDL:
  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    := <public_token> <type_spec> <declarators> ";"

  • Updated: Sun, 8 Mar 2015 21:42 GMT

"Syntax" for grammar rule [value_inheritance_spec] ::= ":" [ safe_token ]

  • Legacy Issue Number: 1250
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"ve come across another small glitch in the orbos/98-01-18
    "Objects by Value" spec. This is in section 5.4.1 "Syntax", for the grammar rule:

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

    { "," <scoped_name> }*

    [ <supports_token> <scoped_name> { "," <scoped_name> }

    * ]

    As the rule (and the rules referring to this rule) are written now, a value
    inheritance spec is either optional, or if specified, MUST begin with an
    inheritance relation to another value type (e.g. : value foo2: foo1

    { ... }

    ).

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 21:42 GMT

CODESET_INCOMPATIBLE exception is not defined

  • Legacy Issue Number: 495
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CODESET_INCOMPATIBLE is not defined in CORBA 2.0, and so must be added to the list of standard exceptions in section 3.15.1

  • Reported: CORBA 1.2 — Tue, 4 Feb 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    resolved is current core 2.3 draft, issue closed

  • Updated: Sun, 8 Mar 2015 21:42 GMT

Wide String (and String encoding)

  • Legacy Issue Number: 140
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Are the string lengths number of bytes or characters (in 3.1.2 of orbos/96-02-03)?

  • Reported: CORBA 1.2 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    resolved in current 2.3 draft, close issue

  • Updated: Sun, 8 Mar 2015 21:42 GMT

IDL TypeExtension correction

  • Legacy Issue Number: 131
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is an error in the grammar as written, so that you cannot (for example) have attributes of type wstring.

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    resolved in Core 2.3 draft, close dissue

  • Updated: Sun, 8 Mar 2015 21:42 GMT

IDL Type Extensions: DATA_CONVERSION exception

  • Legacy Issue Number: 494
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Algorithm on p. 27 says to raise DATA_CONVERSION exception, but textual description on p. 28 par 1 specifies CODESET_INCOMPATIBLE exception when client and server native codesets aren"t compatible

  • Reported: CORBA 1.2 — Tue, 4 Feb 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    resolved is current 2.3 draft, closed issue

  • Updated: Sun, 8 Mar 2015 21:42 GMT

What should an ORB do when it does not find any profile in an IOR

  • Legacy Issue Number: 3234
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

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

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

  • Reported: CORBA 2.3.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with agreed resolution

  • Updated: Sun, 8 Mar 2015 19:20 GMT

Standard System Exception minor codes missing in Chapter 13

  • Legacy Issue Number: 2961
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

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

  • Reported: CORBA 2.3.1 — Tue, 26 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

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

  • Updated: Sun, 8 Mar 2015 19:20 GMT

Component ids in 13.6.2.2

  • Legacy Issue Number: 2914
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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?

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    duplicate

  • Updated: Sun, 8 Mar 2015 19:20 GMT

OBV chunk boundaries

  • Legacy Issue Number: 2155
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 15.3.4.4. of ptc/98-10-11 includes the following statement wrt to
    ObV chunking:

    "The data may be split into multiple chunks at arbitrary points except
    within primitive CDR types, arrays of primitive types, strings, and
    wstrings."

    Unfortunately, this provides only dubious benfits, but introduces
    significant problems. Traditionally, CDR has been designed so that encoding
    engines are only responsible for marshalling CDR primitives, and remain
    independent of the actual constructed IDL type being marshalled. The above
    clause violates this rule: the CDR stream must know that the primitives
    being marshalled are part of an array, understand the size of the array,
    distinguish sequences from arrays, etc.

    In addition, this is impossible to implement using the Java portable
    streams.

  • Reported: CORBA 2.2 — Fri, 30 Oct 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 19:20 GMT

Transmission of type codes across 2.2/2.3 boundaries

  • Legacy Issue Number: 1962
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.2 — Wed, 16 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

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

  • Updated: Sun, 8 Mar 2015 19:20 GMT

LOCATE_FORWARD_PERM and hash()

  • Legacy Issue Number: 1486
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.2 — Wed, 3 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved

  • Updated: Sun, 8 Mar 2015 19:20 GMT

Clarification requested on GIOP 1.1 and wstring

  • Legacy Issue Number: 1948
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Document interop/98-08-02 states:

    For GIOP versions prior to 1.2, interoperability for Wstring is limited
    to the use of two octet fixed length encodings.

    Does this mean simply that only fixed length character encodings that
    are use 2 byte characters are allowed for GIOP versions prior to 1.2?

    The statement is slightly ambiguous, in that it can be parsed as: "(two
    octet) fixed length encodings" or "two (octet fixed length encodings)".

  • Reported: CORBA 2.2 — Mon, 14 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close issue without change

  • Updated: Sun, 8 Mar 2015 19:03 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 12

  • Legacy Issue Number: 14394
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    7.5
    Comment:
    "see CORBA part1, clause 4" is ambiguous.
    Proposed change:
    Replace "see CORBA part1, clause 4" with "in clause 5 of ISO/IEC 19500-1, The Object Model".

  • Reported: CORBA 3.1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — CORBA 3.1.1
  • Disposition Summary:

    Agree to refer to named clause in 19500-1

  • Updated: Sun, 8 Mar 2015 18:08 GMT

TypeCode constants for bounded strings?

  • Legacy Issue Number: 2007
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Mon, 28 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 15:27 GMT

DynValue::get_members/set_members

  • Legacy Issue Number: 2252
  • Status: closed  
  • Source: Anonymous
  • 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."

  • Reported: CORBA 2.2 — Thu, 10 Dec 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    :get_members/set_members as:

  • Updated: Sun, 8 Mar 2015 15:26 GMT

IDL constant declarations

  • Legacy Issue Number: 2883
  • Status: closed  
  • Source: Anonymous
  • 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...

  • Reported: CORBA 2.3.1 — Sun, 12 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 15:24 GMT

Conflict between POA & Exceptions spec for OBJECT_NOT_EXIST

  • Legacy Issue Number: 3919
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • 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 ...]

  • Reported: CORBA 2.3.1 — Thu, 28 Sep 2000 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4.2
  • Disposition Summary:

    Close no change

  • Updated: Sun, 8 Mar 2015 15:23 GMT

SYNC_WITH_SERVER

  • Key: CORBA25-56
  • Legacy Issue Number: 4317
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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?

  • Reported: CORBA 2.4.2 — Mon, 21 May 2001 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.5
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Sun, 8 Mar 2015 15:22 GMT

Changebars missing from POA chapter

  • Legacy Issue Number: 2843
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.3 — Sun, 15 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 15:20 GMT

Type code parameter ordering

  • Legacy Issue Number: 1543
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 15:20 GMT

RMI repository ID references to serial version UID

  • Legacy Issue Number: 4283
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    CORBA formal 00-11-03 10.6.2 states

    "If the actual serialization version UID for the Java class differs from
    the hash code, a colon and the actual serialization version UID
    (transcribed as a 16 digit upper-case hex string) shall be appended to
    the RepositoryId after the hash code."

    Please comment on the following assertions. The CORBA spec is vague
    here, and it has resulted in incompatible interpretations which must be
    resolved quickly.

    1) The "actual serialization version UID" mentioned is as defined in
    the Java Object Serialization specification.

    http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/class.doc6.html#4100

    Based on this Java specification and its note that "If the SUID is not
    declared for a class, the value defaults to the hash for that class":

    2) If a serialVersionUID field is defined in the class with the proper
    modifiers, its value is used as the "actual serialization version UID"
    mentioned in the CORBA spec

    3) If a serialVersionUID field with the proper modifiers is not
    explicitly defined in a class, its value is computed as explained in the
    Java Object Serialization spec, and this computed value is used as the
    "actual serialization version UID" mentioned in the CORBA spec

    4) It is required by the CORBA spec to always include the Java
    serialVersionUID (as computed in assertions 2 and 3 above) in the RMI
    repository ID if the value is different than the OMG hash code (for
    which the algorithm is defined in CORBA formal 00-11-03 10.6.2)

    5) It is not acceptable to leave off the SUID portion of the RMI
    repository ID if the serialVersionUID field is merely absent from the
    Java class

  • Reported: CORBA 2.0 — Wed, 25 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    closed, withdrawn by submitter

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Second bit of response_flags

  • Legacy Issue Number: 2968
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The question below was posted to the corba-dev list. I have to admit
    that I don't understand the purpose of the second-least significant bit
    of response_flags either. From the text in the spec, it appears that
    this bit is set if a request expects a response and is not invoked via
    the DII, whereas if a request is oneway or invoked via the DII with
    INV_NO_RESPONSE set, the bit is clear.

  • Reported: CORBA 2.0 — Tue, 2 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    closed issue ...clarified

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Issue: Problem with issue 2801 resolution

  • Legacy Issue Number: 2863
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: > > Add the following paragraph to 15.8:
    > >
    > > "To avoid collisions of requestId in fragment messages when
    > > bi-directional GIOP is in use:
    > >
    > > - a request may not be sent by an endpoint if a reply has been
    > > sent by that endpoint without a terminating fragment.
    > >
    > > - a reply may not be sent by an endpoint if a request has been
    > > sent by that endpoint without a terminating fragment."
    > >
    >
    > Why is a plain (non-fragmented) request/reply prohibited here? There has
    > never been and feature interaction between fragmented request/replies and
    > non-fragmented ones, so why have this restriction.

    Jishnu Mukerji wrote:

    > After poking around some it seems to me that the following words address
    > Martin"s concern and hence the issue of inadvertently disallowing something
    > that wasn"t broken in the current resolution of 2801. The additional word
    > "fragmented" in two places is bracekted between "*"s.
    >
    > "To avoid collisions of requestId in fragment messages when
    > bi-directional GIOP is in use:
    >
    > - a fragmented request may not be sent by an endpoint if a
    > fragemented reply has been sent by that endpoint without a terminating
    >fragment.
    >
    > - a fragemented reply may not be sent by an endpoint if a
    > fragmented request has been sent by that endpoint without a terminating
    >fragment."

  • Reported: CORBA 2.0 — Wed, 15 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved, see below

  • Updated: Sat, 7 Mar 2015 04:35 GMT

fragmentation broken with bi-dir giop

  • Legacy Issue Number: 2801
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I wish to raise the following as an urgent issue:

    The way that message fragments are encoded in giop 1.2, in conjunction
    with the giop 1.2 specification for bi-directional use of a connection,
    can lead to situations where the protocol is ambiguous.

    (This is urgent because it is impossible to implement the bi-directional
    part of GIOP 1.2 without it.)

  • Reported: CORBA 2.0 — Tue, 13 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

CODESET_INCOMPATIBLE exception

  • Legacy Issue Number: 2620
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: if a code set negotiation fails the CORBA 2.3 specfication says that a
    CODESET_INCOMPATIBLE exception is to be raised. There doesn"t seem to be
    any further reference to a CODESET_INCOMPATIBLE exception elsewhere. So
    where is the CODESET_INCOMPATIBLE exception defined? Or should it read
    INV_OBJREF?

  • Reported: CORBA 2.0 — Thu, 22 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

A Messaging related issue in GIOP 1.2

  • Legacy Issue Number: 2077
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Tom and I have discovered a minor outage in GIOP 1.2 relative to the
    Messaging spec. The outage exists if we want to keep the door open for
    publishing Messaging before GIOP is revved again. If we do not fix this
    the publishing of Messaging will have to wait until the next rev of
    GIOP. The outage is the following:

    1) In the Request header the boolean field "response_expected" was
    changed to an octet field "response_flags" in Messaging, with more
    precise definition of the meanings of various flag values.

    2) The Messaging spec defines a IOP::TaggedComponent for including QoS
    policies in an IOR.

    3) The Messaging service defines a ServiceContext for carrying QoS
    policies in GIOP messages that carry ServiceContexts.

  • Reported: CORBA 2.0 — Tue, 13 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Close with No change required

  • Updated: Sat, 7 Mar 2015 04:35 GMT

IIOP 1.2 fragmentation presents an unrecoverable error situation

  • Legacy Issue Number: 1857
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IIOP 1.2 fragmentation presents an unrecoverable error situation
    1.2 IIOP attempted to provide fragment interleaving by defining a 1.2
    fragment header containing request id. This does not solve the
    possibility of receiving multiple first fragments over the same
    connection which do not contain request id"s. There is no way to
    associate subsequent fragments with these initial fragments since the
    initial request id is received after the 1.2 Fragment header specified
    request_id.

  • Reported: CORBA 2.0 — Mon, 24 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

New IDL types

  • Legacy Issue Number: 1707
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When the new IDL types were added (fixed, long double, etc), no new
    IIOP or GIOP version was introduced, and no new version of CDR was introduced.
    Instead, the marshaling rules for the new types were simply added to CDR,
    and the type code interface was extended to handle these.

    Unfortunately, this creates some rather serious problems for interoperability.

  • Reported: CORBA 2.0 — Tue, 21 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Narrow Interop

  • Legacy Issue Number: 1669
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Narrowing is used in CORBA to check if an object reference obtained by
    a client is of the desired type, ie. supports a specific IDL interface
    that the client wants to use.

    The client program has static information about the interface it wants
    to use from the IDL specification. However, this is not enough as it
    must also be possible to invoke remote objects that support an IDL
    interface derived from the interface the client knows of.

    There are at least 4 possiblities how the type checking can be resolved
    (+ combinations of them):

    Narrow makes a query to an interface repository.
    (ii) Narrow makes a call to the remote object.
    (iii) The object reference contains enough information, e.g. the whole
    interface type hierarchy that the remote object supports.
    (iv) There is no narrow; the type check is made when a request is
    received by the server-side ORB.

  • Reported: CORBA 2.0 — Mon, 13 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Contents of MultiComponent component an encapsulation?

  • Legacy Issue Number: 1588
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I can"t find any text in the CORBA 2.2 spec which says explicitly
    whether the "component_data" field of IOP::TaggedComponent is actually
    an encapsulation, or something else.

    Why don"t we define a typedef "Encapsulation" for "sequence<octet>",
    and use it in the IDL for those octet sequences which are really
    encapsulations?

  • Reported: CORBA 2.0 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    :TaggedComponent is actually

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Type any marshalling rules force slow implementation

  • Legacy Issue Number: 1581
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: type any marshalling rules force slow implementation

    Proposal: require that type any are marshalled as encapsulations

  • Reported: CORBA 2.0 — Thu, 25 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Marshalling of union type codes

  • Legacy Issue Number: 1544
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 13-14, the spec says for marshaling of type codes:

    "Note that the tuples identifying struct, exception, and enum
    members must be in the order defined in the OMG IDL definition
    text."

    This is right and proper, otherwise I wouldn"t know in what order things are
    encoded or what their ordinal values are. However, the text does not
    mention unions, so the order in which a type code describes the union
    members is left to the implementation.

    Suggestion: Require union members to also appear in the order in which
    they are defined in the IDL.

  • Reported: CORBA 2.0 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Typecode encoding is too long

  • Legacy Issue Number: 1531
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Proposal: allow for alternate, compact encoding of typecodes
    It is clear that typecodes are quite long when encoded into CDR and
    transmitted over the wire. This is particularly painful when the CORBA::Any
    type is used in interfaces. Besides, the use of any is becoming increasingly
    important in multiple CORBA specifications, and a global solution to this
    problem should be provided.

    My proposal is to allow for an alternate encoding of typecodes, for those
    specific cases where type identification can be achieved either by other
    application specific mechanisms (for example, Name-Value pairs) or where
    the Repository Id of the type is enough to reconstruct the full typecode
    information locally on the receiving side.

  • Reported: CORBA 2.0 — Thu, 18 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Type code marshalling

  • Legacy Issue Number: 1525
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If a type code does not have a repository ID

    (e.g. dynamic type ) then the member names for
    structs and unions etc. should be required to be
    sent on the wire for GIOP marsalling of Typecodes.
    This may help the type code comparision issue to be resolved.

  • Reported: CORBA 2.0 — Sun, 14 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

CDR encoding of TypeCodes

  • Key: CORBA21-97
  • Legacy Issue Number: 1292
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I just stumbled on the following paragraph in 13.3.4 describing the CDR
    encoding of TypeCodes:

    "The name parameters in tk_objref, tk_struct, tk_union, tk_enum,
    tk_alias, and tk_except TypeCodes and the member name parameters in
    tk_struct, tk_union, tk_enum and tk_except TypeCodes are not specified
    by (or significant in) GIOP. Agents should not make assumptions about
    type equivalence based on these name values; only the structural
    information (including RepositoryId values, if provided) is significant.
    If provided, the strings should be the simple, unscoped names supplied
    in the OMG IDL definition text. If omitted, they are encoded as empty
    strings."

    This would suggest that the name and member name parts of a typecode
    should never be considered significant when an ORB compares typecodes.

  • Reported: CORBA 2.0 — Mon, 30 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:
  • Updated: Sat, 7 Mar 2015 04:35 GMT

Typecode indirection issue

  • Key: CORBA21-99
  • Legacy Issue Number: 1503
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We have come across the following issue with regard to typecode
    indirections. The specification states:

    the indirection is a numeric octet offset within the scope of some
    "top level" TypeCode and points to the TCKind value for the
    typecode.

    The question arrises then is it legal to point to the (possible)
    padding bytes preceeding the TCKind value or must the numberic value
    indicate the position of the actual TCKind value. If you assume the
    former then having rewound the required number of bytes you would word
    align before interogating the TCKind enum value.

  • Reported: CORBA 2.0 — Thu, 4 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:
  • Updated: Sat, 7 Mar 2015 04:35 GMT

No provision for numbering the fragments in fragmented IIOP messages

  • Key: CORBA21-98
  • Legacy Issue Number: 1302
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There seems to be no provision for numbering the fragments in fragmented
    IIOP messages. It is apparently assumed that the fragments will always
    be received in the order that they are generated, however in unreliable
    networks, such as mobile networks, this may not be a safe assumption.

  • Reported: CORBA 2.0 — Fri, 1 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Correct CDR encoding of an empty string

  • Key: CORBA21-96
  • Legacy Issue Number: 1138
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What is the correct encoding for an empty string according to GIOP?

    In section 13.3.2, page 13-11 of CORBA 2.2, the following paragraph
    describes the encoding of strings:

    "A string is encoded as an unsigned long indicating the length of the string
    in octets, followed by the string value in single- or multi-byte form
    represented as a sequence of octets. Both the string length and contents
    include a terminating null."

    This does not clarify what is the correct encoding for empty strings,
    as there are two possibilities:
    a) length=0, no string follows
    b) length=1, "\0" (one-char with the terminating null)

  • Reported: CORBA 2.0 — Wed, 15 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Typecode equality

  • Key: CORBA21-95
  • Legacy Issue Number: 1136
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I just stumbled on the following paragraph in 13.3.4 describing the CDR
    encoding of TypeCodes:

    "The name parameters in tk_objref, tk_struct, tk_union, tk_enum,
    tk_alias, and tk_except TypeCodes and the member name parameters in
    tk_struct, tk_union, tk_enum and tk_except TypeCodes are not specified
    by (or significant in) GIOP. Agents should not make assumptions about
    type equivalence based on these name values; only the structural
    information (including RepositoryId values, if provided) is significant.
    If provided, the strings should be the simple, unscoped names supplied
    in the OMG IDL definition text. If omitted, they are encoded as empty
    strings."

    This would suggest that the name and member name parts of a typecode
    should never be considered significant when an ORB compares typecodes.

    Of course, this still leaves the issue of what to do about aliases up in
    the air.

  • Reported: CORBA 2.0 — Sun, 29 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:
  • Updated: Sat, 7 Mar 2015 04:35 GMT

Wchar and Char can both be multibyte

  • Key: CORBA21-94
  • Legacy Issue Number: 1111
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: With regard to the character encoding issue.

    This is not just a problem with Wchar, and Wstring, it can happen
    with char and string as well. Multibyte encodings are used for
    normal strings in the enhanced IDL as well as for
    Wchars.
    I think the problem is in the definition of char. For interop, the char type could be either:
    1) restricted to a syntactic thing which can only be used with single byte encodings, or
    2) we need to bite the bullet and make the encoding for char a sequence
    of bytes if a multibyte encoding is chosen.

  • Reported: CORBA 2.0 — Wed, 25 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

GIOP Exception formatting description (12.4.2)

  • Key: CORBA21-91
  • Legacy Issue Number: 935
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA 2.1"s GIOP Exception formatting description (12.4.2)
    partitions the space of valid minor codes, with
    20 bits reserved for unique vendor IDs and only 12 bits
    (4096) for possible minor codes for each exception.
    This seems backwards (1 million vendors each with
    only 4 thousand minor codes!) and I would like
    to request a change to (at least) swap these
    numbers with the following textual change:

    The high order 10 bits of minor_code_value contain a 10-bit
    "vendor minor codeset ID" (VMCID); the low order 22 bits
    contain a minor code. A vendor (or group of vendors)
    wishing to define a specific set of system exception
    minor codes should obtain a unique VMCID from the OMG, and
    then define up to (22 bits of) 4194304 minor codes for each
    system exception. Any vendor....

  • Reported: CORBA 2.0 — Mon, 2 Feb 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Issue about CDR encoding for wide characters

  • Key: CORBA21-93
  • Legacy Issue Number: 1096
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. When encoding a wchar, always put 4 bytes into the CDR stream,
    > adding any zero pad bytes as necessary to make the value 4 bytes
    > long.
    2. When encoding a wstring, always encode the length as the total
    > number of bytes used by the encoded value, regardless of whether the
    > encoding is byte-oriented or not.

  • Reported: CORBA 2.0 — Tue, 24 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Query about GIOP and IIOP version numbers in 98-01-03

  • Key: CORBA21-92
  • Legacy Issue Number: 960
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"ve been reading through 98-01-03.pdf (Change pages from Interop 1.2
    RTF), and come across a problem concerning version numbers.

    On page 13-39, the following paragraph has been added:

    "The version number published in the Tag Internet IIOP Profile body
    signals the highest GIOP minor version number that the server supports
    at the time of publication of the IOR"

    As far as I can see, the only version information in the profile body is
    "iiop_version", which has the following note in its description:

    "Note - This value is not equivalent to the GIOP version number
    specified in GIOP message headers. Transport-specific elements of the
    IIOP specification may change independantly from the GIOP specification"

    Which is correct?

  • Reported: CORBA 2.0 — Thu, 5 Feb 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Sections 8.1.1, 8.2.1:

  • Legacy Issue Number: 7920
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    8.1.1, 8.2.1: the description of the metamodel is very skimpy: for
    example there is no description anywhere about what FinderDef is. There
    should be a separate section for each class with a description of each
    attribute/reference. Conversely the text also talks about 'component
    types' which have 'attributes' (and ports) - this has no obvious
    correspondence with the metamodel (are the attributes in the BaseIDL
    package?). Likewise the text refers to a component being able to inherit
    from one other interface - this is not depicted.

    • most of the OCL constraints make use of 'isStereotyped()' which is
      not OCL, UML nor defined in this specification.
    • Table 10: most of the Tags seem to have no correspondence in the
      metamodel e.g. containerType.
  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Section 7.1, line1:

  • Legacy Issue Number: 7916
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    7.1, line1: It's not strictly true to say that the CCM Profile
    'specializes' the UML Core package: the latter is the reference
    metamodel for the former.

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Figure 1

  • Legacy Issue Number: 7915
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure 1 - the import dependencies should be shown with an 'import'
    stereotype

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Section 8.1.1

  • Legacy Issue Number: 7919
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    8.1.1 the heading is 'IDL metamodel' but the caption is 'IDL3
    Metamodel', and in 7.2 it is 'ComponentIDL'.

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

7.2, sentence 3

  • Legacy Issue Number: 7918
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    7.2, sentence 3: it is confusing to refer to BaseIDL as the
    'reference metamodel' since that terminology has a specific meaning for
    Profiles which does not apply here.

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

- Figure 2

  • Legacy Issue Number: 7917
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:
    • Figure 2: the arrows are not correct: they should represent a valid
      MOF 1.4 Package relationship (one of clustering, generalization,
      nesting, import). More seriously, since ComponentIDL is nested within
      metamodel CCM it is not allowed to have an import/cluster relationship
      with an external metamodel (BaseIDL in this case): MOF constraint [C49]
      states that "Nested Packages cannot import or cluster other Packages or
      Classes.".
  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

use the proper notation for expressing Profiles

  • Legacy Issue Number: 7914
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Should use the proper notation for expressing Profiles. The
    presentation of the Profile (e.g. in Table 1) is confusing in mixing
    references to the equivalent metamodel with references to the reference
    metamodel (UML) being extended by the Profile. Though the diagrams in
    the separate section 8.1.3 make things a lot clearer.

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Minor comments re Components FTF

  • Legacy Issue Number: 7913
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The Report should reference the document number of the Final Adopted
    Spec as the base document.

    • Issue 7628: the final line of the resolution is too vague "add the
      package...and update relations"
    • There should be accompanying MOF XMI (for the metamodel) and UML XMI
      (for the profile).
  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Section 7.2

  • Legacy Issue Number: 7912
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 7.2 states says that "BaseIDL that is a MOF-compliant
    description of the pre-existing CORBA Interface Repository that is
    already specified in the UML Profile for CORBA" - however in the
    document referred to for the latter (ptc/00-10-01) there is no mention
    of BaseIDL - in fact there is no metamodel only a pure profile. BTW a
    more up-to-date reference would be formal/02-04-01. This spec is clearly
    dependent on BaseIDL and so it's important to have a proper reference
    (and this should be in Section 3). In fact the appropriate reference for
    BaseIDL seems to be the CORBA components spec.

    The front page of convenience document, and document footer, still refer
    to it as a (Final) Adopted Specification

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

On Page 18 - Figure 11 Home mapping

  • Legacy Issue Number: 7911
  • Status: closed  
  • Source: Technical University Berlin ( Christian Hein)
  • Summary:

    On Page 18 - Figure 11 Home mapping. To me, it doesn't seems properly that CORBAValue inherits from AssociationClass. Perhaps it make sense that the HomeDef gets an attribute with name 'primary key'.

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Section 7, Overview

  • Legacy Issue Number: 7903
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 7, Overview consists only of 3 bullets that are instructions to an author rather than an overview e.g. "Explain relations to BaseIDL package"

  • Reported: CORBA 3.0.3 — Thu, 4 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

sections 1, 3, 4, 5 essentially empty

  • Legacy Issue Number: 7902
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The Convenience Document has sections 1, 3, 4, 5 essentially empty except for 'Editorial Comment: Needs to be completed'. They do need to be completed!
    Even worse, section 2, Conformance, also has a similar 'needs to be completed': though it does contain some text it is nothing like a conformance statement.
    I found it unclear whether the spec was providing a normative metamodel or just a normative profile: the text to be added to Section 1 (Scope) and Section 2 (Conformance) should clarify.

  • Reported: CORBA 3.0.3 — Thu, 4 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    see below

  • Updated: Sat, 7 Mar 2015 03:37 GMT

insufficient examples of component attributes

  • Key: CORBA3-133
  • Legacy Issue Number: 5906
  • Status: closed  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

    In OMG document formal/02-06-65, in section "1.3.3 Component Body", there
    is this text:

    "Declarations for facets, receptacles, event sources, event sinks,
    and attributes all map onto operations on the component's equivalent
    interface. These declarations and their meanings are described in
    detail below."

    In the following sections, I see facets, receptacles, event sources,
    and event sinks described, but I see no mention of attributes.
    It would be usefult to have an example of attributes in an appropriate
    place, as outlined by section 1.3.3.

    In section "1.10 Configuration with Attributes", I see that configurators
    are described, but I see no example of using attributes directly
    to configure a component.

    It would be very useful to include a small example to illustrate
    how to configure a component directly by using attributes.

    Diego Sevilla Ruiz <dsevilla@ditec.um.es> gave this
    C++ example on the CCM mailing list ( http://moriarty.dif.um.es/mailman/listinfo/ccm ):

    ======================================================

    component Whatever

    { attribute long cacheMaxKb; }

    ;

    home WhateverHome manages Whatever
    {
    };

    // C++
    WhateverHome_var weh = // obtain ref
    Whatever_var we = weh->create();

    we->cacheMaxKb(200);

    we->configuration_complete();

    ======================================================

    I don't suggest that this example be used verbatim,
    but a similar example would be useful to have in the
    CCM spec.

  • Reported: CORBA 3.0.2 — Thu, 10 Apr 2003 04:00 GMT
  • Disposition: Duplicate or Merged — CORBA 3.0.3
  • Disposition Summary:

    duplicate of issue 5898

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Derived component supported interface restriction

  • Key: CORBA3-132
  • Legacy Issue Number: 5683
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Both the CORBA spec (formal/02-06-01 page 3-61) and the CCM spec (formal/02-06-65 page 1-51) state that "A derived component type may not directly support an interface." Moreover the sentence you depicted is a contradiction with the formal/02-06-65 section 1.3.2.4 page 1-7.
    Resolution:

    In formal/02-06-65 page 1-51 and formal/02-06-01 page 3-61 replace the sentence

    "A derived component type may not directly support an interface."

    with

    "If a derived component type directly supports one or more IDL interfaces, the component interface is derived from both the interface of its base component type and the supported interfaces."

  • Reported: CORBA 3.0 — Thu, 10 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Typo: "Wrongpolicy"

  • Legacy Issue Number: 3635
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

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

  • Reported: CORBA 2.3.1 — Sun, 21 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Duplicate of 3634.

  • Updated: Sat, 7 Mar 2015 02:37 GMT

destroy on POA

  • Legacy Issue Number: 3402
  • Status: closed  
  • Source: Borland Software Corporation ( Andy Cutright)
  • 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?

  • Reported: CORBA 2.3.1 — Mon, 6 Mar 2000 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.4
  • Disposition Summary:

    closed no change

  • Updated: Sat, 7 Mar 2015 02:37 GMT

Valuetype "copying" semantics underspecified?

  • Legacy Issue Number: 3330
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

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

  • Reported: CORBA 2.3.1 — Fri, 18 Feb 2000 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.4
  • Disposition Summary:

    Merge with issue 3364 and close this issue

  • Updated: Sat, 7 Mar 2015 02:37 GMT

Scope of inherited valuetype initializers

  • Legacy Issue Number: 3329
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • 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."

  • Reported: CORBA 2.3.1 — Thu, 17 Feb 2000 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.4
  • Disposition Summary:

    Same as Issue 3305, Therefore same resolution as 3305

  • Updated: Sat, 7 Mar 2015 02:37 GMT

Null valuetypes not supported by DynValue

  • Legacy Issue Number: 3250
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • 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.

  • Reported: CORBA 2.3.1 — Tue, 25 Jan 2000 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.4
  • Disposition Summary:

    Merge with 3135 and provide resolution as part of 3135

  • Updated: Sat, 7 Mar 2015 02:37 GMT

International Strings in Encapsulations

  • Key: CORBA25-55
  • Legacy Issue Number: 3221
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • 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.

  • Reported: CORBA 2.3.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    closed in interop/2000-05-01

  • Updated: Sat, 7 Mar 2015 02:37 GMT

Expected behavior of POA configured with ServantLocator receiving LocateRe

  • Legacy Issue Number: 2791
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.3 — Thu, 8 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 02:37 GMT

The insert_dyn_any and get_dyn_any operations are barely documented

  • Legacy Issue Number: 2615
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.3 — Tue, 20 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    "The get_dyn_any and

  • Updated: Sat, 7 Mar 2015 02:37 GMT

OBV, value-reference substitution, Multiple Inheritance

  • Legacy Issue Number: 2258
  • Status: closed  
  • Source: Anonymous
  • 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).

  • Reported: CORBA 2.2 — Tue, 15 Dec 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 02:37 GMT

WRONG_TRANSACTION

  • Legacy Issue Number: 2218
  • Status: closed  
  • Source: Anonymous
  • 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?
  • Reported: CORBA 2.2 — Tue, 17 Nov 1998 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.3
  • Disposition Summary:

    issue merged with issue1963

  • Updated: Sat, 7 Mar 2015 02:37 GMT

Proposal on floating point fixes

  • Legacy Issue Number: 1667
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Mon, 13 Jul 1998 04:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 02:37 GMT

Section 3.3.8.16:deactivate_object() operation

  • Legacy Issue Number: 675
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.1 — Wed, 13 Aug 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 02:37 GMT

Object::is_a

  • Legacy Issue Number: 551
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.0 — Tue, 22 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    close no change in 2.4

  • Updated: Sat, 7 Mar 2015 02:37 GMT

DII operations "get_response and get_next_response

  • Legacy Issue Number: 464
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Wed, 18 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    resolved, closed issue

  • Updated: Sat, 7 Mar 2015 02:37 GMT

6.5.6. Repository Paragraph 2 - objection

  • Legacy Issue Number: 434
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.3
  • Disposition Summary:

    the application should use either the naming or trading service to determine which IR to use.

  • Updated: Sat, 7 Mar 2015 02:37 GMT

exception NoServant();

  • Key: CORBAE-21
  • Legacy Issue Number: 9921
  • Status: closed  
  • Source: PrismTech ( Donald Sharp)
  • Summary:

    exception NoServant(); is included in local interface POA but had been removed from minimumCORBA. Is it definitely back in?

  • Reported: CORBAe 1.0b1 — Fri, 14 Jul 2006 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    In “full” CORBA, the exception NoServant is used on in the operation
    get_servant. Since this operation is not present in either the Compact Profile or the
    Micro Profile, the exception should be removed to save the corresponding footprint.

  • Updated: Fri, 6 Mar 2015 23:30 GMT

Section: 8

  • Key: CORBAE-20
  • Legacy Issue Number: 9920
  • Status: closed  
  • Source: PrismTech ( Donald Sharp)
  • Summary:

    The following are included in the Micro Profile but missing from the Compact Profile // Factories for Policy objects LifespanPolicy create_lifespan_policy ( in LifespanPolicyValue value ); IdUniquenessPolicy create_id_uniqueness_policy ( in IdUniquenessPolicyValue value ); IdAssignmentPolicy create_id_assignment_policy ( in IdAssignmentPolicyValue value ); This appears to be an oversight because they are present in minimumCORBA.

  • Reported: CORBAe 1.0b1 — Fri, 14 Jul 2006 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    These operations should not have been included in the Micro Profile. They should only
    be available in the Compact Profile. In the Micro Profile, the policy settings supported for
    these policies by the Root (and only) POA are specified. Therefore, there is no need to
    create these policy objects

  • Updated: Fri, 6 Mar 2015 23:30 GMT

Section: 5.2 and 5.7

  • Key: CORBAE-19
  • Legacy Issue Number: 9879
  • Status: closed  
  • Source: PrismTech ( Donald Sharp)
  • Summary:

    Under ORB Operations register_initial_reference is inside #if ! defined(CORBA_E_MICRO) on page 5-4. Under Consolidated IDL on page 5-35 it is outside the #if ! defined(CORBA_E_MICRO). Where should it fall?

  • Reported: CORBAe 1.0b1 — Fri, 30 Jun 2006 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    The intent is that register_initial_reference is not in the Micro profile. The consolidated
    IDL should be corrected

  • Updated: Fri, 6 Mar 2015 23:30 GMT

Typo in set_values

  • Key: CORBA32-1
  • Legacy Issue Number: 16994
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The set_values is defined as

    void set_values(
    in NVLis values // property values to set
    );

    but should be

    void set_values(
    in NVList values // property values to set
    );

  • Reported: CORBA 3.1.1 — Thu, 12 Jan 2012 05:00 GMT
  • Disposition: Resolved — CORBA 3.2
  • Disposition Summary:

    In CORBA v3.3 Part 1 Interfaces, section8.6.2.2 change
    in NVLis
    to
    in NVList

  • Updated: Fri, 6 Mar 2015 23:16 GMT

context:delete_values has type

  • Key: CORBA32-2
  • Legacy Issue Number: 16995
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    delete_values is define as

    void delete_values(
    in Identifie prop_name // name of property(s) to delete
    );

    but should be

    void delete_values(
    in Identifier prop_name // name of property(s) to delete
    );

  • Reported: CORBA 3.1.1 — Thu, 12 Jan 2012 05:00 GMT
  • Disposition: Resolved — CORBA 3.2
  • Disposition Summary:

    In CORBA v3.3 Part 1 Interfaces, section section 8.6.2.4 replace:
    in Identifie
    with
    in Identifier

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Section: exceptions

  • Legacy Issue Number: 11027
  • Status: closed  
  • Source: wipro ( Rashmi)
  • Summary:

    org.omg.CORBA.NO_PERMISSION: vmcid: 0x0 minor code: 103 completed: No | | at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native | | Method) | | at | | sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces | | sorImpl.java:39) Feb 19 15:48:44 NMADR2CMT1 root: [NotificationChannel]NotificationChannel( ). Creating channel NpmChannel Feb 19 15:52:28 NMADR2CMT1 root: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No Feb 19 15:52:28 NMADR2CMT1 root: above mentioned are the errors we are getting from the the client appilcation. can anybody provide us the information why these execptions are generated and how to fix this kind of errors.

  • Reported: CORBA 3.0.3 — Mon, 21 May 2007 04:00 GMT
  • Disposition: Closed; No Change — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Codec Interface Deficiencies

  • Legacy Issue Number: 7731
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    CORBA 3, chapter 13.8, defines the Codec interface to encode
    arbitrary data values into CORBA::OctetSeq "blobs" and vice
    versa. This interface can be used, e.g., to supply and retrieve
    ServiceContext data using the PortableInterceptor interfaces.

    In practice, the Codec interface is also being used for data
    serialization, i.e., to store and retrieve arbitrary values in
    files or other databases.

    However, the interface is deficient in that it does not consider
    all possible variables that are needed for interoperability.
    It supports setting the CDR version that is to be used, but
    neglects byteorder and codeset settings.

    Consequently, the encoded values are platform-specific. If a
    value was encoded on a little-endian system, it will not decode,
    or worse, decode erroneously, on a big-endian system. The same
    caveats apply to codesets, e.g., when an ISO-8859-1 encoded
    blob is decoded using UTF-8 or Windows-1252.

    To support interoperability, the Codec interface needs to be
    extended.

    My recommendation is to extend the CodecFactory interface,
    so that it supports creating CDR version-, byteorder-, and
    codeset-specific Codec instances, either supplying user-
    provided values for each, or informing the user about chosen
    defaults.

    Example:

    module IOP {
    const EncodingFormat ENCODING_DEFAULT = -1;

    typedef short ByteorderFormat;
    const ByteorderFormat BYTEORDER_DEFAULT = -1;
    const ByteorderFormat BYTEORDER_BIGENDIAN = 0;
    const ByteorderFormat BYTEORDER_LITTLEENDIAN = 1;

    struct EncodingExt

    { EncodingFormat format; octet major_version; // set to 0 for default octet minor_version; ByteorderFormat byteorder; CONV_FRAME::CodeSetId char_data; // set to 0 for default CONV_FRAME::CodeSetId wchar_data; // set to 0 for default }

    ;

    local interface CodecFactory

    { // create_codec remains as before Codec create_codec_ext (inout EncodingExt enc) raises (UnknownEncoding); }

    ;
    };

    The create_codec_ext operation would create an appropriate
    Codec instance, if available; it will then set all "default"
    members of the EncodingExt structure to their actual values,
    so that the application can store this information along
    with any encoded values.

    One potential criticism of the above is that the encoding
    format's parameters depend on the encoding format. For example,
    there may be encoding formats that are byteorder-independent,
    or that consistently use UTF-32 for strings, thus not needing
    codeset parameters. Also, they may use wildly different
    versioning. So a "better" solution might involve passing
    the EncodingFormat, and an Any with a format-specific data
    type.

    That could look like:

    module GIOP {
    typedef short ByteorderFormat;
    const ByteorderFormat BYTEORDER_DEFAULT = -1;
    const ByteorderFormat BYTEORDER_BIGENDIAN = 0;
    const ByteorderFormat BYTEORDER_LITTLEENDIAN = 1;

    struct CDREncodingParameters

    { octet major_version; // set to 0 for default octet minor_version; ByteorderFormat byteorder; CONV_FRAME::CodeSetId char_data; // set to 0 for default CONV_FRAME::CodeSetId wchar_data; // set to 0 for default }

    ;
    };

    module IOP {
    const EncodingFormat ENCODING_DEFAULT = -1;

    local interface CodecFactory

    { // create_codec remains as before Codec create_codec_ext (inout EncodingFormat format, inout Any parameters) raises (UnknownEncoding); }

    ;
    };

    Once we have consensus on the approach, I will gladly volunteer
    to come up with a full set of editing instructions

  • Reported: CORBA 3.0.3 — Thu, 9 Sep 2004 04:00 GMT
  • Disposition: Duplicate or Merged — CORBA 3.1
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 22:25 GMT

Error in Chapter 21 of CORBA 3.0

  • Key: CORBA3-131
  • Legacy Issue Number: 6912
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    there is a serious error in Chapter 21 in both the CORBA 3.0 specification and the 3.1 drafts. The ORT final adopted specification (ptc/01-08-31 mentioned above) does NOT contain the methods ObjectReferenceFactory::equals an ObjectReferenceFactory::make_profiles. These methods were first added in the ORT FTF in issue 4476, then removed after further discussion in issue 4478. The final adopted specification reflects this, but somehow the incorrect text was incorporated into the official CORBA 3.0 specification. Unfortunately I only noticed this recently

  • Reported: CORBA 3.0.2 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    issue closed editorially

  • Updated: Fri, 6 Mar 2015 21:40 GMT

Wrong minor code listed in POAManager::deactivate

  • Key: CORBA3-130
  • Legacy Issue Number: 5449
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 11.3.2.5 states that BAD_INV_ORDER with minor code 6 is raised
    if POAManager::deactivate is called from an invocation on a POA that
    would be affected by the deactivate call.

    This minor code ought to be 3 instead

  • Reported: CORBA 3.0 — Mon, 1 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.1
  • Disposition Summary:

    editorially fixed in 3.0

  • Updated: Fri, 6 Mar 2015 21:40 GMT

DATA_CONVERSION minor code 2 not listed in Table 4-3

  • Key: CORBA3-129
  • Legacy Issue Number: 5322
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    It is used by RealTime CORBA as documented in 24.17.2

  • Reported: CORBA 2.6.1 — Thu, 23 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0
  • Disposition Summary:

    non issue...editorial, issue withdrawn

  • Updated: Fri, 6 Mar 2015 21:38 GMT

New core issue: need UNKNOWN reply status

  • Key: CORBA26-96
  • Legacy Issue Number: 4747
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • 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;

  • Reported: CORBA 2.5 — Wed, 12 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

TypeCode interface issue

  • Key: CORBA26-98
  • Legacy Issue Number: 4803
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.5 — Thu, 10 Jan 2002 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Valuetype initialzers need exceptions

  • Key: CORBA26-97
  • Legacy Issue Number: 4785
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • 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> ] “)” “;”

  • Reported: CORBA 2.5 — Mon, 17 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    Accept the proposed change based on discussion above

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Syntax error in CORBA IDL

  • Key: CORBA26-95
  • Legacy Issue Number: 4742
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • 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.

  • Reported: CORBA 2.5 — Sun, 9 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Incorrect example for recursive definitions which can span multiple levels

  • Key: CORBA25-54
  • Legacy Issue Number: 4261
  • Status: closed  
  • Source: Anonymous
  • 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?; };

  • Reported: CORBA 2.4.2 — Mon, 9 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    This has already been fixed in the previous RTF see orbrev/2001-03-01

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Definition of TRANSIENT minor code 1 confusing

  • Legacy Issue Number: 4036
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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.)"

  • Reported: CORBA 2.4.1 — Thu, 9 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Make it so

  • Updated: Fri, 6 Mar 2015 21:38 GMT

IDL format for RepositoryId

  • Legacy Issue Number: 4035
  • Status: closed  
  • Source: UBS ( Karsten Starr)
  • 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:
  • Reported: CORBA 2.4.1 — Thu, 9 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Incorporate changes and close issue.

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Valuetypes supporting local interfaces are local types?

  • Legacy Issue Number: 4031
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • 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)

  • Reported: CORBA 2.4.1 — Wed, 8 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

DynUnion incomplete

  • Legacy Issue Number: 4005
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.4 — Mon, 30 Oct 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Add the is_set_to_default_member function with the functionality as described for is_set_to_default_

  • Updated: Fri, 6 Mar 2015 21:38 GMT

#pragma version issue

  • Legacy Issue Number: 4016
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • 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?

  • Reported: CORBA 2.4.1 — Fri, 3 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Servant deactivation callback?

  • Legacy Issue Number: 4014
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.4.1 — Thu, 2 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close no change.

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Format of RMI Hashed Format repid

  • Legacy Issue Number: 3970
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • 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.

  • Reported: CORBA 2.4 — Wed, 18 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Clarify as suggested below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Typo: "Wrongpolicy"

  • Legacy Issue Number: 3634
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

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

  • Reported: CORBA 2.3.1 — Sun, 21 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Editorial, fixed editorially in 2.4

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Minor typo

  • Legacy Issue Number: 3621
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.3.1 — Thu, 18 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Editorial, fixed editorially in 2.4

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Section 4.3.7.1 get_client_policy?

  • Legacy Issue Number: 3582
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

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

  • Reported: CORBA 2.3.1 — Thu, 27 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    temporary bug....fixed, and issue closed

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Typo on page 7-9 of 2.3.1

  • Legacy Issue Number: 3564
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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();

  • Reported: CORBA 2.3.1 — Fri, 14 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed issue...editorial

  • Updated: Fri, 6 Mar 2015 21:38 GMT

BAD_QOS system exception

  • Legacy Issue Number: 3337
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

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

  • Reported: CORBA 2.3.1 — Mon, 21 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed issue, available in current draft

  • Updated: Fri, 6 Mar 2015 21:37 GMT

attributes and system exceptions

  • Legacy Issue Number: 3219
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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...)

  • Reported: CORBA 2.3.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 21:37 GMT

why was is_abstract added to structs in CORBA IR?

  • Legacy Issue Number: 3015
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.3.1 — Tue, 9 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    flagged as urgent....resolved

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Null Value semantics under specified

  • Legacy Issue Number: 2817
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • 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

  • Reported: CORBA 2.3 — Wed, 21 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    close issue, no change

  • Updated: Fri, 6 Mar 2015 21:37 GMT

DynFactory or DynAnyFactory?

  • Legacy Issue Number: 2617
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.3 — Tue, 20 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

is_abstract parameter missing from create_interface() IDL

  • Legacy Issue Number: 2579
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.3 — Thu, 8 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Destruction of ORB

  • Legacy Issue Number: 2254
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Mon, 14 Dec 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

OMG VMCID

  • Legacy Issue Number: 2000
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 29 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

New proposal for recursive TypeCode creation

  • Legacy Issue Number: 1967
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 17 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Typo on pages 10-53, 10-55, and 10-70

  • Legacy Issue Number: 1944
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.2 — Fri, 11 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

deactivate_object page no: 9-35

  • Legacy Issue Number: 1950
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.2 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Proposal for creating recursive TypeCodes

  • Legacy Issue Number: 1928
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 2 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Types defined in the CORBA module?

  • Legacy Issue Number: 1797
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 11 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    :Identifier, if I want to use them in my IDL?

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Missing orb.idl

  • Legacy Issue Number: 1796
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 11 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Size of IDL char

  • Legacy Issue Number: 1753
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 30 Jul 1998 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Incorrect LifeCycle IDL?

  • Legacy Issue Number: 1772
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 6.2 of formal/98-07-05 mentions

    typedef Naming::Name Key;

    I believe it should be CosNaming::Name instead.

  • Reported: CORBA 2.2 — Tue, 4 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Proposed change to IDL in section 3.10.2, page 3-32 "Parameter Declaration

  • Legacy Issue Number: 1728
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 23 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 21:36 GMT

CosObjectIdentity::ObjectIdentifiers can"t be UUIDs?

  • Legacy Issue Number: 1725
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 23 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Illegal IDL in CosTime module

  • Legacy Issue Number: 1688
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 16 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

TypeCode comparison proposal (02)

  • Legacy Issue Number: 1623
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 1 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

TypeCode comparison proposal (01)

  • Legacy Issue Number: 1622
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 1 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Description of Wide String type

  • Legacy Issue Number: 1612
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

name scoping issue

  • Legacy Issue Number: 1587
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.2 — Fri, 26 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

IDL struct issue

  • Legacy Issue Number: 1585
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Fri, 26 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Type codes cannot describe all unions

  • Legacy Issue Number: 1545
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Type code operations under-specified

  • Legacy Issue Number: 1542
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Type code typos (as only one issue)

  • Legacy Issue Number: 1541
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typo in chapter 8

  • Legacy Issue Number: 1537
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.2 — Tue, 23 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Does the DII support the standard object operations?

  • Legacy Issue Number: 1422
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.2 — Tue, 2 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos in IR IDL in Specification (050

  • Legacy Issue Number: 1398
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.2 — Wed, 20 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos in IR IDL in Specification (04)

  • Legacy Issue Number: 1397
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.2 — Wed, 20 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos in IR IDL in Specification (03)

  • Legacy Issue Number: 1396
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.2 — Wed, 20 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos in IR IDL in Specification (02)

  • Legacy Issue Number: 1395
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 20 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos in IR IDL in spec (01)

  • Legacy Issue Number: 1394
  • Status: closed  
  • Source: Anonymous
  • 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.
  • Reported: CORBA 2.2 — Wed, 20 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

/ in prefix pragma?

  • Legacy Issue Number: 1241
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Mon, 27 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Versioning by the back door?

  • Legacy Issue Number: 1164
  • Status: closed  
  • Source: Anonymous
  • 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?!

  • Reported: CORBA 2.2 — Wed, 22 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

GIOP typo, section 4.2 (page 4.4) of CORBA 2.2

  • Legacy Issue Number: 1160
  • Status: closed  
  • Source: Anonymous
  • 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".

  • Reported: CORBA 2.2 — Mon, 20 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    :Object. In Section 13.4.1 (page 13-23) it sates that the operation

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Domain Manager related specification shortcomings (03)

  • Legacy Issue Number: 1155
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Fri, 17 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    get_domain_managers operation in an interoperable fashion. To fix

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Semantics and standard exceptions

  • Legacy Issue Number: 1146
  • Status: closed  
  • Source: Anonymous
  • 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...

  • Reported: CORBA 2.2 — Thu, 16 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Forward declarations and inheritance

  • Legacy Issue Number: 1145
  • Status: closed  
  • Source: Anonymous
  • 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).

  • Reported: CORBA 2.2 — Thu, 16 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 21:35 GMT

Indentation on page 4-4

  • Legacy Issue Number: 1094
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Sun, 22 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Editorial issue, chapter 8

  • Legacy Issue Number: 1091
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Sat, 21 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

ORB_init

  • Legacy Issue Number: 1088
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Fri, 20 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

IDl "module" construct - IDL files

  • Legacy Issue Number: 1087
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Fri, 20 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

How to deal with object identity

  • Legacy Issue Number: 1086
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Fri, 20 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typo in type code section (13.3.4)

  • Legacy Issue Number: 1074
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 19 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Fixed point constants issue

  • Legacy Issue Number: 1068
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Wide character and wide string literals

  • Legacy Issue Number: 1067
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Type of fixed point quotients

  • Legacy Issue Number: 1071
  • Status: closed  
  • Source: Anonymous
  • 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).

  • Reported: CORBA 2.2 — Thu, 19 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Fixed point constant typo in 2.2

  • Legacy Issue Number: 1066
  • Status: closed  
  • Source: Anonymous
  • 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".

  • Reported: CORBA 2.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Marshalling is_equivalent

  • Legacy Issue Number: 1054
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    close no change with above explanation

  • Updated: Fri, 6 Mar 2015 21:35 GMT

#pragma prefix issue

  • Legacy Issue Number: 999
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:34 GMT

CORBA 2.2 - "native" and the interface repository

  • Legacy Issue Number: 992
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 5 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:34 GMT

union typecode

  • Legacy Issue Number: 811
  • Status: closed  
  • Source: Anonymous
  • 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).

  • Reported: CORBA 2.1 — Tue, 23 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:34 GMT

CDR encoding of TypeCode names inconsistent with equal operation

  • Legacy Issue Number: 719
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.1 — Wed, 10 Sep 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Duplicate of issue 665

  • Updated: Fri, 6 Mar 2015 21:34 GMT

OMG IDL prefix pragma

  • Key: CORBA21-90
  • Legacy Issue Number: 566
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.0 — Thu, 22 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Description of constant expression semantics is unclear

  • Key: CORBA21-89
  • Legacy Issue Number: 564
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:

  • Reported: CORBA 2.0 — Thu, 1 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved, closed issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Object terminal missing from IDL grammar

  • Key: CORBA21-88
  • Legacy Issue Number: 563
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.0 — Thu, 1 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved, closed in "97

  • Updated: Fri, 6 Mar 2015 21:34 GMT

WRONG_TRANSACTION

  • Key: CORBA21-87
  • Legacy Issue Number: 557
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.0 — Mon, 28 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    issue resolved, see revised text

  • Updated: Fri, 6 Mar 2015 21:34 GMT

OTS 1.1 specification changes

  • Key: CORBA21-86
  • Legacy Issue Number: 556
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.0 — Mon, 28 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Interface Repository

  • Key: CORBA21-85
  • Legacy Issue Number: 542
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.0 — Tue, 15 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

CORBA::Bounds and CORBA::TypeCode::Bounds

  • Key: CORBA21-84
  • Legacy Issue Number: 457
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 1.2 — Wed, 13 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    no change to spec., close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

3.10.3 Raises Expressions

  • Key: CORBA21-83
  • Legacy Issue Number: 390
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.0
  • Disposition Summary:

    Duplicate of issue # 389...closed

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Do simple/anonymous types have repository IDs?

  • Key: CORBA21-82
  • Legacy Issue Number: 137
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Thu, 26 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    clarified, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Exception as explicit parameter

  • Key: CORBA21-81
  • Legacy Issue Number: 87
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Sun, 18 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Length of wstring in GIOP 1.1

  • Key: CORBA26-87
  • Legacy Issue Number: 3075
  • Status: closed  
  • Source: Fujitsu ( Masayoshi Shimamura)
  • Summary:

    I have a question about GIOP wstring encoding. Section "15.3.2.7 Strings
    and Wide Strings" in CORBA 2.3.1 says:

    For GIOP version 1.1, a wide string is encoded as an unsigned long
    indicating the length of the string in octets or unsigned integers
    (determined by the transfer syntax for wchar) followed by the
    individual wide characters. Both the string length and contents
    include a terminating null. The terminating null character for a
    wstring is also a wide character.

    In the sentence above, I believe that the "length" represents number of
    octets (in the case of byte oriented codeset) or number of unsigned
    integers (in the case of non-byte oriented codeset).

    For example,

    "abc" (ASCII code) ----> length is 4 (including one null terminate)
    L"abc" (Unicode, USC2) ----> length is 4 (including one null terminate of wchar)

    Is my understanding right?

  • Reported: CORBA 2.3.1 — Fri, 3 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

padding at the end of a non-fragmented 1.2 request message

  • Key: CORBA26-86
  • Legacy Issue Number: 3014
  • Status: closed  
  • Source: AT&T ( Sai-Lai Lo)
  • Summary:

    Suppose a GIOP 1.2 request message is sent for an operation with no
    argument. In this case the request body is empty because there is no
    argument.

    Furthermore, the whole request message is non-fragmented, i.e. the
    2nd least significant bit of Flags in the request header is 0. Now if the
    request message header ends on a boundary which is not 8-byte
    aligned. Should the request message be extended with extra padding after the
    request message header to make the whole request message multiple of 8?

    I think the relevant statement is in section 15.4.1 (page 15-31):

    "For GIOP version 1.2, if the second least significant bit of Flags is 1,
    the sum the message_size value and 12 must be evenly divisible by 8"

    My intepretation of the statement is that the condition I just described
    does not meet this critera. Hence the message should not be padded to
    multiple of 8. It should just be ended with the end of the message header,
    just like previous GIOP versions.

    I'm asking for clarification on this issue because I'm seeing a different
    behaviour in another ORB implementation and would like to pre-empt any
    interoperability problem in future.

  • Reported: CORBA 2.3.1 — Tue, 9 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IANA ports for IIOP need to be documented in Ch 13 and 15

  • Key: CORBA26-83
  • Legacy Issue Number: 2939
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Chapter 15 (formal/99-07-19), page 15-51 last para of section 15.7.2, and
    Chapter 13 (formal/99-07-17), page 13-36 last para, assert that "no 'well known'
    ports have been allocated", and then proceeds to state that individual
    implementations must use some unallocated port and document it.

    The statement about "no well known port has been allocated" needs to be revised
    to reflect that a well known port (683 for IIOP) has been allocated. Then we can
    change the statement about what individual implementations are expected to do by
    merely replacing the "must use some unallocated port" by a "may use the well
    known port or may use some unallocated port and document it" or some such.

  • Reported: CORBA 2.3 — Tue, 21 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interop, 15.7.3 unclear wording

  • Key: CORBA26-85
  • Legacy Issue Number: 2952
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I do have a quick question on one part and that is
    Section 15.7.3 IIOP IOR Profile Components. This first paragraph has the
    following line in it: " All these components are optional presence in the
    IIOP profile
    and cannot be dropped from an IIOP 1.1 or 1.2 IOR". Now I must admit that I
    am
    new to this CORBA thing, but is there something wrong with this sentence?
    I am not quite sure what this means and the grammar seems quite odd ("are
    optional prensence"?). Any chance someone could translate?

  • Reported: CORBA 2.3.1 — Fri, 15 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Is GIOP 1.x sustainable any more?

  • Key: CORBA26-84
  • Legacy Issue Number: 2941
  • Status: closed  
  • Source: ( Adrian St. John)
  • Summary:

    Is GIOP 1.x really sustainable any more?
    We've got implementation nightmares because:

    • Features haven't been thought through properly
      eg Fragment in 1.1, BiDir in 1.2
    • Simple backwards compatibility is being lost
      eg ReplyHeader v1.2 has fields in completely different places to
      previous versions, albeit for very good reasons.
    • The TypeCode CDR version problems
    • Not enough information in certain messages
      eg MessageError can't indicate which message may have caused a
      problem, and certainly can't describe in what way there was an error.
  • Reported: CORBA 2.3 — Thu, 23 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of undefined "id" attribute

  • Key: CORBA26-82
  • Legacy Issue Number: 3197
  • Status: closed  
  • Source: Ericsson ( John-Luc Bakker)
  • Summary:

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

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

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

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

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

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

    <!ELEMENT idl
    ( link

    fileinarchive
    repository
    ) >

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

  • Reported: CPP 1.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Question about corbaname URL

  • Key: CORBA26-93
  • Legacy Issue Number: 4342
  • Status: closed  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

    I have an interoperability question regarding the
    corbaname URL in the CORBA 2.4.2 specification and would appreciate
    clarification.

    In 13.6.7.3, it states that for a corbaloc URL which
    uses IIOP, if the port number of the endpoint is
    not specified, then the IIOP profile should default
    to port 2809 which is specified by IANA as the corbaloc
    port.
    eg.
    corbaloc:iiop:myhost.com/SomeKey

    In 13.6.7.5, the corbaname URL is described.
    If a corbaname URL is specified for IIOP, but the port
    number is omitted, should the ORB assume that the
    root naming context will be on port 2809 of the host
    specified?

    eg.
    corbaname:iiop:myhost.com:3000#path/obj

    will look for the root naming context on port
    3000 of myhost.com.

    eg.
    corbaname:iiop:myhost.com#path/obj

    Should this look to port 2809 for the root
    naming context?

  • Reported: CORBA 2.4.2 — Fri, 8 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incomplete grammar in section 15.3.4.8

  • Key: CORBA26-92
  • Legacy Issue Number: 4339
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    In orbrev/01-03-01:

    Production rule two at the end of this sections has a comment that it
    should include all IDL types, but in actuality is missing "long long",
    unsigned long long" and "long double".

    Suggest we add these to the production rule in question.

  • Reported: CORBA 2.4.2 — Tue, 5 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Indirections with chunking & fragmentation

  • Key: CORBA26-91
  • Legacy Issue Number: 4328
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    When chunking and fragmenting, it is possible for a chunk length to be
    inserted between the indirection tag and indirection offset.
    Implementations must be careful to compute the indirection offset
    correctly both when writing and reading to avoid errors.

    For interoperability, we should elminate this possibility. From an
    implementation point of view, the code for handling this special case
    should already be there. Please see the original message (see
    attachment) for a detailed description of the problem scenario and two
    implementation possibilities.

    Proposed resolution:

    Elminate the possibility of chunk lengths between indirection tag and
    indirection offset by changing the following paragraph in CORBA formal
    00-11-03 15.3.4.6.

  • Reported: CORBA 2.4.2 — Fri, 25 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In RMI rep Id, when is inclusion of SUID legal?

  • Key: CORBA26-89
  • Legacy Issue Number: 4280
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    In formal 00-11-03 10.6.2 in the discussion of the serial version UID in
    the RMI hashed format, the spec defines the repository ID format as

    RMI: <class name> : <hash code> [ : <serialization version UID> ]

    and says

    "If the actual serialization version UID for the Java class differs from
    the hash code, a colon and the actual serialization version UID
    (transcribed as a 16 digit upper-case hex string) shall be appended to
    the RepositoryId after the hash code."

    The Java to IDL spec ptc-00-01-06 1.3.5.7 says

    "The syntax of the repository ID is the standard OMG RMI Hashed format,
    with an initial “RMI:” followed by the Java class name, followed by a
    hash code string, followed optionally by a serialization version UID
    string."

    Questions:

    1) Is it legal to include the serial version UID in the repository ID
    even when it is equal to the hash code? (Alternatively: Is it legal
    for an ORB to throw an exception/fail if the hash code and serial
    version UID in the repository Id are the same?)

    2) If it is not legal to include the serial Version UID in the
    repository ID when equal to the hash code, what should an ORB do?

    Discussion:

    Other than it not harming anything to include the SUID, there are rare
    cases that the same Java class compiled with different compilers can
    result in different default serial version UIDs, so it would be wise to
    explicitly specify the serialVersionUID field even in the first version
    of a class. If it is legal to always include the serial version UID
    part of the repository ID, ORBs with classes from two different
    compilers would still be able to interoperate.

  • Reported: CORBA 2.4.2 — Mon, 23 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GIOP is silent about extra data in the Request or Reply body

  • Key: CORBA26-88
  • Legacy Issue Number: 4273
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The specification does not say whether extra data after the invocation
    parameters in a Request or Reply body is ignored or considered an
    error. For interoperability purposes, the spec should require one or
    the other.

  • Reported: CORBA 2.4.2 — Wed, 18 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GIOP issue : fragmented replies with exceptions

  • Key: CORBA26-90
  • Legacy Issue Number: 4289
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    Let us assume that the server has sent a few reply fragments. But before sending all the reply
    fragments, an exception occurs (say while marshalling the response).
    What does the server and the client (which has already seen reply fragments) do ?

    Just to note, notice that if the same problem happens while the client is in the midst of sending
    request fragments, the client can choose to send a CancelRequest message to intimate the server.

    Since there are various possible behaviours for the client and server, the GIOP specification needs
    to clarify the standard behaviour, in order for different implementations to remain interoperable.

    One possible behaviour :

    The server could send back a seperate response (containing the exception with
    CompletionStatus.COMPLETED_YES). The client on receipt of the new reply, and noticing the fact that
    another reply with the same requestId is pending, could discard the pending reply and process the
    latest reply.

    Another behaviour :

    The client could simply timeout the request and discard any new reply streams (with the same
    requestId), and raise an exception with CompletionStatus.COMPLETED_MAYBE.

  • Reported: CORBA 2.4.2 — Mon, 30 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    This issue is resolved by the resolution to issue 4273.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Changing VSCID prefix to 24 bits

  • Key: CORBA26-94
  • Legacy Issue Number: 4618
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    In section 13.6.8 of CORBA 2.4.2 (formal/01/02-01), at the top of page
    13-29, it says:

    The high-order 20 bits of service-context ID contain a 20-bit vendor
    service context codeset ID (VSCID); the low-order 12 bits contain the rest
    of the service context ID. A vendor (or group of vendors) who wish to
    define a specific set of system exception minor codes should obtain a
    unique VSCID from the OMG, and then define a specific set of service
    context IDs using the VSCID for the high-order bits.

    The VSCID of zero is reserved for use for OMG-defined standard service
    context IDs (i.e., service context IDs in the range 0-4095 are reserved as
    OMG standard service contexts).

    The VSCID-related text was added by the Interop 1.2 RTF as per RTF report
    as in document number interop/98-01-04, and revised pages as in document
    number interop/98-01-03. However, at about the same time OMG staff
    established a convention that OMG should allocate vendors a 24-bit "service
    tag", which is in fact the same as a VSCID. Since then, some 47 of these 24
    bit service tags have been assigned to various vendors.

    At the risk of having the tail wag the dog, I propose we resolve this
    conflict by revising these paragraphs in the CORBA spec as follows:

    The high-order 24 bits of a service context ID contain a 24-bit vendor
    service context codeset ID (VSCID); the low-order 8 bits contain the rest
    of the service context ID. A vendor (or group of vendors) who wishes to
    define a specific set of system exception minor codes should obtain a
    unique VSCID from the OMG, and then define a specific set of service
    context IDs using the VSCID for the high-order bits.

    The VSCIDs of zero to 15 inclusive (0x000000 to 0x00000f) are reserved for
    use for OMG-defined standard service context IDs (i.e., service context
    IDs in the range 0-4095 are reserved as OMG standard service contexts).

  • Reported: CORBA 2.5 — Fri, 12 Oct 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Component port introspection

  • Key: CORBA26-72
  • Legacy Issue Number: 4412
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The Components::Navigation interface that is implemented by all
    components provides introspection ("generic navigation") capabilities.
    There are lots of use cases for introspection, so I wonder why there
    is introspection for facets, but not for receptacles or event ports.
    I suggest to add such introspection capabilities. All introspection
    features should be alike as much as possible for ease of usage.

  • Reported: CORBA 2.4.2 — Mon, 16 Jul 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"supports" terminology issue for CCM

  • Key: CORBA26-71
  • Legacy Issue Number: 4329
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    . I don't
    think OMG specifications should use a single term in two distinctly
    different ways. The text of the issue starts with the sentence,
    "the Components spec and valuetype spec treat "supports" exactly
    *OPPOSITE* in semantics regarding widening/narrowing." and continues
    for about 3 or 4 paragraphs. Ed's comment should go in there too.

  • Reported: CORBA 2.4.2 — Fri, 18 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CCM: Definition of import declaration unclear

  • Key: CORBA26-77
  • Legacy Issue Number: 4577
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    After reading the definition of the import declaration, it is not at
    all clear what its effect is.

    Suppose the "well-known set of IDL specifications" consists of

    module A {
    module B {
    interface C {
    struct S

    {long a;}

    ;
    };
    };
    };

    Now consider the import statement

    import A::B;

    According to the draft, "Names that occur in IDL declarations within
    the importing specification may be resolved to definitions in imported
    scopes." What is a "Name" in this context? Is it an <identifier>, or
    is it a "<scoped_name>"?

    It is unclear whether in this context, the definition

    interface D : C {};

    would be correct or not. The spec may be interpreted that name "C"
    resolves to ::A::B::C, i.e. that the name "C" is appended to the
    imported scopes, forming a fully-scoped name. If that is the intended
    meaning, the text should explain how to deal with conflicts.

    Alternatively, given the text "Imported IDL name scopes exist in the
    same space as names defined in subsequent declarations in the
    importing specification." would suggest that

    interface D : B::C {};

    is well-formed: "B" would be the name of the imported scope, so it
    exists in the same space "D", and can thus be used for qualifications.

    Furthermore, the text could be understand to mean that

    interface D : ::A::B::C {};

    is allowed. The "definition in the imported scope" has the name
    "A::B::C", so this is the name to be used in the importing
    specification.

  • Reported: CORBA 2.5 — Mon, 17 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CCM: Chapter 66 should be removed

  • Key: CORBA26-70
  • Legacy Issue Number: 4307
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    Looking at ptc/99-10-04, it is not clear to me which parts of this
    document are intended as normative.

    For example, the introduction to chapter 66, "Component Container
    Architecture", states that the presented design "is not the only
    possible design choice." Consequently, it appears that the entire
    chapter 66 is not intended as normative. However, looking at the
    actual text, a reader might be easily confused into taking aspects of
    the design as normative.

    While this text was helpful in the submission to give readers an
    insight how the submitters might design their implementations, it
    should be removed from the specification, to really give implementors
    the freedom of design choice that was apparently intended with the
    submission.

  • Reported: CORBA 2.4.2 — Tue, 15 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL out parameters can't map to EJB?

  • Key: CORBA26-69
  • Legacy Issue Number: 4269
  • Status: closed  
  • Source: Progress Software ( Alan Conway)
  • Summary:

    Section 8.3.1 says "The signatures of the CORBA component operations are mapped to signatures of EJB remote interface methods following the IDL to Java mapping rules."

    As far as I can see, this only works if the IDL signature has no out or inout parameters. The Holder classes for out and inout parameters cannot be used in an EJB interface signature because they need not be Serializable, which breaks the rules for an RMI compliant class. Even if they could the EJB stubs and skeletons would not implement their special return value behavior without modifications to the EJB spec.

    Someone please tell me I've missed something!

  • Reported: CORBA 2.4.2 — Thu, 12 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

explicit definition of CCM exceptions mapped from EJB standard exceptions

  • Key: CORBA26-74
  • Legacy Issue Number: 4540
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    The CCM exceptions mapped from EJB standard exceptions need to be defined
    explicitly in OMG IDL. The resolution to issue 3182 introduces new CCM
    standard exceptions Components::CreateFailure, Components::FinderFailure
    and Components::RemoveFailure but it does not define them explicitly.

  • Reported: CORBA 2.4.2 — Wed, 29 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect syntax in Components::Enumeration

  • Key: CORBA26-73
  • Legacy Issue Number: 4529
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    The use of the state keyword in the Components::Enumeration valuetype,
    introduced by issue 3099 and extended in issue 3418, is not correct
    syntactically. Also, anonymous sequences have been deprecated, so the
    definition of the Components::Enumeration state is incorrect in this sense
    as well.

  • Reported: CORBA 2.4.2 — Fri, 13 Jul 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

minor IDL changes required in CCM API

  • Key: CORBA26-81
  • Legacy Issue Number: 4717
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In order to compile the Components.idl file with a compiler
    compliant with OMG IDL2/IDL3/CIDL/PSDL grammars simultaneously,
    it is required to apply some changes in CCM APIs:

    • In ptc/2001-11-03 draft chapter 61 page 61-225, the following IDL

    valuetype FacetDescription : PortDescription

    { public Object facet; }

    ;

    should be replaced by

    valuetype FacetDescription : PortDescription

    { public Object facet_ref; }

    ;

    because 'facet' is a CIDL keyword.

    • In ptc/99-10-04 chapter 62 page 62-141, the following IDL is defined

    exception Rollback { };
    // ...
    local interface Transaction

    { // ... void commit () raises (Rollback, NoTransaction, HeuristicMixed, HeuristicRollback, Security, SystemError); void rollback () raises (NoTransaction, Security, SystemError); // ... }

    ;

    Here there is a conflit name between the exception Rollback
    and the operation rollback.

    In order to avoid this, the exception Rollback should be renamed
    RollbackError. Then the previous IDL should be replaced by:

    exception RollbackError { };
    // ...
    local interface Transaction

    { // ... void commit () raises (RollbackError, NoTransaction, HeuristicMixed, HeuristicRollback, Security, SystemError); void rollback () raises (NoTransaction, Security, SystemError); // ... }

    ;

    In the commit operation description page 62-142, the Rollback exception
    should be replaced by RollbackError.

    In table 64-7 page 64-197, the Rollback exception of the commit operation
    should be replaced by RollbackError.

    • In ptc/99-10-04 chapter 62 page 62-151, the 1st 'home' parameter
      of the HomeRegistration::register_home and unregister_home operations
      implies a parser error with a CCM IDL compiler as 'home' is a keyword.

    The 'home' parameters should be replaced by 'home_ref'
    Ditto in the following 'register_home' and 'unregister_home'
    operation descriptions.

    • In ptc/99-10-04 chapter 62 page 62-155, the following IDL

    get_oid_from_ref (in Object ref)

    should be replaced by

    get_oid_from_ref (in Object objref)

    because 'ref' is a PSDL keyword.

    In the 'get_oid_from_ref' operation description page 62-156,
    replace 'The ref parameter' by 'The objref parameter'.

    • In ptc/99-10-04 chapter 62 page 62-162, the following IDL

    get_cid_from_ref (in Object ref)

    should be replaced by

    get_cid_from_ref (in Object objref)

    because 'ref' is a PSDL keyword.

    In the 'get_cid_from_ref' operation description page 62-163,
    replace '(ref)' by '(objref)'.

    • In ptc/2001-11-03 draft chapter 69 page 69-551, the following IDL

    void remove_container(in Container ref) raises (RemoveFailure);

    should be read as

    void remove_container(in Container cref) raises (RemoveFailure);

    because 'ref' is a PSDL keyword.

    • In ptc/2001-11-03 draft chapter 69 page 69-553, the following IDL

    void remove_home(in CCMHome ref) raises (RemoveFailure);

    should be read as

    void remove_home(in CCMHome href) raises (RemoveFailure);

    because 'ref' is a PSDL keyword.

  • Reported: CORBA 2.5 — Tue, 27 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    Accept the previous required changes.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Little problem with introspection API

  • Key: CORBA26-80
  • Legacy Issue Number: 4716
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I wanted to point out that the use of the name "ref" or "Ref" in
    > the introspection API may be a problem because "ref" is a
    > reserved word in PSDL and therefore any PSDL file that
    > includes the CCM IDL file will cause compiler errors (this has
    > happened to me when using the OpenORB PSDL compiler). If at
    > all possible we should change the use of "ref" to "reference"
    > or something else in the final version of the spec.

  • Reported: CORBA 2.5 — Tue, 27 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CCM: Meaning of "exposed" scopes unclear.

  • Key: CORBA26-79
  • Legacy Issue Number: 4579
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    ccm/01-08-04 says

    "When a name scope is imported, the names of the enclosing scopes in
    the fully-qualified pathname of the enclosing scope are exposed within
    the context of the importing specification, but their contents are not
    imported. An importing specification may not re-define or re-open a
    name scope which has been exposed (but not imported) by an import
    statement."

    Now consider the following "well-defined set of IDL specs":

    module X {
    module Y {
    module Z{};
    };
    };

    and the following import statement

    import X::Y;

    Now, it appears that this declaration would make it ill-formed to
    specify

    module X{
    interface another_interface{};
    };

    since "X" is an exposed scope. That appears to be inconsistent, since
    clearly, reopening "X" is allowed without the import statement.

  • Reported: CORBA 2.5 — Mon, 17 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CCM: usage of the MOF profile

  • Key: CORBA26-68
  • Legacy Issue Number: 4214
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    The CCM MOF IR draft (ptc/99-10-05) uses UML to denote the MOF model
    of the IR. Without missing elaboration, it is not possible to mentally
    construct the metamodel. For example, the enumeration, primitive, and
    unchangeable stereotypes don't have a well-defined relationship to MOF
    concepts. It seems that the MOF chapter should use the UML MOF profile
    (ad/01-02-29). In addition, it would be desirable if a normative XML
    document that defines the metamodel (following the MOF DTD) is
    provided.

  • Reported: CORBA 2.4.2 — Thu, 1 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CCM: Isolated scope tokens

  • Key: CORBA26-76
  • Legacy Issue Number: 4576
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    In ccm/01-08-03, section 3.6, there is a sentence

    "In isolation, the scope token represents the scope of the
    specification in which it occurs."

    It is not clear what an "isolated scope token" is, since the scope
    token is allowed only as part of a <scoped_name>, but never appears in
    isolation. The intended meaning of this sentence should be clarified.

  • Reported: CORBA 2.5 — Mon, 17 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue for Components: Missing language mapping

  • Key: CORBA26-75
  • Legacy Issue Number: 4574
  • Status: closed  
  • Source: Humboldt-Universitaet ( Harald Boehme)
  • Summary:

    in both documents orbos/99-07-01/6.3 and ptc/99-10-40/615.3 the language
    mapping is noted as open issue.
    Where are the language mappings for components ?

  • Reported: CORBA 2.5 — Mon, 17 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CCM: import and re-opening of modules

  • Key: CORBA26-78
  • Legacy Issue Number: 4578
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    In ccm/01-08-03, a sentence says "IDL module definitions may re-open
    modules defined in imported name scopes."

    Now, consider the following "well-defined set of IDL definitions":

    module Y{};
    module A{
    module Y{};
    };
    module B{
    module Y{};
    };

    and the import statements

    import A;
    import B;

    Clearly, A::Y and B::Y are "modules defined in imported name
    scopes". Does that mean that specifying

    module Y{
    interface another_interface{};
    };

    is now valid? If so, which namespace is extended?

    It may be that this is meant to be an error (if so, where does it say
    that?). In that case, consider the case that there was only a single
    import:

    import A;

    Then, if this means that A::Y is extended, how could I specify a
    re-opening of ::Y?

    Alternatively, it may be that the authors thought of re-opening Y in
    the form of

    module A::Y{
    interface another_interface{};
    };

    That, of course, is illegal syntax. Yet another interpretation is that
    the draft intended to allow

    module A{
    module Y{
    interface another_interface{};
    };
    };

    However, this appears to be possible even without any import
    statement.

  • Reported: CORBA 2.5 — Mon, 17 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 4577.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Extended Interface Repository

  • Key: CORBA26-63
  • Legacy Issue Number: 4116
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    I am somewhat surprised over the ExtendedIR interface in 00-11-01.
    I am very aware of problems with extensibility in the Interface Repo-
    sitory. In the past, a lot of problems have been caused because modi-
    fications like InterfaceDef::is_abstract have been worked in and out.
    We certainly desperately need a backwards-compatible Interface Repo-
    sitory.

    This is unachievable with version pragmas, because then a client's
    is_a inquiries with "old" Repository Ids will fail, and the client
    will refuse to talk any further.

    Backward compatibility is instead achieved by not changing data types
    (such as InterfaceDescription) and by not changing the signature of
    existing attributes and operations.

    Adding new types that are used by new operations on existing interfaces
    does not break compatibility, because the client will simply be unaware
    that there are more operations than it knows of (such as describe_inter-
    face_2_3).

    Whether changing interfaces sensible is debatable, surely it's more
    consistent to use derived interfaces instead – this has the least im-
    pact on compatiblity.

    In that light, I wonder whether the proposal in 00-11-01 gets us any
    further. It adds more fixed interfaces in another module, and this new
    ExtendedIR module is just as static as the old ones have been. If any
    further changes were necessary, backwards-incompatible changes were
    just as necessary.

    The proposal in 00-11-01 also adds a lot of unnecessary verbose baggage
    with its use of "extended" everywhere, and its usage of multiple inheri-
    tance from the original interfaces is confusing.

    Yet there is one item from 00-11-01 that I like much better than the
    proposal in 99-10-03, and that is the usage of AbstractInterfaceDef and
    LocalInterfaceDef. I think that's the way to go.

    Therefore, I tend to vote against issue 3233 and its proposed resolution
    in 00-11-01.

    Rather, I propose to go back to the original version instead, and

    • to add AbstractInterfaceDef, LocalInterfaceDef and the related
      container operations
    • to add an AttributeWithExceptionsDef and InterfaceDef::create_
      attribute_with_exceptions and ValueDef::* operations.

    Whether the Interface Repository should be moved to a different module
    should be a separate discussion. I support the idea, but I don't think
    that the implementation should be forced to offer access to the IFR
    using both the CORBA:: and IR:: modules.
    Note that vendors could still offer the old interfaces in their imple-
    mentation.

  • Reported: CORBA 2.4.1 — Tue, 19 Dec 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problems with the Components Notification Event Interface

  • Key: CORBA26-62
  • Legacy Issue Number: 4081
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    The CCM standard indicates that all CCM Event functions will delegate to
    the container. Chapter 7 of the CCM Volume 1 further dictates the
    interface the container will provide to the component, called
    Components::Notification::Event, referred to as the "Event Interface"
    hereafter. This interface contains many problems and does not address
    all the required functionality. The problems are listed below:<p>

    • The create_channel() method returns an EventConsumerBase for the
      publisher to use to publish events to the channel. It is not possible
      for the Event Interface to construct a concrete EventConsumerBase,
      specifically the interface defined as
      <publishing_component>EventConsumers::
      <event_type>Consumer (per section 5.6.6 and 5.6.7 giving the
      publisher and emitter IDL expansion). The Event::obtain_channel()
      method has the same problem
    • The subscribe() method implies that the container supplying events
      will hold the supplier proxy that will be used to send events to the
      subscriber’s EventConsumerBase. This is an inefficient model. Also,
      this model is in direct conflict with the listen() method, which
      supports a more efficient model (see next bullet).
    • The standard does not provide any documentation on when a consumer
      would call the listen() method. The standard also does not provide a
      means for the consumer’s component to realise the "csmr_name", the
      name used to find the ConsumerAdmin from the Naming Service [see
      possibly related issue #3940]. Nor does the standard indicate when
      the ConsumerAdmin would have ever been added to the Naming Service.
      It might be possible that this would work for emitters, but it does
      not work for publishers (the standard dictates that a consumer cannot
      distinguish between being connected to an emitter or a publisher).
      This method does imply that the consuming component will have a proxy
      local to its container, separate from the publishing component’s
      container (contradictory to the subscribe() method, see previous
      bullet).
    • The push() method does not provide a means to indicate which channel
      the event should be pushed to see possibly related issue #3928.<p>

    The Event Interface is a local interface ­ that is, the client will
    never see this interface, and so it is possible to hide the use of this
    interface inside the generated code and thus replace the interface.
    Internally we have added a PortManager interface to be used in place of
    the Event Interface. This interface provides better management of the
    Event Channels and it also manages receptacle connections. Two
    interfaces will derive from the PortManager, a TransientPortManager and
    a PersistentPortManager. These two derived interfaces will permit
    connections between components to be managed as defined by the type of
    the container. Where meaningful, this permits the port connections to be
    made persistent as part of the overall state so that connections
    (specifically, notification channels) can be more reliably and robustly
    managed. The CCM2Context::get_event() operation is replaced by
    get_port_manager()

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 3937. rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Component home interface inheritance

  • Key: CORBA26-61
  • Legacy Issue Number: 4080
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    The definition of homes does not permit interface inheritance. It
    appears this is an oversight as the omission seems unreasonable and
    counter-intuitive, especially since homes must follow a parallel
    derivation hierarchy with their component types. I have found cases in
    which a home would expose the same interface as its component in which
    the home subsequently delegates to a specific component instance (even a
    persistent instance) however selected. (The component instance may or
    may not be hidden from the client.) Interfaces are a perfect mechanism
    whereby the operational signatures could be standardized, thus
    eliminating potential errors caused by changing one but not the other.
    This could be accomplished using a supports clause in the inheritance
    specification similar to that of valuetypes.

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Components, Facets, and Object References Unclear

  • Key: CORBA26-56
  • Legacy Issue Number: 4073
  • Status: closed  
  • Source: Anonymous
  • Summary:

    See the CORBA Components specification, orbos/99-07-01, chapters 5, 6,
    7, and 9. The semantics, life cycle, and mechanisms behind components,
    facets, "regular" objects, and their related object references is weakly
    specified. In particular, it is not clear how a component interacts
    with a container to generate an object reference to a facet, especially
    a facet in a secondary segment. The description of component
    identifiers indicates that the component object id, the facet number,
    and the segment number are used to generate the facet's object reference
    (or perhaps only the ObjectId), but the sequence of operations is not
    given. It appears that not all the necessary methods have been formally
    specified, nor are the code generation examples adequate for this
    siutation.

    Consider the following IDL:

    interface A {};
    component C

    { provides A a_facet; A get_another_A(); }

    ;

    What is the life-cycle of the A object returned as the provided facet?
    Is it limited to the life-cycle of the component? Is the member
    operation returning an object of the same type as a provided facet
    permitted? Should this return the same object as the facet? If not, is
    the life-cycle of this extra object limited to the life-cycle of the
    component? Should such objects be considered facets, even if not
    explicitly declared such (which, please note, provides the equivalent of
    the deprecated "provides multiple" capability)? What information needs
    to be encoded in its object reference, especially for component
    dependency? How will the context for this be established, and are any
    additional interfaces or operations required to accomplish this?

  • Reported: CORBA 2.4.1 — Tue, 21 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

New component issue: connection failure recovery

  • Key: CORBA26-55
  • Legacy Issue Number: 4025
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The CCM does not describe the behavior of the system in case of various fault situations. In particular, this issue only concerns itself with the recovery mechanisms of event subscriptions or facet receptacles that were automatically established through an assembly. While it is outside the scope of the CCM to describe general fault behavior, it is felt that recovery mechanisms (or their absence) should be explicitly identified for connections automatically built between ports. Otherwise, why go to the trouble of building them, since error detection and recovery wrappers would be needed around any use of them?

    The following scenario highlights the various situations. It assumes that the components are deployed in separate processes on different platforms so that one of the two components remains operational despite failure or inaccessibility of the other. The scenario primarily deals with the recovery of an interface provided by Component X and used by Component Y. Appropriate questions related to event channels are also given where applicable. Event channels are themselves more difficult because the notification services adds yet another object to the set that may fail during the scenario.

    Scenario: Component X declares that it provides an interface A. Likewise, Component Y declares that it uses interface A. (Or, X emits or publishes event A to which Y subscribes.) Instances of the components are combined through an assembly. Now, the assembly description indicates that a connection is to be built between X and Y. That is, the descriptor defines connections in which a connection element defines the association. Said element’s providesport acquires X’s facet A and assigns that through the usesport to Y’s interface receptacle. (For events, read these as emitsport or publishesport and subscribesport.)

    The following questions arise:

    When does the connection take place, during assembly construction or on reference to the port’s receptacle inside Y? That is, is this immediate or lazy initialization? When are event channels created or attached? Can the producer delay creation or attachment until a push() operation? Can the consumer accomplish the creation? Can an m:n emitter to consumer notification matrix be built? (The specification is unclear on this.)
    What happens if the interface reference to A cannot be acquired because (1) X has failed or is inaccessible, (2) X fails during the get operation, or (3) X returns a nil reference?
    What happens during run-time when Y invokes an operation on A and:
    The application server process containing X has terminated (COMM_FAILURE returned)?
    Derived valuetype arguments cannot be marshalled (MARSHALL/BAD_PARAM returned)?
    The underlying object supporting A in X has been deleted (INV_OBJREF returned)?
    An unexpected application error occurs (UNKNOWN returned)?
    With respect to error detection and recovery:
    How does one indicate the set of objects that can detect the error? Possible objects are Y, Y’s home, Y’s container, X’s container, X’s home, the assembly, an independent third party.
    How does one indicate the set of objects that can recover the error?
    How does one indicate whether the error should be detected?
    How does one indicate whether recovery should be attempted?
    How does one indicate the recovery strategy, especially if there are several objects that can recover the error?
    If the strategy has multiple fallback conditions, should this logic be placed into a single object or should it be given as a precedence-ordered list?
    Where should this information be specified: IDL, CIDL, or XML?
    What are the implications when the components have different type and container semantics?
    Let component X be transient and component Y be an entity. If component X fails, can a new X be safely created for its corresponding Y?
    Assume a new X was created and the old X still exists but became inaccessible. Can the old X be detected and one of the X’s be deleted [dismissed] after the old X is again accessible?
    Assume a request to X completes successfully in X but fails during the reply to Y. Can the operation be retried or the previous results retransmitted, either on the old X after recovery or on a new X?
    In these questions, what happens if X is an entity and Y is transient?
    In these questions, what happens if Y aborts rather than X?

    Ideally, it would be nice if either the IDL extensions or the CIDL constructions permitted specification of an error recovery wrapper around access to a receptacle (or event channel). This could actually work as a general mechanism for any component and not just components grouped in an assembly. The wrapper would be a specialized object implemented specifically in the context of the component or assembly that provided the desired error detection and recovery behavior. It would be a proxy similar to a stub: it would have the same interface as the target object to which it delegates. Errors would be caught (as described) and recovered automatically, if possible. This includes the initial reference to an object, which would now be built or acquired dynamically at run-time rather than semi-statically at assembly instantiation. Multiple inheritance, in languages that support it, would be very useful in standardizing proxy behavior. The component DTD could be used to specify desirable run-time operation and associated characteristics.

  • Reported: CORBA 2.4.1 — Tue, 7 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Components FTF: TypeCodeFactory

  • Key: CORBA26-65
  • Legacy Issue Number: 4140
  • Status: closed  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    The third part of the adopted CCM submission (orbos/99-07-03)
    moves all the create_..._tc operations from the ORB interface
    to a new PIDL interface, CORBA::TypeCodeFactory.

    This change breaks source-compatibility: source code that creates
    typecodes with a pre-CORBA 3.0 ORB will need to be updated to use
    a CORBA 3.0 ORB with such a TypeCodeFactory interface.

    And there is no clear benefit from this update:

    • ORB is still PIDL – it even creates an additional PIDL
      interface.
    • type code kinds are not more extensible (TCKind is still an
      enum)

    I suggest to undo this update, i.e. keep the create_..._tc
    operations on the CORBA::ORB interface.

  • Reported: CORBA 2.4.1 — Tue, 9 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ComponentIR Interface fixes

  • Key: CORBA26-64
  • Legacy Issue Number: 4136
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    While reviewing the ComponentIR interfaces in 00-11-01, I have found
    some problems with it. (These are unrelated to the current discussion
    about the Interface Repository itself.)

    Many interfaces inherit Contained::describe(), which is supposed to
    return information about the element. In the basic IFR, this data is
    designed to contain all possible information about that type. This
    is very convenient, since then a map mapping RepositoryIds to
    Contained::Description contains all of the IFR's information.

    By referring to InterfaceDefs rather than RepositoryIds, the client
    will need to store that association elsewhere, or repeatedly invoke
    the Interface Repository.

    Suggested resolution:

    • In ProvidesDescription, replace
      InterfaceDef interface_type
      with
      RepositoryId interface_type
    • Ditto for UsesDescription
    • In EventDescription, replace
      ValueDef event
      with
      RepositoryId event
    • In ComponentDescription, replace
      ProvidesDefSeq provides_interfaces
      UsesDefSeq uses_interfaces
      EmitsDefSeq emits_events
      PublishesDefSeq publishes_events
      ConsumesDefSeq consumes_events
      with
      ProvidesDescriptionSeq provides_interfaces
      UsesDescriptionSeq uses_interfaces
      EmitsDescriptionSeq emits_events
      PublishesDescriptionSeq publishes_events
      ConsumesDescriptionSeq consumes_events
    • In PrimaryKeyDescription, replace
      ValueDef primary_key
      with
      RepositoryId primary_key
    • In HomeDescription, replace
      PrimaryKeyDef primary_key_def
      FactoryDefSeq factories
      FinderDefSeq finders
      with
      PrimaryKeyDescription primary_key
      OpDescriptionSeq factories
      OpDescriptionSeq finders

    Next, all parts of the "basic" Interface Repository are mutable, but
    most attributes of the Components interfaces are declared as readonly.
    I propose to remove the readonly modifier from

    • ProvidesDef::interface_type
    • UsesDef::interface_type
    • UsesDef::is_multiple
    • EventDef::event
    • ComponentDef::supported_interfaces
    • ComponentDef::base_component
    • ComponentDef::provides_interfaces
    • ComponentDef::uses_interfaces
    • ComponentDef::emits_events
    • ComponentDef::publishes_events
    • ComponentDef::consumes_events
    • PrimaryKeyDef::primary_key
    • HomeDef::base_home
    • HomeDef::managed_component
    • HomeDef::primary_key
    • HomeDef::factories
    • HomeDef::finders

    Last but not least, there seems to be some confusion about Primary Keys.
    When a Home is created with Repository::create_home, a ValueDef should
    be passed, while the terminology seems to dictate a PrimaryKeyDef instead.
    You can get a PrimaryKeyDef using HomeDef::create_primary_key, but that
    would be a chicken-egg scenario.

    Proposed resolution:

    • Change the ValueDef in Repository::create_home to PrimaryKeyDef
    • Move the create_primary_key() operation from HomeDef to Repository
  • Reported: CORBA 2.4.1 — Fri, 5 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Component assemblies do not follow composition pattern

  • Key: CORBA26-58
  • Legacy Issue Number: 4077
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    I have noticed that assemblies do not follow the composition pattern.
    Thus, assemblies cannot themselves be used as building blocks for other
    assemblies. I think part of this comes from the fact that installation
    and management of assemblies is mostly "magic" done behind the scenes by
    various installation and support utilities. In order to "reuse" an
    existing assembly, one must copy an existing assembly definition (I
    guess constructed completely by hand) to a new definition, which must
    then be tailored to incorporate the new strategy and pieces. This seems
    counter-intuitive, besides being manually intensive, for if an assembly
    does useful work, why would I want to expose its internal details just
    to take advantage of that usefulness? As pointed out by Mr. Dubois in
    issue 3939, because all of that "magic" is not specified by various
    formal interfaces, it is highly likely approaching certainty that
    assemblies will only work for the particular vendor on which they were
    built. Since I believe the intention was to promote interoperability in
    general and as much code automation as possible for components in
    particular, it would seem that we want to restrict the "magic" by taking
    the formalisms behind assemblies to another level.<p>

    I suggest that, just as a <i>composition</i> exists to tie a component,
    its home, and various configuration properties together, we can create
    for the CIDL grammar productions for an <i>assembly</i> to tie multiple
    compositions together. Subsequently, an assembly could be treated as a
    composition, to be used by other assemblies, only exposing selected
    facets or events from its constituent entities. I think there are a
    number of advantages to this approach: (1) It solves certain semantic
    ambiguities with assemblies, for instance whether facets, receptacles,
    and events are private or public to the assembly. (2) The assembly
    implementation, its XML, and its relation to its constituents and home,
    can be generated automatically from the CIDL description [we have been
    working on this extensively]. Our approach is to use an assembly
    exactly like a composition, as the realization of a component and home
    definition. Our research efforts imply that all of the assembly
    component and home code can be automatically generated - no user
    tailoring will be needed. (3) Because the assembly now acts as a
    component (composition), it can be reused by other assemblies without
    knowledge of its internal structure. (4) Activation of an assembly
    appears the same as for any other component; it merely requires formal
    specification of previously undefined interfaces to accomplish it, thus
    promoting portability and interoperability. (5) The assembly
    "deployment magic" becomes exposed through the interfaces above, thus
    removing several of the deployment tools and servers/services identified
    in the specification. The only real drawbacks I see are the complexity of the assembly
    productions (we can really get out of control with this) and that
    assemblies now have an actual code base rather than being "magical
    creatures" managed by the deployment tools. I guess these are both
    two-edged swords. There might be a run-time footprint change for all of
    these extra interfaces, but those had to be lying around in other places
    anyway.

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inter-component type semantics unclear

  • Key: CORBA26-57
  • Legacy Issue Number: 4075
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    The semantics of components of a particular type (session, entity)
    residing in a compatible container type that access components of a
    different type residing in a corresponding but different compatible
    container type are unclear. Are there any expected or preferred
    combinations? Are any disallowed or discouraged? See, for example, the
    discussion under issue 4025 on automated recovery. In his replies, Mr.
    Dubois seems to assume that entity components create transient (service
    or session) components but not the reverse. In the telecommunications
    domain, however, a session object may share access to an entity, and
    then create additional entities based on external events, even though
    the session itself is not persistent. Could someone please articulate
    the possibilities and their utility (or lack thereof)?

  • Reported: CORBA 2.4.1 — Wed, 22 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in assembly element paragraph heading

  • Key: CORBA26-54
  • Legacy Issue Number: 4024
  • Status: closed  
  • Source: Anonymous
  • Summary:

    See the CORBA Components Model specification, orbos/99-07-01, paragraph
    10.6.2.52, page 10-365. See also the DTD appendices document, orbos/99-08-05.

    The title of this paragraph heading is incorrect. The element is "usesport",
    not "usingcomponent". It has occasionally been hard to find the description
    because of this textual error.

  • Reported: CORBA 2.4.1 — Tue, 7 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

grammar rule for home_executor_body contradicts description

  • Key: CORBA26-53
  • Legacy Issue Number: 4011
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In ptc/99-10-04 on page 15 the grammar rule of home_executor_body in chapter
    60.7 "Home Executor Definition" contains bars implying alternatives. These
    bars have to be removed to match the subsequent description.

  • Reported: CORBA 2.4 — Wed, 1 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No Access to event filter form component

  • Key: CORBA26-52
  • Legacy Issue Number: 3998
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    As the CCM spec is not giving any mean (or very little) to fill in the
    filterable body part, no services are provided for a component to set its
    event filters when sending or receiving events.

    This seems to be a very usefull service to me for application such as:

    • limiting the number of events emitted by a component based on a config
      parameter (like messages with priority > config value can go out, other are
      discarded. when the config value change at runtime the filter could also
      change.
    • filtering events received from a notification channel.

    I agree that these 2 function could be achieve by user code in the component
    but it means that unecessary events are passed between components and the
    netwok load and CPU load is higher than necessary.

    I guess the point I am trying to make is that using the notification service
    without using filters and/or filterable body doesn't seem to make a lot of
    sense.

    What is the intend of the sepc on this issue?

  • Reported: CORBA 2.4 — Wed, 25 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 3938. rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Component home polymorphism

  • Key: CORBA26-60
  • Legacy Issue Number: 4079
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    See the CORBA Component Specification, orbos/99-07-01, and Persistent
    State Service issue #4074. Is there any reason why homes cannot support
    (manage) multiple component types? This seems like a perfect case for
    polymorphism; the only time you really need a new home type is when you
    change the behavior or have some other incompatibility. Is it possible
    to do instances of homes, one per component type (perhaps instances of
    components acting as managers for other components)? I simply do not
    understand why these are one-to-one with parallel but distinct
    derivations. I realize the requirements were to maximize code
    generation, but I don't see that this is a conflict.

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Component assembly templates

  • Key: CORBA26-59
  • Legacy Issue Number: 4078
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    In a complex distributed environment, the implementation of highly
    available and highly reliable services requires redundant placement of
    software components in all their manifestations. Assemblies provide a
    nice, convenient way of specifying the deployment and activation of
    components and the connections that relate them for a particular
    purpose. Now, for various reasons and Fault Tolerant CORBA
    notwithstanding, in corporate reality this sequence and specification
    will occur in multiple places in basically identical fashion. About the
    only thing that changes are the host names and their network addresses;
    everything else from the hardware configuration to the size of the disk
    drives and file systems is (and inherently must be) exactly the same
    among all deployments. This, for example, is one technique to support
    geographic site failover.

    My question is, has anyone thought of a two or more stage XML process,
    one in which the package or assembly composition and deployment XML is
    specified as a template or configurable, parameterized entity, and
    another where the parameters have been substituted for "finalization"?
    This can occur at two distinct points in the life-cycle: one set of
    substitutions occurring when an artifact is deployed (installed?) on the
    various computer systems involved, and another when the home [and
    possibly individual instances] of the artifacts are activated
    (instantiated?) to run on those computer systems. My work in the
    telecom and defense industries has show that deployment of anything is
    rarely a singleton event; there are always redundancies, replications,
    and backups to take into account. Templates seem to provide a nice
    solution to all of the manual editing required.

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CCM : Session2Context naming

  • Key: CORBA26-67
  • Legacy Issue Number: 4204
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Is there any reason to name the context interface for extended session
    components as Session2Context in module Components::Extended? Why not simply
    SessionContext like in the Basic module?

  • Reported: CORBA 2.4.2 — Fri, 16 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CCM : Session2Context and Servants

  • Key: CORBA26-66
  • Legacy Issue Number: 4203
  • Status: closed  
  • Source: Anonymous
  • Summary:

    How to activate servants by only using the Session2Context interface from
    the Extended module? It only offers operations to create references like
    create_ref() and create_ref_from_id() similar to those from the POA but no
    means to activate servants are available in the whole container API!

  • Reported: CORBA 2.4.2 — Fri, 16 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No user access to filterable body in CCM spec.

  • Key: CORBA26-51
  • Legacy Issue Number: 3997
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    The CCM spec seems to have make the choice to prevent the component
    implementor to fill in the filterable body part of a structured event sent
    to the a notification channel.

    What are the reasons of this choice?

    2 remarks:

    • The filtrable body part of a structured event seems to be the most usefull
      part of the event. Not using it (or leaving it to the container to fill in
      from obscure sources) doesn't seem to make a lot of sense.
    • Other standard bodies (like T1M1.5) are using the filterable body part of
      the event and are making the remainder of the boby (where the EventBase
      derived value type should be put) optional and unnecessary.

    Any comment/explanation of the choice is welcome.

  • Reported: CORBA 2.4 — Wed, 25 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 3938. rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL question concerning CCM

  • Key: CORBA26-50
  • Legacy Issue Number: 3996
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I have the following question (problem). The Corba Component Model Spec
    (volume 1) defines the following :
    module CORBA_3 {
    module Components {
    interface Events

    { ... }

    ;
    ...
    module Events

    { ... }

    ;
    };
    };

    So the word 'Events' is used for defining an interface and a module!! Is
    this correct IDL, because ther JavaORB idl-compiler nor the ORBACUS
    idl-compiler is able to compile such idl.

  • Reported: CORBA 2.4 — Sat, 21 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CCM Events issue

  • Key: CORBA26-49
  • Legacy Issue Number: 3993
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I was researching the CCM Event Corba 3 to Corba 2.3 mappings in
    chapter 5 of Volume I, and found that the resulting interfaces did not
    permit a consumer to subscribe to a publisher because the interface
    type returned by the get_consumer_<name>() does not match the
    subscribe_<name)() parameter. I am not sure if I made a mistake when
    mapping the 3.0 to 2.3 idl or if it is a problem in the standard. I
    also provide an alternative that might work, though I'm sure it will
    need some work.

  • Reported: CORBA 2.4 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    Resolved by reference/clarification to 3746

  • Updated: Fri, 6 Mar 2015 20:58 GMT

typo in connections element definition

  • Key: CORBA26-48
  • Legacy Issue Number: 3987
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    in 99-08-05 the componentassembly DTD has a typo in the "connections"
    element definition. "connecthome" should be spelled "connecthomes"

    <!ELEMENT connections
    ( connectinterface

    connectevent
    connecthomes
    extension
    )* >
  • Reported: CORBA 2.4 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Deployment Object Life Cycles

  • Key: CORBA26-45
  • Legacy Issue Number: 3982
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The description of the life cycle and system dynamics of the various
    objects that contribute to component deployment and execution is
    incomplete. From an implementation perspective, there are many run-time
    objects involved that contribute to, or are required for, the overall
    operation of a component. But the CCM does not adequately show the
    interrelationships among such objects. Even the most rudimentary
    implementation depends on the assumptions hidden behind these
    interrelationships.

    The following questions need to be addressed in order to build a
    portable implementation:

    1. Deployment support services:

    • What is the life cycle of the support services needed to create an
      Assembly object?
    • Do these already need to be executing in, known to, or exposed by one
      or more servers?
    • How are these services contacted in a dynamic environment?
    • Is this structure equivalent to the TINA DPE concepts?
    • What is the life cycle of the Assembly object itself?
    • When and how is an Assembly object deleted?

    2. Application servers, containers, homes, components:

    • What is the exact life cycle of these various objects?
    • The specification identifies how component instances are created. How
      are they deleted?
    • When and how is a home removed from a container?
    • When and how is a container removed from an application server?
    • When and how is an application server terminated?

    3. Related or referenced objects:

    • What is the life cycle of event channels?
    • Does the life cycle of objects vary if they are "private" to an
      assembly?
    • When and how are event subscriptions released from their publisher or
      emitter?
    • When and how are objects "registered" with the naming service or
      trader unregistered?

    A full and representative life cycle description of the run-time objects
    denoted above is necessary to understand the dynamic system model and
    its inherent limitations. This will be critical for systems that must
    exhibit very high reliability and availability. There appear to be many
    assumptions, particularly with respect to the deployment tools, that
    affect recovery operations from fault conditions. These must all be made
    explicit. Thus, the CCM description should include a comprehensive state
    transition model. This may be documented as cooperating or nested state
    machines for the various pieces.

  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Services available for a basic container

  • Key: CORBA26-44
  • Legacy Issue Number: 3977
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The CCM describes the services available for a basic container as being
    one of two sets: security, transactions, and naming or security,
    transactions, and persistence. Could someone please describe the exact
    services available to basic containers and the particular semantics for
    each? Are these differences related to one set for the component home
    and the second set for the instance?

  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

push() versus push_event()

  • Key: CORBA26-43
  • Legacy Issue Number: 3955
  • Status: closed  
  • Source: Anonymous
  • Summary:

    See the CORBA Components Model specification, orbos/99-07-01, section
    5.6, pages 5-84 through 5-89, approximately.
    Could someone clarify the push() and push_event() operations, their
    purposes, and their interaction, if any. There is no description
    whatsoever of the relationship between the push() and push_event()
    operations, even though push_event() is declared in the
    inherited Components::EventConsumerBase. The producing component
    invokes its push() operation, which then performs any peculiar
    formatting to the event before transmission to the underlying channel
    through its container. It is unclear when, if ever, the push_event()
    operation will be invoked. A text search of the document reveals the
    operation appears only in the interface definition and its immediate
    descriptive paragraphs.

    Would a better model be to use push_event() as the interface to and from
    the container? (Perhaps this should be independent operations,
    produce_event() and consume_event()?) On the producer side, let push()
    perform any component specific formatting of the event before passing
    the [now modified] event on to push_event(). This latter interacts with
    the container to send the event to the event channel, as
    described. (Most push() implementations will do nothing to the event.
    This could be provided as a default generated implementation.) On the
    consumer side, push_event() will be invoked by the container as part of
    event delivery. The push_event() operation performs type checks, as
    described, before it invokes the consumer agent’s push() operation. This
    process correctly handles the semantics and permits suitable places to
    intercept or override event processing.

  • Reported: CORBA 2.4 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

An assembly is always mono-vendor ???

  • Key: CORBA26-41
  • Legacy Issue Number: 3939
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    Because the interfaces between the Assembly and the
    container/componentServer/servantActivator is not defined, these ones have
    to be vendor specific.

    Because the ExecutorSegmentBase and the HomeExecutorBase are not specified a
    component is always container specific.

    As a result an assembly provided by one vendor can only speak to
    container/componentServer/servantActivator provided by the same vendor and
    the container can only run (even in Java???) components that have
    specifically ported to it.

    The conclusion is that it is not possble to build an asembly that combine
    components build on different CCM platform. All of the component have to be
    ported to a single CCM platform.

    Is it what is intended?

  • Reported: CORBA 2.4 — Thu, 5 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Intent of Components::Events::(un)subscribe to bypass the notif. service ?

  • Key: CORBA26-40
  • Legacy Issue Number: 3938
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    a component wants to publish an event. So, it calls
    Components::Notification::Event::create_channel(). The container contact the
    (remote) Notification service, create a dedicated channel, connect to it and
    return an EventConsumerBase to be used by the component to push any event to
    the channel. Each time the push() method is called on the EventConsumerBase
    it will create a structured_event and push it to the notification channel.

    Now, another component (in another container/memory space/system) wants to
    receive these events. So it calls Components::Event::subscribe() on the
    first component passing a reference to an EventConsumerBase. The component
    internally calls Components::Notification::Event::subscribe() passing the
    remote EventConsumerBase reference. So now the container has to create a
    (local) strutured_push_consumer and connect it to the channel it has
    created. By doing this any event that it send to the channel will be bounced
    back to it so that it can then push them to the (remote) EventConsumerBase
    that have subscribed to the publish port.

    This scenario doesn't seem right to me because the notification service is
    then useless as all events are bounced back to the publisher. The container
    could just call the push() method on each registered EventConsumerBase.

    What seems to be really needed is a way to pass the reference to the
    NotificationAdmin back to the second component so that the second component
    can then subscribe through its own container to the Notification channel.

    Another possiblity would be that the subscribe call accept a (remote)
    strutured_push_consumer as parameter instead of the EventConsumerBase.

    The last solution is that the publisher port is not designed to work with
    the notification service but on its own.

    I am certaimly missing something!!!!!

    Could you explain how it is supposed to work?

  • Reported: CORBA 2.4 — Thu, 5 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected, see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Channel Setup for Emits ports.

  • Key: CORBA26-39
  • Legacy Issue Number: 3937
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    I found 2 (possibly) contradictory statement in 99-10-04 for "emits" ports.

    1) in 62.4.1.2 The Event Interface

    EventConsumerBase obtain_channel (in string supp_name, in EventHeader hdr)
    raises (InvalidName);

    The obtain_channel operation is used by the component to obtain an
    EventConsumerBase which it can use to push events. This operation
    corresponds to an emits declaration in component IDL. The supp_name string
    identifies an Interoperable Naming Service (INS) name which is used to
    identify the SupplierAdmin to be used by CORBA notification. The name is
    associated with the SupplierAdmin thorough container specific configuration
    data. The obtain_channel operation may optionally specify the EventHeader
    required by CORBA notification which will be used for all events pushed to
    this channel. If hdr is present, it is prefixed to all events pushed to this
    channel. If not, it is defaulted as described in Section 66.4, "Event
    Management Integration," on page 66-252. If the supp_name is not recognized,
    the InvalidName exception shall be raised.

    2) in 66.4.2 Transmitting an event

    . channel lookup - for emitted events, this is the channel configured for
    general use at container start-up, for published events, this is the channel
    established by the container for the purpose of pushing this event type.

    Section 62.4.1.2 seems to imply that there can be a different event channels
    for each emit port while 66.4.2 seems to imply that there is only one event
    channel shared by all emits ports.

    What means "general use"?

    What is the truth/intent?.

    Could you make things clear?

    I certainly preffer 1)

  • Reported: CORBA 2.4 — Thu, 5 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

exception raised by Components::Events::subscribe()

  • Key: CORBA26-38
  • Legacy Issue Number: 3930
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    The exception raised by Components::Events::subscribe() doesn't include the
    Components::ExceededConnectionLimit exception raised by the
    subscribe_source_name() 2.3 equivalent interface.

    It should be added.

  • Reported: CORBA 2.4 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExecutablePlacement definition

  • Key: CORBA26-37
  • Legacy Issue Number: 3929
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    In the componentAssembly DTD the executablePlacement is defined as follow:

    <!ELEMENT executableplacement
    ( usagename?
    , componentfileref
    , componentimplref
    , invocation?
    , destination?
    , extension*
    )>
    <!ATTLIST executableplacement
    id ID #REQUIRED
    cardinality CDATA "1" >

    It seems to me that the DTD should not enforce the componentimplref as this
    might depend on the deployment And there is no reason the assembler should
    know where the executable is going to be deployed. For example the
    componentimplref should be different between a Solaris, a Linux or an NT
    placement.

    Therefore I would propose to make componentimplref optional (as it is in
    homePlacement) and change the executablePlacement definition to:

    <!ELEMENT executableplacement
    ( usagename?
    , componentfileref
    , componentimplref?
    , invocation?
    , destination?
    , extension*
    )>
    <!ATTLIST executableplacement
    id ID #REQUIRED
    cardinality CDATA "1" >

  • Reported: CORBA 2.4 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Local push() operation.

  • Key: CORBA26-36
  • Legacy Issue Number: 3928
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    When the component implementor wants to emits an event it has to use the
    push() operation from the local Event interface.

    It is not clear how the container will manage to discriminate the event and
    select the channel this event need to be send to.

    Nothing prevent a component to define several publisher and several emitters
    and nothing force the events to be of different types on all of these
    channels.

    So either the spec is not clear enough on this process or the local push
    method is missing some a parameter (like the emitter/publisher port name) to
    help the container do his job.

  • Reported: CORBA 2.4 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

repository element needed by softpkg DTD

  • Key: CORBA26-47
  • Legacy Issue Number: 3986
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    in 99-08-05 the softpkg DTD is missing the "repository" element
    specification. It could be copied from corbacomponent DTD.

    <!ELEMENT repository
    ( ins

    objref
    link
    ) >
    <!ATTLIST repository
    type CDATA #IMPLIED >
  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

description element need to be added to corbacomponent.dtd

  • Key: CORBA26-46
  • Legacy Issue Number: 3985
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    in 99-08-05, the corbacomponent DTD is missing the "description" element
    specification. It should be the same as the other DTDs and can be copied
    from them

    <!ELEMENT description ( #PCDATA ) >

  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

equivalent interfaces issue

  • Key: CORBA26-42
  • Legacy Issue Number: 3954
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The equivalent interfaces as described within the document result in type mismatches when code is built to implement the functions generated from the CIDL component specification. That is, you cannot assign a consumer to a subscriber because the interfaces are parallel derivations and not an inheritance compatible derivations. The code prototypes must be changed to overcome this problem. We have tried three different approaches, but the one that seems to work best has the most impact to the IDL revisions.

  • Reported: CORBA 2.4 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    Resolved by reference/clarification to 3746/ duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Urgent issue: Alignment of LocateReply body

  • Key: CORBA25-53
  • Legacy Issue Number: 4314
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    In CORBA 2.3, a GIOP 1.2 LocateReply message made no requirements as to
    the alignment of the LocateReply body. This meant that the LocateReply
    body needed to be aligned only on a 4-byte boundary. With the resolution
    for issue 2521, published with CORBA 2.4, the spec was changed to require
    alignment of the LocateReply body on an 8-byte boundary.

    The change is incompatible with the CORBA 2.3 definition because the receiver
    must know where to look for the ReplyBody in the the byte stream following
    the message header. (The LocateReply header is 12 bytes long, so changing
    the alignment rules means that the LocateReply body has to start at offset 12
    for CORBA 2.3, but has to start at offset 16 for CORBA 2.4.)

    The change in alignment did not result in a version change of GIOP,
    despite the incompatibility, so it appears that the change is simply illegal.

    There are already deployed products that use the CORBA 2.3 alignment
    rule; therefore, we cannot deploy a CORBA 2.4 compliant product without
    breaking interoperability with already deployed CORBA 2.3 compliant products.

    So, I'd like to request that we back out the change and continue to
    permit a LocateReply body to be aligned on a 4-byte boundary. There was
    never any need to change the alignment of the LocateReply body anyway because
    a LocateReply header has fixed length and, therefore, cannot ever cause
    remarshaling of the body due to a size change in the header. In other
    words, the motivation quoted in the spec for the 8-byte alignment rule
    isn't founded on fact, and the change should never have been made in the first
    place. (See issue 4309 for details.)

  • Reported: CORBA 2.4.2 — Thu, 17 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect table in section 15.4

  • Key: CORBA25-52
  • Legacy Issue Number: 4311
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The table on page 15-31 (Table 15-3 "GIOP Message Types and Originators")
    is in error. For CloseConnection, it shows that only the server can
    send this message but, in GIOP 1.2, either client or server can send
    the message, as detailed in 15.5.1 and 15.4.7.

    Also. in 15.4.7, we have:

    In GIOP version 1.2 both sides of the connection may send
    the CloseConnection message.

    That should be "must", not "may".

  • Reported: CORBA 2.4.2 — Thu, 17 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 15-2 is missing entry for tk_local_interface

  • Key: CORBA25-48
  • Legacy Issue Number: 4242
  • Status: closed  
  • Source: Floorboard Software ( Yvonne Biggar)
  • Summary:

    Add the missing entry with the same information as tk_objref.

  • Reported: CORBA 2.4.2 — Tue, 27 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    add the missing table entry with the same information as tk_objref

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GIOP 1.2 AddressingDisposition processing on the client side

  • Key: CORBA25-47
  • Legacy Issue Number: 4213
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    If the server ORB sends back a NEEDS_ADDRESSING_MODE reply to the client indicating the prefered
    addressing disposition, then is the client ORB required to 'cache' the prefered addressing
    disposition per object reference, and use it for further requests to the server ?

  • Reported: CORBA 2.4.2 — Wed, 28 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    to close without revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fixed point marshalling

  • Key: CORBA25-46
  • Legacy Issue Number: 4198
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    I have a query about the intended marshalling format for Fixed. Is the
    sending ORB always required to transmit the number of digits specified
    in the IDL, or is it permitted to transmit fewer if there are leading
    zeros?

    Consider transmitting 123.45 as fixed<6,2>. Is the ORB permitted to
    transmit

    12 34 5c

    or must it send the leading zero (plus another zero to pad the first
    octet):

    00 12 34 5c

    In both cases, the receiving ORB knows it is expecting a scale of 2,
    and the sign half-octet tells it where the digits end, so it can
    correctly unmarshal the value as 123.45.

    The discussion of issue 3431 suggests that the first option is not
    permitted, and leading zeros must always be sent. However, the 2.4
    GIOP spec makes no mention of how many digits should be sent. The
    specification should be clarified to either explicitly permit or
    explicitly forbid stripping of leading zeros.

  • Reported: CORBA 2.4.2 — Wed, 7 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Close with clarification revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Null termination of strings

  • Key: CORBA25-45
  • Legacy Issue Number: 4113
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Section 15.3.2.7 of the CORBA 2.3 spec, which describes the CDR encoding
    of strings, includes the following sentence in the first paragraph:

    "Both the string length and contents include a terminating null."

    It is not clear from this whether exactly one terminating null is required,
    or whether more than one null can be included, with the string being terminated
    by the first null.

    Since IDL strings cannot include nulls (see 3.10.3.2: "OMG IDL defines the string
    type string consisting of all possible 8-bit quantities except null"), any
    additional nulls following the first terminating null cannot be part of the
    string, and it therefore seems reasonable to ignore them.

    Proposed Resolution:

    Change the above sentence in section 15.3.2.7 to:

    "Both the string length and contents include at least one terminating null."

    Also make the same change to the corresponding sentence in the third paragraph
    of section 15.3.2.7 describing GIOP 1.1 wide strings.

  • Reported: CORBA 2.4.1 — Fri, 8 Dec 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    To close with clarification revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect text in 15.4.6.2

  • Key: CORBA25-51
  • Legacy Issue Number: 4309
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    15.4.6.2, "LocateReplyBody" says:

    In GIOP version 1.0 and 1.1, Locate reply bodies are marshaled into
    the CDR encapsulation of the containing Message immediately following
    the Reply Header. In GIOP version 1.2, the Reply Body is always
    aligned on an 8-octet boundary. The fact that GIOP specifies the
    maximum alignment for any primitive type is 8 guarantees that
    the ReplyBody will not require remarshaling if the Locate Reply
    Header are modified.

    The final sentence doesn't make sense because the LocateReply header is
    a fixed-length header and therefore can't possibly cause remarshalling.

    I suggest to delete the final sentence of this para.

  • Reported: CORBA 2.4.2 — Wed, 16 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see resolution of Urgent Issue 4314

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GIOP 1.1 Fragment problem

  • Key: CORBA25-50
  • Legacy Issue Number: 4299
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There is nothing in the specification that explicitly states whether the
    data in the body of a GIOP 1.1 Fragment message is marshalled relative
    to the Fragment header or relative to the unfragmented message as a
    whole.

    The restriction in GIOP 1.2 that all fragments but the last must have a
    multiple of 8 bytes, and the careful padding of the GIOP 1.2 Fragment
    header to 16 bytes both strongly suggest that GIOP 1.1 fragments should
    be marshalled only relative to the fragment header.

    Proposed Resolution:

    In section 15.4.9, right after the paragraph that reads:

    "A primitive data type of 8 bytes or smaller should never be broken
    across two
    fragments."

    add the following paragraph:

    In GIOP 1.1, the data in a fragment is marshalled with alignment
    relative to its position in the fragment, not relative to its position
    in the whole unfragmented message.

  • Reported: CORBA 2.4.2 — Fri, 11 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Accept proposal above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

tk_indirect

  • Key: CORBA25-49
  • Legacy Issue Number: 4294
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    I don't understand why tk_indirect isn't allowed as a top-level typecode.
    This causes servere performance penalties for RMI-IIOP because the Java to IDL
    mapping requires that Java objects of declared type java.lang.Object are
    marshalled as CORBA anys. In the case of a Vector or HashTable with 100
    elements, this means that 100 anys must be marshalled. If all of these are
    of actual type foo, the restriction on tk_indirect means that all 100 of
    these data values must repeat the typeCode for foo, which could be very large.
    This causes very substantial overheads, since the space and time needed to
    marshal the TypeCode for foo can greatly exceed that needed to marshal the
    data for foo.

    I understand why a nested tk_indirect cannot refer to any TypeCode outside
    the scope of its enclosing top-level TypeCode. However, I don't think this
    restriction needs to apply to a top-level TypeCode. We have made this
    change experimentally without any adverse effects and we have discovered that
    using tk_indirect for all the top-level foo TypeCodes after the first one can
    speed up some common scenarios by at least a factor of 5 on end-to-end
    measurements. There seems to be no downside to making this change.

    I would therefore like to propose the following change to the section headed
    "Indirection: Recursive and Repeated TypeCodes" within section 15.3.5.1:

    Change the first bullet from:

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

    by the following words:

    The indirection applies only to TypeCodes nested within some “top-level”
    TypeCode, or from one top-level TypeCode to another. Indirected TypeCodes
    nested within a top-level TypeCode can only reference TypeCodes that are part
    of the same top-level TypeCode, including the top-level TypeCode itself.
    Indirected top-level TypeCodes can reference other top-level TypeCodes but
    cannot reference TypeCodes nested within some other top-level TypeCode.

    If this change finds favour, then we need to work out how it can be brought
    into GIOP without causing problems interoperating with older ORBs that insist
    on the stronger restriction of the current spec. This could perhaps be
    added to the "wish list" for GIOP 1.3.

  • Reported: CORBA 2.4.2 — Fri, 4 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Close this issue and add it to the GIOP wish list

  • Updated: Fri, 6 Mar 2015 20:58 GMT

operation get_implementation() referenced but not declared

  • Key: CORBA26-32
  • Legacy Issue Number: 3785
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CPP 1.1 — Thu, 17 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    Duplicate, close

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pbl: Improper mapping rule from IDL3 to IDL2 when dealing with events.

  • Key: CORBA26-31
  • Legacy Issue Number: 3746
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

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

    module example {
    valuetype AnEvent : Components::EventBase

    { public string value; }

    ;

    component Producer

    { publishes AnEvent output; }

    ;

    component Consumer

    { consumes AnEvent input; }

    ;
    };

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

    interface Producer : Components::CCMObject

    { Components::Cookie subscribe_output(in ::example::ProducerEventConsumers::AnEventConsumer consumer) raises (Components::ExceededConnectionLimit); }

    ;

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

    interface Consumer : Components::CCMObject {

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

    };

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

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

    p.subscribe_output(c.get_consumer_input());

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

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

  • Reported: CPP 1.1 — Tue, 18 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue on Assemblies and descriptors

  • Key: CORBA26-30
  • Legacy Issue Number: 3726
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

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

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

  • Reported: CPP 1.1 — Mon, 26 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What about valuetype factories?

  • Key: CORBA26-33
  • Legacy Issue Number: 3786
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

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

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

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

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

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

  • Reported: CPP 1.1 — Thu, 24 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

simple ELEMENT definition

  • Key: CORBA26-35
  • Legacy Issue Number: 3926
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    I have a question about the property.dtd file provided with the CCM spec.

    in this file "simple" is described as follow:

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , defaultvalue?
    ) >

    This seems to indicate that a "simple" element has to have a value in the
    file. Therefore it is not clear how usefull is the optional "defaultvalue"
    field. It also means that if the component or assembly provider wants to
    provide the CPF files with the CCD and CAD files it has to put values into
    them instead of just setting the default value. Obviously the best thing to
    do would be to repeat the default value into the value but it seems strange
    to me. The point is that if there is a default value provided the value
    doesn't seem to be mandatory.

    Also, in a way similar to the CAD file, where placement information are
    added at deployment time, we may want to enable the component/assembly
    provider to provide CPF skeleton files together with the CCD files and
    skeleton CAD files. In this case the "simple" element may not contain any
    "value".

    I propose to replace this definition with:

    <!ELEMENT simple
    ( description?
    , value?
    , choices?
    , defaultvalue?
    ) >

    Any thought

  • Reported: CORBA 2.4 — Mon, 2 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

range description in CPF files.

  • Key: CORBA26-34
  • Legacy Issue Number: 3925
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    The definition for "choices" is as follow in the properties.dtd file:

    <!ELEMENT choice ( #PCDATA ) >
    <!ELEMENT choices ( choice+ )

    knowing that the PCDATA for choice is supposed to hold one possible value
    for the "simple" if I am right

    I believe this is missing a bit of descriptive power. In case you want to
    specify a range of 100 values you will have to give the 100 different values
    each in its own "choice" element. It is very verbose !!!

    We could add a range ELEMENT to the DTD as follow:

    <!ELEMENT range (value, value)>

    We could then change the choices ELEMENT as follow:

    <!ELEMENT choices ( range | choice )+>

    Any thought.

  • Reported: CORBA 2.4 — Mon, 2 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Bridge Interoperability of the Java mapping with the EJB-to-CCM mapping

  • Key: CORBA26-23
  • Legacy Issue Number: 3419
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

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

    Sub-issue: METHOD NAMES IN STANDARD INTERFACES

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

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

    Sub-issue: HANDLING STANDARD EXCEPTIONS

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

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

    Sub-issue: PASSING A PRIMARY KEY PARAMETER

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

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

  • Reported: CPP 1.1 — Tue, 14 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CCM issue chapter 69 ptc/99-10-04

  • Key: CORBA26-22
  • Legacy Issue Number: 3412
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

    Is the sufix ccd right?

  • Reported: CPP 1.1 — Mon, 13 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01

  • Key: CORBA26-21
  • Legacy Issue Number: 3299
  • Status: closed  
  • Source: Ericsson ( John-Luc Bakker)
  • Summary:

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

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

  • Reported: CPP 1.1 — Mon, 7 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EJB/CCM mappings for the IR

  • Key: CORBA26-20
  • Legacy Issue Number: 3260
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

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

  • Reported: CPP 1.1 — Thu, 27 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above, rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IFR backward compatibility broken

  • Key: CORBA26-19
  • Legacy Issue Number: 3233
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

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

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

  • Reported: CPP 1.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing Rights Combinator in Security deployment descriptor

  • Key: CORBA26-18
  • Legacy Issue Number: 3232
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

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

  • Reported: CPP 1.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Purpose of "name" element

  • Key: CORBA26-13
  • Legacy Issue Number: 3198
  • Status: closed  
  • Source: Ericsson ( John-Luc Bakker)
  • Summary:

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

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

  • Reported: CPP 1.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CCM Issue: CIDL Syntax doesn't allow for modules

  • Key: CORBA26-12
  • Legacy Issue Number: 3065
  • Status: closed  
  • Source: Oracle ( Dan Frantz)
  • Summary:

    The FTF draft does not allow a CIDL composition to be
    included in a module.

    Discussion: In the FTF Draft, the CIDL BNF (Section 60.3) is not yet
    tied into IDL syntax. As it stands, a composition cannot be embedded
    in a module. The draft recognizes that with the note (Section 60.4):

  • Reported: CORBA 2.3.1 — Thu, 2 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue On the use of typed home (or CCMHome subtypes)

  • Key: CORBA26-29
  • Legacy Issue Number: 3725
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

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

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

    interface SessionCCMHome : CCMHome

    { // or CCMHomeKeyless void set_session_context ( in SessionContext sc ) ; }

    ;

  • Reported: CPP 1.1 — Mon, 26 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Where is HomeExecutorBase interface defined?

  • Key: CORBA26-28
  • Legacy Issue Number: 3651
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

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

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See the resolution for issue 4574.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In example p.615-86

  • Key: CORBA26-27
  • Legacy Issue Number: 3650
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

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

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

p.615-85 ToonTownImpl

  • Key: CORBA26-26
  • Legacy Issue Number: 3649
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

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

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Why does not CCMHome include the operation create_component() ?

  • Key: CORBA26-25
  • Legacy Issue Number: 3648
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

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

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

operation

  • Key: CORBA26-24
  • Legacy Issue Number: 3647
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

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

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PACKAGING AND DEPLOYMENT METAMODEL

  • Key: CORBA26-15
  • Legacy Issue Number: 3208
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

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

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

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

  • Reported: CPP 1.1 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected, See issue 4575.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

atribute not part of definition

  • Key: CORBA26-14
  • Legacy Issue Number: 3199
  • Status: closed  
  • Source: Ericsson ( John-Luc Bakker)
  • Summary:

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

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

  • Reported: CPP 1.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Versioning needed for CORBA Core

  • Key: CORBA26-11
  • Legacy Issue Number: 2227
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: At present there is no formal mechanism or process for versioning the
    CORBA Core. Indeed, it is somewhat hard to figure out what is part of
    the CORBA Core. In Rev 2.3 we tried to at least bring all the IDL for
    the Core together in pieces at logical places, e.g. ORB interface,
    Object interface, IR Interfaces etc. In addition we also have the
    PortableServer module and the GIOP and related modules, the versions of
    all of which have to match for the resulting system to have any hope of
    working as advertized. I guess the basis of the current state of
    affairs is that - the vendor delivers the core, and therefore one can
    trust the vendor to deliver the right things. This model tends to break
    down in situations where people can download bits and pieces of a Java
    ORB at different times and then try to make the whole thing work
    together.

  • Reported: CORBA 2.2 — Mon, 23 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected, see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Components: readonly_attr_declarator slightly ambiguous

  • Key: CORBA26-17
  • Legacy Issue Number: 3230
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

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

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

    <simple_declarator> { "," <simple_declarator> }*

    is ambiguous, since a sole <simple_declarator> could either denote the
    first alternative (with no <raises_expr>), or the second alternative
    (with the simple-declarator-list omitted). Even though this does not
    constitute a serious problem, it is also easy to fix:

    <readonly_attr_declarator >::=
    <simple_declarator> <raises_expr>
    | <simple_declarator> { "," <simple_declarator> }

    *

  • Reported: CPP 1.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Components: Relationship of CIDL and PSDL unclear

  • Key: CORBA26-16
  • Legacy Issue Number: 3229
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

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

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

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

  • Reported: CPP 1.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 3065.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ValueMembersSeq

  • Legacy Issue Number: 5939
  • Status: closed  
  • Source: MetroApp Entertainment ( Keith Allyn Baker)
  • Summary:

    ValueMembersSeq is not defined in the CORE Specification and appears in interface ORB, but I believe it is a typo of ValueMemberSeq:

    TypeCode create_value_tc ( in RepositoryId id, in Identifier name, in ValueModifier type_modifier, in TypeCode concrete_base, in ValueMembersSeq members );

  • Reported: CORBA 3.0.2 — Sun, 11 May 2003 04:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    In CORBA v3.3 Part 1 Interfaces, section section 8.2 change ValueMembersSeq to
    ValueMemberSeq

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Make a typedef for the POA id new

  • Legacy Issue Number: 7891
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Made a typedef for the POA id new: local interface POA

    { typedef CORBA::OctetSeq POAid; }

    change: local interface POA

    { readonly attribute CORBA::OctetSeq id; }

    to: local interface POA

    { readonly attribute POAid id; }
  • Reported: CORBA 3.0.3 — Mon, 1 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

section 7.1.1 claims to define the "NVList structure", but doesn't

  • Key: CORBA26-10
  • Legacy Issue Number: 4722
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.5 — Thu, 15 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Implied IDL for interfaces in modules

  • Key: CORBA26-9
  • Legacy Issue Number: 4719
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • 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.

  • Reported: CORBA 2.5 — Fri, 30 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL for ORB::resolve_initial_references

  • Key: CORBA26-8
  • Legacy Issue Number: 4718
  • Status: closed  
  • Source: Hewlett-Packard ( Michael Matzek)
  • 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.

  • Reported: CORBA 2.5 — Tue, 27 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    close, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

set_length operation of the DynSequence interface

  • Key: CORBA26-7
  • Legacy Issue Number: 4713
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Jason Courage)
  • 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.

  • Reported: CORBA 2.5 — Tue, 20 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

the IDL include directive should introduce declarations into the namespace

  • Key: CORBA26-6
  • Legacy Issue Number: 4709
  • Status: closed  
  • Source: Hewlett-Packard ( Michael Matzek)
  • 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.

  • Reported: CORBA 2.5 — Fri, 16 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    close, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DynUnion operations

  • Key: CORBA26-5
  • Legacy Issue Number: 4708
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Jason Courage)
  • 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.

  • Reported: CORBA 2.5 — Fri, 16 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problem with IDL Context interface

  • Key: CORBA26-4
  • Legacy Issue Number: 4657
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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!

  • Reported: CORBA 2.5 — Thu, 1 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    Indeed it is hopelessly broken. Fix as suggested below.:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 11, section 11.3.8.19 (WrongPolicy)"

  • Key: CORBA26-3
  • Legacy Issue Number: 4654
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Jason Courage)
  • 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.)

  • Reported: CORBA 2.5 — Thu, 1 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Support for is_a for local interfaces

  • Key: CORBA26-2
  • Legacy Issue Number: 4623
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    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.
  • Reported: CORBA 2.5 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    Reflect this fact as follows

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 11.3.8.16 - ambiguity

  • Key: CORBA26-1
  • Legacy Issue Number: 4620
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.5 — Tue, 16 Oct 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Nil return from resolve_initial_references()

  • Key: CORBA25-44
  • Legacy Issue Number: 4532
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.4.2 — Thu, 23 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interpretation of time field in UtcT?

  • Key: CORBA25-43
  • Legacy Issue Number: 4468
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.4.2 — Thu, 9 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is no mapping for fixed types in the COM/CORBA mapping

  • Key: CORBA25-42
  • Legacy Issue Number: 4441
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There is no mapping for fixed types in the COM/CORBA mapping. Why has this been omitted? Is there a submission underway?

  • Reported: CORBA 2.4.2 — Tue, 31 Jul 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Close with answers to the qestions raised, as given above under Resolution

  • Updated: Fri, 6 Mar 2015 20:58 GMT

COBRA problem using pragma prefix for modules

  • Key: CORBA25-41
  • Legacy Issue Number: 4395
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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

  • Reported: CORBA 2.4.2 — Sun, 24 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Clarify as described below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA 2.4.2 (01-02-01.pdf) 4.2.3.4 shutdown (relevant portion)

  • Key: CORBA25-40
  • Legacy Issue Number: 4392
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.4.2 — Fri, 29 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Clarify that BAD_INV_ORDER is raised in this case with COMPLETED_NO

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Local interface is-a Object?

  • Key: CORBA25-39
  • Legacy Issue Number: 4388
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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...

  • Reported: CORBA 2.4.2 — Fri, 29 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wither pseudo-objects?

  • Key: CORBA25-38
  • Legacy Issue Number: 4387
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.4.2 — Fri, 29 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing TypeCode identity

  • Key: CORBA25-37
  • Legacy Issue Number: 4386
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.4.2 — Thu, 28 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problem with resolution to 4285 and 4306

  • Key: CORBA25-36
  • Legacy Issue Number: 4385
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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?

  • Reported: CORBA 2.4.2 — Sat, 23 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Fix inconsistency as described below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

get_interface() underspecified

  • Key: CORBA25-35
  • Legacy Issue Number: 4335
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.4.2 — Tue, 5 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make the suggested change and the additional change suggested in the archive

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in UML for POA

  • Key: CORBA25-34
  • Legacy Issue Number: 4333
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.4.2 — Mon, 4 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make the suggested corrections

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DII create_request

  • Key: CORBA25-33
  • Legacy Issue Number: 4331
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.4.2 — Fri, 1 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguity in non_existent

  • Key: CORBA25-32
  • Legacy Issue Number: 4322
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.4.2 — Thu, 24 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    close, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

String literal definition incorrect.

  • Key: CORBA25-31
  • Legacy Issue Number: 4320
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    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 “...”.

  • Reported: CORBA 2.4.2 — Mon, 21 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make it so

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent minor code for MARSHAL

  • Key: CORBA25-30
  • Legacy Issue Number: 4310
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.4.2 — Thu, 17 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make it so

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor code

  • Key: CORBA25-29
  • Legacy Issue Number: 4306
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.4.2 — Mon, 14 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Yes the minor code in this case should indeed be 2. Make it so

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing POAManager identity

  • Key: CORBA25-28
  • Legacy Issue Number: 4297
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.4.2 — Wed, 9 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

BAD_OPERATION needs minor code and completion status

  • Key: CORBA25-27
  • Legacy Issue Number: 4285
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • 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).

  • Reported: CORBA 2.4.2 — Thu, 26 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Cross-reference refers to wrong section

  • Key: CORBA25-26
  • Legacy Issue Number: 4276
  • Status: closed  
  • Source: Anonymous
  • 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)'

  • Reported: CORBA 2.4.2 — Wed, 18 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Fix as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Error in section 4.5.3.2 ORBInitRef

  • Key: CORBA25-25
  • Legacy Issue Number: 4275
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    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:...).

  • Reported: CORBA 2.4.2 — Tue, 17 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Fix as suggested above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 10.5.22.2 what happens when conditions not met

  • Key: CORBA25-24
  • Legacy Issue Number: 4266
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • 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.

  • Reported: CORBA 2.4.2 — Wed, 11 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Restrictions on native types

  • Key: CORBA25-23
  • Legacy Issue Number: 4264
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • 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?

  • Reported: CORBA 2.4.2 — Tue, 10 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification about include files and IDL compiler behavior

  • Key: CORBA25-22
  • Legacy Issue Number: 4262
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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."

  • Reported: CORBA 2.4.2 — Tue, 10 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Insert the sugested text in section 3.3

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of NamingContextExt interface in IDL of Appendix A not consisten

  • Key: CORBA25-21
  • Legacy Issue Number: 4246
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.4.2 — Thu, 29 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

3.7.4 Forward Declaration (for interfaces) doesn't mention local

  • Key: CORBA25-20
  • Legacy Issue Number: 4241
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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.

  • Reported: CORBA 2.4.2 — Tue, 27 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make the recommended change in Proposal 1

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What is the semantics of the DataInputStream::read_*_array() operations?

  • Key: CORBA25-19
  • Legacy Issue Number: 4233
  • Status: closed  
  • Source: Floorboard Software ( Yvonne Biggar)
  • 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.

  • Reported: CORBA 2.4.2 — Fri, 23 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Clarify that the operations are expected to extend the sequence to fit

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Introduction of identifiers

  • Key: CORBA25-13
  • Legacy Issue Number: 4171
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • 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.

  • Reported: CORBA 2.4.1 — Tue, 23 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Type redefinition in derived interface

  • Key: CORBA25-12
  • Legacy Issue Number: 4170
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • 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 }

    ;
    };

  • Reported: CORBA 2.4.1 — Tue, 23 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make the suggested change clarifying the inheritance case

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PortableServer::ObjectId

  • Key: CORBA25-11
  • Legacy Issue Number: 4165
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • 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).

  • Reported: CORBA 2.4.1 — Sat, 20 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

core issue: unchecked narrow

  • Key: CORBA25-10
  • Legacy Issue Number: 4159
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • 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.

  • Reported: CORBA 2.4.1 — Fri, 19 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

#include issue

  • Key: CORBA25-18
  • Legacy Issue Number: 4226
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • 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.

  • Reported: CORBA 2.4.2 — Tue, 20 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DynValueBox::set_boxed_value should also raise InvalidValue

  • Key: CORBA25-17
  • Legacy Issue Number: 4224
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • 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."

  • Reported: CORBA 2.4.2 — Fri, 16 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make it so

  • Updated: Fri, 6 Mar 2015 20:58 GMT

misleading wording in 10.5.22.2 Write Interface

  • Key: CORBA25-16
  • Legacy Issue Number: 4217
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.4.2 — Fri, 2 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    make it so

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent text for unknown system exception

  • Key: CORBA25-15
  • Legacy Issue Number: 4189
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • 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.

  • Reported: CORBA 2.4.2 — Sat, 3 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ForwardRequest from normal operations

  • Key: CORBA25-14
  • Legacy Issue Number: 4176
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.4.1 — Fri, 26 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate change and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POAManager::deactivate should not mandate ORB::shutdown implementation

  • Key: CORBA25-3
  • Legacy Issue Number: 4034
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    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.

  • Reported: CORBA 2.4.1 — Wed, 8 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Right, make it so

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POAManager::deactivate does not specify behavior for "reject"

  • Key: CORBA25-2
  • Legacy Issue Number: 4033
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    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.

  • Reported: CORBA 2.4.1 — Wed, 8 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    The proposal proved to be too controversial. So suggest close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Can a valuetype support multiple non-abstract interfaces via inheritance?

  • Key: CORBA25-1
  • Legacy Issue Number: 4003
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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.

  • Reported: CORBA 2.4 — Fri, 27 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::ORB::object_to_string() raising INV_OBJREF or BAD_PARAM

  • Key: CORBA25-6
  • Legacy Issue Number: 4128
  • Status: closed  
  • Source: Progress Software ( Eoghan Glynn)
  • 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.

  • Reported: CORBA 2.4.1 — Tue, 19 Dec 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above, Close issue, already fixed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ServantLocator preinvoke/ postinvoke semantics

  • Key: CORBA25-5
  • Legacy Issue Number: 4117
  • Status: closed  
  • Source: Borland Software Corporation ( Andy Cutright)
  • 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?

  • Reported: CORBA 2.4.1 — Wed, 10 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Clarify the expected behavior if preinvoke raises an exception

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor code 2 description for OBJECT_NOT_EXIST not consistent w/ use

  • Key: CORBA25-4
  • Legacy Issue Number: 4037
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    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?").

  • Reported: CORBA 2.4.1 — Tue, 14 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    incorporate change and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Container::lookup() ordering requirements

  • Key: CORBA25-9
  • Legacy Issue Number: 4152
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • 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.

  • Reported: CORBA 2.4.1 — Tue, 16 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Add language to require preservation of order of elements in IR as shown below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 2.1.7 of CORBA 2.3 and 2.4

  • Key: CORBA25-8
  • Legacy Issue Number: 4135
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • 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.

  • Reported: CORBA 2.4.1 — Wed, 3 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    incorporate change and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Legal IDL?

  • Key: CORBA25-7
  • Legacy Issue Number: 4132
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • 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.

  • Reported: CORBA 2.4.1 — Wed, 20 Dec 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issues related to CCM's XML descriptors: chapter 69.4.5.4

  • Key: CORBA3-124
  • Legacy Issue Number: 5493
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 69.4.5.4
    "The information obtained by (...) it allows component assembly
    tools to decide WHAT ports
    on a component are capable (...)"
    it seems that the word "which" would be better than "what" in
    this sentence

  • Reported: CCM 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Replace "what" by "which".

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Creating IORs

  • Key: CORBA3-128
  • Legacy Issue Number: 4478
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    > // ulgy conversion to objectref: we should think about
    > // creating utilities for IOR<->objref conversion

    I meant to raise that second issue (the ugly IOR to ObjRef conversion).
    It is too painful and I think we should address it. I can think of a few
    possible solutions.

    1. have make object just return profiles, so the ORB can do the
    conversion internally.
    2. Add a method on the ORT to provide this functionality
    3. Add a separate CODEC interface to manufacture IORs from Profiles
    (IORFactory, rir etc)

  • Reported: CORBA 2.4.2 — Tue, 14 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    Undo the resolution of issue 4476 and close 4478 no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is no way to modify a POA's ORT and append to it

  • Key: CORBA3-127
  • Legacy Issue Number: 4476
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    If I wish to register an ORF (ObjectReferenceFactory) as the current
    factory, there is no way for it to append to the current template. In
    other words, an updated factory can only replace the original but not
    say add another profile to the one the given POA would generate w/ the
    adapter template.

    As an inverse, there is no way for a POA to require or even request an
    ORF to include profiles that it deems fit.

    Proposal:

    Add a parameter to make_object

    Object make_object( in string repositoryId, in ObjectId id,
    ObjectReferenceTemplate template);

    Add the following methods to ObjectReferenceTemplate

    abstract valuetype ObjectReferenceTemplate : ObjectReferenceFactory

    { readonly attribute ServerId server_id ; readonly attribute ORBId orb_id ; readonly attribute AdapterName adapter_name; ProfileSeq getProfiles(in string repositoryId, in ObjectId id); ComponentSeq getComponents(in IOP::ProfileId profile_id); }

    ;

    where ProfileSeq is defined as

    module IOP

    { typedef sequence <TaggedProfile> ProfileSeq; typedef sequence <TaggedComponent> ComponentSeq; }

    Add the following sections:

    21.5.3.8 getProfiles

    This returns the set of profiles that the POA would have generated using
    its default template. This can optionally be included in the generated
    IOR.
    [ED: This is independent of make_object, because make_object returns an
    object reference from which profiles would have to be extracted for
    inclusion]

    21.5.3.9 getComponents
    This returns set of components that would have been include in the
    profile with the id profile_id and allows the factory to choose to
    include those in the profiles that it generates.

  • Reported: CORBA 2.4.2 — Sun, 12 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interoperability of ObjectReferenceTemplate and Factory.

  • Key: CORBA3-126
  • Legacy Issue Number: 4445
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    Nothing in the specs (I think the submission does say this somewhere)
    say that the valuetypes defined in this spec and implemented by the ORB
    vendor are not expected to be transmitted across different ORB
    implementations.

    Proposal:

    Add paragraph to 51.5.3.1:

    Concrete definitions and implementations of ObjectReferenceTemplate and
    ObjectReferenceFactory are ORB implementation specific and are not
    defined as they are not expected to be exchanged between ORB
    implementations.

  • Reported: CORBA 2.4.2 — Thu, 2 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    Add a clarification to the specification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Object Adapter name problem in ORT

  • Key: CORBA3-125
  • Legacy Issue Number: 4440
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    The adopted specification for the Object Reference Template is
    ptc/01-04-03. This specification introduces adapter names for
    object adapters. Adapter names are needed in the definition of the
    ObjectReferenceTemplate abstract valuetype. An AdapterName is
    simply a sequence of strings that is used to identify an
    instance of an object adapter.

    In the case of the POA, the spec defines the AdapterName as follows
    in section 21.5.2.1:

    In the case of the POA, the adapter name shall be the sequence
    of names starting with the root POA that is required to reach
    the POA using the find_POA call. The name of the root POA is
    the empty sequence.

    Also, in section 21.3.14.6:

    The adapter_name attribute defines a name for the object adapter that
    services requestws for the invoked object. In the case of the POA,
    the adapter_name is the sequence of names from the root PAO to the POA
    that services the request. The root POA is not named in this sequence.

    The problem here is that the POA occupies the entire name space of
    possible adapter names, so an ORB that supports other proprietary
    object adapters cannot unambiguously identify instances of other
    object adapter through ServerRequestInfo.adapter_name.

  • Reported: CORBA 2.4.2 — Mon, 30 Jul 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    Update the specification so that the Object Adapter ID of the root POA is

    { "RootPOA" }
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Productions 140, 141, 142 and 143 must be removed

  • Key: CORBA3-116
  • Legacy Issue Number: 5500
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    Productions 140, 141, 142 and 143 must be removed. Catalog has been
    removed
    from the PSS specification.
    Production 145 : <home_executor_body> refers to <stored_on_dcl> which is
    defined in production 151
    as <home_persistence_dcl>. Pick one or the other and changes references
    as required ...
    Productions 149 and 150 are not valid any more. Remove them and add a
    new production :
    <abstract_storage_home_name> ::= <identifier>
    identifier must be the name of an abstract storagehome previously
    declared

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

paragraph 60.2.1 : There is two mistakes in keywords

  • Key: CORBA3-115
  • Legacy Issue Number: 5499
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:
    • Capital letters are not appropriated. Correct "storageHome" with
      "storagehome".
    • The keyword "catalog" must be removed as it was removed from PSDL.
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update Table 5-13 in the EJB Chapter of formal/02-06-65

  • Key: CORBA3-123
  • Legacy Issue Number: 5588
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In ptc/01-11-03, page 64-410, there is the following note

    Issue This table will be completed after the Interface Repository
    chapter is ready.

    Then Table 5-13 in formal/02-06-65 would be completed.

  • Reported: CORBA 3.0 — Thu, 22 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial issues in formal/02-06-65

  • Key: CORBA3-122
  • Legacy Issue Number: 5585
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    The Adopted CORBA Components Specification (formal/02-06-65)
    always contains some texts removed by the Components December
    2000 RTF (ptc/01-11-02 and ptc/01-11-03). See at

    formal/02-06-65 ptc/01-11-03

    page 1-24 and 25 page 61-241
    page 1-26 page 61-243
    page 1-28 page 61-245
    page 4-37 page 62-363
    page 6-67 page 69-542
    page 6-72 page 69-548
    page 8-23 page 70-601

    Remove these old texts once again.

    Proposed revised text:

    Following must be applied on formal/02-06-65.

    At pages 1-24 and 1-25, remove

    module <module_name> {
    module <component_name>EventConsumers

    { interface <event_type>Consumer; };
    interface <component_name> : Components::CCMObject { Components::Cookie subscribe_ <source_name> ( in <component_name>EventConsumers:: <event_type>Consumer consumer) raises (Components::ExceededConnectionLimit); <component_name>EventConsumers:: <event_type>Consumer unsubscribe_<source_name> (in Components::Cookie ck) raises (Components::InvalidConnection); };
    module <component_name>EventConsumers {
    interface <event_type>Consumer :
    Components::EventConsumerBase { void push (in <event_type> evt); };
    };
    };


    At page 1-26, remove


    module <module_name> {
    module <component_name>EventConsumers { interface <event_type>Consumer; }

    ;
    interface <component_name> : Components::CCMObject

    { void connect_ <source_name> ( in <component_name>EventConsumers:: <event_type>Consumer consumer ) raises (Components::AlreadyConnected); <component_name>EventConsumers:: <event_type>Consumer disconnect_ <source_name>() raises (Components::NoConnection); }

    ;
    module <component_name>EventConsumers {
    interface <event_type> Consumer :
    Components::EventConsumerBase

    { void push (in <event_type> evt); };
    };
    };


    At page 1-28, remove


    module <module_name> {
    module <component_name>EventConsumers { interface <event_type>Consumer; };
    interface <component_name> : Components::CCMObject { <component_name>EventConsumers:: <event_type>Consumer get_consumer _<sink_name>(); };
    module <component_name>EventConsumers {
    interface <event_type>Consumer :
    Components::EventConsumerBase { void push (in <event_type> evt); }

    ;
    };
    };

    At page 4-37, remove in Session2Context interface
    the two occurrences of PortableServer::ObjectId.

    At page 6-67, remove

    Note Of the interfaces described below, only
    ComponentInstallation,
    AssemblyFactory, and Assembly are required by this specification;
    the other
    interfaces are included for illustrative purposes and to support an
    end-to-end scenario.

    At page 6-72, remove

    exception InvalidLocation { };

    At page 8-23, remove Figure 8-20.

  • Reported: CORBA 3.0 — Thu, 22 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove section 4.4.1.4 in formal/02-06-65

  • Key: CORBA3-120
  • Legacy Issue Number: 5583
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    Proposed resolution:

    The Adopted CORBA Components Specification (formal/02-06-65)
    always contains the section 4.4.1.4 at page 4-36.

    However, this section was removed in the ptc/01-11-03 document
    by the resolution of the issue 3937 of the Final Report of
    Components December 2000 FTF (ptc/01-11-02).

    Proposed revised text:

    In formal/02-06-65 page 4-36, remove the section 4.4.1.4.

  • Reported: CORBA 3.0 — Tue, 20 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

create operation of AssemblyFactory interface

  • Key: CORBA3-119
  • Legacy Issue Number: 5577
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    The name of the create operation in the AssemblyFactory Interface shall
    be renamed to a more specific identifier. Create is often used in other
    interfaces and this may lead to problems e.g. in inheritance relationships.

    suggested change:

    create -> create_assembly

  • Reported: CORBA 3.0 — Tue, 13 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CIDL Grammar problems: Productions must be renumbered : 134 -> 1, ...

  • Key: CORBA3-114
  • Legacy Issue Number: 5498
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    Productions must be renumbered : 134 -> 1, ...

    In all productions, replace ...storage_home... by ...storagehome... and
    ...storage_type...
    by storagetype...

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

69.8.2 Property File XML Elements

  • Key: CORBA3-118
  • Legacy Issue Number: 5507
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    1. 69.8.2.1 The properties Root Element, page 69-537
    Properties Element Cardinality. Suggested change is to replace "*" with "
    +".
    Why does it make sense to have an empty properties file, since the
    properties are
    optional references in the Software Package DTD, CORBA Component DTD, and
    Component Assembly DTD?

    Current Format

    <!ELEMENT properties
    ( description?
    , ( simple

    sequence
    struct
    valuetype
    )*
    ) >

    Suggested New Format

    <!ELEMENT properties
    ( description?
    , ( simple

    sequence
    struct
    valuetype
    )+
    ) >
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo (??) in chapter 61

  • Key: CORBA3-117
  • Legacy Issue Number: 5506
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In the CCM specification document ptc/2001-11-03 page 61-227
    the 'session' word should be removed from the OMG IDL 3.0
    example, i.e.:

    component baz session {

    should be replaced by:

    component baz {

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Correct the typo by removing the 'session' word

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Corrections in XML DTDs for packaging

  • Key: CORBA3-121
  • Legacy Issue Number: 5584
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In the Adopted CORBA Components Specification (formal/02-06-65),
    page 6-4, section 6.3.2.1, the version attribute of the softpkg
    element is tagged as #OPTIONAL and is tagged as #IMPLIED at page 7-5.
    As #OPTIONAL is not valid in XML, then replace it by #IMPLIED.

    In chapter 7, the softpkg XML DTD does not contain the
    ins and objref elements which they are used by the repository
    element described at page 7-4. Add them.

    Proposed revised text:

    In formal/02-06-65:

    At page 6-4, section 6.3.2.1, replace #OPTIONAL
    by #IMPLIED for the version attribute of the softpkg element.

    At page 7-3, add before the humanlanguage element

    <!ELEMENT ins EMPTY >
    <!ATTLIST ins
    name CDATA #REQUIRED >

    At page 7-4, add before the os element

    <!ELEMENT objref EMPTY >
    <!ATTLIST objref
    string CDATA #REQUIRED >

  • Reported: CORBA 3.0 — Wed, 21 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

components-ftf: connectevent element

  • Key: CORBA3-106
  • Legacy Issue Number: 5093
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    On page 69-521 (ptc/01-11-03), the connectevent
    element of an Assembly Descriptor is defined as

    <!ELEMENT connectevent (consumesport,
    (emitsport |
    publishesport))>

    This does not allow for emits and publishes
    ports to be connected to existing consumer
    interfaces that are registered in the naming
    or trading service. I suggest to change that
    element in the spirit of connectinterface to

    <!ELEMENT connectevent (emitsport |
    publishesport) ,
    (consumesport |
    existinginterface)>

  • Reported: CORBA 2.6 — Tue, 26 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

components-ftf: registercomponent element

  • Key: CORBA3-105
  • Legacy Issue Number: 5092
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    On page 69-532 (ptc/01-11-03), the
    registercomponent element of an Assembly
    Descriptor is defined to optionally
    contain an emitsidentifier and publishes-
    identifier element, in order to register
    an event source in the Naming or Trading
    Service. There is also a note saying, "In
    the case of events, what gets registered?"

    I suggest to replace the emitsidentifier
    and publishesidentifier elements with the
    consumesidentifier element, and to change
    the first two paragraphs to read:

    "The registercomponent element is to specify
    that a component, a provided interface, or
    an event consumer interface should be regis-
    tered with a naming service or trader.

    If a consumesidentifier or publishesidentifier
    is specified, then that element is registered.
    If none of the above are specified, then it is
    implied that the component itself is to be
    registered."

  • Reported: CORBA 2.6 — Tue, 26 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

components-ftf: repository id in software package descriptor

  • Key: CORBA3-104
  • Legacy Issue Number: 5091
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The id attribute of the idl element in a
    Software Package Descriptor currently
    contains the Repository Id of the component.

    I suggest to change this to the Repository
    Id of the home, as the home implies the
    component, but not vice versa. This makes
    it easier for the deployment application to
    find out about the home interface, e.g. for
    the purpose of configuring properties.

  • Reported: CORBA 2.6 — Tue, 26 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The Repository Id of the home should be added as an attribute of the idl element

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL3 keyword "eventtype" conflicts with struct "CosNotification::EventType

  • Key: CORBA3-103
  • Legacy Issue Number: 4986
  • Status: closed  
  • Source: Tech-X ( Nanbor Wang)
  • Summary:

    The "eventtype" keyword defined in Section 3.2.4 of the "CORBA 3.0 New
    Components Chapters" (ptc/2001-11-03) will make the Notification
    Service IDL un-compilable because Notification Service defines a
    struct called "EventType" in Section 3.1 of formal/00-06-20.

    I guess one of the specs will have to change.

  • Reported: CORBA 2.6 — Mon, 18 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issues related to CCM's XML descriptors: chapter 695.4

  • Key: CORBA3-113
  • Legacy Issue Number: 5497
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 695.4
    the elements aren't in the alphabetical order
    proxyhome must be placed before publishesidentifier

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issues related to CCM's XML descriptors: chapter 69.7.2.38

  • Key: CORBA3-112
  • Legacy Issue Number: 5496
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 69.7.2.38
    the processcollocation element given in this chapter lacks a
    DESTINATION child element
    right one:
    <!ELEMENT processcollocation
    (usagename?
    , impltype?
    , (homeplacement

    extension
    )+
    ,destination?
    )>
    <!ATTLIST processcollocation
    id ID #IMPLIED
    cardinality CDATA "1">
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue regarding language mapping for keyless homes

  • Key: CORBA3-107
  • Legacy Issue Number: 5340
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In 01-11-03.pdf page 61-255

    Given a base home definition with a primary key (H, T, K), and a derived home
    definition with no primary key (H', T'), such that H' is derived from H, then the
    definition of H' implicitly includes a primary key specification of type K, becoming
    (H', T', K). The implicit interface for H' shall have the form specified for an
    implicit interface of a home with primary key K and component type T'.

    In same document section 615.3.3.6 Home I see no mention that a keyless
    home that inherits from a keyed home is implicitly a keyed home and thus
    the Home Implicit Executor Interface must be constructed for a keyed home
    using the key type declared for the base keyed home. Everyone agree?

  • Reported: CORBA 3.0 — Fri, 7 Jun 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Generic operations for subscribing/unsubscribing at publishing ports

  • Key: CORBA3-102
  • Legacy Issue Number: 4983
  • Status: closed  
  • Source: Anonymous
  • Summary:

    generic operations for subscribing and unsubscribing at publishing ports of components should have the same funtionality as the specific ones. Therefore the generic unsubscribe operation should return the unsubscribed consumer reference like the specific operation does. proposal: change

    void unsubscribe (in FeatureName publisher_name, in Cookie ck) raises (InvalidName, InvalidConnection);

    to

    EventConsumerBase unsubscribe (in FeatureName publisher_name, in Cookie ck) raises (InvalidName, InvalidConnection);

  • Reported: CORBA 2.6 — Fri, 15 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

simple type element of the property file issue

  • Key: CORBA3-108
  • Legacy Issue Number: 5429
  • Status: closed  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    In document 01-11-03.pdf section 69.8.2.8 the simple type element
    of the property file descriptor excludes the types:

    long long
    unsigned long long
    long double
    wchar

    Is there any reason why we can't add these types to the simple element?

  • Reported: CORBA 3.0 — Thu, 13 Jun 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issues related to CCM's XML descriptors: chapter 69.7.2.25

  • Key: CORBA3-111
  • Legacy Issue Number: 5495
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 69.7.2.25
    the given reference to the fileinarchive element is wrong
    (69.3.2.11);
    the right one is 69.3.2.12

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Correct the false cross-reference

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issues related to CCM's XML descriptors: chapter 69.4.5.16

  • Key: CORBA3-110
  • Legacy Issue Number: 5494
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 69.4.5.16
    this eventpolicy element is said to be child element of
    corbacomponent
    in fact it can be child element of: consumes, emits, publishes
    but it's NOT a child element of corbacomponent

  • Reported: CORBA 3.0 — Tue, 23 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issues related to CCM's XML descriptors: chapter 69.4.4

  • Key: CORBA3-109
  • Legacy Issue Number: 5492
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 69.4.4
    the sample componentkind definition given as an entity with
    "process" lifetime seems
    unadapted as described in 69.4.5.49, we can give a best lifetime
    with "container"

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

add a ClientInterceptor then create_POA() in the post_init() method?

  • Key: CORBA3-95
  • Legacy Issue Number: 5764
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Isit possible to add a ClientInterceptor then create_POA() in the
    post_init()
    method? It seems that the ClientInterceptor is not called after that. Do
    you know the
    reason why?

    My Investigation:
    If the post_init method in SampleClientLoader.C creates the new POA
    using create_POA method, the client side PI will not be called. Even if
    an ORB-mediated call is made from within post_init(), ServerInterceptor
    is called beyond the scope of post_init(). Moreover, even if an
    ORB-mediated call is made from within post_init() in VisiBroker for
    Java, ClientInterceptor and ServerInterceptor are called beyond the
    scope of post_init(). However, in Visibroker for C++, the
    ClientInterceptor of VBC is not called. Please see the attachments for
    the difference in results of VBC & VBJ. A testcase is also attached.

    Any comments will be greatly appreciated.

  • Reported: CORBA 3.0.1 — Mon, 18 Nov 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::WrongTransaction and Interceptors

  • Key: CORBA3-94
  • Legacy Issue Number: 5743
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    How can a portable OTS implementation, using only Portable Interceptors,
    achieve the correct semantics for raising CORBA::WrongTransaction from
    Request::get_response or ORB::get_next_response or type specific
    pollers? There doesn't appear to be a way to do this for two reasons:

    1. ClientRequestInterceptors can only change a request result into a
    system exception, but WrongTransaction is a user exception.

    2. 21.4.4.6 says:

    "Interceptors shall assume that each client-side interception point
    logically runs in its own thread, with no context relationship between
    it and any other thread. While an ORB implementation may not actually
    behave in this manner, it is up to the ORB implementation to treat
    PICurrent as if it did."

    I take this to mean that the PICurrent in the receive_* client
    interception points cannot be guaranteed to share the same slot data as
    the client thread that called Request::get_response. This means that
    the interceptor has no way to determine whether or not the transaction
    context of the client thread matches that of the request.

  • Reported: CORBA 3.0 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolved together with 3599. Resolution appears in the resolution for 3599

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How do Portable Interceptors interact with Messaging callbacks

  • Key: CORBA3-93
  • Legacy Issue Number: 5726
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    In the messaging callback model, the response is delivered as a request
    invocation on another object. What is the call-pattern for
    ClientRequestInterceptors in this case?

    My guess is that the receive_other interception point is called for each
    registered ClientRequestInterceptor.

  • Reported: CORBA 3.0 — Fri, 25 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What ORBInitInfo operations are legal during pre_init() and post_init()?

  • Key: CORBA3-92
  • Legacy Issue Number: 5691
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There is no information in chapter 21 that specifies which operations on
    ORBInitInfo can be legally called during pre_init or post_init.

    The intention appears to be that calls to register new interceptors or
    allocate a new slot id should be illegal during post_init.

    Calling resolve_initial_references during pre_init does not appear to be
    wise, but otherwise seems benign.

    Proposed resolution:

    Add the following to 21.7.1.2:

    "During a call to post_init(), invoking the ORBInitInfo methods:
    add_client_request_interceptor, add_server_request_interceptor,
    allocate_slot_id or add_ior_interceptor will raise the BAD_INV_ORDER
    standard system exception with minor code nnn."

  • Reported: CORBA 3.0 — Fri, 18 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fix it as suggested in the archive.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORBInitInfo::arguments() underspecified

  • Key: CORBA3-91
  • Legacy Issue Number: 5690
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    21.7.2.3 states:

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

    First, what good does this do? A portable application can't depend on
    anything useful being returned by this attribute.

    This should be changed to state that ORBInitInfo::arguments() returns
    the original unmodified argv parameter that was passed to ORB_init.


    Second, this attribute really ought to be read-write, so that an
    Interceptor implementation can find and strip out arguments that are
    intended for the Interceptor.

    Alternatively, we should specify a standard prefix for arguments that
    are recognized and processed by interceptors, so that the ORB and client
    code can be explicitly coded to recognize and ignore them.

  • Reported: CORBA 3.0 — Wed, 16 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exception handling in Interceptor initialization

  • Key: CORBA3-90
  • Legacy Issue Number: 5689
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    It is undocumented what should happen if an exception is thrown while
    the ORB initialization process is calling ORBInitializer::pre_init or
    post_init.

    In section 21.7.3.1 concerning the Java binding, the following statement
    related to calling pre_init and post_init appears:

    "If there are any exceptions, the ORB shall ignore them and proceed."

    Taking this as precedent, it suggests that exceptions raised by pre_init
    and post_init should be ignored. However, I'm not convinced that this
    is a good idea, since a failure in an ORBInitializer is very likely to
    cause the application to fail in mysterious ways later on that would be
    difficult to debug.

    I think it would be better to define explicit behavior for exceptions
    raised from pre_init and post_init to be that the ORB initialization is
    abandoned and the ORB is destroyed. Any ORBInitializer implementation
    that really needs the ORB to ignore any thrown exceptions can simply
    catch and discard them itself.

  • Reported: CORBA 3.0 — Wed, 16 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Derived component supported interface restriction (formal/2002-06-01)

  • Key: CORBA3-89
  • Legacy Issue Number: 5687
  • Status: closed  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    Both the CORBA spec (formal/02-06-01 page 3-61) and the CCM spec (formal/02-06-65 page 1-51) state that "A derived component type may not directly support an interface."
    Resolution:

    In formal/02-06-65 page 1-51 and formal/02-06-01 page 3-61 replace the sentence

    "A derived component type may not directly support an interface."

    with

    "If a derived component type directly supports one or more IDL interfaces, the component interface is derived from both the interface of its base component type and the supported interfaces."

  • Reported: CORBA 3.0 — Thu, 10 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Local types allowed as valuetype state?

  • Key: CORBA3-88
  • Legacy Issue Number: 5674
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    A bullet in 3.8.7 states:

    "o A local type may not appear as a parameter, attribute, return type,
    or exception declaration of an unconstrained interface or as a state
    member of a valuetype."

    while 3.9.1.4 says:

    "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 similar to local interfaces when an attempt is made to
    marshal them."

    I presume the second statement is the correct one.

    Proposed resolution:

    Strike "or as a state member of a valuetype." from the bullet in 3.8.7.

  • Reported: CORBA 3.0 — Sat, 12 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Presumption is correct. Fix as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Why does PollableSet::number_left() return unsigned short?

  • Key: CORBA3-87
  • Legacy Issue Number: 5673
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Is there a particular design reason to limit the Pollable count to
    65535?

  • Reported: CORBA 3.0 — Mon, 7 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Incorporate change and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pollable in more than one PollableSet?

  • Key: CORBA3-86
  • Legacy Issue Number: 5672
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The descriptions of Pollable and PollableSet in 7.4 do not indicate if
    it is legal to add a Pollable to more than one PollableSet. If this is
    made illegal, it is easier to implement Pollable and PollableSet to
    cooperate behind the scenes to improve the efficiency of the PollableSet
    implementation.

    Recommended Resolution:

    Make it illegal to add a Pollable to more than one PollableSet, by
    adding the following text to 7.4.3.2:

    "If the supplied Pollable has already been added to another PollableSet,
    this operation raises the standard BAD_PARAM system exception with minor
    code XYZ.

    and add a new minor code for BAD_PARAM to appendix A:

    "XYZ: Attempt to add a Pollable to a second PollableSet."

  • Reported: CORBA 3.0 — Sat, 5 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Oneway operations should not generate sendc_ and sendp_ variants

  • Key: CORBA3-85
  • Legacy Issue Number: 5669
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Somewhere in the discussion in 22.6, it should specify that oneway
    operations are not mapped with sendc_ and sendp_ variants, because they
    would be useless.

  • Reported: CORBA 3.0 — Mon, 30 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DII sendc reply delivery underspecified

  • Key: CORBA3-84
  • Legacy Issue Number: 5668
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    7.2.10 states that sendc delivers the reply by using the supplied
    Messaging::ReplyHandler, but it does not spell out the mechanics of the
    delivery.

    I presume that for an invocation of operation "foo", the "foo" or
    "foo_excep" methods of the ReplyHandler will be invoked to deliver the
    reply

  • Reported: CORBA 3.0 — Mon, 30 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Yes, indeed. Insert a short description in section 7.10.2 on how the reply is obtained from the Repl

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Bad example code in 22.11.4.3

  • Key: CORBA3-83
  • Legacy Issue Number: 5667
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The example code in 22.11.4.3 seems to be from a draft version of the
    Messaging specification where the Pollable type was an interface rather
    than a valuetype

  • Reported: CORBA 3.0 — Mon, 30 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Turns out that the examples in both 22.11.4.2 and 22.11.4.3 need fixing. Make changes as described

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Messaging Poller generation is broken for interfaces with multiple inherite

  • Key: CORBA3-82
  • Legacy Issue Number: 5666
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    22.10.1 states that Type-Specific poller valuetypes inherit from the
    poller valuetype associated with the interface that the original
    interface inherits from. This does not address multiple inheritance,
    and in fact it cannot, since valuetype inheritance is more limited than
    interface inheritance.

    The problem is that the base valuetype for polling, Messaging::Poller,
    is not abstract, and cannot be inherited more than once by a derived
    valuetype. So as it stands now, the AMI polling model is broken for
    multiple inheritance, and needs to be treated as an urgent issue in
    order to produce an immediate fix.

    Proposed resolution:

    1. Make Messaging::Poller an abstract valuetype, and remove the state
    members from it. Change the IDL for Poller in 22.9 and 22.16.1 to:

    module Messaging {
    abstract valuetype Poller : CORBA::Pollable

    { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; }

    ;
    };

    2. Add back the private target and op_name state members to the
    persistent type-specific poller valuetypes. Modify the example IDL in
    22.10.2 to:

    valuetype AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller

    { private MessageRouting::PersistentRequest outstanding_request; private Object target; private string op_name; }

    ;

    This is necessary so the PersistentPoller can be propagated from one
    process to another with all of its necessary state.

    3. Change the text in 22.10.1 that describes inheritance of
    type-specific pollers to:

    For each interface, the IDL compiler generates a type-specific Poller
    value. A Poller is created by the ORB for each asynchronous invocation
    that uses the polling model operations. The name of the basic
    type-specific Poller is AMI_<ifaceName>Poller, where ifaceName is the
    unqualified name of the interface for which the Poller is being
    generated. If the interface ifaceName derives from one or more IDL
    interfaces, then the Poller is derived from the corresponding
    Poller for each base interface, but if it does not, then it is derived
    from Messaging::Poller. Poller valuetypes are declared abstract. If
    this name conflicts with definitions in the original IDL, additional
    AMI_ prefixes are prepended before <ifaceName> until a unique valuetype
    name is generated (such as "AMI_AMI_FooPoller"for interface Foo).

    4. Change the example IDL in 22.10.3 to make the poller abstract:

    // AMI implied-IDL of type-specific Poller
    // for original example IDL defined in Section 22.5
    abstract valuetype AMI_StockManagerPoller : Messaging::Poller {
    ...

    and add the target and op_name private state members to the persistent
    poller:

    valuetype AMI_StockManagerPersistentPoller : AMI_StockManagerPoller

    { private MessageRouting::PersistentRequest request; private Object target; private string op_name; }

    ;

  • Reported: CORBA 1.1 — Mon, 28 Sep 1992 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Make the changes recommended in the archive

  • Updated: Fri, 6 Mar 2015 20:58 GMT

name disambiguation for AMI interface & poller names is confusing

  • Key: CORBA3-81
  • Legacy Issue Number: 5665
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The rule for generating a unique AMI_ callback or poller name is to
    stuff additional "AMI_" strings until the name is unique. However,
    consider the following IDL:

    // IDL
    module M {

    interface A {
    };

    interface AMI_A {
    };

    };

    this apparently maps to the implied IDL:

    // implied IDL
    module M {

    interface A {
    };

    interface AMI_AMI_A

    { // callback interface for A }

    ;

    interface AMI_A {
    };

    interface AMI_AMI_AMI_A

    { // callback interface for AMI_A }

    ;
    };

    however, if I switch the order of declaration of A and AMI_A, the names
    of the associated callback interfaces change.

    Not only that, but if I split the IDL into two files:

    // File 1
    module M {

    interface A {
    };
    };

    // File 2
    module M {
    interface AMI_A {
    };

    };

    and try to compile them separately, the generated code will fail.

    I don't think there is any solution to this problem other than to
    declare it an error to use an IDL identifier that begins with "AMI_" if
    it causes a name clash.

    The same problem applies to the AMI poller valuetypes.

  • Reported: CORBA 3.0 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolution: Insert the requirement that any IDL that is meant to be used for AMI should not have any

  • Updated: Fri, 6 Mar 2015 20:58 GMT

potential name clash with Messaging type-specific poller timeout argument

  • Key: CORBA3-80
  • Legacy Issue Number: 5663
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The name generated for the type-specific poller timeout argument is
    "timeout", which could clash with a real IDL argument name.

    The name should be changed to "ami_timout", similar to "ami_return_val".

  • Reported: CORBA 3.0 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    make it so

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What ORBInitInfo operations are legal during pre_init() and post_init()?

  • Key: CORBA3-101
  • Legacy Issue Number: 5692
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There is no information in chapter 21 that specifies which operations on
    ORBInitInfo can be legally called during pre_init or post_init.

    The intention appears to be that calls to register new interceptors or
    allocate a new slot id should be illegal during post_init.

    Calling resolve_initial_references during pre_init does not appear to be
    wise, but otherwise seems benign.

    Proposed resolution:

    Add the following to 21.7.1.2:

    "During a call to post_init(), invoking the ORBInitInfo methods:
    add_client_request_interceptor, add_server_request_interceptor,
    allocate_slot_id or add_ior_interceptor will raise the BAD_INV_ORDER
    standard system exception with minor code nnn."

  • Reported: CORBA 3.0 — Thu, 17 Oct 2002 04:00 GMT
  • Disposition: Duplicate or Merged — CORBA 3.0.2
  • Disposition Summary:

    duplicate of issue 5691

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AMI vs abstract & local interfaces

  • Key: CORBA3-100
  • Legacy Issue Number: 5664
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The spec is silent about the interaction of AMI implied IDL and abstract
    interfaces

  • Reported: CORBA 3.0 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Clarify that sendc_ and sendp_ operations are not generated for abstract interfaces

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sending codeset context more than once?

  • Key: CORBA3-99
  • Legacy Issue Number: 3318
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

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

    The spec says:

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

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

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

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

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

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

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

  • Reported: CPP 1.1 — Tue, 14 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Getting reply svc ctxts from PersistentRequests

  • Key: CORBA3-98
  • Legacy Issue Number: 2629
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It does not appear that reply service contexts are maintained when retrieving
    polled requests from a Router. Although the Router interfaces properly
    propogate the service contexts to the the untyped reply handler representing the
    PersistentRequest, there is no way for the client to retrieve these contexts
    from the PersistentRequest::get_reply. This may make it impossible for the
    client to interpret the reply data (e.g. if the reply contained CodeSet
    contexts).

  • Reported: CPP 1.0 — Tue, 4 May 1999 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Type code creation

  • Key: CORBA3-97
  • Legacy Issue Number: 5771
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The core spec says in section 4.11.3:

    Typecode creation operations that take name as an argument shall check that
    the name
    is a valid IDL name or is a null string.

    This is oxymoronic: we are talking about IDL here; IDL does not have the
    concept of
    a null string. If anything, we can say "empty string".

    Looking at this bit of spec, it would appear that a call such as

    orb->create_interface_tc(someRepId, 0);

    is legal. But that doesn't make sense because it's illegal to pass null
    pointers
    across IDL interfaces in C++ (or null references as strings in Java).

  • Reported: CORBA 3.0.1 — Sun, 1 Dec 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fix as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unfortunate CDR Encapsulation of ASN.1 Encodings

  • Key: CORBA3-96
  • Legacy Issue Number: 5766
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Document: Chapter 24 Corba, CSIv2

    There is a misinterpretation in the current JDK implementations as to the
    interpretation of the word of "encapsulation" in the CSIv2 specification
    in relation to the encoding of the fields within the CSI Identity Token.

    The issue is that the JDK and already certified implementations have
    performed a CDR encapsulation of the byte arrays within the Identity
    Token. This CDR encapsulation is not needed as the the Identity Token is
    already a CDR encapsulation, so further CDR encapsulating the byte array
    containing the ASN.1 encodings is inefficient.

    We can suggest that current implementations do not generate CDR
    encapsulation for these fields, yet accept them to be compatible with
    misaligned implementations.

    Proposed Fix:

    Remove the word "encapsulation" before "octet stream" from the rows of the
    table 24-2 "Identity Token Types".

    Remove the word "encapsulation" in the paragraph in section 24.2.3
    "Authorization Token Format".

    Remove the word "encapsulated" in the comments in the IDL section for the
    definition of the X509CertifcateChain.

    Remove the sentence "The two-part SEQUENCE is encapsulated in an octet
    stream." in the IDL definition for "const AuthorizationElementType
    X509AttributeCertChain".

    Add paragraph to section 24.2.5 "Identity Token Formats".

    The identity token for ITTPrincipalName, ITTDistinguishedName,
    ITTX509CertChain should contain their respective ASN.1 encodings of the
    name directly. However, the token may contain a CDR encapsulation of the
    octet stream that contains the ASN.1 encoding of the name. The TSS shall
    distinguish the difference by the first octet of the field. The values of
    0x00 or 0x01 shall indicate that the field contains a CDR encapsulation.
    Any other value indicates the field for these identity token types
    contains the ASN.1 encoded value. For instance, the ASN.1 encoding for
    ITTPrincipalName starts with 0x04, and ITTDistinguishedName and
    ITTX509CertChain each start with 0x30. The TSS shall accept both the CDR
    encapsulation form and the direct ASN.1 encoding for these identity token
    types.

  • Reported: CORBA 3.0.1 — Tue, 19 Nov 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Indeed a severe interoperability problem. Fix as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Messaging type-specific poller valuetypes should be abstract

  • Key: CORBA3-79
  • Legacy Issue Number: 5661
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The generated type-specific poller valuetypes generated for an interface
    should be abstract valuetypes and should inherit the corresponding
    type-specific poller valuetypes of the base interfaces.

    Without this, code reuse is prevented in both implementing the
    type-specific poller valuetypes, as well as in using them in client
    code.

  • Reported: CORBA 3.0 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The resolution of 5666 fixes this. Close this one no change with that comment

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors in definition of Messaging poller types

  • Key: CORBA3-78
  • Legacy Issue Number: 5660
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The definintion of Messaging::Poller in section 22.9 is missing the
    keyword "private" on the target & op_name valuetype attribute
    declarations.

    The persistent poller in 22.10.2 is also missing a "private" on the
    "outstanding_request" attribute, as well as the example in 22.10.3.

  • Reported: CORBA 3.0 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolution: Fix as suggested. No problem with versioninhg since the published IDL already contains t

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Messaging: bad example code for type specific poller

  • Key: CORBA3-77
  • Legacy Issue Number: 5642
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    22.10.3 has bad example code for the type specific poller generated for
    the StockManager interface. The AMI_StockManagerPoller is shown with
    the following:

    valuetype AMI_StockManagerPoller : Messaging::Poller

    { ... attribute AMI_StockManagerHandler associated_handler; ... }

    ;

    This is illegal, since Messaging::Poller also defines an attribute named
    "associated_handler". Since the text does not specify that this
    attribute ought to be generated in a type-specific poller, I suspect
    that this is an editing mistake from a draft version of the Messaging
    RFP response and should be removed.

    The C++ example generated code in 22.11.4.2 also needs to be edited to
    remove the associated_handler attribute as well.

  • Reported: CORBA 3.0 — Wed, 11 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The observation above is correct. Fix it

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SyncScope for oneway invocations

  • Key: CORBA3-76
  • Legacy Issue Number: 5641
  • Status: closed  
  • Source: Eternal Systems ( Wenbing Zhao)
  • Summary:

    I was reading the CORBA specification (formal/02-06-01) concerning the
    SyncScope for oneway invocations. I found out that there is a mismatch on
    the meaning of SYNC_WITH_TARGET:

    On page 21-23 (Request Interceptors), there is the following paragraph:

    "For SYNC_WITH_SERVER and SYNC_WITH_TARGET, the server does send an empty reply back to the client before the target is invoked."

    That is true for SYNC_WITH_SERVER, but not correct according to the specification of the CORBA Messaging service, given on page 22-7:

    "SYNC_WITH_TARGET - equivalent to a synchronous, non-oneway operation in CORBA. The server-side ORB shall only send the reply message after the target has completed the invoked operation."

    Note that a reply is send back to the client AFTER the target has completed the invoked operation, not BEFORE.

    This error has been around already in eariler versions of the CORBA specification.

  • Reported: CORBA 3.0 — Mon, 9 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The statement about SYNC_WITH_TARGET in 21-23 is indeed wrong. Fix it.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Messaging time based policy enforcement?

  • Key: CORBA3-75
  • Legacy Issue Number: 5626
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 22.2.4 provides various time-based policies to bound the
    delivery and lifetime of requests, but has no information about who
    (client, router or target server) is responsible for enforcing those
    policies. Without this information, there will certainly be
    interoperability issues.

  • Reported: CORBA 3.0 — Mon, 2 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fix it as suggested in the archive with a few minor changes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

determining TimeT or UtcT value

  • Key: CORBA3-74
  • Legacy Issue Number: 5623
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The Time service states that determining if a TimeT or UtcT value is
    absolute or relative needs to be specified by the context. One presumes
    that the Messaging RequestStartTimePolicy, RequestStopTimePolicy,
    ReplyStartTimePolicy and ReplyEndTimePolicy contain absolute timestamps,
    and that RelativeRequestTimeoutPolicy and RelativeRoundtripTimeoutPolicy
    contain relative timestamps. The specification should make the context
    explicit.

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Is a router allowed to pick any value in the range for a priority?

  • Key: CORBA3-73
  • Legacy Issue Number: 5622
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Does it make sense (and is it legal) for a request to be sent with a
    RequestPriorityPolicy or ReplyPriorityValue in a service context where
    the min and max priorities are not the same? Is a router allowed to
    pick any value in the range for a priority?

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Who is responsible for generating the TIMEOUT exception

  • Key: CORBA3-72
  • Legacy Issue Number: 5620
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    What is the expected behavior of a server or router that receives a
    request with a RequestEndTimePolicy or ReplyEndTimePolicy value that has
    expired? Who is responsible for generating the TIMEOUT exception--the
    client or server or both?

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    This issue is a subset of issue 5626. Merge it with 5626 and close this issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Object::validate_connection()

  • Key: CORBA3-71
  • Legacy Issue Number: 5619
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    How does Object::validate_connection() interact with RoutingPolicy
    values of ROUTE_FORWARD or ROUTE_STORE_AND_FORWARD? Should
    validate_connection() force the client to open a connection to a message
    router and fail if it cannot?

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sloppy text in CORBA 3.0, 4.3.8.1 get_policy

  • Key: CORBA3-70
  • Legacy Issue Number: 5614
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    In CORBA 3.0 section 4.3.8.1, the description of the Object::get_policy
    operation says:

    "Invoking non_existent on an object reference prior to get_policy
    ensures the accuracy of the returned effective Policy.Ifget_policy is
    invoked prior to the object reference being bound, the returned
    effective Policy is implementation dependent. In that situation, a
    compliant implementation may do any of the following: raise the standard
    system exception BAD_INV_ORDER, return some value for that PolicyType
    which may be subject to change once a binding is performed, or attempt a
    binding and then return the effective Policy."

    This is silly, since the only portable thing that applications can do is
    to call validate_connection or non_existent before calling get_policy,
    having two other non-portable behaviors just serves to make the standard
    larger and confuse users.

    We should pick one of the two reasonable behaviors--throw BAD_INV_ORDER
    or force a binding before returning a valid policy value--and make that
    the only valid behavior. Either one will be backwards compatible with
    portable code.

  • Reported: CORBA 3.0 — Thu, 29 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Makes sense. Fix it as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Object::get_client_policy problem

  • Key: CORBA3-69
  • Legacy Issue Number: 5592
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    4.3.7.2 says:

    "Returns the effective overriding Policy for the object reference. The
    effective override is obtained by first checking for an override of the
    given PolicyType at the Object scope, then at the Current scope, and
    finally at the ORB scope. If no override is present for the requested
    PolicyType, the system-dependent default value for that PolicyType is
    used. Portable applications are expected to set the desired defaults
    at the ORB scope since default Policy values are not specified."

    Some policies may not have a sensible default value, such as
    RequestStartTime and in fact, perhaps should not have one to avoid
    putting any value in the INVOCATION_POLICIES service context. In this
    case, it would be better if get_client_policy were allowed to return a
    nil Policy reference.

    Suggested revision:

    Change the sentence that reads:

    "If no override is present for the requested PolicyType, the
    system-dependent default value for that PolicyType is used."

    to:

    "If no override is present for the requested PolicyType, a
    system-dependent default value for that Policy Type may be returned. A
    nil Policy reference may also be returned to indicate that there is no
    default for the policy."

  • Reported: CORBA 3.0 — Sat, 24 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fix as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent definition of semantics of RebindPolicy?

  • Key: CORBA3-68
  • Legacy Issue Number: 5587
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    4.12.3.32 states:

    > REBIND is raised when the current effective RebindPolicy, as described in
    > Section 22.2.1.2, interface RebindPolicy on page 22-5, has a value of
    > NO_REBIND or NO_RECONNECT and an invocation on a bound object reference results
    > in a LocateReply message with status OBJECT_FORWARD or a Reply message with
    > status LOCATION_FORWARD. This exception is also raised if the current effective
    > RebindPolicy has a value of NO_RECONNECT and a connection must be re-opened.
    > The invocation can be retried once the effective RebindPolicy is changed to
    > TRANSPARENT or binding is re-established through an invocation of
    > CORBA::Object::validate_connection.

    but 22.2.1.2 says:

    > If the effective Policy of this type has a rebind_mode value of NO_REBIND, the
    > ORB will raise a REBIND system exception if any rebind handling would cause a
    > client-visible change in policies. This could happen under the following
    > circumstances:
    >
    > o The client receives a LocateReply message with an OBJECT_FORWARD status and a
    > new IOR that has policy requirements incompatible with the effective policies
    > currently in use.
    >
    > o The client receives a Reply message with LOCATION_FORWARD status and a new
    > IOR that has policy requirements incompatible with the effective policies
    > currently in use.

    So the former says that a REBIND exception always occurs a rebind is
    necessary (and NO_REBIND is set), but the latter says that a REBIND
    exception only occurs when any client-visible policies would change.

    Which one is correct?

    Also, it is not clear from the specification whether an invocation on a
    new object reference that has never been bound must fail if RebindMode
    is not TRANSPARENT, forcing the use of validate_connection, or whether
    the first initial binding can proceed without the use of
    validate_connection.

  • Reported: CORBA 3.0 — Tue, 20 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

pragma prefix syntax

  • Key: CORBA3-63
  • Legacy Issue Number: 5327
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    suppose the following [pseudo-]idl:

    #pragma prefix "2abc.def"

    module xyz {
    interface q

    {...}

    ;
    };

    It would generate a Java class 'q' within package 'def.2abc.xyz'.
    The package name '2abc' is not that popular with the java compiler
    since it starts with a digit.

    From what I could see in CORBA 2.6.1, identifiers have to start
    with a character (or at least not a digit). So, I guess that the
    prefix pragma is erroneous here, right ?

    The OpenORB IDL parser 1.2.0 did though generate Java code without any
    complaints, which confuses me ...

  • Reported: CORBA 2.6.1 — Sat, 25 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Avoiding Interceptors for colocated method requests

  • Key: CORBA3-62
  • Legacy Issue Number: 5296
  • Status: closed  
  • Source: International Business Machines ( Ann Collins)
  • Summary:

    Could we please discuss the possibility of introducing a performance
    optimization for Interceptors.

    There may be considerable overhead involved in invoking Portable
    Interceptors. While some interceptors need to be invoked when caller
    and target are colocated (the locally optimized path), many do not.
    I think it would be useful to introduce a mechanism to allow this
    unnecessary overhead to be avoided for interceptors that do not need
    to be invoked on the colocated path, for example by adding a
    'run_local' parameter to the add_xxx_request_interceptor methods of
    the ORBInitInfo interface.

    I realise that this issue was touched upon during discussion of interop
    issue 4291 but, at the time, the focus was on getting the interceptor
    mechanism to work correctly in the colocated case; the performance
    aspect of the issue seems to have been lost.

  • Reported: CORBA 2.6.1 — Mon, 13 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Provide means for the optimization as shown below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Codeset negotiation and the CODESET_INCOMPATIBLE exception

  • Key: CORBA3-61
  • Legacy Issue Number: 5270
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    1. There's no minor code assigned to the use of CODESET_INCOMPATIBLE
    for a failed codeset negotiation in 13.10.2.6.

    2. There's no indication of what a server should do if the client
    delivers a codeset via a CodeSetContext that the server does not support
    as a transmission codeset). This isn't likely to happen, but we ought
    to close the hole. I propose that we have the server raise
    CODESET_INCOMPATIBLE (with a different minor code from 1) in this case
    too.

    3. Would it be a good idea for us to include recommendations on how to
    change a persistent server's native codeset while remaining backwards
    compatible with existing IORs floating around the world with obsolete
    CodeSetComponent data? Or is it too obvious? (Just make sure the new
    server advertises (or at least continues to support) the old native
    codeset as a transmission codeset.)

  • Reported: CORBA 2.6.1 — Tue, 7 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Replace deprecated anonymous type declarations?

  • Key: CORBA3-60
  • Legacy Issue Number: 5232
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Now that we've deprecated defining types anonymously with bounded
    strings, fixed, sequences and arrays, should we take the next step and
    deliberately purge them from the Core IDL?

    Here are the offenders that I've identified and the edits that should
    occur:

    In module CORBA:

    1. the service_detail member of struct ServiceDetail

    Fix: Add 'typedef sequence<octet> ServiceDetailData' and replace
    member type

    2. the service_options & service_details members of struct
    ServiceInformation

    Fix: Add 'typedef sequence<ServiceOption> ServiceOptionSeq' and
    'typedef sequence<ServiceDetail> ServiceDetailSeq' and replace
    member type

    In module GIOP:

    3. the magic member in the various struct MessageHeader_1_X types

    Fix: Add 'typedef char Magic[4]' and replace member types

    4. the reserved member in the struct RequestHeader_1_1 and
    RequestHeader_1_2 types

    Fix: Add 'typedef octet RequestReserved[3]' and replace member
    types

    5. the object_key member in various Header structures

    Fix: replace member types with IOP::ObjectKey

    In module IIOP:

    6. the object_key member in various struct ProfileBody_1_X types

    Fix: replace member types with IOP::ObjectKey

    7. the components member in struct ProfileBody_1_1

    Fix: replace member type with IOP::ComponentSeq

    In module IOP:

    8. the profile_data member in struct TaggedProfile

    Fix: Add 'typedef sequence<octet> ProfileData' and replace member
    type

    9. the profiles member in struct IOR

    Fix: Add 'typedef sequence<TaggedProfile> TaggedProfileSeq' and
    replace
    member type

    10. the component_data member in struct TaggedComponent

    Fix: Add 'typedef sequence<octet> ComponentData' and replace member
    type

    11. the context_data in struct ServiceContext

    Fix: Add 'typedef sequence<octet> ContextData' and replace member
    type

    also to complete fixes for cases 5, 6, and 20:

    Fix: Add 'typedef sequence<octet> ObjectKey' and
    'typedef sequence<TaggedComponent> TaggedComponentList'

    In module MessageRouting:

    12. the body member in struct MessageBody

    Fix: Add 'typedef sequence<octet> BodyData' and replace member type

    13. the object_key member in struct RequestMessage

    Fix: replace member type with 'IOP::ObjectKey'

    14. the reserved member in struct RequestMessage

    Fix: replace member type with 'GIOP::RequestReserved'

    15. the typed_excep_holder_repids in struct ReplyDestination

    Fix: replace member type with 'CORBA::RepositoryIdSeq'

    In module Messaging:

    16. the pvalue member in struct PolicyValue

    Fix: Add 'typedef sequence<octet> PolicyData' and replace member
    type

    17. the marshaled_exception member in valuetype ExceptionHolder

    Fix: Add 'typedef sequence<octet> MarshalledException' and replace
    member
    type

    In module CONV_FRAME:

    18. the conversion_code_sets member in struct CodeSetComponent

    Fix: Add 'typedef sequence<CodeSetId> CodeSetIdSeq' and replace
    member type

    In module DCE_CIOP:

    19. the object_key member in struct InvokeRequestHeader and struct
    LocateRequestHeader

    Fix: replace member type with 'IOP::ObjectKey'

    In module DCE_CIOPSecurity.idl:

    20. the components member in struct DCESecurityMechanismInfo

    Fix: replace member type with 'IOP::TaggedComponentList'

  • Reported: CORBA 2.6 — Tue, 30 Apr 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

reference_to_servant

  • Key: CORBA3-59
  • Legacy Issue Number: 5105
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    For reference_to_servant(), the spec says:

    > This operation requires the RETAIN policy or the USE_DEFAULT_SERVANT
    policy.
    > If neither policy is present, the WrongPolicy exception is raised.
    >
    > If the POA has the RETAIN policy and the specified object is present in
    the Active
    > Object Map, this operation returns the servant associated with that object
    in the Active
    > Object Map. Otherwise, if the POA has the USE_DEFAULT_SERVANT policy and a
    > default servant has been registered with the POA, this operation returns
    the default
    > servant. Otherwise, the ObjectNotActive exception is raised.

    This says that, if I use USE_DEFAULT_SERVANT, reference_to_servant() always
    and unconditionally returns the default servant.

    This appears to be wrong. In particular, I can have USE_DEFAULT_SERVANT but
    still add other servants explicitly to the AOM. If I do that, I can have,
    for example,
    servant X with object ID 1 as an explicitly activated servant, in addition
    to the default
    servant. In this situation, if I call reference_to_servant() with a
    reference with object ID 1,
    it should return servant X instead of the default servant.

    The exact same reasoning applies to id_to_servant(), which also
    unconditionally returns
    the default servant with USE_DEFAULT_SERVANT().

    I think we need to fix this – it appears that the current words are simply
    wrong.

  • Reported: CORBA 2.6 — Tue, 2 Apr 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

BAD_INV_ORDER minor code 5 and 10 mean the same thing?

  • Key: CORBA3-67
  • Legacy Issue Number: 5448
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    From the descriptions in CORBA 2.6.1 sections 7.2 and 7.2.3, the
    BAD_INV_ORDER minor codes 5 and 10 appear to mean the same thing. We
    should officially deprecate one, or state that either is acceptable

  • Reported: CORBA 3.0 — Sun, 30 Jun 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Easiest fix is to state either is acceptable

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Serious backward compatibility issue in the PI

  • Key: CORBA3-66
  • Legacy Issue Number: 5430
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    I have recently realized that there is a serious backward compatibility
    issue in the PI changes introduced by the Object Reference Template.
    The problem is in the IORInterceptor. The original PI specification
    defined only the establish_components method on IORInterceptor.
    ORT added 3 new methods to this interface: components_established,
    adapter_state_changed, and adapter_manager_state_changed.

    The compatibility problem arises with the Java mapping. Prior to
    the CORBA 3.0 IDL to Java mapping, local interfaces were simply
    mapped to interfaces. The mapping for the CORBA 3.0 IORInterceptor
    is then simply:

    public interface IORInterceptorOperations
    extends org.omg.PortableInterceptor.InterceptorOperations

    { void establish_components (org.omg.PortableInterceptor.IORInfo info); void components_established (org.omg.PortableInterceptor.IORInfo info); void adapter_manager_state_changed (int id, short state); void adapter_state_changed ( org.omg.PortableInterceptor.ObjectReferenceTemplate[] templates, short state); }

    public interface IORInterceptor extends IORInterceptorOperations,
    org.omg.PortableInterceptor.Interceptor, org.omg.CORBA.portable.IDLEntity
    {
    }

    Any client of PI that implements IORInterceptor from CORBA 2.6 defines only the
    establish_components method, so that client will fail on a CORBA 3.0 version of PI.

    I propose the following changes to the draft CORBA 3.0 spec to fix this problem:

    In Section 21.5.4, replace the definition of IORInterceptor with:

    local interface IORInterceptor : Interceptor

    { void establish_components( in IORInfo info ) ; }

    ;

    local interface IORInterceptor_3_0 : IORInterceptor

    { void components_established( in IORInfo info ) ; void adapter_manager_state_changed( in AdapterManagerId id, in AdapterState state ) ; void adapter_state_changed( in ObjectReferenceTemplateSeq templates, in AdapterState state ) ; }

    ;

    Replace the first sentence in 21.5.4.2 with:

    After all of the establish_components methods have been called, the
    components_established methods are called on all registered IORInterceptor_3_0
    instances.

    Replace the first sentence in 21.5.4.3 with:

    Any time the state of an adapter manager changes, the adapter_manager_state_changed
    method is invoked on all registered IORInterceptor_3_0 instances.

    Replace the first sentence in 21.5.4.4 with:

    Adapter state changes unrelated to adapter manager state changes are reported by
    invoking the adapter_state_changed method on all registered IORInterceptor_3_0
    instances.

  • Reported: CORBA 3.0 — Fri, 14 Jun 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolve urgently as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OpaqueValue/add_arg never mapped to languages

  • Key: CORBA3-65
  • Legacy Issue Number: 5333
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Bill Beckwith)
  • Summary:

    As far as I can tell, OpaqueValue, a new native type
    introduced in Issue 2162 (void * in DII Chapter) for
    add_arg, was never documented in any of the language
    mappings.

    Also, the len parameter of add_arg is underspecified.

  • Reported: CORBA 3.0 — Mon, 3 Jun 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor codes in specified NO_IMPLEMENT exceptions incomplete/inconsistent

  • Key: CORBA3-64
  • Legacy Issue Number: 5329
  • Status: closed  
  • Source: Xanalys ( Martin Simmons)
  • Summary:

    The minor codes in the specified NO_IMPLEMENT exceptions are incomplete/inconsistent.

    In particular:

    1) In 3.7.6.1 "Semantics", minor code 3 is mentioned for DII support pseudo-operations, but 3.7.6.2 seems to specify minor code 4 for these (though it uses different wording).

    2) 3.7.6.2 "LocalObject" doesn't specify the minor code for "is_a" etc, though presumably it should be 3 as in 3.7.6.2.

    3) The explanation for minor code 3 is "Unable to use any profile in IOR." but that isn't particular clear for local objects, which probably don't have an IOR at all.

  • Reported: CORBA 2.6.1 — Tue, 28 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Valuetypes supporting forward declared interfaces

  • Key: CORBA3-58
  • Legacy Issue Number: 5100
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Interfaces cannot inherit from forward declared interfaces and
    valuetypes cannot inherit from forward declared valuetypes, but there is
    no specific prohibition against a valuetype supporting a forward
    declared interface. There should be.

    Proposed resolution:

    Add the following sentence to section 3.8.4:

    "It is illegal for a value type to support a forward-declared interface
    whose definition has not yet been seen."

  • Reported: CORBA 2.6 — Fri, 29 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Do as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsitent exception handling with find_POA & unknown_adapter

  • Key: CORBA3-57
  • Legacy Issue Number: 4982
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    I think we totally messed up the resolution to issue 3740. We added the
    following text (circa CORBA 2.5) to 11.3.3.2:

    "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."

    [ There is also a typo in this text: "unkown_adapter".]

    and this text to 11.3.8.3:

    "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."

    In the former, system exceptions raised by unknown_adapter are to be
    passed through unchanged by find_POA. In the latter, system exceptions
    raised by unknown_adapter are to be replaced with OBJ_ADAPTER(1).

    I think the former behavior is more correct, since it preserves the
    original exception and doesn't throw away useful debugging information.

  • Reported: CORBA 2.6 — Thu, 14 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The former (i.e. 11.3.3.2) is right. Change the latter to match the former

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IOR processing performance

  • Key: CORBA3-56
  • Legacy Issue Number: 4945
  • Status: closed  
  • Source: International Business Machines ( Ann Collins)
  • Summary:

    The overhead of processing TaggedComponents within an IOR becomes
    significant when done many times, as in the case of J2EE implementations
    where multiple request interceptors are used. IOR access and creation
    performance could be improved by making better use of Java facilities to
    provide access to an IOR's components without the overhead of CDR encoding,
    and by recognising that many of the constituent parts of an IOR are
    identical for all objects within an object adapter.

    I would like to propose that we introduce a Java API for IOR, along the
    following lines:-

    An abstract model of an IOR could be defined as follows:
    an IOR has a type ID string, and contains TaggedProfile instances
    an IIOPProfile is a TaggedProfile
    an IIOPProfile is composed of an IIOPProfileTemplate and an object ID
    an IIOPProfileTemplate has an ObjectKeyTemplate, and contains
    TaggedComponents
    a TaggedComponent has an ID, and can be written to an OuputStream.
    a TaggedComponentFactory reads a TaggedComponent from an InputStream.

    It should be possible to manipulate IOR TaggedProfiles and
    IIOPProfileTemplate TaggedComponents using all of the facilities in the
    Java collections framework.

    Templates can be used to create IIOPProfile and ObjectKey because the basic
    object adapter model for object creation is to establish all properties of
    an IOR (except for type and object ID) when the object adapter is created.
    This has been present for the POA essentially from the beginning, since
    policies can only be passed to create_POA, and cannot be changed on an
    existing POA. The Portable Interceptors work has also made this clear,
    since the IOR interceptor runs only when an object adapter is created,
    which is the only time that user code can add tagged components to an IOR.

    TaggedComponent is a framework that may be extended to support application
    defined TaggedComponents. It would be necessary to be able to register
    TaggedComponentFactory instances with an ORB, in which case any IOR
    unmarshalled by that ORB instance would use the registered
    TaggedComponentFactory to unmarshal the TaggedComponent.

    In order to use the IOR API, a method would be needed, probably on ORB,
    to obtain an abstract IOR from an object reference.

  • Reported: CORBA 2.6 — Wed, 6 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wide string in reply before codeset was negotiated

  • Key: CORBA3-47
  • Legacy Issue Number: 4824
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Martin von Loewis posed the following rather intersting question in
    comp.object.corba:

    > Also notice that you must perform character set negotiation to
    > communicate wstring values, unlike string values. You don't have to do
    > that in the first message, though, but sometime before the first wide
    > string is transmitted (I wonder what happens if the client does not
    > negotiate a character set in its first message but the server wants to
    > sent back a wstring response, e.g. inside an any).

    The current codeset negotiation rules don't address this problem.

  • Reported: CORBA 2.6 — Tue, 12 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

conflict between CORBA specification and C++ mapping (_this method

  • Key: CORBA3-46
  • Legacy Issue Number: 4823
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I think that there is conflict between CORBA specification and C++ mapping (_this method). May be it relates both to CORBA specification and C++ mapping.

    The Portable Object Adapter chapter of CORBA 2.6 specification 11.2.7 Implicit Activation (last paragraph - before Note)

    If the POA has the MULTIPLE_ID policy, the servant_to_reference and servant_to_id operations will always perform implicit activation, even if the servant is already associated with an Object Id. The behavior of language mapping operations in the MULTIPLE_ID case is specified by the language mapping. For example, in C++, the _this() servant member function will not implicitly activate a MULTIPLE_ID servant if the invocation of _this() is immediately within the dynamic context of a request invocation directed by the POA to that servant; instead, it returns the object reference used to issue the request.

    If I am right, author thinks that _this operation can be called on servant (related to POA with MULTIPLE_ID policy) multiple times (and it will not raise PortableServer::WrongPolicy exception).

    But C++ mapping provides the following semantics of _this:

    1.36.5 Skeleton Operations 3. ... This requires the POA with which the servant was activated to have been created with the UNIQUE_ID and RETAIN policies. If the POA was created with the MULTIPLE_ID or NON_RETAIN policies, the PortableServer::WrongPolicy exception is thrown.

    Moreover CORBA specification provides the following semantics for servant_to_reference method: 11.3.8.20 servant_to_reference 2. If the POA has both the RETAIN and 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 a corresponding object reference is returned.

    If I am right, _this and servant_to_reference are very close by their semantics (sometimes _this can be implemented using servant_to_reference invocation on appropriate POA). That's why I think that C++ mapping conflicts with CORBA specification.

    Could you please provide some explanation about this problem (even if I am not right).

  • Reported: CORBA 2.6 — Mon, 4 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Codeset negotiation requires clarification

  • Key: CORBA3-51
  • Legacy Issue Number: 4850
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    We need to analyze this problem in pieces, because our discussions have been all
    over
    the map.

    I have identified some legitimate needs for clarification though this discussion.
    To help
    we should target each discussion to be within one or more of these scenarios:

    Lets look at a few typical scenarios a, b, and c:

    a) server does not support international Strings

    Server cannot support Objects which use WSTRING in their IDL. It does not use
    codeset component in IORs, thus closing off Client’s use of international strings
    on the connection.

    We have a problem as to what to do with an ANY which may have WSRING in it for
    this case (we could mandate the orb to consider this a failed negotiation and go
    to the fallback of UTF-16).

    b) Server supports only Latin 1 for string, and Unicode UCS-2 for Wstring

    Server places a Codeset component in the IOR with TCS-W indicated.

    There may be a need for clarification as to what Native Code Sets should be used
    for Unicode.

    • If we view the GIOP negotiation mechanism as transport oriented, then the Server
      should put in UTF-16 as the Native Code set.in the IOR component
    • If we view it as a presentation mechanism, then the Server might put UCS-2 as
      Native code set, and UTF-16 as Conversion Code Set in the IOR component.

    What can the server legally put in the IOR component for TCS-C in this case. Is
    Null allowed? Should ISO 8859-1 be explicitly called out in the TCS-C portion of
    the codeset component?

    c) Server supports ShiftJISC for string and Unicode UCS-2 for Wstring

    There might be an issue on whether the server may also place UTF-8 in as an
    explicit Conversion code set in the TCS-C portion of the IOR component?

    If the client does not support ShiftJISC, it should assert UTF-8 in the Codeset
    Service context for the TCS-C.

  • Reported: CORBA 2.6 — Thu, 28 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The whole negotiation thing should be removed, Unicode should be mandated

  • Key: CORBA3-50
  • Legacy Issue Number: 4846
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The whole negotiation thing should be removed from the spec and Unicode should be mandated"

  • Reported: CORBA 2.6 — Wed, 27 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

discussion on the create_union_tc operation could use some clarifications

  • Key: CORBA3-53
  • Legacy Issue Number: 4852
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The discussion on the create_union_tc operation could use some clarifications to prevent implementation errors.

    Firstly, in the previous paragraph of the spec it states that member names must be unique, but this is not true for unions: only the member (label) values need to be unique, not the member names.

    Secondly, there is a check that each member (label) type matches the discriminator type, but this will not hold for the default label, because according to the typecode spec (section 4.11.1) the default label type of a union will be octet so it will never match the discriminator type.

  • Reported: CORBA 2.6 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    There is indeed a defect that should be fixed by replacing a single sentence as shown below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL inheritance issue

  • Key: CORBA3-52
  • Legacy Issue Number: 4851
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    The IDL specification is unclear about the names that can be used to
    denote a base interface. Section 3.7.2 says

    "Each <scoped_name> in an <interface_inheritance_spec> must denote a
    previously defined interface."

    but the word "denote" is not defined. In particular, is the following
    legal?

    interface I { };
    typedef I J;
    interface K : J { };

    There is real IDL in use in the world that assumes that inheriting
    from a typedef is permitted. I therefore suggest re-wording the part
    of section 3.7.2 to be

    "Each <scoped_name> in an <interface_inheritance_spec> must be the
    name of a previously defined interface or an alias to a previously
    defined interface."

    A similar clarification is required in section 3.8.1.3, regarding
    valuetype inheritance.

  • Reported: CORBA 2.6 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Good point. Incorporate the clarification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

interaction of #pragma and typeid, typeprefix

  • Key: CORBA3-49
  • Legacy Issue Number: 4835
  • Status: closed  
  • Source: Memorial University of Newfoundland ( Jeffrey Parsons)
  • Summary:

    The CCM final draft has a section on repository identity
    related declarations (3.15), and the rules for which trumps
    which and what may be reset a second time are clear. Likewise
    for the #pragma prefix, version and ID directives in section
    10.7.5. But I'm still confused about how these two things
    interact – I haven't been able to find anywhere where this is
    addressed.

  • Reported: CORBA 2.6 — Mon, 18 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IPv6 in corbaloc URLs

  • Key: CORBA3-48
  • Legacy Issue Number: 4825
  • Status: closed  
  • Source: Progress Software ( Markus Heichel)
  • Summary:

    is there any recent specification for IPv6 addresses in corbaloc
    URLs? I could not find any hint.

    Since it is not possible to unambiguously determine the meaning
    of something like:

    corbaloc::10:5::5:6/Hello

    there should be an escape for the colons or a delimiter for
    the IP address.

  • Reported: CORBA 2.6 — Tue, 12 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GIOP version in replies

  • Key: CORBA3-55
  • Legacy Issue Number: 4899
  • Status: closed  
  • Source: seimet.de ( Uwe Seimet)
  • Summary:

    is it allowed to return a reply with a GIOP version number of 1.0 for a
    request with GIOP version number 1.1 or 1.2, as long as the reply can be
    correctly encoded with GIOP 1.0? IMO the spec is not clear about that, i.e.
    it does not explicity state that the version numbers of request and reply
    must match. This should be clarified.

  • Reported: CORBA 2.6 — Fri, 1 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Clarify that the reply message must have the same GIOP version as the request message

  • Updated: Fri, 6 Mar 2015 20:58 GMT

definition of the TypeCode interface (4.11.1)

  • Key: CORBA3-54
  • Legacy Issue Number: 4870
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Jason Courage)
  • Summary:

    In the definition of the TypeCode interface (4.11.1) the length operation is defined as:

    // for tk_string, tk_sequence, and tk_array unsigned long length () raises (BadKind);

    The comment for this operation should include tk_wstring.

  • Reported: CORBA 2.6 — Wed, 27 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fixed editorially in CORBA 3.0, close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue with chunking

  • Key: CORBA3-43
  • Legacy Issue Number: 4806
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    15.3.4 is silent on the treatment of encapsulations containing chunked valuetypes and in particular chunked valuetypes containing encapsulations containing chunked valuetypes. My understanding of encapsulations leads me to believe that the encapsulation should ignore the current nesting level and chunk length and start from scratch, i.e. chunks within an encapsulation are calculated relative to the start of the encapsulation rather than relative to the stream.

    The reason this needs clarification is because the spec goes to great lengths to make sure chunks are not nested so I think that it would be clearer if this case was specifically discussed. Additionally I don't know whether 15.3.4.6 should include encapsulations in the list of data types that cannot be split across a chunk. In general you would probably have to read the entire encapsulation before you can decode it, so allowing it to be split across chunks might be problematic.

  • Reported: CORBA 2.6 — Tue, 15 Jan 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Clarify as shown below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypeCode indirections

  • Key: CORBA3-42
  • Legacy Issue Number: 4796
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    This issues was previously raised as issue 4294, and was deferred to the
    GIOP 1.3 wishlist. Now that GIOP 1.3 is about to become a reality, I am
    re-raising the issue because of its importance for efficient RMI-IIOP
    communications. This is an interop issue, but I am also copying the
    Java to IDL list because of its impact on RMI-IIOP performance.

    CDR should allow TypeCode indirections that refer to top-level TypeCodes.
    The current prohibition of this causes servere performance penalties for
    RMI-IIOP because the Java to IDL mapping requires that Java objects of
    declared type java.lang.Object are marshalled as CORBA anys. In the case
    of a Vector or HashTable with 100 elements, this means that 100 anys must
    be marshalled. If all of these are of actual type foo, the restriction
    on TypeCode indirections means that all 100 of these data values must repeat
    the TypeCode for foo, which could be very large. This causes very substantial
    overheads, since the space and time needed to marshal the TypeCode for foo
    can greatly exceed that needed to marshal the data for foo.

    I understand why a nested indirection cannot refer to any TypeCode outside
    the scope of its enclosing top-level TypeCode. However, this restriction
    does not need to apply to a top-level TypeCode. We have made this change
    experimentally without any adverse effects and we have discovered that
    using indirections for all repeated top-level TypeCodes can speed up some
    common scenarios by at least a factor of 5 on end-to-end measurements.
    There appears to be no downside to making this change.

    Proposed Resolution:

    In the section headed "Indirection: Recursive and Repeated TypeCodes" within
    section 15.3.5.1, replace the current first bullet:

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

    by the following two bullets:

    For GIOP 1.2 and below, the indirection applies only to TypeCodes nested
    within some “top-level” TypeCode. Indirected TypeCodes are not “freestanding,”
    but only exist inside some other encoded TypeCode.

    For GIOP 1.3 and above, the indirection applies only to TypeCodes nested
    within some “top-level” TypeCode, or from one top-level TypeCode to another.
    Indirected TypeCodes nested within a top-level TypeCode can only reference
    TypeCodes that are part of the same top-level TypeCode, including the
    top-level TypeCode itself. Indirected top-level TypeCodes can reference
    other top-level TypeCodes but cannot reference TypeCodes nested within
    some other top-level TypeCode.

  • Reported: CORBA 2.6 — Fri, 21 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapters 13.10.1.9, and 13.10.1.12 -- issue

  • Key: CORBA3-41
  • Legacy Issue Number: 4725
  • Status: closed  
  • Source: International Business Machines ( Richard Sitze)
  • Summary:

    [3, Chapters 13.10.1.9, and 13.10.1.12] apparently indicate that both TCS-C
    and TCS-W can be byte-oriented or non-byte-oriented.

    Assume the following configurations for two communicating ORBs.

    CNCS-C = windows-1252, SNCS-C = ISO-8859-1, and CCCS-C = SCCS-C =

    {UTF-16}

    .

    The execution of the OMG code set negotiation algorithm [3, Chapter
    13.10.2.6] in this case will result in the value of the TCS-C as UTF-16!

    An IDL string will then be marshalled as UTF-16 encoded data, which may
    have embedded single-octet NULLs. This point should be mentioned explicitly
    somewhere in [3, Chapter 15.3.1.6], especially when IDL string data types
    are not allowed to contain any embedded NULLs [3, Chapter 3.10.3.2]. [3,
    Chapter 15.3.1.6] states that "Both the string length and contents include
    a terminating null". If TCS-C is selected to be UTF-16, this 'null' should
    be a null of two-octet size. [3, Chapter 15.3.1.6] should be explicit in
    stating that the concrete representation of the 'terminating null' is
    dependent on the TCS-C.

    Similarly, for the following configuration
    CNCS-W = UCS-2, SNCS-W = UCS-4, and CCCS-W = SCCS-W =

    {UTF-8}

    TCS-W will be selected as UTF-8!

    Are these configurations valid? Regardless of the answer to this question,
    [3, Chapters 13.10.1.9, and 13.10.1.12] should clarify the issue of the
    orthogonality of TCS with respect to the byte-oriented and
    non-byte-oriented code sets with appropriate examples.

  • Reported: CORBA 2.6 — Tue, 4 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Alignment for empty sequence?

  • Key: CORBA3-38
  • Legacy Issue Number: 4650
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    struct X

    { long long_1; sequence<double> double_seq; long long_2; }

    ;

    The question is, how should things be padded if double_seq is empty?
    (Assume that we are starting at byte offset 0 for marshaling this structure.)

    Approach taken by ORB 1:

    • long_1 is aligned on a four-byte boundary (offset 0).
    • The length of double_seq is aligned on a four-byte boundary,
      immediately following long_1 (offset 4).
    • long_2 is aligned on a four-byte boundary. Because double_seq is
      empty, this means that long_2 immediately follows the length of
      double_seq on the wire, so long_2 begins at offset 8 and the total
      number of bytes for the struct is 12.

    Approach taken by ORB 2:

    • long_1 is aligned on a four-byte boundary (offset 0).
    • The length of double_seq is aligned on a four-byte boundary,
      immediately following long_1 (offset 4).
    • Now four bytes of padding are inserted because the sequence element
      type is double, so the next data item is expected to start on
      an eight-byte boundary.
    • long_2 is aligned on that eight-byte boundary, so long_2 begins at
      offset 12 and the total number of bytes for the struct is 16.

    The spec isn't clear on what should happen:

    Sequences are encoded as an unsigned long value, followed by the
    elements of the sequence. The initial unsigned lon gcontains the
    number of elements in the sequence. The elements of the sequence
    are encoded as specified for their type.

    >From this, I cannot infer unambiguously which interpretation is correct.

    Both approaches seem reasonable. (Personally, I have a slight preference
    toward approach 2 because it's more consistent: after consuming the sequence,
    the next data item will always start on an 8-byte boundary, which is more
    consistent than approach 1, because the padding rules don't depend on the
    length of the sequence at run time.)

    I suspect that the best way to resolve this might be to take a majority vote
    in line with the behavior of current implementations. And, of course,
    the question now is what do we do with the GIOP version? We probably should
    increment it, but I don't see what that would achieve for already existing
    implementations, sigh...

  • Reported: CORBA 2.5 — Tue, 30 Oct 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, no change necessary

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA 2.5 and Portable Interceptors mismerged

  • Key: CORBA3-37
  • Legacy Issue Number: 4585
  • Status: closed  
  • Source: Vanderbilt University ( Mr. Ossama Othman)
  • Summary:

    The new Portable Interceptor chapter in the CORBA 2.5 specification
    has apparently been mismerged. Section 13.8 "Coder/Decoder
    Interfaces," the Codec related interfaces added to the "IOP" module,
    should supercede those in the deprecated "IOP_N" module that is listed
    in section 21.10 "Portable Interceptor IDL."

    Suggested changes include:

    • Remove the IOP_N module from Section 21.10 "Portable Interceptor
      IDL."
    • Change all instances of "IOP_N" to "IOP." In particular, methods
      listed in sections 21.3.13 (ClientRequestInfo IDL) and 21.10 refer
      to the "IOP_N" module. The following methods in section 21.10 must
      be updated:

    module PortableInterceptor {

    // ...
    local interface ClientRequestInfo

    { // ... IOP_N::TaggedComponent get_effective_component (...) IOP_N::TaggedComponentSeq get_effective_components (...) // ... }

    ;
    // ...

    local interface ORBInitInfo

    { readonly attribute IOP_N::CodecFactory codec_factory; }

    ;

    };

  • Reported: CORBA 2.5 — Mon, 1 Oct 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fixed in CORBA 3.0 (ptc/02-01-14). Close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Detecting Recursion in Other Interceptors

  • Key: CORBA3-36
  • Legacy Issue Number: 4554
  • Status: closed  
  • Source: International Business Machines ( Mr. Tim Baldwin)
  • Summary:

    We have identified a requirement where the interceptors for one service
    need to be able to detect recursive invocations made by some other
    interceptor during the processing of a request. As far as we have been
    able to determine there is no way to achieve this using the
    Request-scope/Thread-scope Current mechanism described in the spec.

    It is probably easiest to explain this using a specific example. Start
    with some form of "transaction" service that registers client-side
    interceptors so it can detect all new request invocations and add service
    contexts that perform some form of "begin transaction" processing at the
    server. This transaction service must only perform this "begin
    transaction" once per application-level request, so it allocates a
    PICurrent slot and performs the processing described in section 21.4.4.2 to
    ensure that any recursive calls it makes itself will form part of the same
    transaction and not begin a new one.

    However a problem now occurs if we introduce some other service, say a
    "security" service that has its own interceptors registered. The order in
    which these two service's interceptors run can affect what happens, but
    since interceptor ordering is undefined assume that the security
    interceptor runs first.

    An application makes a request on its own thread A. The send_request
    interceptors start to run on thread B and the security interceptor runs
    first, at this point both the RSC and TSC slots for the transaction service
    are empty. The security interceptor makes a recursive request so the
    send_request interceptors run again on a new thread C. The security
    interceptor runs again and this time doesn't recurse so the transaction
    interceptor now runs on thread C. At this point it finds its RSC slot
    empty so does a "begin transaction" and sets its TSC for thread C. We've
    now finished interceptors on thread C and return to thread B and invoke
    send_request for the transaction service. Once again it finds its RSC slot
    empty and will try to "begin transaction" again. Now we have a problem as
    we have issued two "begin transactions" for the same application request.

    In fact it as actually the second of those two "begin transactions" that we
    really want to do, as that represents the true start of the application's
    transaction. The first one (caused by the recursive call in the other
    interceptor) is at best redundant and wasteful and at worst wrong and
    problematic.

    Does anyone have any comments on this problem?

  • Reported: CORBA 2.5 — Tue, 4 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

X/Open Codeset registry is obsolete needs to be replaced

  • Key: CORBA3-27
  • Legacy Issue Number: 4236
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    13.9.1 refers to the X/Open (nee OSF) Codeset registry. This registry
    is obsolete and no longer maintained. We should replace it with the
    IANA codeset registry instead and grandfather the old values for a
    transition period.

  • Reported: CORBA 2.4.2 — Mon, 26 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify that each interception point executes in a distinct logical thread

  • Key: CORBA3-26
  • Legacy Issue Number: 4173
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    To me the key word is "EACH" - in other words values set via
    PICurrent.set_slot in send_request are visible to other interceptors in
    that point and go into the RSC of client interceptors serving any
    requests made from within the interceptor(s). However, the TSC for
    receive_reply (etc) would have a clean PICurrent since it runs in its
    own logical thread.

    We should clarify this.

  • Reported: CORBA 2.4.1 — Wed, 24 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Clarify as shown below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

11.3.2.1 Processing States (end of second paragraph and third paragraph

  • Key: CORBA3-45
  • Legacy Issue Number: 4822
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Hello, I think I've found inconsistency (or slips of the pen) in CORBA specification.

    ----------------------------------------- 11.3.2.1 Processing States (end of second paragraph and third paragraph):

    For example, if a POA is in active state, it does not change state due to an activate operation. Such operations complete successfully with no special notice.

    The only exception is the inactive state: a deactivate operation raises an exception just the same as every other attempted state change operation.

    Probably incosistent to:

    11.3.2.5 deactivate (first paragraph):

    This operation changes the state of the POA manager to inactive. This operation has no affect on the POA manager's state if it is already in the inactive state. (no more explanation about AdapterInactive exception)

    ------------------------------------------ So, each POAManager state changing operation do nothing if it will not really change the state of the POAManager (activate call on already active POAManager, for example)

    On the other hand:

    Each POAManager state changing operation raises the AdapterInactive exception if issued while the POA manager is in the inactive state.

    CORBA 2.5 specification was the first in which explanation about AdapterInactive exception during deactivate operation was removed (but third paragraph of 11.3.2.1 was not changed respectively).

    Probably, the third paragraph of 11.3.2.1 should be removed.

    Could you please provide some explanation about this problem (even if I am not right).

  • Reported: CORBA 2.6 — Mon, 4 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Potential problem using BiDir GIOP and codeset conversion service context

  • Key: CORBA3-44
  • Legacy Issue Number: 4820
  • Status: closed  
  • Source: ICL ( Chris Wood)
  • Summary:

    I've just noticed there's a potential problem when using BiDir GIOP and the codeset conversion service context, or in fact any service context that has connection rather than request scope.

    Take the following example:

    A opens connection to B

    A issues a request 1 (R1) containing the bidir service context, but not the codeset conversion service context.

    B processes R1, marking the connection as bidirectional.

    B invokes a callback object with a request (R2), this request does contain the codeset conversion service context, since B has noticed A has not set one for the request.

    A symultaniously issues another request (R3), this one does contain the codeset service context, however the codesets it selects are different.

    So we have a problem, which codesets should be used for the connection?

    The obvious solution is to force each direction to negotiate it's own character encodings, however this is not stated anywhere in the spec AFAICS. This problem will also occour for any connection specific state as set up by service contexts.

    Suggested resolution: add to the BiDir part of chapter 15 the following:

    "For any connection level state negotiated by exchange of service contexts, each direction of a bidirectional connection should be negotiated independently. For example, the codeset negotiation process shall produce independent transmission codesets for each direction"

  • Reported: CORBA 2.6 — Fri, 1 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GIOP 1.2 encoding of wstring

  • Key: CORBA3-40
  • Legacy Issue Number: 4724
  • Status: closed  
  • Source: International Business Machines ( Richard Sitze)
  • Summary:

    [3, Chapter 3.10.3.2] defines an IDL wstring data type to be a sequence of
    wchars. But the GIOP 1.2 encoding of wstring is defined differently [3,
    Chapter 15.3.2.7]. A GIOP 1.2 encoded wstring is not a sequence of GIOP 1.2
    encoded wchars.

    Each individually encoded wchar is associated with an octet containing the
    size of the encoded wchar in octets [3, Chapter 15.3.1.6], whereas an
    encoded wstring is associated with an unsigned long containing the length
    of the entire wstring in octets. Probably [3, Chapter 15.3.2.7] should
    clearly mention and explain this point with sample layout diagrams of
    appropriately encoded wchars and wstrings.

  • Reported: CORBA 2.6 — Tue, 4 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORBs using BOMs for UTF-16 (closely related to issue 4008)

  • Key: CORBA3-39
  • Legacy Issue Number: 4723
  • Status: closed  
  • Source: International Business Machines ( Richard Sitze)
  • Summary:

    [3, Chapter 15.3.1.6] mentions the use of BOM to indicate (and override the
    OMG byte order indicator flag [3, Chapter 15.2.1]) the endian-ness of the
    UTF-16 encoded wchar or wstring data.

    This is incorrect and goes against the Unicode recommendations [1]?refer to
    the Unicode conformance clause C3 [4, Chapter 3.1], and the discussion
    related to the use of BOM [4, Chapter 2.7].

    [4, Chapter 3.1] unambiguously implies that a BOM is not necessary if a
    higher-level protocol indicates the endian-ness. [4, Chapter 2.7]
    categorically states: "if other signaling methods (the OMG byte order flag
    in this context) are used, signatures (BOM) should not be employed".

    The UTF-16 endian rules of [3, Chapter 15.3.1.6] are clearly influenced by
    [2]. In the MIME world, an initial U+FEFF or U+FFFE is interpreted as BOMs.
    The BOM (or its absence) indicates the endian-ness of UTF-16 encoded data
    in the internet MIME world. But for CORBA messages or CDR encapsulations,
    the OMG byte order flag is already explicitly marking the UTF-16 encoded
    data as UTF-16BE or as UTF-16LE. U+FEFF or U+FFFE should not be used as
    BOMs for UTF-16 encoded data in the CORBA domain.

    Therefore, it is proposed that any U+FEFF or U+FFFE, regardless of their
    positions in the marshalled data, must be interpreted as ZERO WIDTH
    NO-BREAK SPACE characters, and not as BOMs. All the references to BOM in
    [3, Chapter 15.3.1.6] must be removed altogether.

    Adoption of the above Unicode conformant rule will
    – result in more efficient encoding of wchar/wstring data?no need to place
    U+FFFE for little-endian UTF-16/UTF-32 wchars/wstrings,
    – eliminate the ugly situation, where the BOM of an UTF-16/UTF-32 encoded
    wchar/wstring data contained in a message or CDR encapsulation indicate a
    different byte order than that specified by the OMG byte order flag for the
    same message or CDR encapsulation.

  • Reported: CORBA 2.6 — Tue, 4 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    This proposal results in a complete reversal of an earlier adopted resolution, and hence would be in

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problem with CSIv2 and GIOP LocateRequest

  • Key: CORBA3-29
  • Legacy Issue Number: 4290
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    CSIv2 uses GIOP ServiceContexts to associate a security context with a
    given GIOP message, but the GIOP LocateRequest & LocateReply messages to
    not have a ServiceContext field to carry the CSIv2 security context
    information. Thus, it is impossible to use LocateReuest & LocateReply
    when using CSIv2.

  • Reported: CORBA 2.4.2 — Fri, 20 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

21.8.1 register_initial_reference

  • Key: CORBA3-28
  • Legacy Issue Number: 4284
  • Status: closed  
  • Source: SeeBeyond Technology Corp. ( Tom Urquhart)
  • Summary:

    21.8.1 register_initial_reference

    An operation is available in the ORB interface:
    void register_initial_reference (in ObjectId id, in Object obj) raises
    (InvalidName);
    If this operation is called with an id, Y , and an object, YY, then a
    subsequent call to ORB::resolve_initial_references ( Y ) will return object
    YY.
    InvalidName is raised if:
    " this operation is called with an empty string id;
    or
    " this operation is called with an id that is already registered, including
    the default names defined by OMG.
    What we think this means is that it would be impossible to register (and
    resolve) ORB vendor external implementations of, for example, CORBA
    Services, such as Naming, Trading, Notification, etc. as they are some of
    the "default names".

    Could you please amend the second "or" clause to something like:
    or
    " this operation is called with an id that is already registered, including
    the default LOCALLY CONSTRAINED names defined by OMG, where 'LOCALLY
    CONSTRAINED' would not then apply to any predefined CORBA Service names
    such as NameService, NotificationService, etc.
    Many thanks and apologies if you've already addressed this.

  • Reported: CORBA 2.4.2 — Wed, 25 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

rep_id() operation on Object?

  • Key: CORBA3-33
  • Legacy Issue Number: 4337
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I'm seeing more and more questions along the lines of:

    "How can I get the repository ID of an object, given its reference?"

    The standard answer is to call get_interface() and to then grope around
    in the IFR. However, that's cumbersome, and the IFR may well not be
    populated or running.

    So, why is it that there is no way to get the repository ID from the target
    object directly? I would think that adding something like the following
    to CORBA::Object would work nicely:

    interface Object

    { // ... string rep_id(); }

    ;

    As far as the implementation is concerned, it would be trivial. We'd have
    another "_rep_id" operation name in IIOP (similar to "_get_interface" and
    "_non_existent"). On the server side, the implementation would simply
    return the repository ID of the servant (the result of _primary_interface()
    in the C++ mapping).

    Yes, I know, we'd have to rev IIOP (which we are due to do some time
    soon anyway, so we might as well add this at the same time).

    Apart from the IIOP issue, I'd be interested in hearing what other people
    think of this idea. Any glitches with it?

  • Reported: CORBA 2.4.2 — Tue, 5 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Repository ID in nil references

  • Key: CORBA3-32
  • Legacy Issue Number: 4334
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    on page 13-17, the spec says:

    A Null TypeID is the only mechanism that can be used to represent
    the type CORBA::Object.

    This is in conflict with the information provided on page 15-28:

    When a reference to a base Object is encoded, there are two allowed
    encodings for the Repository ID: either "IDL:omg.org/CORBA/Object:1.0"
    or "" may be used.

    I would suggest to strike the sentence on page 13-17 because that is a
    historical hangover.

    Also, the entire section talks about "type IDs", when what it really means
    are "repository IDs". I would suggest to hunt down all uses of "type ID"
    and to replace them with "repository ID", because that's the correct
    terminology.

  • Reported: CORBA 2.4.2 — Tue, 5 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above Close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Note on page 15-43, OBJECT_FORWARD_PERM

  • Key: CORBA3-31
  • Legacy Issue Number: 4324
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    On page 15-43, we have a note:

    Note--Usage of OBJECT_FORWARD_PERM is now deprecated, due to problems it
    causes with the semantics of the Object::hash operation.
    OBJECT_FORWARD_PERM features could be removed from some future GIOP
    versions if solutions to these problems are not provided.

    This seems to be in conflict with the decision to retain permanent forwarding
    for FT ORBs. The note needs to be either deleted or updated to reflect
    the real state of affairs.

  • Reported: CORBA 2.4.2 — Tue, 29 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Good catch. The note is simply wrong and should be removed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interpretation of defined ServiceConfigurationSyntax constants is incomplet

  • Key: CORBA3-30
  • Legacy Issue Number: 4321
  • Status: closed  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    If the ServiceConfigurationSyntax identifier is a 0, the specification
    says that the contents of the associated ServiceConfiguration is an ANS.1
    Encoded version of a GeneralNames construct.

    It is not specified what a conforming client implementation does when it
    encounters this type of privilege authority. What is the conforming
    behavior of a client?

    If there is no conforming behavior, I believe the definition of
    CSIIOP:SCS_GeneralNames should be removed from the specification, as there
    is nothing "interoperable" about it, and this specification is an
    interoperability specification.

    As a remedy to this situation we should probably use a resolution of the
    VMCID solution sought after in issue 4268, and let that Vendor specify it
    in their specification (i.e. does EJB have a use for this?), when there is
    a specification for it.

    The ServiceConfigurationSyntax identifier of 1 specifies that the
    ServiceConfiguration is a GSSExported name.

    This one has a bit more use than 0, as the contents of a GSS exported name
    construct can imply a lot, such as the protocol, the format of the token,
    and a specification of where to get the authorization token.

    So, the specification should state the specific OIDs that are understood
    by a conforming CSS, and where to find the specification of the conforming
    behavior of each OID.

    Obviously there are no OID specified (yet), but there might be in the
    future. It would be nice to know where to look, or otherwise remove the
    definition of SCS_GSSExportedName from the specification.

  • Reported: CORBA 2.4.2 — Thu, 24 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA components requires new GIOP version?

  • Key: CORBA3-35
  • Legacy Issue Number: 4536
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    Please forgive me if this is old news. I was trying to find a recent
    CORBA Components spec to see what changes it has had on the core spec.

    It looks like several new TypeCode kinds have been added (two from
    CCM?), but doesn't that require a new GIOP version? Even if the specs
    did declare the wire formats in new versions of Chapter 15, how could
    older GIOP 1.2 ORBs handle them?

    Specs:

    CCM FTF drafts of modified CORBA Core chapters
    Adds tk_component and tk_home in 10.7.1. No update to 15.
    http://www.omg.org/cgi-bin/doc?ptc/99-10-03

    CORBA 2.4.2 complete specification
    Adds tk_local_interface in 10.7.1. No update to 15.
    http://www.omg.org/cgi-bin/doc?formal/01-02-01

  • Reported: CORBA 2.4.2 — Mon, 27 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change, see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypeCodes for custom marshaled valuetypes

  • Key: CORBA3-34
  • Legacy Issue Number: 4506
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    It is underspecified what value member information for custom
    marshaled valuetypes an ORB must provide.

    Users of custom marshaled valuetypes must provide their own marshaling
    code, and the ORB has no way of knowing what it does before executing
    it.

    This comes into play for custom marshaled valuetypes inside of Anys,
    as well as the ValueMemberSeq in the FullValueDescription of a custom
    marshaled valuetype.

    In both cases, one can query whether or not the valuetype is custom
    marshaled. With Anys, the TypeCode has a ValueModifier type_modifier
    which is set to VM_CUSTOM. The FullValueDescription includes a
    boolean is_custom.

    I can see two possible solutions:

    1. TypeCodes for custom marshaled valuetypes will encode no value
    member information, so the member_count will be 0. The
    FullValueDescription will have a zero length sequence for the
    ValueMemberSeq members.

    or

    2. Value member information for the TypeCode or FullValueDescription
    for a custom marshaled valuetype is the state defined in the
    valuetype's IDL in the same way as if it were not custom marshaled.

    I propose #1 as the solution. This member information is only useful
    for finding out what is encoded, and solution #2 doesn't provide
    that. Plus, it can be very expensive to create and transmit if many
    repository IDs are involved.

  • Reported: CORBA 2.4.2 — Thu, 16 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Stateful boolean causes all CSI mechanisms to operate the same way.

  • Key: CORBA3-25
  • Legacy Issue Number: 4167
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    The stateful boolean of the CSIIOP::CompoundSecMech forces all CSI
    mechanisms to behave the same way with respect to state retention. This is
    problematic and makes mechanisms parametric on the POA they are
    supporting. The retention of state is actually a function of an
    established transport, not a POA.

    Discussion:

    In the architecture (OMA) POA's are the 'owners' of object references.
    Therefore, the state retention boolean must be set there, as there is only
    one CompundSecMecList per object reference.

    You may have cases where multiple CSI mechanisms must support one POA.

    These mechanisms may span POA's as they may be defaults for many POA's. If
    state retention is parameterized on the particular mechanism, then
    negotiating the state retention for each mechanism becomes easier to
    handle, as the state retention algorithm is mechanism specific. Therefore,
    that mechanism may operate independently of knowing the POA.

    This makes the TSS mechanisms to be able to work independently of the POA
    policy.

    Also, for another reason, CSI state retention is based on the established
    transport, which has nothing to do with a POA, therefore it is part of the
    CSI mechanism over which the transport it is working.

    I think the purpose for the "stateful" boolean was ill conceived. It was
    thought of by some as a deficiency in your implementation and you needed
    to provide a single boolean so one could RED FLAG a security service
    "inferior" in some sense.

    The fact is that state retention can be inefficient in some cases. State
    retention is actually parameter that is a function of the mechanism over a
    particular transport mechanism. One may want to use mechanisms that retain
    their state where one makes lots of invocations over a single transport
    (long live connections). (State retention is a function of transport).
    Short lived connections need not incur the overhead.

    Proposed Solution:

    Move the stateful field, as follows:

    module CSIIOP {
    // type used in the body of a TAG_CSI_SEC_MECH_LIST component to describe a
    // compound mechanism

    struct CompoundSecMech

    { AssociationOptions target_requires; IOP::TaggedComponent transport_mech; AS_ContextSec as_context_mech; SAS_ContextSec sas_context_mech; boolean stateful; }

    ;

    // type corresponding to the body of a TAG_CSI_SEC_MECH_LIST component

    struct CompoundSecMechList

    { sequence <CompoundSecMech> mechanism_list; }

    ;

    };

  • Reported: CORBA 2.4.1 — Mon, 22 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    CLOSE NO CHANGE

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Bug in C++ NVList mapping

  • Key: CORBA21-80
  • Legacy Issue Number: 501
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: NVList has an item () operation, which returns a NamedValue reference. The same special memory management rules should apply to item().

  • Reported: CORBA 2.0 — Thu, 20 Feb 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by portability submission

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OMG C++ Mapping: Implicit Conversion Operators

  • Key: CORBA21-79
  • Legacy Issue Number: 484
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I propose that public interface of _var types, the similar "smart pointer" types used in struct fields, and "smart pointer" types returned from sequence index operators be extended. (see file)

  • Reported: CPP 1.0b1 — Thu, 30 Jan 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Persistent Any values

  • Key: CORBA21-78
  • Legacy Issue Number: 480
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It"s currently not possible for a C++ client or server to receive a parameter value of type Any, store that value in filesystem or a database and later reconstruct Any value from persistent represe

  • Reported: CPP 1.0b1 — Wed, 22 Jan 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by portability submission

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DII and DSI are useless with current Any

  • Key: CORBA21-77
  • Legacy Issue Number: 479
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Cannot use DII to invoke an operation that expects or returns a complex user-defined type. Any needs to provide member functions for composing Any"s containing arbitrary user-defined values

  • Reported: CPP 1.0b1 — Wed, 22 Jan 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

  • Updated: Fri, 6 Mar 2015 20:58 GMT

iterating over Any primitives

  • Key: CORBA21-76
  • Legacy Issue Number: 254
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There hsould be a way to access an unknown type inside an Any by "iterating" over the Any to examine the type in terms of the primitive types that make it up.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

  • Updated: Fri, 6 Mar 2015 20:58 GMT

decompose Any into constituent primitives

  • Key: CORBA21-75
  • Legacy Issue Number: 251
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here is an extremely simple extension to the any type to allow decomposition of values to their constituent parts: <EXAMPLE issue251>

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rethrowing exceptions

  • Key: CORBA21-69
  • Legacy Issue Number: 144
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If all I want to do is rethrow an exception in my C++ client code, there is no convenient and compliant way. It would be useful to add extra members to allow this.

  • Reported: CPP 1.0b1 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Return value of operator[] for array var

  • Key: CORBA21-72
  • Legacy Issue Number: 220
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.12 Pg 16-27 CORBA2.o Why are we returning a Long * from operator[] rather than an LongArray_slice&?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Taking T out of T_var

  • Key: CORBA21-71
  • Legacy Issue Number: 205
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Sec 16.8.1 Pg 16-14 CORBA2.0 p31, Section 3.10.1 para 14: If I have T_var referring to T. How can I take ownership?How to stop it from being deallocated when T_var goes out of scope?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Freeing inaccessible storage for T_var as out parameter

  • Key: CORBA21-70
  • Legacy Issue Number: 187
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Standard requires that a conforming implementation must free the inaccessable storage associated with a parameter passed as a managed type(T_var). How to achieve it for out parameters??

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RTTI vs. _narrow for exceptions

  • Key: CORBA21-74
  • Legacy Issue Number: 244
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Since RTTI is not ubiquitous, the _narrow operations for Exceptions should be defined, even when RTTI available. They are trivial to implement using RTTI.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Implementation of parameter passing for T_var types

  • Key: CORBA21-73
  • Legacy Issue Number: 239
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: Implementation of parameter passing using T_var types

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL grammar

  • Key: CORBA21-68
  • Legacy Issue Number: 458
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 1.2 — Thu, 5 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

8.1 Role of the Basic Object Adapter Para 1 - comment

  • Key: CORBA21-67
  • Legacy Issue Number: 455
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.4 ORB Initialization Last Paragraph - objection

  • Key: CORBA21-66
  • Legacy Issue Number: 454
  • Status: closed  
  • Source: Anonymous
  • 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."

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    defer to portability

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.4 ORB Initialization Last Paragraph - objection

  • Key: CORBA21-65
  • Legacy Issue Number: 453
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    No change to the specification. The existing spec supports a default ORB

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.2.5 Probing for Object Non-Existence Paragraph 2 - comment

  • Key: CORBA21-64
  • Legacy Issue Number: 452
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    no change required, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.2.4 Equivalence Checking Operation Paragraph 3 - comment

  • Key: CORBA21-63
  • Legacy Issue Number: 451
  • Status: closed  
  • Source: Anonymous
  • 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??

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.2.1 Determining the Object Implementation and Interface

  • Key: CORBA21-62
  • Legacy Issue Number: 450
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.1 Converting Object References to Strings Para 3 - comment

  • Key: CORBA21-61
  • Legacy Issue Number: 449
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.6 Repository Paragraph 4 - editorial

  • Key: CORBA21-60
  • Legacy Issue Number: 436
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Last Paragraph - editorial

  • Key: CORBA21-59
  • Legacy Issue Number: 433
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The trailing period is missing.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    changed, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.4.3 Interface Objects Paragraph 2 - editorial

  • Key: CORBA21-58
  • Legacy Issue Number: 419
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.4.3 Interface Objects Paragrapg 1 - editorial

  • Key: CORBA21-57
  • Legacy Issue Number: 418
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.3.1 Managing Interface Repositories

  • Key: CORBA21-56
  • Legacy Issue Number: 417
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

5.3.2 Registering Dynamic Implementation Routines Para 1- comment

  • Key: CORBA21-55
  • Legacy Issue Number: 411
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    This is fixed by the new DSI text from the Portability FP

  • Updated: Fri, 6 Mar 2015 20:58 GMT

5.2 Explicit Request State: ServerRequest Pseudo Object

  • Key: CORBA21-54
  • Legacy Issue Number: 410
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6.5 delete_values Paragraph 1 - editorial

  • Key: CORBA21-53
  • Legacy Issue Number: 407
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.3.3 get_response

  • Key: CORBA21-52
  • Legacy Issue Number: 401
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.2.3 invoke

  • Key: CORBA21-51
  • Legacy Issue Number: 398
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.1.2 Memory usage, Para 1, editorial

  • Key: CORBA21-50
  • Legacy Issue Number: 394
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.1 Overview, Paragraph 3, editorial

  • Key: CORBA21-49
  • Legacy Issue Number: 392
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

3.15.2 Object Non-Existence, Para 1, editorial

  • Key: CORBA21-48
  • Legacy Issue Number: 391
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

3.10.3 Raises Expressions

  • Key: CORBA21-47
  • Legacy Issue Number: 389
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

3.9 Exception Declaration

  • Key: CORBA21-46
  • Legacy Issue Number: 388
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.5 Structure of an Object Adapter

  • Key: CORBA21-45
  • Legacy Issue Number: 387
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.1 Structure of an Object Request Broker

  • Key: CORBA21-44
  • Legacy Issue Number: 386
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

1.2.2 Requests Paragraph last - editorial

  • Key: CORBA21-43
  • Legacy Issue Number: 385
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA2.0, 1.2.2 Paragraph 2 - comment

  • Key: CORBA21-42
  • Legacy Issue Number: 384
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Scope of standard exceptions

  • Key: CORBA21-41
  • Legacy Issue Number: 132
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unions with enum as discriminator type

  • Key: CORBA21-40
  • Legacy Issue Number: 130
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    no change necessary, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

_is_a with CORBA::Object as input parameter

  • Key: CORBA21-39
  • Legacy Issue Number: 127
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    closed with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unqualified names in scopes

  • Key: CORBA21-38
  • Legacy Issue Number: 117
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    no change to spec., close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Usage of standard exceptions

  • Key: CORBA21-37
  • Legacy Issue Number: 97
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 1.2 — Fri, 6 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguity in DII and DSI

  • Key: CORBA21-36
  • Legacy Issue Number: 90
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Thu, 22 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Request reuse

  • Key: CORBA21-35
  • Legacy Issue Number: 88
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 20 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Whether unions carry exact discriminant information

  • Key: CORBA21-34
  • Legacy Issue Number: 66
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Mon, 5 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Recusive Type Definitions

  • Key: CORBA21-33
  • Legacy Issue Number: 1
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    closed issue, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Detail lacking in when request interceptors are called

  • Key: CORBA3-11
  • Legacy Issue Number: 3599
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

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

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

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

    {reply,exception,other}

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

    This paragraph in 21.3.7.2:

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

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

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

  • Reported: CPP 1.1 — Tue, 9 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How correlate requests and replies when using pollable sets?

  • Key: CORBA3-10
  • Legacy Issue Number: 3541
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

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

    Consider the following IDL:

    module Stock
    {
    interface Quoter

    { long get_quote(in string stock_name); }

    };

    and a client that does a 1000 invocations in the style

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

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

    while(poll_set->number_left() > 0)

    { pollable = poll_set->get_ready_pollable(timeout); ... }

    ;

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

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

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

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

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

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

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

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

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

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

  • Reported: CPP 1.1 — Mon, 10 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

no way to register value factory from ORB initializer

  • Key: CORBA3-18
  • Legacy Issue Number: 3793
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

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

  • Reported: CPP 1.1 — Mon, 28 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORB accessor on POA?

  • Key: CORBA3-17
  • Legacy Issue Number: 3772
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

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

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

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

    interface POA

    { CORBA::ORB ORB(); // ... }

    ;

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

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

    Opinions?

  • Reported: CPP 1.1 — Tue, 15 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RoutingPolicy issue

  • Key: CORBA3-16
  • Legacy Issue Number: 3770
  • Status: closed  
  • Source: Perot Systems ( Bill Binko)
  • Summary:

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

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

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

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

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

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

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

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

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

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

  • Reported: CPP 1.1 — Mon, 31 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORB::shutdown vs. ORB::destroy

  • Key: CORBA3-24
  • Legacy Issue Number: 4164
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    The CORBA 2.3 spec says under ORB shutdown:

    Once an ORB has shutdown, only object reference management
    operations(duplicate, release and is_nil) may be invoked on the ORB or
    any object reference obtained from it. An application may also invoke
    the destroy operation on the ORB itself. Invoking any other operation
    will raise the BAD_INV_ORDER system exception with the OMG minor code 4.

    This implies that calling ORB::shutdown also terminates the client
    side processing. I think that this wrong. I believe that ORB::shutdown
    should terminate server side processing. ORB::destroy should terminate
    the client side processing.

  • Reported: CORBA 2.4.1 — Sat, 20 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Encodings of Sequences of Certificates are not standard.

  • Key: CORBA3-23
  • Legacy Issue Number: 4156
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Explicit ASN.1 definitions of a sequence of certificates make a single
    ASN.1 object out of the certificates. This approach is not what most
    systems use today.

    Discussion:

    The CSI::ITTX509CertChain and the CSI::X509AttributeCertChain both
    stipulate that the encodings of these "chains" be a single ASN.1 encoded
    object. Sequences of certificates usually come in the form of a byte
    stream of either ASN.1 DER encoded objects, or PEM encoded objects, (i.e.
    Base64 encodings wrapped with "---BEGIN CERTIFICATE--", "---END
    CERTIFICATE---" lines). It would be ideal to be able to handle both of
    kinds these sequences, since many toolkits work this way already.

    Tool kits that are provided in OpenSSL and Java, namely,
    java.security.cert.CertificateFactory will not be able to handle the
    encoding brought forth by the CSIv2 specification. However, the toolkits
    will be able to handle a stream sequence of ASN.1 or even PEM encoded
    objects, i.e. without the ASN.1 SEQUENCE wrapper.

    Proposed Solution:

    Eliminate the ASN.1 definitions in the specification, namely para 50 that
    defines ASN.1 syntax for a certificate chain (i.e. "CertificateChain"),
    and para 33 thru 34 for the corresponding one that fits the
    AttributeCertificate(i.e. AttributeCertChain and VerifyingChain).

    Furthermore, I believe, that the definition of CSI:ITTX509CertChain be
    eliminated in favor of a single OID that forms a GSS_NT_ExportedName type,
    in which it's name component is simply a non-empty sequence of
    certificates (in any form), as well as creating an OID that stipulates a
    supported name type is a DN, ASN.1 encoded or string form.

  • Reported: CORBA 2.4.1 — Thu, 18 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The proposed change is backward incompatible. Close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Portable interceptors and invocation timeouts

  • Key: CORBA3-20
  • Legacy Issue Number: 3947
  • Status: closed  
  • Source: Progress Software ( Eoghan Glynn)
  • Summary:

    I'd like to raise an issue and garner feedback on the interaction of the
    Messaging timeout QoS policies (or indeed any proprietary invocation
    timeout mechanism) and portable interceptors.

    Where a bound is being imposed on request and/or reply delivery, and
    portable interceptors are present in the client- and/or server-side
    binding, these interceptors surely must be made aware of the relevant
    timeout(s) so that they may bound any potentially blocking activities
    they engage in. Assuming that it would be unacceptable to dictate that
    potentially blocking activity (such as making a subsidiary invocation)
    may not be undertaken in interception point operations, it appears some
    addition to the PortableInterceptor::RequestInfo interface is required
    to facilitate the Messaging timeout policies at least. For instance, the
    absolute request and reply expiry times could be passed as additional
    attributes:

    module PortableInterceptor
    {
    interface RequestInfo

    { // ... readonly attribute TimeBase::UtcT request_end_time; readonly attribute TimeBase::UtcT reply_end_time; }

    ;
    };

    the former bounding the send_request, send_poll,
    receive_request_service_contexts and receive_request interception points
    and the latter bounding the send_reply, send_exception, send_other,
    receive_reply, receive_exception and receive_other interception points.
    Of course this all relies on the discipline of the portable interceptor
    implementor, i.e. that they do not ignore the constraints imposed by the
    timeouts.

  • Reported: CORBA 2.4 — Thu, 12 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing minor codes in Messaging Chapter

  • Key: CORBA3-19
  • Legacy Issue Number: 3914
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

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

  • Reported: CPP 1.1 — Thu, 14 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

wchar endianness

  • Key: CORBA3-22
  • Legacy Issue Number: 4008
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    In a similar vein to Vishy's question about alignment, what should the
    endianness of a word-oriented wchar be? This applies both to single
    wchars, and the separate code points in a wstring. With the 2.3 spec,
    it seemed quite obvious to me that word-oriented wide characters
    should have the same endianness as the rest of the stream. After all,
    they are no different from any other word-oriented type.

    However, with the new 2.4 spec, there is now a bizarre section saying
    that if, and only if, the TCS-W is UTF-16, all wchar values are
    marshalled big-endian unless there is a byte-order-mark telling you
    otherwise. I don't understand the point of this. Section 2.7 of the
    Unicode Standard, version 3.0 says [emphasis mine]:

    "Data streams that begin with U+FEFF byte order mark are likely to
    contain Unicode values. It is recommended that applications sending
    or receiving untyped data streams of coded characters use this
    signature. _If other signaling methods are used, signatures should
    not be employed._"

    It seems quite clear to me that a GIOP stream is a typed data stream
    which uses its own signalling methods. The Unicode standard therefore
    says that a BOM should not be used.

    I guess it's too late to clean up the UTF-16 encoding, but what about
    other word-oriented code sets? What if the end-points have negotiated
    the use of UCS-4? Should that be big-endian unless there's a BOM?
    The spec doesn't say. Even worse, what if the negotiated encoding is
    something like Big5? That doesn't have byte order marks. Big5
    doesn't have a one-to-one Unicode mapping, so it's not sensible to
    always translate to UTF-16.

    GIOP already has a perfectly good mechanism for sorting out this kind
    of issue. Please can wchar be considered on equal footing with all
    other types, and use the stream's endianness?

  • Reported: CORBA 2.4 — Tue, 31 Oct 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No portable way to turn IOR components into object-reference policies

  • Key: CORBA3-21
  • Legacy Issue Number: 3989
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    For instance, OTS has a policy called OTSPolicy. This policy is
    encoded in an IOR component with component id TAG_OTS_POLICY. This
    policy governs how transactions are handled when invocations are made
    on the object reference.

    Problem:

    As an end user I would like to be able to interrogate the value of this
    policy. I would expect to be able to call CORBA::Object::_get_policy
    with the OTS PolicyType identifier to retrieve the OTSPolicy and
    subsequently determine the value. However, at present there is no
    portable way to turn this IOR component into a policy.

  • Reported: CORBA 2.4 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    This is in essence the same as issue 3615. Merge with 3615 and close this issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Portable Interceptors / register_initial_reference()

  • Key: CORBA3-15
  • Legacy Issue Number: 3672
  • Status: closed  
  • Source: International Business Machines ( Mr. Phil Adams)
  • Summary:

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

    The interface for this function is as follows:

    void register_initial_reference (
    ObjectId id,
    Object_ptr obj
    );

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

    Here is my proposed resolution:

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

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

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

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

  • Reported: CPP 1.1 — Tue, 6 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Policy Management in Portable Interceptors

  • Key: CORBA3-14
  • Legacy Issue Number: 3615
  • Status: closed  
  • Source: foxfield-sw.demon.co.uk ( Nick Sharman)
  • Summary:

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

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

    I suggest something like:

    local interface ReceiveIORInterceptor : Interceptor

    { void establish_policies (in ReceiveIORInfo info); }

    ;

    local interface ReceiveIORInfo

    { CORBA::Policy set_policy (in CORBA::Policy policy); IOP::TaggedComponent get_ior_component (); IOP::TaggedComponent get_ior_component_from_profile ( in IOP::ProfileId profile_id); }

    ;

    and an extra operation add_receive_ior_interceptor in ORBInitInfo.

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

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

  • Reported: CPP 1.1 — Mon, 15 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORBInitInfo needs the ORB

  • Key: CORBA3-9
  • Legacy Issue Number: 3429
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

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

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

  • Reported: CPP 1.1 — Thu, 16 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PI needs the ORB to be available in IDL

  • Key: CORBA3-8
  • Legacy Issue Number: 3403
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

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

    1. Define the ORB as "native ORB;"

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

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

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

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

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

    4. Make the ORB a primitive type like TypeCode.

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

  • Reported: CPP 1.1 — Thu, 16 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Question about routing policies

  • Key: CORBA3-7
  • Legacy Issue Number: 3355
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

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

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

  • Reported: CPP 1.1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Portable Interceptors: object_to_string, string_to_object

  • Key: CORBA3-6
  • Legacy Issue Number: 3322
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    object_to_string and string_to_object are missing on ORBInitInfo.

  • Reported: CPP 1.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Implementing proper handling of CloseConnection

  • Key: CORBA3-5
  • Legacy Issue Number: 3076
  • Status: closed  
  • Source: ZeroC ( Marc Laukien)
  • Summary:

    The CORBA 2.3 spec says in chapter 15.7.1:

    "After receiving a CloseConnection message, an ORB must close the TCP/IP
    connection. After sending a CloseConnection, an ORB may close the TCP/IP
    connection immediately, or may delay closing the connection until it
    receives an
    indication that the other side has closed the connection. For maximum
    interoperability with ORBs using TCP implementations which do not
    properly implement orderly shutdown, an ORB may wish to only shutdown
    the sending side of the connection, and then read any incoming data
    until it receives an indication that the other side has also shutdown,
    at which point the TCP connection can be closed completely."

    Most (or all?) Unix TCP/IP implementations suffer from the problem
    described above, i.e., with most Unix TCP/IP implementations the last
    message sent is discarded if the connection is closed. The workaround,
    to shut down the sending side only, and then to read data until EOF is
    received, works fine for C++ ORBs.

    However, there is no equivalent to shutdown() in Java, so I don't see
    any way to reliably transmit the CloseConnection message from a Java ORB
    running on Unix.

    Questions:

    • Is there perhaps some other way to reliably transmit the last message
      before closing the connection, using Java running on Unix?
    • If not, doesn't this mean that IIOP's connection closure strategy is
      unimplementable in Java under most Unixes?
  • Reported: CORBA 2.3.1 — Fri, 3 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, close, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Overriding POA policies

  • Key: CORBA3-13
  • Legacy Issue Number: 3609
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    it appears to be impossible to portably attach OTS policies
    to POAs with the machinery that is currently in place. We need a fix for
    that, otherwise OTS ends up getting hamstrung...

  • Reported: CPP 1.1 — Mon, 15 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Portable Interceptors: 9.2.3 text describing `Arguments'

  • Key: CORBA3-12
  • Legacy Issue Number: 3601
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

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

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

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

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

  • Reported: CPP 1.1 — Wed, 3 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No way to detect that ORB has outstanding deferred synchronous requests

  • Key: CORBA3-2
  • Legacy Issue Number: 2299
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: There is currently no way to detect that an ORB has outstanding
    deferred synchronous requests. In the DII, this was possible via
    the blocking ORB::get_next_response operation. A mechanism is needed so
    that applications can (for example) shutdown gracefully
    only after all outstanding deferred synchronous operations have
    returned results.

  • Reported: CORBA 2.2 — Thu, 7 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

constant decls broken

  • Key: CORBA3-1
  • Legacy Issue Number: 1139
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    Summary: When the extended IDL types were added to CORBA, the semantics of IDL
    constant declarations seems to have been broken. In CORBA 2.0 (July
    1995) the third paragraph of section 3.7.2 page 3-18 states:

    "An integer constant expression is evaluated as unsigned long unless
    it contains a negated integer literal or the name of an integer
    constant with a negative value. In the latter case, the constant
    expression is evaluated as signed long. The computed value is coerced
    back to the target type in constant initializers. It is an error if
    the computed value exceeds the precision of the target type. It is an
    error if any intermediate value exceeds the range of the evaluated-as
    type (long or unsigned long)."

    The paragraph following the one quoted above explains the same for
    floating-point constants.

    Unfortunately, CORBA 2.2 has broken this. Section 3.7.2, page 3-20,
    of formal/98-02-01 tells us what to do if types are long, unsigned
    long, long long, unsigned long long, double, and long double, but the
    old text stating how general integer constants and floating point
    constants were evaluated has been completely removed! How should the
    following be evaluated?

    const short S = 1 + 2;

  • Reported: CORBA 2.2 — Wed, 15 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

scheme name for IORs

  • Key: CORBA3-4
  • Legacy Issue Number: 2785
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The syntax for stringified IORs in section 13.6.6 shows:

    <prefix> = "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.

  • Reported: CORBA 2.3 — Thu, 1 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Already fixed in CORBA 3.0, close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

issue with ForwardRequest exception in POA

  • Key: CORBA3-3
  • Legacy Issue Number: 2431
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The ForwardRequest exception in the POA specification doesn"t allow the
    servant manager to specify whether the status of the GIOP reply is
    LOCATION_FORWARD or LOCATION_FORWARD_PERM. If an application is designed
    to use ForwardRequest exceptions, then it should be able to state whether
    the new object reference is transient or permanent.

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 13C-36: Editorials

  • Key: CORBA21-31
  • Legacy Issue Number: 711
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The typpedef enum at top of page should be called CORBA_CompletionStatus, not CORBA_ExceptionType. Second line 4th paragraph, text should refer to table 13-5, not 3-5

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    closed with issue 901-2 revision text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

More wrong references in chapetr 11

  • Key: CORBAE-17
  • Legacy Issue Number: 11416
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Section 11 starts with the note that 8.3.4.12 is not required for CORBA/e micro (which should be 11.3.4.12). But the consolidated IDL for corba/e micro does mention this method, probably it needs to removed from there. Maybe also add a note about this to 11.3.4.12

  • Reported: CORBAe 1.0b1 — Mon, 17 Sep 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Upon further discussion, use cases that demonstrated the need for either
    create_reference or create_reference_with_id in either profile are
    lacking. (create_reference and create_reference_with_id were
    developed for use with Servant Managers, mainly). Therefore, both of these operations
    are removed from the Compact and from the Micro profile.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong references in chapter 11

  • Key: CORBAE-16
  • Legacy Issue Number: 11415
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Chapter 11 starts with the text below, see that it references chapter 8, that should be 11: Conformant implementations of the CORBA/e Compact Profile must comply with clauses 8.1, 8.2, 8.3 and 8.4.1 of this chapter. Conformant implementations of the CORBA/e Micro Profile must support a single root POA and must comply with clauses 8.1, 8.2, 8.3 (except 8.3.4.1, 8.3.4.2, 8.3.4.4, 8.3.4.9, and 8.3.4.12) and 8.4.2 of this chapter.

  • Reported: CORBAe 1.0b1 — Mon, 17 Sep 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Change as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA/e and get_interface

  • Key: CORBAE-13
  • Legacy Issue Number: 11324
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    A question, when I look at the CORBA/e compact info it says: no DII, DSI,
    Interface Repository, or Component support.

    But, when looking at the spec, CORBA::Object does deliver get_interface,
    which is documented as below. Why does CORBA/e state that we don't support
    the interface repository, but we do deliver an operation for it?

  • Reported: CORBAe 1.0b1 — Fri, 31 Aug 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    close

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 9.2.1.1

  • Key: CORBAE-12
  • Legacy Issue Number: 11306
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    A question, when I look at the CORBA/e compact info it says: no DII, DSI, Interface Repository, or Component support. But, when looking at the spec, CORBA::Object does deliver get_interface, which is documented as below. Why does CORBA/e state that we don’t support the interface repository, but we do deliver an operation for it? Shouldn't get_interface be removed from CORBA/e? >From the spec: get_interface, returns an object in the Interface Repository that describes the most derived type of the object addressed by the reference. 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. If the interface repository is not available, get_interface raises INTF_REPOS with standard 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 standard minor code 2.

  • Reported: CORBAe 1.0b1 — Sat, 25 Aug 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    get_interface should be excluded from both profiles for the stated reasons.
    get_interface was not included in the Minimum CORBA specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.2

  • Key: CORBAE-18
  • Legacy Issue Number: 12211
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    At the end of section 8.2, there are several sentences that are incomplete and missing cross references

  • Reported: CORBAe 1.0b1 — Tue, 5 Feb 2008 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Add the description of register_initial_reference from section 21.8.1 in
    CORBA 3.0.3 to the specification. (It is somewhat misplaced in the CORBA 3.0.3
    specification).
    Add correct cross references to the last three sentences before section 8.2.1.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.4.1

  • Key: CORBAE-15
  • Legacy Issue Number: 11334
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On this page we have: #if ! defined (CORBA_E_MICRO) // POA attributes readonly attribute string the_name; readonly attribute POA the_parent; readonly attribute POAManager the_POAManager; But there is not endif associated with the !defined

  • Reported: CORBAe 1.0b1 — Fri, 7 Sep 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Since 11.4.1 is confined to the Compact profile and section 11.4.2 separately
    shows the interface supported by the Micro profile, the #if statements are
    redundant and should be removed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 18.2.2

  • Key: CORBAE-14
  • Legacy Issue Number: 11331
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 18.2.2 the get_implementation method is mentioned, but this is not mentioned anywhere else in this spec, should the get_implementation be part of CORBA/e, to my idea not

  • Reported: CORBAe 1.0b1 — Fri, 7 Sep 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    The contents of the Interoperability sections were not touched, only reorganized.
    However, get_implementation was deprecated in CORBA 2.2, and should be
    removed from this document and from the “full” CORBA specification.
    Issue opened with CORBA RTF to reconcile.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 6.2.12

  • Key: CORBAE-11
  • Legacy Issue Number: 11113
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    for localobject the interfaces are listed that raise a no_implement, but some methods are listed that are not part of corba/e, like get_component, I think these methods should be removed

  • Reported: CORBAe 1.0b1 — Tue, 26 Jun 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Change as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The removal of static any from micro

  • Key: CORBAE-10
  • Legacy Issue Number: 10599
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Problem: The use of static any may be needed in a micro profile. For example, SDR Deployment and Configuration which can be done for embedded constrained environments for signal processing environments such as DSP and RTL devices need this capability.

    Suggested Change

    Make the static any as an optional compliance point that is not mandatory but is part of the profile.

  • Reported: CORBAe 1.0b1 — Fri, 19 Jan 2007 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Servant_to_id clarification

  • Key: CORBAE-9
  • Legacy Issue Number: 10522
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the OMG spec the servant_to_id is described as below. If the RETAIN,
    NO_IMPLICIT_ACTIVATION an UNIQUE has been set then the pre condition is
    valid so we don't get wrong policy. Then we follow the steps, 1 is not
    possible, 2 is also not possible, 3 is not possible, so 4 is triggered but
    that looks very strange. I think there should be another step says if RETAIN
    and UNIQUE and NO_IMPLICIT_ACTIVATION and not active then we get
    WrongPolicy. Ok, the servant is not active, but it is more that the policies
    are wrong.

    This appeared when testing for CORBA/e compact. There RETAIN,
    NO_IMPLICIT_ACTIVATION and UNIQUE are the default and without a special
    check for CORBA/e we got a ServantNotActive exception instead of the wrong
    policy. We could add a check for CORBA/e compact but it looks that the real
    issue is in the core spec already.

    Johnny

    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.
    This operation has four possible behaviors.
    1. If the POA has both the RETAIN and the UNIQUE_ID policy and the specified
    servant is active, the Object Id associated with that servant is returned.
    March 2004 CORBA, v3.0.3: Interfaces 11-43
    11
    2. If the POA has both the RETAIN and 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.
    3. If the POA has the USE_DEFAULT_SERVANT policy, the servant specified is
    the
    default servant, and the operation is being invoked in the context of
    executing a
    request on the default servant, then the ObjectId associated with the
    current
    invocation is returned.
    4. Otherwise, the ServantNotActive exception is raised.

  • Reported: CORBAe 1.0b1 — Tue, 12 Dec 2006 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.2.3

  • Key: CORBAE-8
  • Legacy Issue Number: 10507
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    What is the exact implicit activation policy the root poa should support for CORBA/e compact and micro. The page 175 says IMPLICIT_ACTIVATION but section 11.3.3.2 and 11.3.3.1 say NO_IMPLICIT_ACTIVATION

  • Reported: CORBAe 1.0b1 — Thu, 7 Dec 2006 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    NO_IMPLICIT_ACTIVATION was the intent

  • Updated: Fri, 6 Mar 2015 20:58 GMT

document style and use of headings

  • Key: CORBAE-7
  • Legacy Issue Number: 9926
  • Status: closed  
  • Source: Objective Interface Systems ( Dr. Ben A. Calloni)
  • Summary:

    In each of 2.4.1 thru 2.4.4 the document titles have paragraphs below them and if necessary then sub headings. In 2.4.5 there is the title and then a sub heading.

    I'd recommend deleting the heading of 2.4.5.1 and make 2.4.5 the Quality of Service Abstract Model (or Quality of Service Model to match 2.4.1 - 2.4.4 and put the rest of the text under it

    As reads:

    2.4.5Quality of Service

    2.4.5.1 QoS Abstract Model The abstract model describes the Quality of Service (QoS) components and their relationships. The specification defines a framework within which current QoS levels are queried and overridden. This framework is intended to be of use for CORBAServices specifiers, as well as for future revisions of CORBA.

    To read:

    2.4.5Quality of Service (Abstract) Model
    The abstract model describes the Quality of Service (QoS) components and their relationships. The specification defines a framework within which current QoS levels are queried and overridden. This framework is intended to be of use for CORBAServices specifiers, as well as for future revisions of CORBA.

  • Reported: CORBAe 1.0b1 — Tue, 18 Jul 2006 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Change as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 6.2

  • Key: CORBAE-6
  • Legacy Issue Number: 9809
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The InvalidPolicies exception uses an anonymous sequence as member. Instead of exception InvalidPolicies

    { sequence <unsigned short> indices; }

    ; It should be exception InvalidPolicies

    { UShortSeq indices; }

    ;

  • Reported: CORBAe 1.0b1 — Thu, 8 Jun 2006 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Accepted as suggested.
    Issue opened with CORBA RTF to reconcile.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add table that captures the features that are in/out of CORBA/e

  • Key: CORBAE-5
  • Legacy Issue Number: 9756
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    The whole spec is apparently a subset (with rationale) with compliance points of the original CORBA spec. There should be a table that captures the features that are in/out of CORBA/e so that readers can determine quickly what is in the CORBA/e spec (or out), and how it differs.

    Same would apply to CORBA/i when it becomes available.

  • Reported: CORBAe 1.0b1 — Tue, 14 Feb 2006 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Accept as suggested: developed and added comparison table as Annex B.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

state machine diagram

  • Key: CORBAE-4
  • Legacy Issue Number: 9755
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    The "state machine diagram" on pg 8-13 of the 473 page spec isn't UML. (See the dotted state.)

  • Reported: CORBAe 1.0b1 — Tue, 14 Feb 2006 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Correct diagram (now 11-5) to “proper syntax”.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Validity of object references

  • Legacy Issue Number: 3307
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Section 15.4.5, page 15-39:

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

    • whether the object reference is valid

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

  • Reported: CPP 1.1 — Wed, 9 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    close with revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

An ORB should not accept an IOR with no usable profiles

  • Legacy Issue Number: 3303
  • Status: closed  
  • Source: Xerox ( Bill Janssen)
  • Summary:

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

  • Reported: CPP 1.1 — Wed, 9 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    accomodated by proposed change from Issue 3234.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Should an ORB be allowed to drop non-standard profiles

  • Legacy Issue Number: 3235
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

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

  • Reported: CPP 1.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

selected_profile_index origin

  • Legacy Issue Number: 3622
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

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

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

  • Reported: CPP 1.1 — Thu, 18 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Accept proposed solution.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Absence of Wide Character Code Set

  • Legacy Issue Number: 3576
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

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

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

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

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

  • Reported: CPP 1.1 — Fri, 21 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORB throwing exception if it finds unknown service context

  • Legacy Issue Number: 3565
  • Status: closed  
  • Source: UBS ( Urs Kuenzler)
  • Summary:

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

  • Reported: CPP 1.1 — Fri, 14 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong minor code specified in Chapter 13

  • Legacy Issue Number: 3561
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

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

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

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

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

  • Reported: CPP 1.1 — Fri, 14 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 13-1 needs update for valuetypes & abstract interfaces

  • Legacy Issue Number: 3128
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Table 13-1 is missing a row:

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

  • Reported: CORBA 2.3.1 — Thu, 16 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    add table row as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

marshalling of null values unclear

  • Legacy Issue Number: 3102
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

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

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

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

    to close with revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CDR Encapsulation Issue

  • Legacy Issue Number: 3096
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

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

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

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

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

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

  • Reported: CORBA 2.3.1 — Tue, 7 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Preserving unencapsulated information

  • Legacy Issue Number: 3327
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 15-50 of 2.3.1:

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

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

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

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

  • Reported: CPP 1.1 — Thu, 17 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close with revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Indirection for value types

  • Legacy Issue Number: 3315
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Section 15.3.4, page 15-18:

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

    [...]

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

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

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

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

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

  • Reported: CPP 1.1 — Fri, 11 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    close with revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

chunked value encoding:

  • Legacy Issue Number: 3231
  • Status: closed  
  • Source: Anonymous
  • Summary:

    a chunk can be followed by:

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

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

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

  • Reported: CPP 1.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA 2.3.1 missing text describing the response_expected field

  • Legacy Issue Number: 3195
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

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

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Supporting TAG_MULTIPLE_COMPONENTS

  • Legacy Issue Number: 3176
  • Status: closed  
  • Source: Borland Software Corporation ( Vishy Kasar)
  • Summary:

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

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

  • Reported: CPP 1.1 — Tue, 4 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close with no revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GIOP version and CloseConnection

  • Legacy Issue Number: 3438
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

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

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

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

  • Reported: CPP 1.1 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    To close with revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Valuetype in anys. Unmarshaling problem?

  • Legacy Issue Number: 3434
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

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

    Consider the following:
    valuetype A

    { A a; }

    ;

    valuetype B : A

    { private long long x; }

    ;

    If an instance w/ the following structure:

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

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

    Am I missing something here?

  • Reported: CPP 1.1 — Mon, 20 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Transferring Java exception reason string across the wire

  • Legacy Issue Number: 3405
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

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

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

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

    Java bindings do not need to change for this proposal.

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

    const ServiceId SystemExceptionReason = TBD;

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

  • Reported: CPP 1.1 — Tue, 21 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Nesting depth in valuetype end tags

  • Legacy Issue Number: 3526
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

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

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

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

    However the spec also says:

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

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

    Proposed resolution:

    Delete the second above sentence from the spec.

  • Reported: CPP 1.1 — Fri, 31 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close with revision using alternative A above.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Valuetype encoding grammar in 15.3.4.7 is wrong

  • Legacy Issue Number: 3512
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

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

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

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

    -

  • Reported: CPP 1.1 — Wed, 29 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Marshaling fixed-point decimal types

  • Legacy Issue Number: 3431
  • Status: closed  
  • Source: Oracle ( Stefan Bauer)
  • Summary:

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

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

  • Reported: CPP 1.1 — Thu, 16 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close with no Interop Revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IIOP 1.2 Early Reply message in presence of fragmented Request

  • Legacy Issue Number: 3409
  • Status: closed  
  • Source: ICL ( Chris Wood)
  • Summary:

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

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

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

  • Reported: CPP 1.1 — Wed, 8 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    close without revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor code allocation inconsistency

  • Legacy Issue Number: 3040
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

    CORBA 2.3, section 15.4.3.2 - Reply Body - states:

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

    Section 3.17 - Standard Exceptions - states:

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

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

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

  • Reported: CORBA 2.3.1 — Fri, 12 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Take proposed resolution from Core RTF discussion in issue Archive

  • Updated: Fri, 6 Mar 2015 20:58 GMT

.Passing the interface repository ID of the method in IIOP

  • Legacy Issue Number: 2031
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

  • Reported: CORBA 2.2 — Mon, 5 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chunked GIOP marshalling for variable-length types

  • Legacy Issue Number: 1677
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

  • Reported: CORBA 2.2 — Tue, 14 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TAG_ENDPOINT_ID_POSITION and TAG_LOCATION_POLICY

  • Legacy Issue Number: 1303
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

  • Reported: CORBA 2.2 — Mon, 4 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Optimization of LOCATION_FORWARD replies

  • Legacy Issue Number: 1133
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

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

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Compacting GIOP Requests by hashing down operation names

  • Legacy Issue Number: 1132
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GIOP encoding of nil Abstract Interface is unspecified

  • Legacy Issue Number: 2333
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Compacting GIOP Messages by using templates

  • Legacy Issue Number: 1131
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Compacting GIOP messages by using indirections

  • Legacy Issue Number: 1130
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of the type ComponentHome

  • Legacy Issue Number: 3645
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

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

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    You are correct. ComponentHome should be CCMHome

  • Updated: Fri, 6 Mar 2015 20:58 GMT

USING Components::Enumeration

  • Legacy Issue Number: 3418
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

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

  • Reported: CPP 1.1 — Tue, 14 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    resolution see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

destroy() for local objects

  • Legacy Issue Number: 3236
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

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

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

  • Reported: CPP 1.1 — Wed, 19 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

New IDL keywords

  • Legacy Issue Number: 3216
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

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

  • Reported: CPP 1.1 — Wed, 12 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Implementation of get_component

  • Legacy Issue Number: 3213
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

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

  • Reported: CPP 1.1 — Wed, 12 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    closed issue, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA IR METAMODEL

  • Legacy Issue Number: 3207
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

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

  • Reported: CPP 1.1 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Is the ccm_home method shown in Table 8-1 a typo?

  • Legacy Issue Number: 3191
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

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

    Proposal:

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

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How is CCMHome::get_home_def mapped to EJB operations?

  • Legacy Issue Number: 3190
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

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

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

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

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What's the return type of CCM mappings of EJB finder and creator methods?

  • Legacy Issue Number: 3189
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    Summary:

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

    Proposal:

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

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Do EJB-mapped attributes go to the ComponentDefault interface?

  • Legacy Issue Number: 3187
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

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

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

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

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CCM Issue: Is CCMObject::remove intended to be available to the CCM client?

  • Legacy Issue Number: 3183
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

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

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

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

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Small optimization for the GIOP header

  • Legacy Issue Number: 3708
  • Status: closed  
  • Source: University of California, Irvine ( Carlos O'Ryan)
  • Summary:

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

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

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

  • Reported: CPP 1.1 — Fri, 16 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

interop issue: CodeSets service context in GIOP 1.0 request

  • Legacy Issue Number: 3681
  • Status: closed  
  • Source: Xerox ( Bill Janssen)
  • Summary:

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

    IOR:000000000000002849444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578743A312E300000000002000000000000002F0001000000000016776174736F6E2E706172632E7865726F782E636F6D00270F0000000B4E616D6553657276696365000000000100000024000100000000000100000001000000140001001800010001000000000001010000000000

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

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

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

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

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

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

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

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

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

  • Reported: CPP 1.1 — Wed, 5 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    close with revision. See below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Version and byte order changes when fragmenting messages (interop)

  • Legacy Issue Number: 3680
  • Status: closed  
  • Source: ICL ( Chris Wood)
  • Summary:

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

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

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

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

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

  • Reported: CPP 1.1 — Fri, 16 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue 2 -- resulting from UK comment UK-5:

  • Legacy Issue Number: 3624
  • Status: closed  
  • Source: Object Management Group ( Henry Lowe)
  • Summary:

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

  • Reported: CPP 1.1 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close without revision.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue 1 -- resulting from Japanese comment JPN-009E:

  • Legacy Issue Number: 3623
  • Status: closed  
  • Source: Object Management Group ( Henry Lowe)
  • Summary:

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

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

  • Reported: CPP 1.1 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Agree that this was an editorial oversight in corba 2.3.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

wchar alignment in GIOP 1.2

  • Legacy Issue Number: 4007
  • Status: closed  
  • Source: Borland Software Corporation ( Vishy Kasar)
  • Summary:

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

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

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

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

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

  • Reported: CORBA 2.4 — Tue, 31 Oct 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close with revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Is padding necessary for empty Reply body?

  • Legacy Issue Number: 3792
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

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

  • Reported: CPP 1.1 — Fri, 25 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Agree to add equivalent text for reply bodies.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GIOP _get_domain_managers ambiguous

  • Legacy Issue Number: 3787
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

    interface I

    { readonly attribute long domain_managers; }

    ;

  • Reported: CPP 1.1 — Fri, 18 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CCM Issue: How are standard EJB exceptions mapped into the CCM View

  • Legacy Issue Number: 3182
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

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

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

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

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Should Components::Enumeration be an IDL interface or an IDL abstract value

  • Legacy Issue Number: 3099
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

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

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

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

  • Reported: CORBA 2.3.1 — Wed, 8 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Define Components::Enumeration as an IDL abstract valuetype

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CCM Issue: Is a home needed?

  • Legacy Issue Number: 3066
  • Status: closed  
  • Source: Oracle ( Dan Frantz)
  • Summary:

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

  • Reported: CORBA 2.3.1 — Thu, 2 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    A component must have a home

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Components Issues - Interface Repository ptc/99-10-03

  • Legacy Issue Number: 3063
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

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

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

  • Reported: CORBA 2.3.1 — Mon, 22 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Components Issues - Chapter 61 ptc/99-10-04

  • Legacy Issue Number: 3060
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

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

    { FeatureName name; any value; }

    ;
    with
    valuetype ConfigValue

    { public FeatureName name; public any value; }

    ;

  • Reported: CORBA 2.3.1 — Mon, 22 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

implementing import for C++

  • Legacy Issue Number: 2973
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

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

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

  • Reported: CORBA 2.3.1 — Fri, 29 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Policies not locality-constrained?

  • Legacy Issue Number: 2611
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CPP 1.0 — Fri, 16 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close, no change (for 2.4).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Locality-constrained objects

  • Legacy Issue Number: 2301
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

    This seems rather strange.

  • Reported: CORBA 2.2 — Sun, 10 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    close, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Locality constrained objects + externalization

  • Legacy Issue Number: 2204
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.2 — Wed, 11 Nov 1998 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4
  • Disposition Summary:

    issue closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Nested Recursive Structs Legal in 2.3.x?

  • Legacy Issue Number: 3764
  • Status: closed  
  • Source: Perot Systems ( Bill Binko)
  • 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.

  • Reported: CORBA 2.3.1 — Tue, 25 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close no change with explanation as above.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

incomplete rules for forward declaration of structs/unions

  • Legacy Issue Number: 3751
  • Status: closed  
  • Source: ICL ( Trevor Nash)
  • 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.

  • Reported: CORBA 2.3.1 — Sat, 8 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

read_fixed() and write_fixed() methods missing

  • Legacy Issue Number: 3799
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • 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.

  • Reported: CORBA 2.3.1 — Thu, 31 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Initializers and user exceptions

  • Legacy Issue Number: 3781
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • 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?

  • Reported: CORBA 2.3.1 — Wed, 9 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No won for B above so this issue is closed no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL: Clashes with inherited identifiers

  • Legacy Issue Number: 3768
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • 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.

  • Reported: CORBA 2.3.1 — Mon, 31 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close no change with explanation as above.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Should POA spec examples use string_to_ObjectId?

  • Legacy Issue Number: 3918
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • 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?

  • Reported: CORBA 2.3.1 — Thu, 28 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Resolve no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Values for CORBA::ARG_IN,... not defined

  • Legacy Issue Number: 3905
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • 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).

  • Reported: CORBA 2.3.1 — Wed, 20 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

module IOP_N needs a real name

  • Legacy Issue Number: 3877
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • 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.

  • Reported: CORBA 2.3.1 — Tue, 19 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"omg.org" prefix missing from interceptor specification and its reference

  • Legacy Issue Number: 3862
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • 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.

  • Reported: CORBA 2.3.1 — Tue, 19 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The last sentence of the summary states the way things are, so there really is no issue here

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORB ID accessor

  • Legacy Issue Number: 3817
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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(); // ... }

    ;

  • Reported: CORBA 2.3.1 — Fri, 8 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Add the proposed accessor to ORB.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ValueMemberDef section omitted from CORBA 2.3.1 spec

  • Key: CORBA24-85
  • Legacy Issue Number: 3560
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.3.1 — Thu, 13 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Missing section should be filled in

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inheritance description incorrect

  • Key: CORBA24-84
  • Legacy Issue Number: 3525
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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; }

    ;

  • Reported: CORBA 2.3.1 — Fri, 31 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Fix as suggested below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORB mediation for servant managers, references for servant managers?

  • Key: CORBA24-83
  • Legacy Issue Number: 3460
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.3.1 — Tue, 28 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Merge into Issue 4264 and close this with the resolution of 4264.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Policy Management in the ORB core

  • Key: CORBA24-92
  • Legacy Issue Number: 3614
  • Status: closed  
  • Source: foxfield-sw.demon.co.uk ( Nick Sharman)
  • 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.

  • Reported: CORBA 2.3.1 — Mon, 15 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Some problems

  • Key: CORBA24-91
  • Legacy Issue Number: 3612
  • Status: closed  
  • Source: Anonymous
  • 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....

  • Reported: CORBA 2.3.1 — Mon, 15 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close no change with explanation as above.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORB shutdown vs destroy

  • Key: CORBA24-90
  • Legacy Issue Number: 3608
  • Status: closed  
  • Source: Borland Software Corporation ( Vishy Kasar)
  • 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?

  • Reported: CORBA 2.3.1 — Fri, 12 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

With reference to forward declarations of structs and unions.

  • Legacy Issue Number: 3749
  • Status: closed  
  • Source: ICL ( Trevor Nash)
  • 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.

  • Reported: CORBA 2.3.1 — Sat, 8 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is inconsistency in the POA.IDL and description in section 11.3.8.19

  • Legacy Issue Number: 3743
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • 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.

  • Reported: CORBA 2.3.1 — Fri, 14 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The POA IDL should be fixed by removing the raises(WrongPolicy) clause

  • Updated: Fri, 6 Mar 2015 20:58 GMT

description of unknown_adapter

  • Legacy Issue Number: 3740
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • 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.

  • Reported: CORBA 2.3.1 — Wed, 5 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clearly the current text potentially leads readers astray, so clarify it as shown below:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

reference_to_servant raises ObjectNotActive, WrongAdapter, and WrongPolicy

  • Key: CORBA24-99
  • Legacy Issue Number: 3739
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • 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.

  • Reported: CORBA 2.3.1 — Wed, 5 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Fix the editorial error

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing exception for activation

  • Key: CORBA24-98
  • Legacy Issue Number: 3738
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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...

  • Reported: CORBA 2.3.1 — Wed, 5 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The proposed clarification is in order.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AbstractBase not declared.

  • Key: CORBA24-97
  • Legacy Issue Number: 3737
  • Status: closed  
  • Source: Département Informatique & Réseaux ( Thomas Quinot)
  • 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

  • Reported: CORBA 2.3.1 — Tue, 4 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Declaration of native AbstractBase needs to be added to orb.idl as stated above.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POA deactivate_object description is ambiguous

  • Key: CORBA24-82
  • Legacy Issue Number: 3449
  • Status: closed  
  • Source: Borland Software Corporation ( Vishy Kasar)
  • 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?

  • Reported: CORBA 2.3.1 — Thu, 23 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

how are valid ORBids determined

  • Key: CORBA24-81
  • Legacy Issue Number: 3443
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • 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.

  • Reported: CORBA 2.3.1 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate change and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POA namespace and ORB ID

  • Key: CORBA24-80
  • Legacy Issue Number: 3441
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • 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.

  • Reported: CORBA 2.3.1 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clarifying sentence is justified.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

servant_to_id versus servant_to_reference

  • Key: CORBA24-94
  • Legacy Issue Number: 3636
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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?

  • Reported: CORBA 2.3.1 — Mon, 22 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORB::shutdown underspecified

  • Key: CORBA24-93
  • Legacy Issue Number: 3618
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.3.1 — Wed, 17 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect use of negative fixed scale

  • Key: CORBA24-87
  • Legacy Issue Number: 3581
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • 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>."

  • Reported: CORBA 2.3.1 — Tue, 25 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Remove the specification for stripping leading and trailing zeros, and fix the examples accordingly

  • Updated: Fri, 6 Mar 2015 20:58 GMT

is_equivalent and policies

  • Key: CORBA24-86
  • Legacy Issue Number: 3566
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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?

  • Reported: CORBA 2.3.1 — Sat, 15 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POA servant_to_id inconsistent with servant_to_reference

  • Key: CORBA24-89
  • Legacy Issue Number: 3607
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • 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

  • Reported: CORBA 2.3.1 — Wed, 10 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Same as Issue 3636, and is fixed by the fix for 3636.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Valuetypes with multiple interfaces

  • Key: CORBA24-88
  • Legacy Issue Number: 3589
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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!

  • Reported: CORBA 2.3.1 — Fri, 28 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Resolve no change with explanation as above.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pragma version 2.3

  • Key: CORBA24-96
  • Legacy Issue Number: 3694
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Bill Beckwith)
  • 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

    1. 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.

  • Reported: CORBA 2.3.1 — Fri, 9 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Non-escaped keywords in published IDL

  • Key: CORBA24-95
  • Legacy Issue Number: 3685
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.3.1 — Thu, 6 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Fix IDL as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

return type of TypeCode::fixed_scale()

  • Key: CORBA24-79
  • Legacy Issue Number: 3439
  • Status: closed  
  • Source: AdNovum Informatik ( Stefan Wengi)
  • 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.

  • Reported: CORBA 2.3.1 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4
  • Disposition Summary:

    Close no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POA status during destruction is unclear

  • Key: CORBA24-78
  • Legacy Issue Number: 3436
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • 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.

  • Reported: CORBA 2.3.1 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clarify POA behavior during destruction as described below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problem with valuetype parameter copying

  • Key: CORBA24-77
  • Legacy Issue Number: 3364
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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?

  • Reported: CORBA 2.3.1 — Fri, 25 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved, see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ordering issues in the DII

  • Key: CORBA24-64
  • Legacy Issue Number: 3194
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.3.1 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Fix as described above.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Efficient construction of Any types w/o DynamicAny

  • Key: CORBA24-63
  • Legacy Issue Number: 3185
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.3.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Does a value in a valuebox make sense?

  • Key: CORBA24-68
  • Legacy Issue Number: 3220
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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?

  • Reported: CORBA 2.3.1 — Sat, 15 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics for DynAny::equal underspecified

  • Key: CORBA24-67
  • Legacy Issue Number: 3205
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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.

  • Reported: CORBA 2.3.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Resolve as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of COMPLETED_NO needs to be clarified

  • Key: CORBA24-73
  • Legacy Issue Number: 3302
  • Status: closed  
  • Source: BROKAT Informationssysteme ( Blake Biesecker)
  • 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.)

  • Reported: CORBA 2.3.1 — Tue, 8 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor glitch about forward declared things

  • Key: CORBA24-72
  • Legacy Issue Number: 3270
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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:

  • Reported: CORBA 2.3.1 — Fri, 4 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Add the following clarification:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial mistake in IDL chapter

  • Key: CORBA24-70
  • Legacy Issue Number: 3268
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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

  • Reported: CORBA 2.3.1 — Wed, 2 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Move the text in question to a more appropriate place as suggested below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Can native be used in constructed IDL types?

  • Key: CORBA24-69
  • Legacy Issue Number: 3258
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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.

  • Reported: CORBA 2.3.1 — Wed, 26 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

response_flags in interop draft

  • Key: CORBA24-76
  • Legacy Issue Number: 3338
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • 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.

  • Reported: CORBA 2.3.1 — Mon, 21 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved in interop RTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

symbolic constants for minor exception codes

  • Key: CORBA24-75
  • Legacy Issue Number: 3319
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.3.1 — Wed, 16 Feb 2000 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4
  • Disposition Summary:

    Close no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inheritence table 3-10 wrong?

  • Key: CORBA24-66
  • Legacy Issue Number: 3203
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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
  • Reported: CORBA 2.3.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The table needs to be changed to clarify as shown below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

poll_response()

  • Key: CORBA24-65
  • Legacy Issue Number: 3196
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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);

  • Reported: CORBA 2.3.1 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4
  • Disposition Summary:

    Already fixed editorially in draft.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

#pragma rules are too restrictive

  • Key: CORBA24-71
  • Legacy Issue Number: 3269
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.3.1 — Fri, 4 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clarify as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

valuetype factory inheritence?

  • Key: CORBA24-74
  • Legacy Issue Number: 3305
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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."

  • Reported: CORBA 2.3.1 — Wed, 9 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Add clarifying text as shown below:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

special-casing TypeCode is unnecessary

  • Key: CORBA24-62
  • Legacy Issue Number: 3181
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • 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.

  • Reported: CORBA 2.3.1 — Thu, 6 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CDR encoding for fixed

  • Legacy Issue Number: 1653
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The CDR encoding rules for fixed-point types are incomplete.

    In particular, it is not stated which value encodes what digit in each
    nibble of an octet. It seems sensible to use 0x0 -> "0", 0x1 -> "1", ...,
    0x9 -> "9". However, this isn"t stated (but should be).

    The same comment applies to page 7-10 for DynFixed. I would suggest that
    rather than repeat the same explanations in the CDR section and the DynFixed
    section, the spec should use a cross-reference in the DynFixed section that
    points at the CDR rules.

  • Reported: CORBA 2.2 — Thu, 9 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Interop RTF has recommended adoption of this resolution.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

LocateRequest and LocateReply messages

  • Legacy Issue Number: 2494
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: GIOP 1.1 only allows Request and Reply headers to be fragmented. But
    GIOP 1.2 increases the size of LocateRequest messages, and large
    LocateReply messages are also likely. I see no reason why GIOP 1.2
    should not allow LocateRequest and LocateReply messages to be
    fragmented. If noone objects, I"d like to see the following put to a
    vote in the next ORB 2.4 Interoperability RTF for inclusion in CORBA
    2.3:

  • Reported: CORBA 2.2 — Fri, 26 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

profile ids & component ids

  • Legacy Issue Number: 2904
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Dave Stringer)
  • Summary:

    Section 15.7.3 includes TAG_INTERNET_IOP and TAG_MULTIPLE_COMPONENTS
    in the list of tagged component ids when they are tagged profile ids.

  • Reported: CORBA 2.3 — Tue, 28 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    editorial change to CORBA 3.0 resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need clarification on GIOP::TargetAddress

  • Legacy Issue Number: 2940
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    Something seems unclear to me about how to interpret a RequestHeader_1_2
    when the AddressingDisposition of the TargetAddress is ReferenceAddr:

    In the case the request contains a full IOR, which may have several
    profiles. Since each profile has its own object_key, and there is no
    requirement that they all be the same, the key for the operation may
    depend on which profile chosen.

    The client had to choose some profile in order to send the request, but
    that information is not included in the request. So apparently the
    server must decide on its own which profile it would like to use. This
    may not be the same one the client chose.

    What if any requirements are there on how this is done?

  • Reported: CORBA 2.3 — Wed, 22 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    withdrawn by submitter...issue closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors in published IDL for CORBA module

  • Key: CORBA24-51
  • Legacy Issue Number: 3105
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.3.1 — Fri, 10 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Non-standard system exceptions

  • Key: CORBA24-50
  • Legacy Issue Number: 3104
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • 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.

  • Reported: CORBA 2.3.1 — Fri, 10 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    See text below for resolution

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of Principal in GIOP Module erroneous

  • Key: CORBA24-49
  • Legacy Issue Number: 3095
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • 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.

  • Reported: CORBA 2.3.1 — Mon, 6 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed in interop/2000-01-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

valuebox and DynAny

  • Key: CORBA24-56
  • Legacy Issue Number: 3135
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • 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?

  • Reported: CORBA 2.3.1 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Following text changes address the outage raised in this issue as well as the one from issue 3250

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OMG wchar <-> COM WCHAR in CORBA 2.3

  • Key: CORBA24-55
  • Legacy Issue Number: 3134
  • Status: closed  
  • Source: IONA ( Thomas Moriarty)
  • 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?

  • Reported: CORBA 2.3.1 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    OMG IDL wchar should indeed map to COM WCHAR. Add it to table 18-1

  • Updated: Fri, 6 Mar 2015 20:58 GMT

local interfaces and the DII

  • Key: CORBA24-61
  • Legacy Issue Number: 3177
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.3.1 — Wed, 5 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved, see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

servant_to_id

  • Key: CORBA24-60
  • Legacy Issue Number: 3174
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.3.1 — Tue, 4 Jan 2000 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4
  • Disposition Summary:

    Close with no change, since a POA cannot have IMPLICIT_ACTIVATION and USER_ID.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What is the TypeCode for ValueBase?

  • Key: CORBA24-54
  • Legacy Issue Number: 3132
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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.

  • Reported: CORBA 2.3.1 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Yes, this is a signficant outage. It should be fixed and the fix should be incorporated in 2.3 via t

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Do valueboxes have factories?

  • Key: CORBA24-53
  • Legacy Issue Number: 3115
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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."

  • Reported: CORBA 2.3.1 — Tue, 14 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DynAny & abstract interfaces don't mix!

  • Key: CORBA24-52
  • Legacy Issue Number: 3109
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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.

  • Reported: CORBA 2.3.1 — Fri, 10 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

create_POA and inactive state?

  • Key: CORBA24-48
  • Legacy Issue Number: 3073
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.3.1 — Thu, 2 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

value type substitutability

  • Key: CORBA24-47
  • Legacy Issue Number: 3072
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • 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.

  • Reported: CORBA 2.3.1 — Tue, 30 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clarify the ambiguity that leads to the possible inappropriate interpretation

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OMG IDL Syntax and Semantics issue

  • Key: CORBA24-46
  • Legacy Issue Number: 3069
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.3.1 — Mon, 29 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypeCode issue

  • Key: CORBA24-45
  • Legacy Issue Number: 3048
  • Status: closed  
  • Source: ZeroC ( Marc Laukien)
  • 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.

  • Reported: CORBA 2.3.1 — Tue, 23 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL scoping rules

  • Key: CORBA24-59
  • Legacy Issue Number: 3173
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.3.1 — Sun, 2 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Additional clarifying words are needed as shown below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

null & void TCs and DynAny

  • Key: CORBA24-57
  • Legacy Issue Number: 3159
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • 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.

  • Reported: CORBA 2.3.1 — Tue, 21 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clarify with additional text as shown below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Bug in 11.3.7.6

  • Key: CORBA24-58
  • Legacy Issue Number: 3172
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.3.1 — Sun, 2 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Remove the incorrect sentence

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problem with the "Special scoping" rules in 3.15.3

  • Key: CORBA24-37
  • Legacy Issue Number: 2980
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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?

  • Reported: CORBA 2.3.1 — Mon, 8 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The changes below provide clarification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Meaningless sentence on page 3-11?

  • Key: CORBA24-36
  • Legacy Issue Number: 2978
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.3.1 — Wed, 3 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Type Code Section issue

  • Key: CORBA24-32
  • Legacy Issue Number: 2963
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • 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.

  • Reported: CORBA 2.3.1 — Wed, 27 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor codes for Standard System Exceptions in Chapter 8 missing

  • Key: CORBA24-31
  • Legacy Issue Number: 2960
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • 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.

  • Reported: CORBA 2.3.1 — Tue, 26 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor codes for Standard System Exceptions in Chapter 5 missing

  • Key: CORBA24-30
  • Legacy Issue Number: 2959
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • 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.

  • Reported: CORBA 2.3.1 — Tue, 26 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL and C++ relationship

  • Key: CORBA24-34
  • Legacy Issue Number: 2976
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.3.1 — Wed, 3 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PIDL vs Local

  • Key: CORBA24-33
  • Legacy Issue Number: 2974
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • 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.

  • Reported: CORBA 2.3.1 — Mon, 25 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed in interop/2000-01-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing "abstract" in forward declaration

  • Key: CORBA24-40
  • Legacy Issue Number: 3018
  • Status: closed  
  • Source: Perot Systems ( Bill Binko)
  • 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>

  • Reported: CORBA 2.3.1 — Wed, 10 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The algorithm for TypeCode::equivalent in 10.7.1 was not updated

  • Key: CORBA24-39
  • Legacy Issue Number: 3001
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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.

  • Reported: CORBA 2.3.1 — Thu, 4 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial glitch in DynAny::destroy, section 9.2.3.6

  • Key: CORBA24-44
  • Legacy Issue Number: 3041
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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".

  • Reported: CORBA 2.3.1 — Tue, 16 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What is the NO_RESPONSE exception good for?

  • Key: CORBA24-43
  • Legacy Issue Number: 3022
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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?

  • Reported: CORBA 2.3.1 — Fri, 12 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

General Exception Question

  • Key: CORBA24-29
  • Legacy Issue Number: 2955
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • 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.

  • Reported: CORBA 2.3.1 — Tue, 26 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exception section issue

  • Key: CORBA24-28
  • Legacy Issue Number: 2954
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • 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.

  • Reported: CORBA 2.3.1 — Thu, 14 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.6: IDL context housecleaning

  • Key: CORBA24-42
  • Legacy Issue Number: 3021
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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.

  • Reported: CORBA 2.3.1 — Fri, 12 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Question about IDL \uxxxx escape format

  • Key: CORBA24-41
  • Legacy Issue Number: 3020
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Why was the \uxxxx escape from C++ added to wide string & char literals
    in IDL, but the equivalent \Uxxxxxxxx escape was not?

  • Reported: CORBA 2.3.1 — Thu, 11 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Preprocessing of IDL

  • Key: CORBA24-35
  • Legacy Issue Number: 2977
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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.

  • Reported: CORBA 2.3.1 — Wed, 3 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Codeset conversions and unions

  • Key: CORBA24-38
  • Legacy Issue Number: 3000
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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

  • Reported: CORBA 2.3.1 — Thu, 4 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of incomplete recursive TypeCodes underspecified

  • Key: CORBA24-17
  • Legacy Issue Number: 2903
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • 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?
  • Reported: CORBA 2.3.1 — Thu, 14 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of DynAny with alias TypeCodes

  • Key: CORBA24-16
  • Legacy Issue Number: 2901
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • 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.

  • Reported: CORBA 2.3.1 — Thu, 14 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

URLs interact poorly with code set selection

  • Key: CORBA24-15
  • Legacy Issue Number: 2900
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • 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

  • Reported: CORBA 2.3.1 — Tue, 5 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DataInputStream specification is inefficient for Java

  • Key: CORBA24-12
  • Legacy Issue Number: 2892
  • Status: closed  
  • Source: Anonymous
  • 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!)

  • Reported: CORBA 2.3 — Fri, 17 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POA exception minor codes

  • Key: CORBA24-11
  • Legacy Issue Number: 2861
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.3 — Tue, 31 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wchar as discriminator in union

  • Key: CORBA24-10
  • Legacy Issue Number: 2859
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.3 — Thu, 26 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problem with text of POAManager::deactivate()

  • Key: CORBA24-23
  • Legacy Issue Number: 2911
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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?

  • Reported: CORBA 2.3.1 — Mon, 18 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA 2.3 spec hasn't been updated with corrections in COM-CORBA Part B

  • Key: CORBA24-22
  • Legacy Issue Number: 2910
  • Status: closed  
  • Source: Anonymous
  • 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).

  • Reported: CORBA 2.3.1 — Wed, 13 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

creation of arguments to TypeCode creation ops

  • Key: CORBA24-19
  • Legacy Issue Number: 2907
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • 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.

  • Reported: CORBA 2.3.1 — Thu, 14 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DynFixed editorial issue

  • Key: CORBA24-18
  • Legacy Issue Number: 2906
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • 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."

  • Reported: CORBA 2.3 — Wed, 29 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA 2.3 Editorial issue for TypeCodes & abstract_interface

  • Key: CORBA24-27
  • Legacy Issue Number: 2945
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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.

  • Reported: CORBA 2.3.1 — Thu, 21 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial issue for CORBA 2.3, 1.3.8.20

  • Key: CORBA24-26
  • Legacy Issue Number: 2944
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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.

  • Reported: CORBA 2.3.1 — Wed, 20 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA 2.3: minor editorial issue

  • Key: CORBA24-9
  • Legacy Issue Number: 2849
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.3 — Fri, 13 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

chapter 3 and recursion

  • Key: CORBA24-8
  • Legacy Issue Number: 2848
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.3 — Fri, 13 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Component ids in 13.6.2.2

  • Key: CORBA24-25
  • Legacy Issue Number: 2913
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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?

  • Reported: CORBA 2.3 — Tue, 28 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed in interop/2000-01-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

(CORBA Core) Data streams missing arrays of long double

  • Key: CORBA24-24
  • Legacy Issue Number: 2912
  • Status: closed  
  • Source: Oracle ( Dan Frantz)
  • 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.

  • Reported: CORBA 2.3 — Wed, 22 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Why are Standard Exceptions defined in IDL chapter?

  • Key: CORBA24-14
  • Legacy Issue Number: 2898
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • 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.

  • Reported: CORBA 2.3.1 — Wed, 13 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What is the RepId of Object?

  • Key: CORBA24-13
  • Legacy Issue Number: 2896
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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"?"

  • Reported: CORBA 2.3.1 — Wed, 20 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

formal/99-08-01.txt missing pragmas

  • Key: CORBA24-21
  • Legacy Issue Number: 2909
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The ORB Core IDL extracted in formal/99-08-01.txt is missing the various
    '#pragma' definitions for the IFR interfaces.

  • Reported: CORBA 2.3.1 — Tue, 12 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::ORB::RequestSeq definition obsolete

  • Key: CORBA24-20
  • Legacy Issue Number: 2908
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • 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.

  • Reported: CORBA 2.3.1 — Tue, 12 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect IDL is section 5.5.3

  • Key: CORBA23-84
  • Legacy Issue Number: 2539
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Mon, 15 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    make it so.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RMI style repository ID hash code

  • Key: CORBA23-83
  • Legacy Issue Number: 2529
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Fri, 12 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Replace the currently defined algorithm with one that fixes the problem as described below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

forward declaration in ptc/98-10-04

  • Key: CORBA23-82
  • Legacy Issue Number: 2522
  • Status: closed  
  • Source: Anonymous
  • 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(); }

    ;
    };

  • Reported: CORBA 2.2 — Tue, 9 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close no change in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: CORBA24-4
  • Legacy Issue Number: 2828
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: CORBA 2.3 — Mon, 2 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved in interop RTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

mixing giop versions

  • Key: CORBA24-3
  • Legacy Issue Number: 2822
  • Status: closed  
  • Source: Anonymous
  • 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?
  • Reported: CORBA 2.3 — Mon, 26 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed in interop/2000-01-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UNIQUE_ID and ServantActivator issue

  • Key: CORBA23-92
  • Legacy Issue Number: 2576
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Fri, 2 Apr 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate change and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification on IdUniquenessPolicy

  • Key: CORBA23-91
  • Legacy Issue Number: 2574
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 31 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

New "opaque" data type

  • Key: CORBA23-95
  • Legacy Issue Number: 2674
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Sun, 30 May 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DynAny::equal operator issue

  • Key: CORBA23-94
  • Legacy Issue Number: 2616
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 20 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

sharing valuetypes across Anys

  • Key: CORBA23-93
  • Legacy Issue Number: 2577
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should valuetype identity be preserved across arguments when those
    valuetypes reside within Anys?

  • Reported: CORBA 2.2 — Mon, 5 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DynAny.insert_valuetype shoud be insert_val

  • Key: CORBA23-86
  • Legacy Issue Number: 2547
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 16 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    fix the names in section 9.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

confusing rules for operations on Object

  • Key: CORBA23-85
  • Legacy Issue Number: 2543
  • Status: closed  
  • Source: Anonymous
  • 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)
  • Reported: CORBA 2.2 — Tue, 16 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ambiguity in wstrings having a Unicode escape sequence

  • Key: CORBA24-7
  • Legacy Issue Number: 2847
  • Status: closed  
  • Source: Anonymous
  • 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)

  • Reported: CORBA 2.3 — Fri, 13 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POA: false placement of paragraph

  • Key: CORBA24-6
  • Legacy Issue Number: 2846
  • Status: closed  
  • Source: Anonymous
  • 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().

  • Reported: CORBA 2.3 — Sun, 15 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OBV interface support inconsistencies

  • Key: CORBA24-5
  • Legacy Issue Number: 2844
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.3 — Sun, 15 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

activate_object_with_id and exceptions

  • Key: CORBA23-88
  • Legacy Issue Number: 2549
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.2 — Thu, 18 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Repository ID for Object

  • Key: CORBA23-87
  • Legacy Issue Number: 2548
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 17 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    closed in interop/2000-01-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

interop issue: what system exceptions may be raised on GIOP 1.0?

  • Key: CORBA24-2
  • Legacy Issue Number: 2819
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.3 — Wed, 21 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed in interop/2000-01-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The syntax for stringified IORs in section 13.6.6

  • Key: CORBA24-1
  • Legacy Issue Number: 2796
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.3 — Fri, 9 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed in interop/2000-01-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

deactivate_object asymmetry

  • Key: CORBA23-90
  • Legacy Issue Number: 2559
  • Status: closed  
  • Source: Anonymous
  • 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(...);

  • Reported: CORBA 2.2 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORB::shutdown again

  • Key: CORBA23-89
  • Legacy Issue Number: 2553
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 23 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    This issue should be closed no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent spellings of "policy" related identifiers:

  • Key: CORBA23-70
  • Legacy Issue Number: 2454
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.2 — Wed, 17 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close no change in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IR Changes in 2.3

  • Key: CORBA23-69
  • Legacy Issue Number: 2450
  • Status: closed  
  • Source: Anonymous
  • 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!!

  • Reported: CORBA 2.2 — Fri, 12 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    incorporate changes in 2.4 and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interceptors broken

  • Key: CORBA23-63
  • Legacy Issue Number: 2435
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 4 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close in 2.4 with no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

clarification and bug in InterfaceDef::FullInterfaceDescription

  • Key: CORBA23-62
  • Legacy Issue Number: 2432
  • Status: closed  
  • Source: Anonymous
  • 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;

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Try to define obligatory and optional parts of the CORBA specification.

  • Key: CORBA23-61
  • Legacy Issue Number: 2378
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close in 2.4 with no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Application Interface issue

  • Key: CORBA23-60
  • Legacy Issue Number: 2377
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    This issue is adequately dealt with in the POA specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use UNICODE Character set

  • Key: CORBA23-59
  • Legacy Issue Number: 2372
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close issue in 2.4 with no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

LocateReply body alignment issue

  • Key: CORBA23-81
  • Legacy Issue Number: 2521
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Mon, 8 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    closed in interop/2000-01-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POA issue, section 11.3.8.10

  • Key: CORBA23-80
  • Legacy Issue Number: 2513
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Fri, 5 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POA that has IdAssignmentPolicy=SYSTEM--portability problem

  • Key: CORBA23-79
  • Legacy Issue Number: 2511
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 4 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close no change in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Scope of SendingContextRunTime service context

  • Key: CORBA23-76
  • Legacy Issue Number: 2507
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 3 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    closed in interop/2000-01-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need to specify exception for abstract interface error

  • Key: CORBA23-75
  • Legacy Issue Number: 2502
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 3 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Add a new minor code to the BAD_PARAM system exception:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Error in IRObject definition in 98-12-04

  • Key: CORBA23-74
  • Legacy Issue Number: 2492
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Fri, 26 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    They have been fixed in ptc/98-12-04.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What use is CORBA::exception_type?

  • Key: CORBA23-73
  • Legacy Issue Number: 2490
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This enumeration type is defined in 3.17.1, but used no where else. Why
    is it even there?

  • Reported: CORBA 2.2 — Thu, 25 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    incorporate changes in 2.4 and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent Definition of Flags type

  • Key: CORBA23-72
  • Legacy Issue Number: 2487
  • Status: closed  
  • Source: Anonymous
  • 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".

  • Reported: CORBA 2.2 — Wed, 24 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Make it uniformly unsigned long

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::Object::ping ?

  • Key: CORBA23-71
  • Legacy Issue Number: 2456
  • Status: closed  
  • Source: Anonymous
  • 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).

  • Reported: CORBA 2.2 — Thu, 18 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Can an any with a tk_null or tk_void TypeCode be encoded with CDR?

  • Key: CORBA23-78
  • Legacy Issue Number: 2509
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 3 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    closed in interop/2000-01-01

  • Updated: Fri, 6 Mar 2015 20:58 GMT

omg.org prefix not well specified

  • Key: CORBA23-77
  • Legacy Issue Number: 2508
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.2 — Wed, 3 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate change in 2.4 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What value type does ValueDef"s base_value() return?

  • Key: CORBA23-68
  • Legacy Issue Number: 2447
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 9 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inheritance of value types

  • Key: CORBA23-67
  • Legacy Issue Number: 2446
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 9 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    close this issue with the note that it is resolved as part of 2490 in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problems in Chapter 5 IDL

  • Key: CORBA23-66
  • Legacy Issue Number: 2444
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 9 Feb 1999 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.3
  • Disposition Summary:

    Close no change in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POA Construction Policy.

  • Key: CORBA23-65
  • Legacy Issue Number: 2442
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Fri, 5 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

another problem with IDL specification section 3.9.2

  • Key: CORBA23-64
  • Legacy Issue Number: 2436
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 4 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue - no PIDL, just language bindings

  • Key: CORBA23-58
  • Legacy Issue Number: 2371
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue and raise new issue in C++ RTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Grammar section 3.9.2 missing "float" rules, and other problems

  • Key: CORBA23-57
  • Legacy Issue Number: 2343
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Mon, 25 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Sumsume this issue in 1139, and close this issue with that annotation in 2.4.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No description for NativeDef

  • Key: CORBA23-45
  • Legacy Issue Number: 2322
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 10.5.26, NativeDef, has no description of its read and write
    interfaces. This is inconsistent with other sections.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Provide description

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors in figure 10-2

  • Key: CORBA23-44
  • Legacy Issue Number: 2321
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    fix the order and indentation

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Signature of unmarshal method is wrong

  • Key: CORBA23-43
  • Legacy Issue Number: 2320
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 5-11, section 5.5.1, the signature of the unmarshal method is
    wrong. It should return void, not ValueBase.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Fix it

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Value base and the IFR

  • Key: CORBA23-54
  • Legacy Issue Number: 2334
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Add value base to primitive defs.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarifications needed in section 5.2.2

  • Key: CORBA23-53
  • Legacy Issue Number: 2332
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Fix it.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify meaning of no IDL initializers

  • Key: CORBA23-42
  • Legacy Issue Number: 2319
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Fix it

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Misleading text in section 3.2.5.2

  • Key: CORBA23-41
  • Legacy Issue Number: 2318
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Fix it

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Calling get_response twice?

  • Key: CORBA23-56
  • Legacy Issue Number: 2341
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Forward-Declared Interfaces

  • Key: CORBA23-55
  • Legacy Issue Number: 2340
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No description for ValueBoxDef

  • Key: CORBA23-47
  • Legacy Issue Number: 2325
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Provide description

  • Updated: Fri, 6 Mar 2015 20:58 GMT

is_a description is wrong

  • Key: CORBA23-46
  • Legacy Issue Number: 2323
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RMI Repository ID missing from section 10.6

  • Key: CORBA23-50
  • Legacy Issue Number: 2329
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 10.6 needs to be updated to reflect the addition of RMI
    Hashed Format RepositoryIds.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    change introductory sentence to fix this problem in section 10.6

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Text was inserted in wrong place

  • Key: CORBA23-49
  • Legacy Issue Number: 2328
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Make it so

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify text in section 15.3.7

  • Key: CORBA23-52
  • Legacy Issue Number: 2331
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate change in 2.4 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Error in text describing TypeCode interface

  • Key: CORBA23-51
  • Legacy Issue Number: 2330
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Fix it.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Error in ValueDef IDL

  • Key: CORBA23-48
  • Legacy Issue Number: 2327
  • Status: closed  
  • Source: Anonymous
  • 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).

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    The resolution of this is tied to the resolution of issue 2314. So this issue is attached to and sub

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Core uses both "standard" and "system" exception terminology

  • Key: CORBA23-28
  • Legacy Issue Number: 2221
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 19 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

create_policy specification needs to be completed

  • Key: CORBA23-27
  • Legacy Issue Number: 2214
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Mon, 16 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need namespace for Policy Type

  • Key: CORBA23-26
  • Legacy Issue Number: 2206
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 11 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Codebases with multiple URLs

  • Key: CORBA23-40
  • Legacy Issue Number: 2316
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Supporting multiple abstract interfaces

  • Key: CORBA23-39
  • Legacy Issue Number: 2314
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Names of Data*Stream methods

  • Key: CORBA23-38
  • Legacy Issue Number: 2312
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Scoping resolution for member names

  • Key: CORBA23-25
  • Legacy Issue Number: 2202
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 10 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close this issue in 2.4 noting that the resolution of issue 1893 subsumes this issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in POA

  • Key: CORBA23-24
  • Legacy Issue Number: 2200
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Mon, 9 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

void * in DII Chapter

  • Key: CORBA23-23
  • Legacy Issue Number: 2162
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 3 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in text and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

is_a underspecified

  • Key: CORBA23-30
  • Legacy Issue Number: 2230
  • Status: closed  
  • Source: Anonymous
  • 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).

  • Reported: CORBA 2.2 — Tue, 1 Dec 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    clarify

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Local operations on CORBA::Object

  • Key: CORBA23-29
  • Legacy Issue Number: 2223
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 19 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

uses of recursive_tc

  • Key: CORBA23-31
  • Legacy Issue Number: 2235
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.2 — Thu, 3 Dec 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close no change in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Custom Marshaling clarification

  • Key: CORBA23-37
  • Legacy Issue Number: 2311
  • Status: closed  
  • Source: Anonymous
  • 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".

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate change in 2.4 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing minor code

  • Key: CORBA23-36
  • Legacy Issue Number: 2310
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Let minor code one be used for all value factory related exceptions.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Custom marshalling & AbstractBase

  • Key: CORBA23-33
  • Legacy Issue Number: 2296
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 7 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Add AbstractBase as a native type in the CORBA module, together with explanation in Chapter 6.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequences of recursive structs/unions

  • Key: CORBA23-32
  • Legacy Issue Number: 2275
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Mon, 21 Dec 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POA SINGLE_THREAD_MODEL description ambiguous

  • Key: CORBA23-35
  • Legacy Issue Number: 2308
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Mon, 18 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POA threading policies

  • Key: CORBA23-34
  • Legacy Issue Number: 2303
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Sun, 10 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exception for abstract interface inheritance

  • Key: CORBA23-22
  • Legacy Issue Number: 2156
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Mon, 2 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

long double problem?

  • Key: CORBA23-21
  • Legacy Issue Number: 2119
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Fri, 23 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No inconsistency exists as explained in the archive.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Lifetime of ORB and validity of ORB pointe

  • Key: CORBA23-6
  • Legacy Issue Number: 1665
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.2 — Fri, 10 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Fix the problem as described below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of system exception completion_status

  • Key: CORBA23-5
  • Legacy Issue Number: 1315
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Mon, 11 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What does interface substitutability mean in CORBA?

  • Key: CORBA23-17
  • Legacy Issue Number: 1997
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 29 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Which OBV initialiser to run is under-specified

  • Key: CORBA23-16
  • Legacy Issue Number: 1981
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Sun, 20 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Handling of minor codes for standard exceptions underspecified

  • Key: CORBA23-12
  • Legacy Issue Number: 1969
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.2 — Wed, 23 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    I believe that this issue has been adequately addressed in the 2.3a revision. So I propose that we c

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 3-47: Identifiers

  • Key: CORBA23-11
  • Legacy Issue Number: 1893
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.2 — Thu, 27 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing equality for DynAny

  • Key: CORBA23-14
  • Legacy Issue Number: 1972
  • Status: closed  
  • Source: Anonymous
  • 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);

  • Reported: CORBA 2.2 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    added comparison operator

  • Updated: Fri, 6 Mar 2015 20:58 GMT

set_servant_manager

  • Key: CORBA23-13
  • Legacy Issue Number: 1970
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.2 — Thu, 24 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate change in 2.4 and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Nested scopes

  • Key: CORBA23-10
  • Legacy Issue Number: 1892
  • Status: closed  
  • Source: Anonymous
  • 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 }

    ;
    };

  • Reported: CORBA 2.2 — Thu, 27 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changed text and close issue in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiple paths to a recursive sequence typecode

  • Key: CORBA23-9
  • Legacy Issue Number: 1802
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Wed, 12 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    This was fixed in the process of resolving issue 1928 in Core Revision 2.3a. See resolution of 1928.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change to IDL for anonymous types

  • Key: CORBA23-8
  • Legacy Issue Number: 1729
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 23 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DynStruct::get_members needs exception

  • Key: CORBA23-7
  • Legacy Issue Number: 1679
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Tue, 14 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    incorproate changes and close issue in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Recursive exceptions?

  • Key: CORBA23-20
  • Legacy Issue Number: 2084
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 15 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InconsistentTypeCode exception in CORBA 2.3

  • Key: CORBA23-19
  • Legacy Issue Number: 2070
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.2 — Sat, 10 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Already fixed in 2.3a Draft

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Recursive IDL types

  • Key: CORBA23-18
  • Legacy Issue Number: 2034
  • Status: closed  
  • Source: Anonymous
  • 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;
    };

  • Reported: CORBA 2.2 — Mon, 5 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DynUnion::member()

  • Key: CORBA23-15
  • Legacy Issue Number: 1974
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Thu, 17 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    incorporate change and close in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

resolve_initial_references under-specified

  • Key: CORBA23-4
  • Legacy Issue Number: 1156
  • Status: closed  
  • Source: Anonymous
  • 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".

  • Reported: CORBA 2.2 — Fri, 17 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Needs no further action in Core RTF. Close this issue no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Domain Manager related specification shortcoming (02)-ConstructionPolicy

  • Key: CORBA23-3
  • Legacy Issue Number: 1154
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Fri, 17 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    This issue is included in the mandatory requirements of the Security Domain Membership management R

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Domain manager related specification shortcoming(s) (01)

  • Key: CORBA23-2
  • Legacy Issue Number: 1153
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.2 — Fri, 17 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    This issue is included in the mandatory requirements of the Security Domain Membership Management R

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operation to add to CORBA::ORB pseudo-object

  • Key: CORBA23-1
  • Legacy Issue Number: 991
  • Status: closed  
  • Source: Anonymous
  • 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); ... }

    ;
    };

  • Reported: CORBA 2.2 — Wed, 4 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close no change in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

marshalling service context

  • Legacy Issue Number: 905
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The question is: What is the exact marshalling for an encapsulation
    of a zero length sequence? (Service context is an encapsulation of a
    sequence. CORBA 2.1, Section 10.6.7, page 10-22.)
    While it may or may not be an ambiguity,
    it does appear that ORB vendors differ in their interpretations, so
    it might be important to clarify it.

  • Reported: CORBA 2.1 — Wed, 14 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed, no revision required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Alignment and offsets in the presence of fragmentation

  • Legacy Issue Number: 904
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Its not clear to me how octet indices used for alignment and for
    TypeCode indirection offsets are calculated in the presence of
    fragmentation. Different interpretations will prevent successful
    interoperablity when fragmentation is used. IIOP 1.2 should clarify how alignment and TypeCode indirection work in the presence of fragmentation.

  • Reported: CORBA 2.1 — Tue, 13 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Changes to and strategy for 1.2

  • Legacy Issue Number: 886
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are 2 changes:
    1. add the request id to message fragments so that fragmentation is usable.
    2. change the alignment rules so that message headers may be changed
    without having to remarshal the body.
    [ as an aside we"d really like to remove all the alignment rules so that
    any"s no longer have to be double marshaled, but we don"t think its
    possible to deal with all the details quickly ]
    3. Add some more addressing information to request, locate_request,etc.

  • Reported: CORBA 2.1 — Thu, 8 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Type ids in OBJECT_FORWARD return message

  • Legacy Issue Number: 74
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When a GIOP "LocateRequest" message is sent to a location service and it replies with OBJECT_FORWARD, can the IOR have a type_id equal to simply CORBA::Object rather than the true type id?

  • Reported: CPP 1.0b1 — Tue, 13 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Closed with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of dynamic ports

  • Legacy Issue Number: 382
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Static port # should not be mandated-unworkable.It would be nice if a "standard" IIOP port # was registered with IANA

  • Reported: CPP 1.0b1 — Mon, 2 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with no revision required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::Object::non_existent

  • Legacy Issue Number: 126
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: section 7.2.5 names it "non_existent", while section 12.4.1 says that the GIOP protocol version is "_nonexistent".

  • Reported: CPP 1.0b1 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Correct IIOP marshalling of union TypeCodes

  • Legacy Issue Number: 89
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is a problem with marshalling of union TypeCodes where multiple discriminant values select the same arm of the union.

  • Reported: CPP 1.0b1 — Thu, 22 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

LOCATION_FORWARD byte alignment

  • Legacy Issue Number: 77
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It would be good if the request body of a LOCATION_FORWARD reply always started on an 8 byte boundary.

  • Reported: CPP 1.0b1 — Tue, 13 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with revision from issue 901, 902

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos in PIDL to C++ mappings

  • Legacy Issue Number: 804
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I think that there is a pervasive Typo in Appendix A of chapter 18.
    A number of the PIDL classes include a member function _duplicate.
    It should be declared as a static member function
    with an argument; i.e. the pointer to be "duplicated".

  • Reported: CORBA 2.1 — Thu, 4 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in C++ mapping

  • Legacy Issue Number: 732
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: C++ mapping in CORBA 2.1 has a typo in the array mapping (section 18.15 page 18-33).Same typo appears in orbos/97-05-15 in section 16.12 page 16-33. It would be nice to actually show the C++ definitions for the types F, V, and M. Find details in corresponding file

  • Reported: CORBA 2.1 — Thu, 25 Sep 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C mapping for list_initial_services is incorrect

  • Legacy Issue Number: 621
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 14.29: The C mapping for list_initial_services is incorrect and should return a pointer to a sequence (example in corresponding archive file)

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Defintion of Any

  • Legacy Issue Number: 147
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The definition of Any in C.3 is missing the no_copy flag in the class Any::from_string.

  • Reported: CPP 1.0b1 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any extractor signature problem

  • Legacy Issue Number: 146
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should the Any extractor signature be (Any_ptr &) instead of (Any &)?

  • Reported: CPP 1.0b1 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing Any inserter

  • Legacy Issue Number: 145
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The following inserter is missing in the C++ spec: void operation <<=(Any &, Any *); // non-copying

  • Reported: CPP 1.0b1 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IIOP object pointer resetting

  • Legacy Issue Number: 55
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Some IIOP implementations set the object pointers to nil object pointers, while others set them to nil pointers.

  • Reported: CPP 1.0b1 — Tue, 16 Jul 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed, no revision required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Additional enumeration to the ReplyStatusType

  • Legacy Issue Number: 807
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Add an additional enumeration to the ReplyStatusType (and
    LocationStatusType) called LOCATION_FORWARD_PERM (and
    OBJECT_FORWARD_PERM) that acts like the current LOCATION_FORWARD (and
    OBJECT_FORWARD), but can be used as a hint by the client that it should
    permanently discard the original IOR and replace it with the new IOR.

  • Reported: CORBA 2.1 — Wed, 10 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Additional Requirement for GIOP 1.2

  • Legacy Issue Number: 798
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"d like to suggest that for GIOP 1.2 that we add an additional requirement
    that an eight byte alignment occur before the body of any message.
    This allows for numerous optimizations that currently cannot be performed
    because the alignment of the beginning of the bodies is not consistent.

  • Reported: CORBA 2.1 — Mon, 22 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification on IIOP2.1 12.3.2 fixed point type representation needed

  • Legacy Issue Number: 782
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In CORBA /IIOP 2.1, 12.3.2 OMG IDL Constructed Types, Fixed-Point Decimal Type Section it is unclear to me that where is the decimal point in the IDL Fixed Type Representation (Figure 12-3), how the scale information is represented in the format

  • Reported: CORBA 2.1 — Fri, 7 Nov 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close with no change: The scale information is in the IDL definition of the fixed-point type

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 12.7.2 type IIOP::ProfileBody_1_0 not compatible

  • Legacy Issue Number: 885
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 12.7.2 defines the type IIOP::ProfileBody_1_0, which is
    supposed to be compatible with the type ProfileBody of earlier
    versions of CORBA. Unfortunately, it has a different repository
    ID, leading to incompatibilities.
    Proposed change: Add two pragmas to section 12.7.2, inside
    the module IIOP

  • Reported: CORBA 2.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IIOP marshalling of empty strings

  • Legacy Issue Number: 817
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Add a rule to CDR that allows an empty string to be marshaled as a four byte count of zero, followed by nothing. This change is backward compatible because a count value of zero is currently impossible.
    For a structure with five simple data members, this reduces the size of the
    TypeCode on the wire from 88 bytes to 60 bytes (32% saving).

  • Reported: CORBA 2.1 — Mon, 1 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problem with GIOP CancelRequest when fragments are used

  • Legacy Issue Number: 488
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Potential problem in determining whether CancelRequest message applies to the current message or a message that has already had a reply sent. Resolutions to this: (file)

  • Reported: CPP 1.0b1 — Thu, 30 Jan 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Transport Level Bridge

  • Legacy Issue Number: 465
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Work for transport level bridge that doesn"t need to understand full GIOP/IIOP protocol. Requirements: interoperability across network that doesn"t share commom transport protocol

  • Reported: CPP 1.0b1 — Wed, 4 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    accomodated by "NeedAddressingInfo" change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL Type Extensions: wstring CDR encoding issue

  • Legacy Issue Number: 586
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 4.1.2 p. 20 : Implementation needs to know whether it is byte-oriented or not, since CDR representation is different in each case. ORB expected to maintain table mapping of all codesets?

  • Reported: CORBA 2.0 — Thu, 29 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    duplicate to closed issue 1096

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL Type Extensions: wchar and wstring CDR encoding

  • Legacy Issue Number: 585
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 4.1 GIOP CDR Transfer Syntax: The spec should cover cases where TCS-W is byte-oriented or non-byte oriented

  • Reported: CORBA 2.0 — Thu, 29 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    duplicate to closed issue 1096

  • Updated: Fri, 6 Mar 2015 20:58 GMT

1.0 backward compat (2)

  • Legacy Issue Number: 592
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Assuming a 1.1 server we must Reply using 1.o to Request sent from 1.o client. If we get request with junk revision (eg 2.2) we wil automatically send (1.1) MessageError, but connection is close

  • Reported: CORBA 2.0 — Tue, 17 Jun 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed, accomodated by clarification of version semantics

  • Updated: Fri, 6 Mar 2015 20:58 GMT

1.0 backward compat (1)

  • Legacy Issue Number: 591
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If 1.1 client sends request to 1.0 server and tis causes 1.0 MessageError msf from serverthen 1.1 client must recognize MessageErrors from 1.o servers

  • Reported: CORBA 2.0 — Tue, 17 Jun 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    accomodated by clarification of version semantics

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IORs and identifying Object Keys

  • Legacy Issue Number: 460
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is there a standard by which you can identify whether incoming IOR is for an object reference in our ORB or not? Opaque object key could have same encoding in another ORB...Confusion

  • Reported: CPP 1.0b1 — Thu, 5 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with no revision required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Callbacks in IIOP

  • Legacy Issue Number: 383
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Callbacks in IIOP are to be implemented by getting the server to connect back to client and act as a client itself. If this could be changed it would really help from firewall perspective.

  • Reported: CPP 1.0b1 — Mon, 2 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with no revision required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fragment improvements (2)

  • Legacy Issue Number: 590
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A response_expected setting should be added to a new "Fragment Header"(issue589) so that this setting may be delayed until the final fragment

  • Reported: CORBA 2.0 — Tue, 17 Jun 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    issue closed, no change required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fragment improvements (1)

  • Legacy Issue Number: 589
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Fragment messages should contain fragment header which contains a Request ID to associate the fragment with given request message. Frgamented request could otherwise block connection until sent.

  • Reported: CORBA 2.0 — Tue, 17 Jun 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    fixed, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Type extensions char code set negotiation

  • Legacy Issue Number: 574
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This negotiation adds 16 bytes to both request and reply messages. It"s overburdening an already obese message header scheme.

  • Reported: CORBA 2.0 — Wed, 14 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed, no revision required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Type Extensions and code set negotiation

  • Legacy Issue Number: 573
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: page 26 of ptc/97-01-01: replace "Code set negotiation is not....." with"Code set negotiation is performed on a per-request basis."

  • Reported: CORBA 2.0 — Wed, 14 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with no revision required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue with service context

  • Legacy Issue Number: 651
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What should an ORB do when it gets a message with an unknown service context ID value?

  • Reported: CORBA 2.0 — Mon, 4 Aug 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CloseConnection messages

  • Legacy Issue Number: 593
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1.1 client may get 1.0 CloseConnection prior to first attemptto send Requests which it needs to recognize. Spec should clarify this.

  • Reported: CORBA 2.0 — Tue, 17 Jun 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

union typecode (02)

  • Key: CORBA22-96
  • Legacy Issue Number: 812
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.1 — Tue, 23 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

locally constrained

  • Key: CORBA22-95
  • Legacy Issue Number: 797
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.1 — Tue, 9 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL types are ambiguous with inheritance

  • Key: CORBA22-94
  • Legacy Issue Number: 783
  • Status: closed  
  • Source: Anonymous
  • 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")

  • Reported: CORBA 2.1 — Tue, 25 Nov 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close noting that this has been explained in Revised Chapter 3.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Question about typecode creation

  • Legacy Issue Number: 911
  • Status: closed  
  • Source: Anonymous
  • 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>>

  • Reported: CORBA 2.1 — Wed, 21 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Add clarification to section 10.6 that consistency of RepositoryIds with the IDL source or the IR i

  • Updated: Fri, 6 Mar 2015 20:58 GMT

#pragma processing

  • Key: CORBA22-99
  • Legacy Issue Number: 910
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.1 — Fri, 23 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    See resolution of 999 , close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::Contained::describe() underspecified

  • Legacy Issue Number: 918
  • Status: closed  
  • Source: Anonymous
  • 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!

  • Reported: CORBA 2.1 — Sun, 25 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    incorporate the proposed clarification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguity in non_existent() specification

  • Key: CORBA22-98
  • Legacy Issue Number: 903
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.1 — Tue, 13 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Sugested text below , close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Appendix B lists incorrect CORBA Components IDs

  • Key: CORBA22-97
  • Legacy Issue Number: 884
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Proposed resolution: Change Appendix B to correspond to the

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Trader constraint language and international characters

  • Legacy Issue Number: 915
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.1 — Wed, 21 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Replace section B.2.3 with corresponding text from the ISO Trader standard

  • Updated: Fri, 6 Mar 2015 20:58 GMT

defined_in member of ModuleDescription for top-level module

  • Legacy Issue Number: 913
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.1 — Wed, 21 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate change in 2.3 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inheritance of Exceptions

  • Legacy Issue Number: 912
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.1 — Thu, 22 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RIDs

  • Key: CORBA22-93
  • Legacy Issue Number: 780
  • Status: closed  
  • Source: Anonymous
  • 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 "/".

  • Reported: CORBA 2.1 — Fri, 7 Nov 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed with sepcific example in section 10.6.5.2 in Rev 2.3

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Containers

  • Key: CORBA22-92
  • Legacy Issue Number: 779
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.1 — Fri, 7 Nov 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    This issue appears to be a rehash of the essence of Issue 777 so I recommend that we close this wit

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect definition of "object type"

  • Legacy Issue Number: 917
  • Status: closed  
  • Source: Anonymous
  • 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)]

  • Reported: CORBA 2.1 — Tue, 27 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Clarify as follows

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Resetting #pragma prefix?

  • Legacy Issue Number: 916
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.1 — Mon, 26 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    See resolution of issue 999 , close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Proposed IFR exceptions

  • Key: CORBA22-91
  • Legacy Issue Number: 778
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.1 — Fri, 7 Nov 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate changes in 2.3a and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypedefDef issue

  • Key: CORBA22-90
  • Legacy Issue Number: 777
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.1 — Thu, 30 Oct 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, issue closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA 2.1 IR Structdef typo

  • Key: CORBA22-89
  • Legacy Issue Number: 776
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.1 — Thu, 30 Oct 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Remove the second sentence in section 8.5.10 of Rev 2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue with ObjectId_to_string and string_to_ObjectId

  • Key: CORBA22-85
  • Legacy Issue Number: 749
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.1 — Mon, 6 Oct 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Bug in the 2.1.spec for IDL unions

  • Key: CORBA22-84
  • Legacy Issue Number: 727
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.1 — Fri, 17 Oct 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 2-2 in CORBA 2.0 and CORBA 2.1

  • Key: CORBA22-83
  • Legacy Issue Number: 726
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.1 — Thu, 18 Sep 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Add an Up-Call Arrow to the Dynamic skeleton box.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Octet and enum constants

  • Key: CORBA22-82
  • Legacy Issue Number: 725
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IDL should permit enum and octet constants.

  • Reported: CORBA 2.1 — Wed, 17 Sep 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    The following changes add enum and octet constants to IDL:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Non ASCII alphabetics in IDL identifiers

  • Key: CORBA22-81
  • Legacy Issue Number: 724
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.1 — Wed, 17 Sep 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Since most of the implementation languages to which IDL is mapped do not accept non-ASCII character

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Native types with respect to typecodes, DII, DSI,Interface Reposit.

  • Key: CORBA22-80
  • Legacy Issue Number: 666
  • Status: closed  
  • Source: Anonymous
  • 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)

  • Reported: CORBA 2.0 — Mon, 11 Aug 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Proposed resolution is to add representation of native type in the IR. Details below as proposed by

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypeCode equality

  • Key: CORBA22-79
  • Legacy Issue Number: 665
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.0 — Mon, 11 Aug 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate more complete specification as shown below:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor bug in 2.1 spec

  • Key: CORBA22-88
  • Legacy Issue Number: 754
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.1 — Tue, 21 Oct 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    incorporate changes in 2.3 and close this issue and 1066.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inheriting exceptions in IDL

  • Key: CORBA22-87
  • Legacy Issue Number: 753
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.1 — Thu, 23 Oct 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue with no change with the above explanation.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inclusion of standard exception

  • Key: CORBA22-86
  • Legacy Issue Number: 751
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.1 — Mon, 6 Oct 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close no change in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Syntax for basic types must be updated

  • Key: CORBA22-75
  • Legacy Issue Number: 611
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in 2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

create_exception() is declared outside any interface scope

  • Key: CORBA22-74
  • Legacy Issue Number: 610
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in 2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TCKind enum should be updated

  • Key: CORBA22-73
  • Legacy Issue Number: 609
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close, fixed in 2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Do identifiers and keywords clash if they differ in case?

  • Key: CORBA22-78
  • Legacy Issue Number: 641
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.0 — Wed, 30 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in 2.2+, Close

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 3.7.2: take new IDL type extensions into account

  • Key: CORBA22-77
  • Legacy Issue Number: 624
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close, Fixed in 2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.8: editorial

  • Key: CORBA22-76
  • Legacy Issue Number: 623
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close, Fixed in 2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

sec 17.7.1: IDL for interface request doesn"t match C++ mapping

  • Key: CORBA22-70
  • Legacy Issue Number: 598
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Language mappings are allowed to have custom mappings for pseudo-interfaces.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequence parameter specified is ignored

  • Key: CORBA22-69
  • Legacy Issue Number: 597
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    That is an artificat of C/C++ historical usage and is not a core issue. In general language mapping

  • Updated: Fri, 6 Mar 2015 20:58 GMT

request() should be added to IDL (section 17.13.2)

  • Key: CORBA22-68
  • Legacy Issue Number: 596
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.2
  • Disposition Summary:

    The Object::_request operation is an artifact of the C++ mapping and not generally applicable to ot

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 16.7: only C++ mapping defines string_free and string_dup

  • Key: CORBA22-67
  • Legacy Issue Number: 595
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.2
  • Disposition Summary:

    They are C++ language specific helper functions, that is why they are in the C++ mapping section. T

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No defined value for OBJECT_NIL

  • Key: CORBA22-72
  • Legacy Issue Number: 607
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2: get_implementation function

  • Key: CORBA22-71
  • Legacy Issue Number: 604
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.2
  • Disposition Summary:

    closed issue, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"service"~~operation or interface?

  • Key: CORBA22-64
  • Legacy Issue Number: 570
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Cleaning up the use of the word service throughout the document does not seem to be an achievable g

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What exactly is a request

  • Key: CORBA22-63
  • Legacy Issue Number: 569
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Clarify the sense in which the term Request is used in section 1.2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Scope and use of prefix pragma in IDL-style repository IDs

  • Key: CORBA22-61
  • Legacy Issue Number: 567
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.0 — Mon, 12 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Clarifying language has been incorporated in section 10.6.5.2 (old section 8.6.5.2) in Rev 2.3 adeq

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Terminology consistency

  • Key: CORBA22-60
  • Legacy Issue Number: 565
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved closed issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.6.4 Pragma Directives for RepositoryId Para 1 - objection

  • Key: CORBA22-52
  • Legacy Issue Number: 444
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    The proposal in the summary is unreasonably restrictive, and would disallow use of other pragmas i

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.6.1 OMG IDL Format Paragraph 5 - comment

  • Key: CORBA22-51
  • Legacy Issue Number: 443
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    That"s what the sections appears to say. close issue, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.7.2 TypeCode Constants Last Paragraph - comment

  • Key: CORBA22-56
  • Legacy Issue Number: 448
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Offending language has been removed in Revision 2.3

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.7.1 The Type Code Interface Paragraph 4 - comment

  • Key: CORBA22-55
  • Legacy Issue Number: 447
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in 2.2 close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Enums and enumerators

  • Key: CORBA22-59
  • Legacy Issue Number: 545
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.0 — Thu, 10 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    issue closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Internationalization

  • Key: CORBA22-58
  • Legacy Issue Number: 499
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 2.0 — Wed, 12 Feb 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    not interpretable, closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.7.1 The TypeCode Interface All Paragraphs - objection

  • Key: CORBA22-54
  • Legacy Issue Number: 446
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in 2.2 close no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.7 TypeCodes Paragraph 3 - objection

  • Key: CORBA22-53
  • Legacy Issue Number: 445
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Offending sentence removed in the resolution of issue 73. This is the same as issue 73

  • Updated: Fri, 6 Mar 2015 20:58 GMT

limited-length strings

  • Key: CORBA22-66
  • Legacy Issue Number: 588
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.0 — Thu, 29 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate change in 2.3a and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Question about IDL grammar

  • Key: CORBA22-65
  • Legacy Issue Number: 571
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.0 — Tue, 6 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    subsumed by issue 725

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORE spec reference

  • Key: CORBA22-57
  • Legacy Issue Number: 459
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Such information now exists only in the way of examples of what a particular piece of pseudo-IDL me

  • Updated: Fri, 6 Mar 2015 20:58 GMT

inherit vs. include

  • Key: CORBA22-62
  • Legacy Issue Number: 568
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 2.0 — Wed, 21 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue with annotation fixed in Rev 2.2+

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.22 InterfaceDef Paragraphs 7 and 8 - comment

  • Key: CORBA22-50
  • Legacy Issue Number: 442
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Superceded by 778

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.22 InterfaceDef Paragraph 6 - comment

  • Key: CORBA22-49
  • Legacy Issue Number: 441
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Subsumed by 778

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.20 AttributeDef Paragraph 2 - comment

  • Key: CORBA22-48
  • Legacy Issue Number: 440
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Add the sentence "The describe operation for an AttributeDef object returns an AttributeDescription

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Paragraph 6 - editorial

  • Key: CORBA22-38
  • Legacy Issue Number: 427
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    changed, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Paragraph 5 - comment

  • Key: CORBA22-37
  • Legacy Issue Number: 426
  • Status: closed  
  • Source: Anonymous
  • 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).

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    no change required, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Paragraph 2 - objection

  • Key: CORBA22-36
  • Legacy Issue Number: 425
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    no change required, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.3 Contained Paragraph 10 - comment

  • Key: CORBA22-35
  • Legacy Issue Number: 424
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Subsumed by 778 . Closed with that annotation

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Paragraph 15 - comment

  • Key: CORBA22-43
  • Legacy Issue Number: 432
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Superceded by 778

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Paragraph 12 - comment

  • Key: CORBA22-42
  • Legacy Issue Number: 431
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.10 StructDef Last paragraph - comment

  • Key: CORBA22-46
  • Legacy Issue Number: 438
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Remove the phrase "is ignored" from the last sentence of section 8.5.9 rev 2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.8 ConstantDef Interface Paragraph 2 - comment

  • Key: CORBA22-45
  • Legacy Issue Number: 437
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Replace the phrase "simple type( ..... )" by the phrase "primitive types allowed in a constant decl

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Paragraph 10 - comment

  • Key: CORBA22-40
  • Legacy Issue Number: 429
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate resolution and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Paragraph 8 - comment

  • Key: CORBA22-39
  • Legacy Issue Number: 428
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.6 Repository Paragraph 4 - comment

  • Key: CORBA22-44
  • Legacy Issue Number: 435
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    In section 8.5.6 second para under Read Interface, add a cross reference to section 8.5.13 where Pr

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.11 UnionDef Last Paragraph - comment

  • Key: CORBA22-47
  • Legacy Issue Number: 439
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate resolution and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Paragraph 11 - comment

  • Key: CORBA22-41
  • Legacy Issue Number: 430
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate resolution and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.3 Contained - Paragraph 7 - comment

  • Key: CORBA22-34
  • Legacy Issue Number: 423
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close with annotation as above.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.3 Contained Paragraph 2 - comment

  • Key: CORBA22-33
  • Legacy Issue Number: 422
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.2 IRObject Paragraph 3 - objection

  • Key: CORBA22-32
  • Legacy Issue Number: 421
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6 Context Object Operations, Para 2 - objection

  • Key: CORBA22-22
  • Legacy Issue Number: 399
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Propose to apply resolution as above and close issue in 2.3

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.2.2 add_arg Paragraph 5-comment

  • Key: CORBA22-21
  • Legacy Issue Number: 397
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    In Section 5.2.2 Para 5 Rev 2.2 remove the word "currently" from the last sentence

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6.2 set_on_value Paragraph 2 - objection

  • Key: CORBA22-24
  • Legacy Issue Number: 402
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Propose apply resolution to rev 2.3 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.3.1 sen3 - comment 23 - comment

  • Key: CORBA22-23
  • Legacy Issue Number: 400
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6.4 get_values Paragraph 5 - objection

  • Key: CORBA22-28
  • Legacy Issue Number: 406
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    See resolution of 404

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6.4 get_values Paragraph 4 - objection

  • Key: CORBA22-27
  • Legacy Issue Number: 405
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Remove paragraph 4. Does not add any value to the spec.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6.4 get_values Paragraph 2 - objection

  • Key: CORBA22-26
  • Legacy Issue Number: 404
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    add text to sections 5.6.4, 5.6.5 and 5.6.7 stating what exceptions are raised under what condition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6.3 set_values

  • Key: CORBA22-25
  • Legacy Issue Number: 403
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: See comment on set_value in issue # 402

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Propose apply resolution to rev 2.3 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.1.1 Common Data Structures, Paragraph 6, comment

  • Key: CORBA22-18
  • Legacy Issue Number: 393
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close no change in 2.3a

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface for managing interceptors is missing

  • Key: CORBA22-17
  • Legacy Issue Number: 380
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 1.2 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.4.3 Interface Objects Paragraph 3 - comment

  • Key: CORBA22-31
  • Legacy Issue Number: 420
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    no change necessary, issue closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6.7 delete Paragraph 4 - objection

  • Key: CORBA22-30
  • Legacy Issue Number: 409
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    see resolution of 404

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.2.1 create_request Paragraph 8 - comment

  • Key: CORBA22-20
  • Legacy Issue Number: 396
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    issue closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.1.3 Return Status and Exceptions

  • Key: CORBA22-19
  • Legacy Issue Number: 395
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed issue, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6.5 delete_values Paragraph 3 - objection

  • Key: CORBA22-29
  • Legacy Issue Number: 408
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    see resolution of 404

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Do typecodes need literal constant representations in all mappings?

  • Key: CORBA22-4
  • Legacy Issue Number: 73
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 1.2 — Tue, 13 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    The offending paragraph, which is now the para 3 of section 10.7, seems to not clearly state anythi

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing info about the semantics of ORB_init and OA_init

  • Key: CORBA22-3
  • Legacy Issue Number: 68
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 13 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate change in 2.3a and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Similar structure to IR::Identifier

  • Key: CORBA22-14
  • Legacy Issue Number: 283
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 1.2 — Sat, 19 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved in 2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pseudo-IDL identifiers differ by case only

  • Key: CORBA22-13
  • Legacy Issue Number: 233
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typecodes for recursive sequences

  • Key: CORBA22-8
  • Legacy Issue Number: 116
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 1.2 — Fri, 13 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No parameter is missing. you just create a TypeCode with TCKind set to tk_sequence and content type

  • Updated: Fri, 6 Mar 2015 20:58 GMT

lookup() questions

  • Key: CORBA22-7
  • Legacy Issue Number: 86
  • Status: closed  
  • Source: Anonymous
  • 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?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DSI and oneway operations

  • Key: CORBA22-10
  • Legacy Issue Number: 129
  • Status: closed  
  • Source: Anonymous
  • 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")?

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    The ORB uses protocol information (i.e. from GIOP response_expected) to make this decision.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ServerRequest::op_def()

  • Key: CORBA22-9
  • Legacy Issue Number: 128
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface Repository Error Handling

  • Key: CORBA22-6
  • Legacy Issue Number: 85
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Superceded by Issue 778

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::InterfaceDef name collision

  • Key: CORBA22-5
  • Legacy Issue Number: 76
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 13 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Apparent error in CORBA 2.0 Interoperability

  • Key: CORBA22-12
  • Legacy Issue Number: 156
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Tue, 8 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    issue closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Repository IDs

  • Key: CORBA22-11
  • Legacy Issue Number: 133
  • Status: closed  
  • Source: Anonymous
  • 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.

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Portability and the #include directive

  • Key: CORBA22-16
  • Legacy Issue Number: 306
  • Status: closed  
  • Source: Anonymous
  • 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

  • Reported: CORBA 1.2 — Sat, 23 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close no change in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Recursive sequence TypeCodes

  • Key: CORBA22-15
  • Legacy Issue Number: 300
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Tue, 29 Oct 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    subsumed by issue 116, close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IFR: union elements associated with case labels

  • Key: CORBA22-2
  • Legacy Issue Number: 14
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inheritance of describe_contents()

  • Key: CORBA22-1
  • Legacy Issue Number: 2
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT