1. OMG Mailing List
  2. Core 3.5 Revision Task Force

Closed Issues

  • Issues resolved by a task force and approved by Board
  • Name: corba-rtf
  • Issues Count: 594

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-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-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-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-17 Chapter/section: 15.4.2.2 "Request Body" CORBA 3.0.2 CORBA 3.4 Deferred 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
CORBA3-134 IDL keyword clash in CosNotification.idl CORBA 2.6 CORBA 3.0 Resolved closed
CORBA31-217 Japan CORBA Part 2 PAS Ballot Comments - comment 12 CORBA 3.1 CORBA 3.1.1 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
ZIOP-62 Japan CORBA Part 3 PAS Ballot Comments - comment 9 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-61 Japan CORBA Part 3 PAS Ballot Comments - comment 8 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-60 Japan CORBA Part 3 PAS Ballot Comments - comment 7 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-57 Japan CORBA Part 3 PAS Ballot Comments - comment 4 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-56 Japan CORBA Part 3 PAS Ballot Comments - comment 3 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-64 Japan CORBA Part 3 PAS Ballot Comments - comment 11 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-63 Japan CORBA Part 3 PAS Ballot Comments - comment 10 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-70 Japan CORBA Part 3 PAS Ballot Comments - comment 16 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-69 Japan CORBA Part 3 PAS Ballot Comments - comment 15 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-66 Japan CORBA Part 3 PAS Ballot Comments - comment 13 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-65 Japan CORBA Part 3 PAS Ballot Comments - comment 12 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-59 Japan CORBA Part 3 PAS Ballot Comments - comment 6 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-58 Japan CORBA Part 3 PAS Ballot Comments - comment 5 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-68 Japan CORBA Part 3 PAS Ballot Comments - comment 14 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-67 Japan CORBA Part 3 PAS Ballot Comments - comment 13.5 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-48 Japan CORBA Part 2 PAS Ballot Comments - comment 17 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-47 Japan CORBA Part 2 PAS Ballot Comments - comment 16 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-46 Japan CORBA Part 2 PAS Ballot Comments - comment 15 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-55 Japan CORBA Part 3 PAS Ballot Comments - comment 2 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-54 Japan CORBA Part 3 PAS Ballot Comments - comment 1 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-53 Japan CORBA Part 2 PAS Ballot Comments - comment 22 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-52 Japan CORBA Part 2 PAS Ballot Comments - comment 21 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-51 Japan CORBA Part 2 PAS Ballot Comments - comment 20 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-50 Japan CORBA Part 2 PAS Ballot Comments - comment 19 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-49 Japan CORBA Part 2 PAS Ballot Comments - comment 18 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-45 Japan CORBA Part 2 PAS Ballot Comments - comment 14 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-44 Japan CORBA Part 2 PAS Ballot Comments - comment 13 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-43 Japan CORBA Part 2 PAS Ballot Comments - comment 11 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-38 Japan CORBA Part 2 PAS Ballot Comments - comment 6 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-37 Japan CORBA Part 2 PAS Ballot Comments - comment 5 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-42 Japan CORBA Part 2 PAS Ballot Comments - comment 10 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-41 Japan CORBA Part 2 PAS Ballot Comments - comment 9 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-40 Japan CORBA Part 2 PAS Ballot Comments - comment 8 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-39 Japan CORBA Part 2 PAS Ballot Comments - comment 7 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-34 Japan CORBA Part 2 PAS Ballot Comments - comment 2 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-33 Japan CORBA Part 2 PAS Ballot Comments - comment 1 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-36 Japan CORBA Part 2 PAS Ballot Comments - comment 4 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-35 Japan CORBA Part 2 PAS Ballot Comments - comment 3 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-27 Japan CORBA Part 1 PAS Ballot Comments - comment 14 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-26 Japan CORBA Part 1 PAS Ballot Comments - comment 13 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-30 Japan CORBA Part 1 PAS Ballot Comments - comment 17 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-29 Japan CORBA Part 1 PAS Ballot Comments - comment 16 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-28 Japan CORBA Part 1 PAS Ballot Comments - comment 15 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-32 Japan CORBA Part 1 PAS Ballot Comments - comment 19 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-31 Japan CORBA Part 1 PAS Ballot Comments - comment 18 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-23 Japan CORBA Part 1 PAS Ballot Comments - comment 10 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-22 Japan CORBA Part 1 PAS Ballot Comments - comment 9 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-21 Japan CORBA Part 1 PAS Ballot Comments - comment 8 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-20 Japan CORBA Part 1 PAS Ballot Comments - comment 7 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-16 Japan CORBA Part 1 PAS Ballot Comments - comment 3 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-15 Japan CORBA Part 1 PAS Ballot Comments - comment 2 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-25 Japan CORBA Part 1 PAS Ballot Comments - comment 12 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-24 Japan CORBA Part 1 PAS Ballot Comments - comment 11 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-19 Japan CORBA Part 1 PAS Ballot Comments - comment 6 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-18 Japan CORBA Part 1 PAS Ballot Comments - comment 5 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-17 Japan CORBA Part 1 PAS Ballot Comments - comment 4 ZIOP 1.0b1 ZIOP 1.0 Resolved closed
ZIOP-14 Japan CORBA Part 1 PAS Ballot Comments - comment 1 ZIOP 1.0b1 ZIOP 1.0 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
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
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
RT12-9 PriorityModelPolicy RT 1.1 RT 1.2 Resolved closed
RT12-10 Minor syntax errors in spec RT 1.1 RT 1.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

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

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

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

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

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

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

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

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

Japan CORBA Part 3 PAS Ballot Comments - comment 9

  • Key: ZIOP-62
  • Legacy Issue Number: 14413
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    1 Scope
    Comment:
    There are many references to PIM/PSM. However, those definitions aren't prescribed.
    Proposed change:
    Add reference to MDA prescription. http://www.omg.org/docs/omg/03-06-1/pdf

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agreed to add refernce to MDA Guide version 1.0.1, and to use it in abbreviation
    definitions for PIM and PSM

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 3 PAS Ballot Comments - comment 8

  • Key: ZIOP-61
  • Legacy Issue Number: 14412
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    1 Scope
    Comment:
    There is a reference to EJB. This should be referred as normative reference. Furthermore, this refers to private web page (http://java.sun.com/products/ejb/javadocs-1.1-fr).
    Proposed change:
    This reference should move to clause "Normative Reference" and refer to public specification, such as JCP. Furthermore, referred version number should be designated.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree that the reference should be changed to use the JCP url for JSR 950 - EJB 1.1 spec
    final release with errata

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 3 PAS Ballot Comments - comment 7

  • Key: ZIOP-60
  • Legacy Issue Number: 14411
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Introduction 3rd paragraph
    Comment:
    Since this document is submitted as PAS, it is better to reference ISO/IEC standard in addition to OMG standard.
    Proposed change:
    Add " or this standard (ISO/IEC 19500)" at the end of the first sentence..

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to clarify the references

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 3 PAS Ballot Comments - comment 4

  • Key: ZIOP-57
  • Legacy Issue Number: 14408
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Introduction 3rd paragraph
    Comment:
    1) The second "Part2" seems to be "Part3" instead.
    2) Mixed use of "RM-ODP" and "RM ODP" is confusing.
    Proposed change:
    1) The second "Part2" should be replaced with "Part3".
    2) "RM ODP" should be replaced with "RM-ODP" where applicable..

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Accept proposed change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 3 PAS Ballot Comments - comment 3

  • Key: ZIOP-56
  • Legacy Issue Number: 14407
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Foreword 6th paragraph
    Comment
    1) The year of the standard's issuance need to be corrected.
    2) The names in the second half of two referenced standards start with "-" and need to be removed.
    Proposed change:
    1) The year within the title of RM-ODP Part2 and 3 should be replaced with 1996, like following.
    ITU-T Recommendation X.902(1995)|ISO/IEC 10746-2:1996
    ITU-T Recommendation X.903(1995)|ISO/IEC 10746-3:1996

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    accept proposed change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 3 PAS Ballot Comments - comment 11

  • Key: ZIOP-64
  • Legacy Issue Number: 14415
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    3.1 Normative Reference
    Comment:
    ZIP is referred to http://www.pkware.com/products/enterprise/white_paper/annnote.txt
    Proposed change:
    Refer to public document. Otherwise ZIP should be removed.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    According to section 6.12.1 (note on Tools), the exact nature of a zip file format is tool
    and platform dependent.
    Thus the single reference in 14.3.3 should be made informal, and the reference [ZIP]
    needs to be removed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 3 PAS Ballot Comments - comment 10

  • Key: ZIOP-63
  • Legacy Issue Number: 14414
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    3.1 Normative Reference
    Comment:
    There are reference to UML 1.5, MOF 1.4 and XMI.
    Proposed change:
    ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
    ISO/IEC 19501:2005 Information technology - Unified Modeling Language (UML)
    ISO/IEC 19503:2005 Information technology – XML Metadata Interchange (XMI)

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agreed to add the three references

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 3 PAS Ballot Comments - comment 16

  • Key: ZIOP-70
  • Legacy Issue Number: 14421
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    All Clauses
    Comment:
    ISO standard documents are described with "shall", "should" and "may".
    Proposed Change
    Define this with "shall", "should" and "may"

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 3 PAS Ballot Comments - comment 15

  • Key: ZIOP-69
  • Legacy Issue Number: 14420
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Annex B,C
    Comment:
    This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as OMG document only.
    Proposed Change
    Remove Annex D and C from ISO standard.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to remove Annex B and Annex C from both the ISO Standard and the OMG specification (for
    consistency)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 3 PAS Ballot Comments - comment 13

  • Key: ZIOP-66
  • Legacy Issue Number: 14417
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    8.2.6, 8.2.7 Figure 8.1, Figure 8.2
    Comment:
    Syntax for the composition structure diagram is ambiguous. For example, there are gray dashed arrows, however, the legends only show gray solid arrow.
    Proposed change:
    The Fig 8.1 and 8.2 should be represented using the symbol of the legend."

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    The light grey dashed arrows are a fourth type, and are used to represent correspondence
    form the composition example to one of the diagram elements.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 3 PAS Ballot Comments - comment 12

  • Key: ZIOP-65
  • Legacy Issue Number: 14416
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    6.11 Figure 6.2
    Comment:
    The diagram looks like class diagram. However, its syntax is ambiguous. For example, Inheritance arrowhead is solid black triangle. Generally, Inheritance arrowhead is hollow triangle. Besides, there are dashed lines without definition.
    Proposed change:
    Replace the diagram with class diagram.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Accommodated by deletion of the Figure, since it is not referred to in the text of the
    document

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 3 PAS Ballot Comments - comment 6

  • Key: ZIOP-59
  • Legacy Issue Number: 14410
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Introduction Last paragraph
    Comment:
    There is no sentence included with respect to annexes of this standard.
    Proposed change:
    Add text that says this standard includes normative and non-normative annexes.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to add proposed sentence, however Annex B and C are to be removed, and the Annex A is non
    -normative

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 3 PAS Ballot Comments - comment 5

  • Key: ZIOP-58
  • Legacy Issue Number: 14409
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Introduction Structure of this standard
    Comment:
    1) This chapter numbers in Structure of this standard are not consistent with actual chapter numbers.
    Proposed change:
    1) Revise the chapter numbers..

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Accommodate by deletion of “Structure of this Standard” unnumbered subsection. This
    subsection is not required.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 3 PAS Ballot Comments - comment 14

  • Key: ZIOP-68
  • Legacy Issue Number: 14419
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Annex A
    Comment:
    This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition.
    Proposed Change
    Remove Annex a or make it informative Annex

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to make Annex A an informative Annex

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 3 PAS Ballot Comments - comment 13.5

  • Key: ZIOP-67
  • Legacy Issue Number: 14418
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    8.2.9.1 Code fragment
    Comment:
    It is unclear if this description is normative or informative.
    Proposed change:
    Make distinction between normative and informative.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to clarify that this code fragment is a normative implicit definition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 17

  • Key: ZIOP-48
  • Legacy Issue Number: 14399
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    7.6.6.3 p.31, p.32
    Comment:
    There are sentences each of which begins with "See Â…".
    However, the reference pointers are ambiguous for those who are not familiar with the CORBA work.
    Proposed change:
    Replace the references as mentioned above.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to change to proper OMG normative references, and to add to normative
    references clause. OMG is an Authorized Reference Originator
    Replace all the numbered reference text to Firewall spec , showing in the document as
    “(ptc/04-03-01)” with the “[FIREWALL]” reference tag.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 16

  • Key: ZIOP-47
  • Legacy Issue Number: 14398
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    7.6.6 p.30
    Comment:
    We can't find where the DCE ESIOP is. There is no clause which names DCE ESIOP in ISO/IEC 19500-2.
    What document are CORBA services included in?
    Proposed change:
    Modify the sentence

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to fix by removing deprecated references to DCE ESIOP components

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 15

  • Key: ZIOP-46
  • Legacy Issue Number: 14397
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Location:
    7.6.4.4 p.29
    Comment:
    The reference pointer of the "Unreliable Multicast" is necessary for the convenience of the readers.
    Proposed change:
    Replace the "Unreliable Multicast" with "in clause 11 of ISO/IEC 19500-2, Unreliable Multicast"..

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to add reference to clause 11:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 3 PAS Ballot Comments - comment 2

  • Key: ZIOP-55
  • Legacy Issue Number: 14406
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Foreword 5th paragraph
    Comment:
    1) The reference to JTC1 is not correct.
    2) The JTC1 subcommittee referenced in this standard is SC32. It seems there is no reference to the reference.
    Proposed change:
    1)"ISO/IEC/TC JTC1" should be replaced with "ISO/IEC JTC1"
    2) Remove reference to SC32.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Accept proposed change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 3 PAS Ballot Comments - comment 1

  • Key: ZIOP-54
  • Legacy Issue Number: 14405
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Source: Japan NB, Severity te
    Summary:
    Japan will approve this DIS if the te comment jp 8, 11, 14 will be satisfactorily resolved
    Resolution:
    If the te comments JP 8, 11, 14 were accepted in the approved resolutions. See resolutions to OMG Issues

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    All of the comments JP 8, 11, and 14, were resolved in the approved resolutions. See
    resolutions to OMG Issues

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 22

  • Key: ZIOP-53
  • Legacy Issue Number: 14404
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    All Clauses
    Comment:
    ISO standard documents are described with "shall", "should" and "may".
    Proposed Change
    Define this with "shall", "should" and "may"

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Specification uses RFC 2119 Terminology

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 21

  • Key: ZIOP-52
  • Legacy Issue Number: 14403
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Annex C, D
    Comment:
    This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as OMG document only.
    Proposed Change
    Remove Annex C and D from ISO standard.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to remove Annex C and Annex D from both the ISO Standard and the OMG specification (for
    consistency)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 20

  • Key: ZIOP-51
  • Legacy Issue Number: 14402
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Annex B
    Comment:
    This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition.
    Proposed Change
    Remove Annex B or make it informative Annex

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to make Annex B an informative Annex

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 19

  • Key: ZIOP-50
  • Legacy Issue Number: 14401
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Introduction p.xviii (Last paragraph)
    Comment:
    There is no sentence included with respect to annexes of this standard.
    Proposed change:
    Add a sentence which says that this standard includes normative and non-normative annexes.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to add proposed sentence

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 18

  • Key: ZIOP-49
  • Legacy Issue Number: 14400
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Location:
    3.1 p 2
    Forward p xv
    Comment:
    The year of ITU-T recommendation is different from that of ISO/IEC. The former is 1995, and the latter is 1996.
    Proposed change:
    The correct expressions of the Normative references are as follows:
    ITU-T Recommendation X.902 (1995)| ISO/IEC 10746-2:1996,
    ITU-T Recommendation X.903 (1995)| ISO/IEC 10746-3:1996,

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to proposed change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 14

  • Key: ZIOP-45
  • Legacy Issue Number: 14396
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Location:
    7.6.4.3 p 28
    Comment:
    There is a phrase that "see the CORBA/TC Interworking specification". However, we can't find the place.
    Proposed change:
    Where is this clause ?.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to add proper reference to OMG spec

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 13

  • Key: ZIOP-44
  • Legacy Issue Number: 14395
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    7.6.3 p.27, l.24
    7.6.9 p.33
    Comment:
    We use the term 'clause' when we need to point to the other sections.
    Proposed change:
    Replace "see Section 9.7.3" with "see clause 9.7.3".
    Replace "see Section 9.3" with "see clause 9.3".

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    agree to proposed change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 11

  • Key: ZIOP-43
  • Legacy Issue Number: 14393
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    6.3.4
    Comment:
    When referring to clause(s) in other parts of ISO/IEC 19500 from within ISO/IEC 19500-2, it is clearer to explicitly provide the clause number and part number of the standard, rather stating like "this standard(Part 1).
    Proposed change:
    Replace "in the Interface Repository clause of this standard (Part1)" with "in clause 14 of ISO/IEC 19500-1, Interface Repository clause of CORBA interfaces"..

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to refer to clause in 19500-1 as “Part 1 of this Specification” which will hold for both OMG and ISO
    versions of text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 6

  • Key: ZIOP-38
  • Legacy Issue Number: 14388
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    4.2
    In 'repository', the sentence tells to 'see' the other terms. However, there is no 'implementation repository' in the definitions list.
    Proposed change:
    Modify the definition of this 'repository' or add the reference to the definition of 'implementation repository', which is mentioned in the clause 6.1.4 of ISO/IEC 19500-1.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree that there is no specialized definition of the word repository as used in this spec

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 5

  • Key: ZIOP-37
  • Legacy Issue Number: 14387
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Location:
    4.1
    Comment:
    As the terms 'transparency', 'domain' and 'service' are used in clause 7, and these terms are important for the concept of interoperability, it is preferable to explain the difference or resemblance of usage between the RM-ODP and this CORBA in the document. One way to do this is to define the meaning of the terms. The term 'domain' is defined in clause 4.2. However, other terms are not defined in this document. Where are the definitions of 'transparency' and 'service' ?
    Proposed change:
    If the terms are already defined in the other documents, make a reference to the documents in which the terms are defined. Otherwise, define these terms in this document..

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Add “transparency” and “service” to the list of terms defined in ODP Reference Model 10746-2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 10

  • Key: ZIOP-42
  • Legacy Issue Number: 14392
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    6.2
    Comment:
    ISO documents are not a book but consist of several parts of documents.
    Proposed change:
    Correct the expression of the phrase "ORB Interface clause of this book(Part1)" , such as "clause 8 of ISO/IEC 19500-1, ORB Interface"..

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to change reference to a neutral designation for 19500-1 as “Part 1 of this Specification” which will
    hold for both OMG and ISO versions of text. Use of clause names in other spec references rather than
    clause numbers is more robust to amendments/corrigenda on the references external specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 9

  • Key: ZIOP-41
  • Legacy Issue Number: 14391
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Clause 5
    Comment:
    The term ESIOP plays important roles in the document.
    Proposed change:
    ESIOP should be added in the symbols.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to add ESIOP to symbols

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 8

  • Key: ZIOP-40
  • Legacy Issue Number: 14390
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    4.2
    Comment:
    It seems that the definition of a 'request' is circular.
    Proposed change:
    Modify the definition which is not circular. A candidate is " A message issued by a client to cause a service to be performed."..

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to proposed change of definition text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 7

  • Key: ZIOP-39
  • Legacy Issue Number: 14389
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Location:
    4.2
    Comment:
    There are misspellings in the definitions list.
    Proposed change:
    Correct the word 'wiat' to 'wait' in the definition of the "synchronous request".
    Correct the word 'tow' to 'two' in the definition of the 'interoperability'..

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    agree to proposed changes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 2

  • Key: ZIOP-34
  • Legacy Issue Number: 14384
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Comment:
    This document is revision for 19500-2:2003. Therefore, status of the old document is ambiguous.
    Proposed Change
    It is desirable to withdraw the old standard (19500-2:2003) to avoid confusion, if possible.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Clarify upon publication by ISO that This PAS specification is intended to supersede the
    2003 version

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 1

  • Key: ZIOP-33
  • Legacy Issue Number: 14383
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Japan will approve this DIS if the te comment jp 20 will be satisfactorily resolved
    Resolution:
    If the te commentsJP17 were accepted in the approved resolutions. See resolutions to OMG Issues

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    The comment JP20 was resolved in the approved resolutions. See resolutions to OMG
    Issues

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 4

  • Key: ZIOP-36
  • Legacy Issue Number: 14386
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Location:
    4.1 1st line
    Comment:
    The delimiter between X and 902 is not a comma but a dot, and the part number following a document number should be connected by a hyphen.
    Proposed change:
    X,902 should be X.902 and 10746.2 should be 10746-2..

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    agree to proposed change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 3

  • Key: ZIOP-35
  • Legacy Issue Number: 14385
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Clause 2 2nd paragraph
    Comment:
    What does ESIOP mean? There are no descriptions on it.
    Proposed Change:
    Change 'additional ESIOPs' to 'additional Environment-Specific Inter-ORB Protocols(ESIOPs)'

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to proposed change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 14

  • Key: ZIOP-27
  • Legacy Issue Number: 14377
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Location:
    All Clauses
    Comment:
    1) Both terms, "OMG IDL" and "IDL," are used in the document, and this usage is not consistent.
    Proposed Change
    1) It is suggested to use "OMG IDL" for the first appearance, and with the text explaining that IDL hereafter means OMG IDL, use just IDL for the rest of the document.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to proposed change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 13

  • Key: ZIOP-26
  • Legacy Issue Number: 14376
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Location:
    Clause 5
    Comment:
    1) OMA is mentioned but no reference to OMA document is included.
    Proposed Change
    Add the reference to Object Management Architecture Guide

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to add reference to OMG OMA Guide

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 17

  • Key: ZIOP-30
  • Legacy Issue Number: 14380
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Annex B
    Comment:
    This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition.
    Proposed Change
    Remove Annex B or make it informative Annex
    Resolution:

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to make Annex B an informative Annex

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 16

  • Key: ZIOP-29
  • Legacy Issue Number: 14379
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Clause 8.5.2 and other places Table 8.1
    Comment:
    1) There are places where the reference to Part 2 is describe like the following:
    "See CORBA, Part 2: ORB Interoperability Architecture clause".
    Proposed Change
    Change the text of referring to other part of the standard throughout the document to:
    "See ISO/IEC 19500-2 Common Object Request Broker Architecture (CORBA) specification - Part 2: Interoperability"
    or
    "See ISO/IEC 19500-2 CORBA specification Part 2: Interoperability"
    or
    "See Part 2 of this standard"

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to second proposed change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 15

  • Key: ZIOP-28
  • Legacy Issue Number: 14378
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Clause 7.3 1st paragraph
    Comment:
    1) There is a stand-alone term "1998" in the second line of this paragraph.
    Proposed Change
    1) Change the standard name to "ISO/IEC 14882:2003" or "ISO/IEC 14882:1998" or remove this number from the text.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to proposed change to incorporate reference from normative references

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 19

  • Key: ZIOP-32
  • Legacy Issue Number: 14382
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    All Clauses
    Comment:
    ISO standard documents are described with "shall", "should" and "may".
    Proposed Change
    Define this with "shall", "should" and "may"

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Change the title of clause 4 to the following:

    4 Additional information

    Add a new sub section header at beginning of clause 4:

    4.1 Outline of specification contents

    Add new subsection to end of section 4:

    4.2 Keywords for Requirement statements”
    The keywords "must", "must not", "shall", "shall not", "should", "should not", and "may” in this
    specification are to be interpreted as described in [RFC 2119].“

    Add the following reference in the normative references - section 3.2:
    [RFC2119] IETF RFC2119, “Key words for use in RFCs to Indicate Requirement Levels”, S. Bradner,
    March 1997. Available from http://ietf.org/rfc/rfc2119

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 18

  • Key: ZIOP-31
  • Legacy Issue Number: 14381
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Annex C, D
    Comment:
    This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as OMG document only.
    Proposed Change
    Remove Annex C and D from ISO standard.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to remove Annex C and Annex D from both the ISO Standard and the OMG specification (for
    consistency)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 10

  • Key: ZIOP-23
  • Legacy Issue Number: 14373
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Location:
    Clause 4
    Comment:
    1) There seems to be duplication between "structure of this standard" section of Introduction and clause 4, and therefore it is better to make text simpler.
    Proposed Change
    1) Structure of this standard section of Introduction and clause 4 should be merged and placed in one place.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Accommodated by removal of Structure of Standard subsection from Issue 14369.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 9

  • Key: ZIOP-22
  • Legacy Issue Number: 14372
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Clause 3 Bullet items
    Comment:
    1) The year of the standard's issuance need to be corrected.
    Proposed Change
    1) The years within the title of RM-ODP Part 2 and 3 should be replaced with 1996, like the following.
    o ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1996
    o ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1996

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Accept proposed change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 8

  • Key: ZIOP-21
  • Legacy Issue Number: 14371
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Location:
    Clause 2
    Comment:
    1) It would be better to have reference to programming language C++ standard, since it is used in mapping examples.
    2) It would be better to have reference to programming language C standard too.
    Proposed Change
    1) Add the reference to C++, which is ISO/IEC 14882:2003, somewhere in the document.
    See also a comment on Clause 7.3.
    2) Add the reference to C, which is ISO/IEC 9899:1999, somewhere in the document.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to proposed change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 7

  • Key: ZIOP-20
  • Legacy Issue Number: 14370
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Introduction last paragraph
    Comment:
    1) There is no sentence included with respect to annexes of this standard.
    Proposed Change
    1) Add text that says this standard includes normative and non-normative annexes.
    Resolution:

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Agree to add proposed sentence, however Annex B and C are to be removed, and the Annex A is non
    -normative

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 3

  • Key: ZIOP-16
  • Legacy Issue Number: 14366
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Forword 6th paragraph
    Comment:
    1) The year of the standard's issurance need to be corrected.
    2) The names in the second half of four referenced standards start with "-" and need to be removed.
    3) ISO/IEC 19500-3 needs to be added in the list of relevant standards.
    Proposed Change
    1) The years within the title of RM-ODP Part 2 and 3 should be replaced with 1996, like the following.
    o ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1996
    o ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1996
    2) Starting "-"s need to be removed.
    3) Add the following to the list of related standards.
    ISO/IEC 19500-3, Information Technology - Open Distributed Processing - CORBA Specification Part 3: CORBA Components

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Accept proposed change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 2

  • Key: ZIOP-15
  • Legacy Issue Number: 14365
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Source: Japan NB, Severity ed
    Summary:
    Location:
    Forword 5th paragraph
    Comment:
    1) The reference to JTC1 is not correct.
    2) The JTC1 Subcommittee referenced in this standard should be SC7 instead of SC32.
    Proposed Change
    1) "ISO/IEC/TC JTC1" should be replaced with "ISO/IEC JTC1."
    2) "Subcommittee SC 32, Data Management" should be replaced with "Subcommittee SC 7, Software and Systems Engineering."
    Resolution:
    Revised Text:

    Disposition:

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    To be consistent with resolution of similar comment on part 3 (OMG Issue 14406),
    1)”ISO/IEC/TC JTC1” should be replaced with “ISO/IEC JTC1”
    2) Remove reference to SC32.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 12

  • Key: ZIOP-25
  • Legacy Issue Number: 14375
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Location:
    Forword 5th paragraph
    Comment:
    1) This document does not have definitions clause.
    Proposed Change
    1) It is suggested to create definitions clause that covers at least major concepts for this standard

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Do not agree to proposed change, since the terms are all defined implicitly by the text in
    the body of the document as they are first introduced.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 11

  • Key: ZIOP-24
  • Legacy Issue Number: 14374
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Location:
    Clause 4
    Comment:
    This is a multipart standard, and this clause title is "4 Part1 Document". It is confusing.
    Proposed Change
    Delete unnecessary "Part1".

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    agree to proposed change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 6

  • Key: ZIOP-19
  • Legacy Issue Number: 14369
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Introduction Structure of this standard
    Comment:
    1) The chapter numbers in Structure of this standard are not consistent with actual chapter numbers.
    Proposed Change
    1) Revise the chapter numbers.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Accommodate by deletion of “Structure of this Standard” unnumbered subsection. This
    subsection is not required.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 5

  • Key: ZIOP-18
  • Legacy Issue Number: 14368
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Introduction context of CORBA last para
    Comment:
    1) Since this document is submitted as PAS, it is better to reference ISO/IEC standard in addition to OMG standard
    Proposed Change
    1) Add ", or this standard (ISO/IEC 19500)" at the end of the first sentence.
    Resolution:

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    accept proposed changes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 4

  • Key: ZIOP-17
  • Legacy Issue Number: 14367
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    Introduction 3rd paragraph
    Comment:
    1) The second "Part 2" seems to be "Part 3" instead.
    2) Mixed use of "RM-ODP" and "RM ODP" is confusing.
    Proposed Change
    1) The second "Part 2" should be replaced with "Part 3."
    2) "RM ODP" should be replaced with "RM-ODP" where applicable.

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    Accept proposed change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Japan CORBA Part 1 PAS Ballot Comments - comment 1

  • Key: ZIOP-14
  • Legacy Issue Number: 14364
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Source: Japan NB, Severity te
    Summary:
    Japan will approve this DIS if the TH comments will accept.
    Resolution:
    If The TH comments JP17 were accepted in the approved resolutions. See resolutions to OMG Issues
    Revised Text:

    Disposition: Duplicate of xxxxxx

  • Reported: ZIOP 1.0b1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — ZIOP 1.0
  • Disposition Summary:

    No Data Available

  • 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

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

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

PriorityModelPolicy

  • Key: RT12-9
  • Legacy Issue Number: 5613
  • Status: closed  
  • Source: OOMWorks ( Irfan Pyarali)
  • Summary:

    RTCORBA::PriorityModelPolicy cannot be created via ORB::create_policy() method because this policy has two attributes <priority_model> and <server_priority> and the Any that is passed to the ORB::create_policy() method can only hold one parameter. Here is the proposed fix:

    struct PriorityModelParameter

    { PriorityModel priority_model; Priority server_priority; }

    ;

    local interface PriorityModelPolicy : CORBA::Policy

    { readonly attribute PriorityModelParameter value; }

    ;

    RTCORBA::create_priority_model_policy may also need to be changed (for consistency) to accept <PriorityModelParameter> rather than the two parameters separately.

  • Reported: RT 1.1 — Thu, 29 Aug 2002 04:00 GMT
  • Disposition: Resolved — RT 1.2
  • Disposition Summary:

    Closed, no change

  • Updated: Fri, 6 Mar 2015 20:51 GMT

Minor syntax errors in spec

  • Key: RT12-10
  • Legacy Issue Number: 5949
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Bill Beckwith)
  • Summary:

    These should be editorial changes:

    Section 2.7.4 Server Declared Priority Model

    ObjectId activate_object_with_priority (
    in PortableServer::Servant p_servant,
    in RTCORBA::Priority priority )
    raises ( ServantAlreadyActive, WrongPolicy );

    Should be:

    PortableServer::POA::ObjectId activate_object_with_priority (
    in PortableServer::Servant p_servant,
    in RTCORBA::Priority priority )
    raises ( PortableServer::POA::ServantAlreadyActive,
    PortableServer::POA::WrongPolicy );

  • Reported: RT 1.1 — Thu, 12 Jun 2003 04:00 GMT
  • Disposition: Resolved — RT 1.2
  • Disposition Summary:

    Accept as specified

  • Updated: Fri, 6 Mar 2015 20:51 GMT