Issues for IDL/Java Revision Task Force mailing list

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

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

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

Issue 632: Spec insufficient in section 5.2.1 - Reserved Names
Issue 799: Problems with IDL unions mapped to Java
Issue 888: Section 5.14 and 6.11 IDL/Java Language mapping
Issue 890: Add missing UnknownUserException
Issue 891: ImplementationDef should be an abstarct class
Issue 892: create_list semantics not well defined
Issue 893: delegate field in ObjectImpl should be transient
Issue 894: input/output streams should extend java.io.streams
Issue 895: _orb() is missing from ObjectImpl
Issue 896: Make all basic Holders implement Streamable
Issue 897: Fix any"s to have implement copy semantics
Issue 898: Clarify the use of return_value() before invoke() in DII
Issue 899: Clarify exact list of methods available on singleton orb
Issue 907: Current mapped incorrectly in Java language mapping
Issue 908: CORBA::DATA::CONVERSION exception for IDL types wchar/wstring
Issue 909: IDL/Java language mapping, section 5.14, 6.11
Issue 919: Problem with IDL --> Java mapping for Unions
Issue 1090: Reserved names
Issue 1142: POA_Interface bug
Issue 1143: Chapter 9.8.1 Local stubs-bug
Issue 1167: Any.insert_Object()
Issue 1242: Any"s and Exceptions
Issue 1381: No INV_NO_RESPONSE possible in Java DII
Issue 1385: Discriminated Union value issue
Issue 1536: Helper classes are only for user defined IDL types
Issue 1577: Section 7.1.3 of Java to IDL mapping
Issue 1583: org.omg.CORBA.UserException class not specified
Issue 1586: Callback issue
Issue 1672: Does object reference == ObjectImpl?
Issue 1696: Proposed change to orb.init
Issue 1701: Mapping of IDL constants to Java
Issue 1703: orb.properties file issue
Issue 1704: Proposed change sto IDL/Java mapping
Issue 1705: Add Any.extract_Streamable()
Issue 1722: New stream based stubs and location forward
Issue 1724: OutputStream semantics question
Issue 1730: Changes to Java fixed type mapping
Issue 1731: Java mapping"s use of _this()
Issue 1732: Changes to Java interface mapping
Issue 1734: Mapping of IDL names that clash with java.lang.Object methods
Issue 1737: Compiler-readable code
Issue 1738: Object._request variants are unspecified
Issue 1739: Local stubs
Issue 1741: Java RTF issue
Issue 1746: Conext support in Java
Issue 1750: 2 IDL->Java issues on the singleton ORB (02)
Issue 1752: mapping of IDL enumerations to java
Issue 1754: Proposal to change get_value_def in Java mapping
Issue 1795: final methods on ObjectImpl
Issue 1897: Evolving the org.omg.* APIs
Issue 1941: Problem mapping "global" types in Java mapping
Issue 1942: Need overloaded write_Value method on OutputStream
Issue 1961: Java Mapping for interfaces -- Proposal
Issue 1964: Creating TypeCodes safely in java
Issue 1980: Updated proposal for the OBV Java mapping
Issue 1993: create_lname & create_lname_context
Issue 1994: Local stubs proposal
Issue 2079: Potential problem with Java Mapping ORB init for Applet
Issue 2096: Issue with Mapping for Constants within an interface
Issue 2228: typedefs in IDl when generating Java code
Issue 2233: Helper "narrow" exception clarification
Issue 2251: Java LocalStub
Issue 2255: Proposal for persistent valuetypes
Issue 2256: PSS requiremnets for the ObV/Java mapping
Issue 2462: BAD_PARAM issue
Issue 2514: PortableServer Servant issue
Issue 2517: orb.properties search should include home directory
Issue 2518: Incorrect search order for ORB implementation class name
Issue 2519: Need SerializableHolder class
Issue 2520: Standard properties should include initial host and port
Issue 2528: Mapping Messaging sendc_ (and sendp_) methods to Java
Issue 2531: Serializable objects in Anys need reference semantics
Issue 2532: Mapping of AbstractBase and abstract interfaces
Issue 2540: _servant_postinvoke
Issue 2550: Dealing with reserved suffixes (e.g. POA)
Issue 2608: Java - Mapping for Struct issue
Issue 2609: Issues with ObjectImpl implementations
Issue 2647: Modification of Constant Mapping
Issue 2661: Valuetype packages
Issue 2721: DII and SystemException semantics
Issue 2770: Java substitutability issue: value instance -> interface type
Issue 2823: Java mapping for PolicyType...
Issue 2889: Should Any.extract_string work for bounded strings?
Issue 2979: Java SystemException should contain nested exception field
Issue 3068: Messaging sendc and sendp missing from portability interfaces
Issue 3204: ORB Init problems
Issue 3209: Illegal return statement
Issue 3267: How to create marshalel data of java.lang.Throwable instance?
Issue 3320: Java language mapping: Tie classes for local interfaces.
Issue 3323: Need clarification on custructor(s) for stream-based stubs/skeletons
Issue 3410: IDL/Java: methods marked final in PortableServer.Servant
Issue 3570: org.omg.CORBA.portable.UnknownException does not have all constructors
Issue 3575: Custom marshal does not work for certain valuetypes
Issue 3633: Request clarification for use of alias typecodes in typedef helper classes
Issue 3643: Description of ORB.init parameters insufficient
Issue 3654: OMG ZIP FILE ISSUES for IDL to Java RTF (01)
Issue 3655: OMG ZIP FILE ISSUES for IDL to Java RTF (02)
Issue 3656: OMG ZIP FILE ISSUES for IDL to Java RTF (03)
Issue 3657: OMG ZIP FILE ISSUES for IDL to Java RTF (04)
Issue 3658: OMG ZIP FILE ISSUES for IDL to Java RTF (05)
Issue 3659: OMG ZIP FILE ISSUES for IDL to Java RTF (06)
Issue 3665: Java ORB Id
Issue 3668: Possible problem with IDL to Java mapping of fixed-point decimal types
Issue 3669: Enum mapping issue
Issue 3686: How can org.omg.CORBA.portable.InputStream.read_fixed possibly work?
Issue 3707: Need clarification on custructor(s) for stream-based
Issue 3750: SystemExceptionHelper missing
Issue 3788: Mapping for Sequences -> <sequence_class>Holder
Issue 3794: IDLEntity interface has to be public.
Issue 3795: Incorrect method declaration in CORBA_2_3/portable/InputStream.java and Out
Issue 3801: policy_type should map to a Java int.
Issue 3818: Operations signatures include throws clauses on system exceptions.
Issue 3819: Issues with Java mapping of Typecode
Issue 3903: mapping for Request.target will not compile
Issue 3904: ptc/00-01-08: Conflict 1.15.1 paragraph 2 - 1.19.2 paragraph 2
Issue 3911: Incomplete union mapping
Issue 3912: How is an ORB to determine whether or not it is in an applet context?
Issue 3913: Vendor-specific ORB_init methods
Issue 3923: #pragma prefix issue
Issue 3946: CompletionStatus needs to implement org.omg.CORBA.portable.IDLEntity
Issue 3979: IDL to Java Spec Issue : need to add SystemExceptions introduced in CORBA 2
Issue 3994: Valuetype unmarshalling
Issue 3995: Copying boxed valuetypes on local calls
Issue 4009: Union exceptions
Issue 4010: Should valuetype helper insert/extract make copies?
Issue 4013: Usage of ExceptionDetailMessage service context
Issue 4057: Displaying SystemExceptions
Issue 4059: When to honor the servant delegate in POA?
Issue 4064: Any extract operations for tk_abstract_interface
Issue 4076: System Exceptions REBIND, TIMEOUT, BAD_QOS
Issue 4158: publication of messaging / unchecked_narrow
Issue 4271: IDL/Java issue, Mapping for IDL enum
Issue 4286: Clarification of serialization of Anys and Typecodes
Issue 4323: local interface mapping underspecified
Issue 4549: Missing elements of the local mapping
Issue 4624: support for local objects
Issue 4699: is_a support in Java for local interfaces
Issue 4701: Colocated calls in Java
Issue 4710: Mapping for Character and String Types
Issue 4741: New issue on register_initial_reference
Issue 4748: Naming issues for new ORB methods
Issue 4749: New issue: Error in resolution of issue 4699
Issue 4750: Make CORBA_2_3.ORB methods available in CORBA.ORB
Issue 4792: exceptions on valuetype initializers
Issue 4793: attribute exceptions
Issue 4794: OMG Java Language Mapping and the use of Java null
Issue 4802: Should a holder class for ProtectingEntity get generated
Issue 4804: section 1.18.2 of the OMG IDL mapping document ptc/00-01-08
Issue 4805: Java mapping changes for core issue 4337
Issue 5108: J2EE ORB Socket Factory API
Issue 5465: Default UnknownException behavior
Issue 5468: Anys obtained using the singleton ORB
Issue 5586: interfaces that do not extend org.omg.CORBA.portable.ValueBase
Issue 5595: Should javadoc statement be removed or should method be removed?
Issue 5615: Streaming Interfaces
Issue 5638: Typo on getRaises and setRaises in formal/2002-08-05
Issue 5646: Java source code for org.omg.PortableServer.POAOperations
Issue 5693: POA changes missing in Java source archive
Issue 5694: What is the IDL for ServiceInformation and/or what is correct Java mapping?
Issue 5696: Package name issue
Issue 5728: How does a Java ORB implement a write_fixed/read_fixed?
Issue 5782: Missing operations on org.omg.CORBA.Object
Issue 5783: Stub handling of UnknownException
Issue 5806: response_expected value for colocated invocations
Issue 5893: definition of FixedHolder should have been removed
Issue 7846: wrong enumeration value for SetOverrideType
Issue 9795: section 1.21.3 IDLEntity
Issue 15709: Specification does not provide mapping spec for Home, Component and Event

Issue 632: Spec insufficient in section 5.2.1 - Reserved Names (java-rtf)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:
Summary: Reserved words seen as IDL identifiers be prepended by an underscore. Insufficient for Holder, Helper, Package in case where two or three of these strings appear in single identifier

Resolution: Clarify the IDL Name conflict resolution rules to resolve this case. Also change the naming rules
Revised Text: Solution suggested: extend rule in section 5.2.1 to require one underscore to be prepended for each suffix on the nameAdd the following sentence to paragraph 2 in Section 25.1 "Names":
Actions taken:
July 23, 1997: received issue
May 18, 1998: Deferred
June 4, 1999: closed issue

Discussion:


Issue 799: Problems with IDL unions mapped to Java (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:
Summary: I have found a problem with the Java to IDL mapping (97-03-01) in the area of Unions. The problem is that the Java-idl mapping does not provide any means by
 which the user can set the value of the union to be one of the non
 branch members of the enum such as B.
 
 

Resolution: resolved/closed
Revised Text:
Actions taken:
November 28, 1997: received issue
February 19, 1999: closed issue

Discussion:


Issue 888: Section 5.14 and 6.11 IDL/Java Language mapping (java-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Summary: In the class definition for Any there is only 
 insert_Streamable(...), but no 
 extract_Streamable(...).  How do you extract 
 streamables?
 

Resolution: duplicate, issue closed
Revised Text:
Actions taken:
January 7, 1998: received issue
May 19, 1998: closed issue, duplicate of issue 909

Discussion:


Issue 890: Add missing UnknownUserException (java-rtf)

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

Resolution: closed issue, resolved
Revised Text:
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 891: ImplementationDef should be an abstarct class (java-rtf)

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

Resolution: closed issue, resolved
Revised Text:
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 892: create_list semantics not well defined (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: create_list semantics are not well-defined in CORE and hence Java
        Language Mapping
 

Resolution: resolved/closed
Revised Text:
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:
 received issue


Issue 893: delegate field in ObjectImpl should be transient (java-rtf)

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

Resolution: closed issue
Revised Text:
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 894: input/output streams should extend java.io.streams (java-rtf)

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

Resolution: closed issue, resolved
Revised Text:
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 895: _orb() is missing from ObjectImpl (java-rtf)

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

Resolution: closed issue, resolved
Revised Text:
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 896: Make all basic Holders implement Streamable (java-rtf)

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

Resolution: proposal approved, issue closed
Revised Text:
Actions taken:
January 12, 1998: received issue
February 19, 1999: closed issue

Discussion:


Issue 897: Fix any"s to have implement copy semantics (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Issue: Fix any"s to have implement copy semantics, similar to C++
 

Resolution: closed
Revised Text: closed issue
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:
 closed issue


Issue 898: Clarify the use of return_value() before invoke() in DII (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Clarify the use of return_value() before invoke() in DII.
        When using dii in Java (in portable stubs), it should be possible
        to call return_value() before invoke() in order to get the Any 
        that will be associated with the return. It is then possible
        to insert a streamable, which when combined with fixing copy
        semantics for any"s, will enable a big performance improvement. 
 

Resolution: closed
Revised Text:
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 899: Clarify exact list of methods available on singleton orb (java-rtf)

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

Resolution: closed issue
Revised Text:
Actions taken:
January 12, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 907: Current mapped incorrectly in Java language mapping (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:
Summary: 
  In 2.1 current became a regular IDL interface, so its mapping needs to
 change.
  Proposed Change:
     delete section 23.16.14 on current
 

Resolution: closed issue
Revised Text:
Actions taken:
January 15, 1998: received issue
May 19, 1998: closed issue

Discussion:
 closed issue


Issue 908: CORBA::DATA::CONVERSION exception for IDL types wchar/wstring (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: This specification defines CORBA::DATA_CONVERSION exception for IDL
 types char/string, but does not define same exception for IDL types
 wchar/wstring. However, in the CORBA 2.1, IDL types wchar/wstring can
 handle any codeset beside Unicode (see section "10.7 Code Set Conversion"
 in CORBA 2.1) as well as IDL types char/string. Therefore, data
 conversion error may occur between IDL types wchar/wstring and Java
 types char/java.lang.String.
 

Resolution: closed issue
Revised Text:
Actions taken:
January 16, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 909: IDL/Java language mapping, section 5.14, 6.11 (java-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
Summary: In the class definition for Any there is only 
 insert_Streamable(...), but no 
 extract_Streamable(...).  How do you extract 
 streamables?
 

Resolution: closed issue
Revised Text:
Actions taken:
January 7, 1998: received issue
May 18, 1998: Deferred
July 30, 1998: closed issue

Discussion:


Issue 919: Problem with IDL --> Java mapping for Unions (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: I have found what appears to be a short coming of the IDL to Java
 mapping for unions.  
 Reading the CORBA V2.0 (July 1995) on pages 3-23 and 3-24 it indicates
 unions can have a value of the discriminator where there is not a case
 that matches the discriminator.  The Trader Service specification has a
 great example of when this may be needed (in fact we are following this
 pattern in PIDS). The Java mapping for unions does not have a method or constructor for
 setting the discriminator when the discriminator does not correspond to
 at least one case label. 
 

Resolution: closed issue
Revised Text:
Actions taken:
January 23, 1998: received issue
May 19, 1998: closed issue

Discussion:


Issue 1090: Reserved names (java-rtf)

Click
here for this issue's archive.
Nature:
Severity:
Summary:
Summary:  The list of java keywords provided is an old one.
 >     Should this be updated to the following list?
 >       abstract boolean break
 >       byte byvalue case cast catch char
 >       class const continue default do double
 >       else extends final finally float for
 >       future generic goto if implements import
 >       inner instanceof int interface long native
 >       new null operator outer package private
 >       protected public rest return short static
 >       super switch synchronized this throw throws
 >       transient try var void volatile while
 

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

Discussion:


Issue 1142: POA_Interface bug (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: Chapter 5.2.4
 class POA_<interface_name> is supposed to implement 
 <interface_name>Operations.
 
 However neither specification nor the example contain any  
 operations method.  The class also are not specified abstract.
 
 

Resolution: closed issue
Revised Text:
Actions taken:
April 16, 1998: received issue
May 18, 1998: closed issue

Discussion:


Issue 1143: Chapter 9.8.1 Local stubs-bug (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Chapter 9.8.1
 Says "Local stubs are defined to be direct base classes of remote stubs"
 Does it matter?  It is the opposite way as proposed in the drawing in
 chapter 6.4
 
 
 MORE FAR-FETCHED IDEA
 
 What if the Operations interface would not contain the inheritance
 relationship?  Wouldn"t that be a step in the direction of being able
 to implement independent interfaces with one class.  (To be
 functional this would need matching changes in the tie class) 
 

Resolution: closed issue
Revised Text:
Actions taken:
April 16, 1998: received issue
May 18, 1998: closed issue

Discussion:


Issue 1167: Any.insert_Object() (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: In Section 23.13, the signature for insert_Object() is given as,
 
 // throw excep when typecode inconsistent with value
 abstract public void insert_Object(
                     org.omg.CORBA.Object o, org.omg.CORBA.TypeCode t)
                                 throws org.omg.CORBA.MARSHAL;
 
 Does this mean if an incorrect TypeCode is passed, eg. tk_short, that a
 MARSHAL
 Exception must be thrown or could a BAD_PARAM Exception be thrown.
 

Resolution: closed issue
Revised Text:
Actions taken:
April 22, 1998: received issue
May 18, 1998: closed issue

Discussion:


Issue 1242: Any"s and Exceptions (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: In Section 23.13, the signature for insert_Object() is given as,
 
 // throw excep when typecode inconsistent with value
 abstract public void insert_Object(
                     org.omg.CORBA.Object o, org.omg.CORBA.TypeCode t)
                                 throws org.omg.CORBA.MARSHAL;
 
 Does this mean if an incorrect TypeCode is passed, eg. tk_short, that a
 MARSHAL Exception must be thrown or could a BAD_PARAM Exception
 be thrown.
 
 Also, I assume read_value() is meant to insert a complex IDL type into
 an Any ?
 If so, read_value() is supposed to throw a MARSHAL Exception if the
 typecode
 is inconsistent with the value. Does this mean that if a short has been
 written to the
 stream, but the stream is passed with a tk_sequence typecode, then an
 Exception
 should be thrown by read_value() ?.
 

Resolution: closed issue
Revised Text:
Actions taken:
April 27, 1998: received issue
May 18, 1998: closed issue

Discussion:


Issue 1381: No INV_NO_RESPONSE possible in Java DII (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: There is no Flags argument in the create_request operations
 as mapped from PIDL to Java.  This means that there is no
 way to create a request with INV_NO_RESPONSE.  Therefore,
 you cannot do oneway invocations in Java DII without the ORB 
 having to consult the Interface Repository (clearly
 unnacceptable).
 

Resolution: closed/resolved
Revised Text:
Actions taken:
May 18, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1385: Discriminated Union value issue (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: An IDL Discriminated Union has a discriminator of some type. The
 discriminator is permitted to take any value allowed by its type -
 nothing in the CORBA spec constrains the discriminator"s value to be
 those of the branch labels present in the union or just one catch-all
 default. For this reason, CORBA 2.2, section 3.8.2 defines a Discriminated
 Union"s value as follows:  <example>So, if I were to create a foo and set the discriminator to 74, someone
 receiving this instance from me should be able to discern that the
 discriminator"s value was set to 74.
 
 As it stands, the IDL->Java mapping provides for discovering the value
 of the discriminator, so if some other ORB sent me a foo with the
 discriminator set to 74 I could discern this, but as far as I can tell
 from reading the current IDL->Java mapping (CORBA 2.2 - no relevant
 changes appear to be present on orbos/98-03-10) there is no way that I
 could set the discriminator"s value to 74.
 
 

Resolution: closed issue
Revised Text:
Actions taken:
May 19, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1536: Helper classes are only for user defined IDL types (java-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
Summary: The Java Language Mapping mandates Helper classes for user defined IDL
 types but does not say Helper classes are ONLY for user defined IDL types.
 Please let us all know whether the ObjectHelper class is standard or not.
 

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

Discussion:


Issue 1577: Section 7.1.3 of Java to IDL mapping (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Section 7.1.3 of the Java to IDL mapping specifies new methods
 _request, _invoke, and _releaseReply to be added to both 
 org.omg.CORBA.portable.ObjectImpl and org.omg.CORBA.portable.Delegate.
 
 There is an existing convention that methods on ObjectImpl have
 leading underscores but the corresponding methods on Delegate do not.
 
 I propose that the new methods on Delegate be named request, invoke,
 and releaseReply to confirm to this existing convention.
 

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

Discussion:


Issue 1583: org.omg.CORBA.UserException class not specified (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: The current mapping does not specify the org.omg.CORBA.UserException
 class. I propose the mapping below. All generated user exception 
 constructors should then pass the exception"s id to the UserException
 string constructor. The toString() method on the exception will then 
 output the Exception"s type id.
 
 package org.omg.CORBA;
 
 public abstract class UserException extends java.lang.Exception 
 {
   public UserException()
   {
   }
 
   public UserException(String r)
   {
     super(r);
   }
 }
 
 

Resolution: closed issue
Revised Text:
Actions taken:
June 26, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1586: Callback issue (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: IIOP only permits requests to flow in the direction that the underlying
 connection was opened. The Java sandbox only allows outbound
 connections. Consequently we are left with a situation where applets can
 only ever make outbound requests, callback objects can never be
 registered. For any sort of asynchronous notification pattern, this is a
 problem. (There is an obvious workaround with blocking calls and a
 waiting thread, but this sort of interaction should never be required of
 application developers.)
 
 Most products provide a means to handle callbacks in this situation,
 presumably via non-standard mechanisms, I am yet to explore how.
 
 It would seem that, from the point of view of those involved in this
 RTF, a standardised means to handle reverse calls over IIOP would be
 beneficial.
 
 Is my reasoning flawed? Is there a revision going on elsewhere to
 address this? Is there interest in standardising this?
 

Resolution: closed issue
Revised Text:
Actions taken:
June 26, 1998: received issue
July 30, 1998: closed issue

Discussion:


Issue 1672: Does object reference == ObjectImpl? (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The issue is whether or not code that calls the _this_object method
 of the org.omg.PortableServer.Servant class (which is declared to
 return an org.omg.CORBA.Object type) can assume that the result
 of calling _this_object can be safely cast to ObjectImpl.
 
 The decision of the RTF was that this is a safe assumption, but no
 change is necessary to the spec because it is already clearly stated
 that all stubs (object references) must be subclasses of ObjectImpl.
 
 
 
 
 
 
 
 

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

Discussion:


Issue 1696: Proposed change to orb.init (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: How should ORB.init() be fixed?
 
 ORB.init() should try to find an ORB class in the following order:
 
   1. Try loading the class using Class.forName(String className) --  this is
      to take into account the possibility that the ORB implementation class
      is in the core (for example: com.sun.CORBA.iiop.ORB). If that fails,
   2. Try loading the class using Class.forName(String className, boolean
      initialize, ClassLoader cl), where cl ==
      ClassLoader.getSystemClassLoader(). In the case of an applet, cl ==
      applet.getClass().getClassLoader().
 
 For sophisticated users who might have a well-behaved ClassLoader that knows
 how to load the ORB implementation, it might be necessary to have a new
 ORB.init() that takes a ClassLoader as an argument. For example:
 
      ORB.init(String[] args, Properties props, ClassLoader cl);
 
 In this case, ORB.init() would load the class using the class loader that
 was passed by the user instead of the system class loader.
 

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

Discussion:


Issue 1701: Mapping of IDL constants to Java (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The IDL to Java mapping specifies that IDL constants are mapped
 to public static final fields within a Java interface.  Examples
 are shown that include "public static final" modifiers for these
 fields.
 
 The Java Language Specification (Gosling/Joy/Steele) states in
 section 9.3 that "Every field declaration in the body of an
 interface is implicitly public, static, and final.  It is permitted,
 but strongly discouraged as a matter of style, to redundantly
 specify any or all of these modifiers for such fields."
 
 I propose that the text and examples be changed to remove the 
 explicit "public static final" modifiers.
 

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

Discussion:


Issue 1703: orb.properties file issue (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: 
 The search order followed by ORB.init when looking for the names
 of the ORB and ORB singleton classes does not allow a user to
 install a specified ORB as the default ORB, overriding the 
 hardcoded default behavior.  It is possible to override the
 hardcoded default by setting system properties, but this requires
 running the java command with an explicit -D option every time, 
 which is awkward.
 
 I propose that an additional step be added to this search order,
 between "check in the System properties" and "fall back on 
 hardcoded default behavior".

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

Discussion:


Issue 1704: Proposed change sto IDL/Java mapping (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: The following proposal describes changes to the IDL/Java mapping
 that will allow values to be marshalled and demarshalled more
 efficiently in both the "forward mapping" and "reverse mapping"
 cases.  It also allows other IDLEntity types to be marshalled and
 demarshalled more efficiently in the reverse mapping case, and it
 fixes some problems in the existing spec with marshalling and
 demarshalling values and boxed strings. 
 

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

Discussion:


Issue 1705: Add Any.extract_Streamable() (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: 	org.omg.CORBA.portable.Streamable extract_Streamable(); 
 
 As the name of the operation suggests it allows any Streamable 
 value inserted into an Any using insert_Streamable() to be 
 extracted. A BAD_INV_ORDER exception will be thrown if the 
 operation is invoked on an Any that doesn"t already contain a 
 Streamable. 
 
 The addition of this method allows for a more efficient Any 
 implementation especially when collocation and DII/DSI is in use. 
 
 
 

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

Discussion:


Issue 1722: New stream based stubs and location forward (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The new portable stream-based stubs for the Java language mapping
 do not properly handle location forwards properly.  The ORB must
 be able to give some indication to the ORB that it must remarshal
 in case the ORB receives a locate forward or object forward message.
 The remarshalling is required because the object key in the request
 message may have changed and the alignment will be incorrect.
 

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

Discussion:


Issue 1724: OutputStream semantics question (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: When an InputStream is created by an OutputStream, is it permitted to
 continue to write anything more to the OutputStream?
 
 If this is not permitted, we should presumably lock out the OutputStream
 and throw an exception if another write_X is attempted after the 
 create_input_stream.
 
 If this is permitted, we need to say whether or not the things written
 to the OutputStream after the InputStream is created show up in the
 InputStream or not.
 

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

Discussion:


Issue 1730: Changes to Java fixed type mapping (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The current mapping for fixed type was written with the intention
 of supporting JDK 1.0.2 as well as JDK 1.1.  Recent changes in the
 Java RTF and other recently adopted submissions (Java to IDL) have
 introduced a JDK 1.1 requirement in the Java mapping which make
 it possible to implement certain operations on fixed types in a
 type safe manner instead of the current specification.
 
 

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

Discussion:


Issue 1731: Java mapping"s use of _this() (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The current Java mapping for the POA defines semantics for _this()
 (also known as _this_object()) which are consistent with the C++
 mapping.  However, the current specification for 
 org.omg.PortableServer.Servant does not support those semantics.
 
 

Resolution: closed issue
Revised Text:
Actions taken:
July 24, 1998: received issue
July 30, 1998: Deferred
February 22, 1999: closed issue

Discussion:
  Resolution is to fix the behavior of servant_to_reference by revising text as shown below


Issue 1732: Changes to Java interface mapping (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: This issue is based off of discussion with engineers at Sun.
 
 The recent portability submission introduced changes to the 
 mapping for Java interfaces.  This change was to generate both
 a signature interface and an operations interface.  The signature
 interface is defined to extend the operations interface.  While
 the need for both interfaces is clear, it is not clear if the
 relationship between the two interfaces is necessary. The change
 requires additional classes to be downloaded for the remote stub
 case and could potentially impact performance.
 
 
 
 

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

Discussion:


Issue 1734: Mapping of IDL names that clash with java.lang.Object methods (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: It appears that the IDL to Java mapping does not remap IDL identifiers
 that collide with the 9 method names defined for java.lang.Object; i.e.
   "clone", "equals", "finalize", "getClass", "hashCode", "notify", 
   "notifyAll", "toString" and "wait"
 If a CORBA/Java server attempts to implement IDL operations with these 
 names, it will either overload the Object operations, or give compilation
 errors (for Object methods declared as "final").  In either case, it looks
 like the IDL mapping should treat these names as if they were Java
 reserved words.
 
 

Resolution: closed issue
Revised Text:
Actions taken:
July 25, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1737: Compiler-readable code (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: 
 
 PLEASE PLEASE PLEASE resist the temptation to include consolidated Java
 source code in .PDF files. At least 3 reasons exist:
 
 - EVERY publication of the consolidated org.omg.* hierachy so far has
 contained code that, even before inclusion in the PDF, simply could not
 have compiled (void functions returning values, non-void functions
 failing to do so, etc.). Errors of this nature arise through having an
 editor have to maintain two seperate copies of the code. The need to
 apply changes twice (to compiler readable and to .PDF) all but
 guarantees that errors will creep in, particularly given that only the
 non-.PDF version can be machine checked.
 

Resolution: closed issue
Revised Text:
Actions taken:
July 27, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1738: Object._request variants are unspecified (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: It is possible that some part of the C++ mapping is intended to apply
 here, but even so, the Java mapping should stand independantly of the
 C++ mapping. Requiring Java developers (of ORBs and of applications) to
 know C++ and the C++ mapping seems excessive
 
 
 

Resolution: closed issue
Revised Text:
Actions taken:
July 27, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1739: Local stubs (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: - There is no example given in the mapping. I forget the exact problem,
 but some guesswork was required to work out exactly what code should be
 generated.
 
 - Why should the class name be specified? Surely it is up to the Helper
 to generate instances and thus decide which to create? (I note that
 recent changes have altered this somewhat, with ORBs apparently now free
 to bypass the Helper altogether and instantiate stubs directly. This
 seems like a bad idea.)
 
 - Why are local stubs disctinct? Given that a local stub has to deal
 with the possibility of an object ceasing to be local, and that it would
 be desirable for a non-local stub to discover that an object has become
 local and make use of that knowledge, surely it is up to ORB
 implementors to have their Helpers make whatever choices are appropriate
 to instantiate appropriate stubs. The way that the mapping currently
 stands, it does not seem to be possible to implement a stub that will
 cope with objects moving into and out of the current JVM and still
 remain compliant.
 
 - _is_local is redundant. The success/failure of preinvoke is the acid
 test. This also avoids races: if preinvoke suceeds then you know that
 the object is available for a single local invocation. If _is_local
 suceeds, then you know nothing of the sort, you have to invoke preinvoke
 anyway, and if it fails, invoke remotely anyway.
 

Resolution: closed issue
Revised Text:
Actions taken:
July 27, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1741: Java RTF issue (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: ObjectImpl._servant_preinvoke(), how many arguments does it take? The
 spec and the consolidated code in the appendix currently differ.
 
 ---
 
 Are Helpers/Holders for SystemExceptions generated? Are they streamable?
 How does one insert them into an Any?
 
 (I gain the impression that there has been some work in this area. This
 may no longer be an issue.)
 
 ---
 
 Why are the mapped classes for structs "final" when little else is? Is
 there a reason for preventing application developers from sub-typing
 them?
 

Resolution: closed issue
Revised Text:
Actions taken:
July 27, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1746: Conext support in Java (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: Below are the proposed spec changes to support Contexts in IDL/Java.
 It turns out that some type of API change will be required.  As I was
 investigating this further today I realized that one of the methods
 on ORB we have to support Context streaming is a proprietary method
 and not a standard method, so there is no way to create a Context 
 object given an InputStream.  This makes demarshalling of contexts
 impossible in the stream-based model as it exists today.  The proposal
 adds one new method each to InputStream and OutputStream.  Also, as
 requested by Simon I have text which states how the Context parameters
 are used in interface method declarations.
 
 

Resolution: closed issue
Revised Text:
Actions taken:
July 27, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1750: 2 IDL->Java issues on the singleton ORB (02) (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: How is an ORB to determine whether or not it is in an
 applet context? The nearest that I can see is to check for the presence
 of a SecurityManager. If we are in an applet context, then there is a
 SecurityManager present, but the inverse (that the presence of a
 SecurityManager implies that we are in an applet) is not true. It is
 however the case that whenever a SecurityManager is present, potentially
 untrusted code is present, so the same constraints on the singleton ORB
 are probably appropriate. Therefore, I propose that the specification be
 changed to state that if System.getSecurityManager() returns a non-null
 result, the singeton ORB should be constrained to creating TypeCodes and
 Anys.
 
 

Resolution: Close, no action
Revised Text:
Actions taken:
July 29, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1752: mapping of IDL enumerations to java (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:
Summary: he current mapping of IDL enumerations to Java relies on there being
 one and only one instance of an enum.  The instance is held as
 a static variable in the enumeration class.  Since there is only
 one instance, identity comparisons are used in comparing enums and
 the enumeration value class does not implement equality or hash
 methods based on the value of the enum.
 

Resolution: Close, no action
Revised Text:
Actions taken:
July 29, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1754: Proposal to change get_value_def in Java mapping (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: The current support for get_value_def in Helper classes in the
 Java mapping for values is currently has several problems.
 
 1. It cannot work with the singleton ORB, which means that the API
    is unusable.
 
 2. It requires the generation of the nearly the exact same code in
    every single value helper which is very wasteful.
 
 The new proposal is to remove get_value_def from the Value helper class
 and add it to the ORB class

Resolution: closed issue
Revised Text:
Actions taken:
July 30, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1795: final methods on ObjectImpl (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The _get_delegate() and _set_delegate() methods on the Java class
 org.omg.CORBA.portable.ObjectImpl should be marked "final" so they
 can be inlined by an optimizing java compiler.
 
 

Resolution: closed issue
Revised Text:
Actions taken:
August 11, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1897: Evolving the org.omg.* APIs (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: Now that the org.omg.* APIs are built into the JDK core (from JDK 1.2
 onwards), there is an issue with how these could be evolved to
 support changes to the OMG spec that happen between JDK major releases.
 The following is a proposal for how this could be handled.
 

Resolution: resolved, see revised text
Revised Text: 1. Change the IDL/Java mapping of enums so that a. the generated Java classes are not final b. the from_int method is not final, and c. the constructor is protected instead of private. Rationale: This change has previously been discussed by this RTF. It is needed in this context because of the need to include some Java classes mapped from IDL enums (e.g., TCKind) in the core JDK. If new members are added to such an enum later, there needs to be a way to subclass the generated Java class to produce a subclass that corresponds to the new IDL (or PIDL) enum. 2. Change the Object, ObjectImpl, and Delegate classes to a. add new methods org.omg.CORBA.Object _get_interface_def() to Object and ObjectImpl and org.omg.CORBA.Object get_interface_def(org.omg.CORBA.Object self) to Delegate. b. deprecate the existing methods org.omg.CORBA.InterfaceDef _get_interface() on Object and ObjectImpl and org.omg.CORBA.InterfaceDef get_interface(org.omg.CORBA.Object self) on Delegate. Rationale: The new methods do not refer to Interface Repository types in their signatures. However, at runtime they still return the same IR objects as the deprecated methods. Since this signature change is a binary incompatible change, and since Java methods cannot be overloaded on their return types, the new methods have different names than the deprecated methods. This allows an easier path for user migration than if the method signatures had been updated "in place". Removing IR types from the signatures allows the new methods to be included in the core JDK without also having to include all the IR classes in the core JDK. With likely changes in this area in the near future because of the Components RFP, it is felt to be unwise to put the IR into core in JDK 1.2. 3. Change the ORB class to a. add a new method public NVList create_operation_list(org.omg.CORBA.Object oper) b. deprecate the existing method public NVList create_operation_list(org.omg.CORBA.OperationDef oper) Rationale: The reason for this change is as for item 2 above. Since Java supports overloading on argument types, there is no need to change the method name in this case. 4. Move some methods needed by Objects By Value from the ORB, InputStream and OutputStream classes to new subclasses (that will not be part of the core JDK 1.2). The names of these new classes are: org.omg.CORBA_2_3.ORB org.omg.CORBA_2_3.portable.InputStream org.omg.CORBA_2_3.portable.OutputStream and the methods affected are: ORB.get_value_def ORB.register_value_factory ORB.unregister_value_factory ORB.lookup_value_factory InputStream.read_Value InputStream.read_Abstract OutputStream.write_Value OutputStream.write_Abstract OutputStream.start_block OutputStream.end_block
Actions taken:
August 28, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1941: Problem mapping "global" types in Java mapping (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The current IDL/Java mapping cannot correctly map IDL "global" types
 correctly in all cases.

Resolution: Close, no action
Revised Text:
Actions taken:
September 9, 1998: received issue
June 4, 1999: closed issue

Discussion:
 closed issue


Issue 1942: Need overloaded write_Value method on OutputStream (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: We have come across a case in the Java-to-IDL mapping where we
 need another overloaded form of the write_Value method on the
 org.omg.CORBA.portable.OutputStream class.
 

Resolution: Close, no action
Revised Text:
Actions taken:
September 10, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1961: Java Mapping for interfaces -- Proposal (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Sun would like to see the following changes to the mapping: 
 * Change the specification to:
 * 
 * either not specify that object reference types extend the operations interfaces, or
 * 
 * specify that object reference types do not inherit from the operations interface and that the operations interface is just used on the server-side for delegation-based object implementations.
 * 
 
 * The convention established was that the names of all Java classes/interfaces generated for the server-side as well as those that are not visible start with an `_". We would like to stick to the convention and rename the operations interface accordingly.
 

Resolution:
Revised Text:
Actions taken:
September 15, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1964: Creating TypeCodes safely in java (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: There are problems with creating recursive TypeCodes containing values.Our proposal is really quite simple.  We want to add a new class to the
 org.omg.CORBA.portable package defined as follows:
 
 package org.omg.CORBA.portable;
 
 final public class TypeCodeLock {
 }
 
 All generated type() methods in Helper"s could synchronize on the
 TypeCodeLock"s class object to grab a global lock which is used during
 TypeCode creation to guarnatee the atomicity of TypeCode creation.
 Note, this is essentialy what is done in C++ where TypeCodes are typically
 initialized in a global static initalizer which is done from a single
 thread.  We are just allowing the typecodes to be created lazily.
 

Resolution: Close, no action
Revised Text:
Actions taken:
September 16, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1980: Updated proposal for the OBV Java mapping (java-rtf)

Click
here for this issue's archive.
Nature: Revision
Severity:
Summary:
Summary: updated proposal for the OBV Java mapping which addresses
 a number of issues which have been raised by us and others.  This
 proposal is based on a number of discussions and previous proposals
 and current OMG submissions (thanks to Simon Nash and Bernard
 Normier).  As with previous poposals, these are not currently formal
 proposals, just working drafts. ;-)
 
 Here are the current issues:
 
 1. Java valuetypes cannot unmarshal recursive references to themselves.
    This is the same problem that occurs with custom valuetypes.
 
 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.
 
 3. Java valuetypes need a way to unmarshal the state of their base class.
 
 4. The addition of the new Helper interface adds ~400 bytes to every 
    Helper class, of which there are about 250 in a typical ORB implementation.
    Which is an overhead of about 100k just to support an optimization of
    a corner case in RMI/IIOP where an RMI type happens to contain an IDL type.
    This doesn"t even begin to address the bloat that would occur to user code
    as well as any additional CORBA services.  The space/time tradeoff here
    appears to have gone the wrong way.
 
 5. The ValueHelper interface contains the method get_safe_base_ids, which is
    inconsistent with current OBV terminology.
 
 6. The marshaling of boxed types should be considered carefully, because of
    the special casing required for boxed strings, arrays, and sequences.
 
 7. The compiler should provide compile time enforcement of init() declarations.
 

Resolution: resolved, see revised text
Revised Text: The solution is modify the mapping so as to use an easier deal with form of a 2 class mapping, much like C++, to add facilites that will fix the bugs that don't allow recursive structures to be marshaled and unmarshaled, reduce the "bloat", handle all the boxed values correctly, etc. This proposal, coupled with the proposal to fix Issue 1981, which deals with the "init" portion of the issue at the IDL level, fixes all the known problems with the OBV/Java mapping. Revised Text: The changes are relative to version of Chapter 25 which has had Issue 1897 Evolving the org.omg.* APIs applied to it (available as ftp://ftp.omg.org/orbrev/drafts/idljava_2_4v1.2.pdf ) Add in section 25.4.1.4 after ObjectHolder final public class ValueBaseHolder { public org.omg.CORBA.portable.ValueBase value; public ValueBaseHolder() {} public ValueBaseHolder(org.omg.CORBA.portable.ValueBase initial) {...} public void _read(org.omg.CORBA.portable.InputStream is) {...} public void _write(org.omg.CORBA.portable.OutputStream os){...} public org.omg.CORBA.TypeCode _type(){...} } Replace section 25.5.1 with: 25.5.1 Generic BoxedValueHelper Interface package org.omg.CORBA.portable; public interface BoxedValueHelper { java.io.Serializable read_value(InputStream is); void write_value(OutputStream os, java.io.Serializable value); java.lang.String get_id(); } In 25.5.2 delete the 2nd and 5th paragraphs. In 25.5.2 delete the specification of the "generated Java helper (value types) In 25.5.2, in the specification of the "generated Java helper (non value types): a. delete the "(non value types)" from the comment b. Add the following methods to the end of the generated <typename>Helper class specification: // for each initializer in non abstract value type (see section 25.5.2.1) public static <typename> <initializername> (org.omg.CORBA.ORB orb, [<initializer arguments>]) {...} c. Remove the paragraph following that starts with: "For any user defined, value type ... " Add a new section 25.5.2.1 "Value type initializer convenience functions" as follows: For each initializer in a value type declaration, a corresponding static convenience method is generated in the helper class for the value type. The name of this method is the name of the initializer. This method takes an orb instance and all the arguments specified in the initializer argument list. The implementation of each of these methods will locate a <typename>ValueFactory (see section xxx) and call the identically named method on the ValueFactory passing in the supplied arguments. Replace all of section 25.13 Mapping for Value Type with: 25.13.1 Supporting interfaces for value types 25.13.1.1 ValueBase interface package org.omg.CORBA.portable; public interface ValueBase extends IDLEntity { String[] _truncatable_ids(); } All values implement ValueBase either directly (for boxed primitives - see section 25.14.1), or indirectly by implementing either the StreamableValue or CustomValue interface (see below). 25.13.1.2 StreamableValue interface package org.omg.CORBA.portable; public interface StreamableValue extends Streamable, ValueBase { } All non-boxed IDL valuetypes that are not custom marshalled, implement this interface. 25.13.1.3 CustomMarshal interface package org.omg.CORBA; public interface CustomMarshal { public void marshal (org.omg.CORBA.DataOutputStream os); public void unmarshal (org.omg.CORBA.DataInputStream is); } Implementors of custom marshalled values implement the above interface to provide custom marshalling. 25.13.1.4 CustomValue interface package org.omg.CORBA.portable; public interface CustomValue extends ValueBase, org.omg.CORBA.CustomMarshal { } All custom value types generated from IDL implement this interface. 25.13.1.5 ValueFactory interface package org.omg.CORBA.portable; public interface ValueFactory { java.io.Serializable read_value(InputStream is); } The ValueFactory interface is the native mapping for the IDL type CORBA::ValueFactory. The ValueFactory's read_value() method is called by the ORB runtime in the process of unmarshaling a valuetype. A user must implement this method as part of implementing a type specific ValueFactory. In this implementation, the user must call java.io.Serializable is.read_value(java.io.Serializable) with a blank valuetype to use for unmarshalling. The value returned by the stream is the same value passed in with all the data unmarshalled. 25.13.2 Basics for stateful value types A concrete value type (i.e. one that is not declared as abstract) is mapped to an abstract Java class with the same name, and a factory Java interface with the suffix "ValueFactory" appended to the value type name. In addition, a helper class with the suffix "Helper" appended to the value type name and a holder class with the suffix "Holder" appended to the value type name shall be generated. The specification of the generated holder class is as follows: public final class <typename>Holder implements org.omg.CORBA.portable.Streamable { public <typename> value; public <typename>Holder () {} public <typename>Holder (final <typename> initial) { value = initial; } public void _read (final org.omg.CORBA.portable.InputStream input) {...} public void _write (final org.omg.CORBA.portable.OutputStream output) {...} public org.omg.CORBA.TypeCode _type () {...} } The value type's mapped Java abstract class contains instance variables that correspond to the fields in the state definition in the IDL declaration. The order and name of the Java instance variables shall be the same as the correspondng IDL state fields. Fields that are identified as public in the IDL are mapped to public instance variables. Fields that are identified as private in the IDL are mapped to protected instance variables in the mapped Java class. The Java class for the value type extends either org.omg.CORBA.portable.CustomValue or org.omg.CORBA.portable.StreamableValue, depending on whether it is declared as custom in IDL or not, respectively. The generated Java class shall provide implementation of the ValueBase interface for this value type. The value type's generated value factory interface extends org.omg.CORBA.portable.ValueFactory and contains one method corresponding to each initializer declared in the IDL. The name of the method is the same as the name of the initializer, and the initializer arguments are mapped in the same way as in parameters are for IDL operations. The implementor shall provide a factory class with implementations for the methods in the generated value factory interface. When no initializers are declared in IDL, then the value type's value factory is eliminated from the mapping and the implementor shall simply implement org.omg.CORBA.portable.ValueFactory to provide the method body for read_value(). The inheritance scheme and specifics of the mapped class depend upon the inheritance and implementation characteristics of the value type and are described in the following subsections. The mapped Java class contains abstract method definitions which correspond to the operations and attributes defined on the value type in IDL. An implementor of the value type extends the generated Java class to provide implementation for the operations and attributes declared in the IDL, including those for any derived or supported value types or interfaces. 25.13.2.1 Inheritance from values - Value types that do not inherit from other values or interfaces: For non custom values, the generated Java class also implements the StreamableValue interface and provides appropriate implementation to marshal the state of the object. For custom values, the generated class extends CustomValue but does not provide an implementation for the CustomMarshal methods. - inheritance from other stateful values The generated Java class extends the Java class to which the inherited value type is mapped - inheritance from abstract values The generated Java class implements the Java interface to which the inherited abstract value is mapped(see section 25.13.3). - supported interfaces The Java class implements the Operations Java interface of all the interfaces(if any) that it supports. (Note that the operations interface for abstract interfaces does not have the "Operations" suffix, see section 25.12.1.1). The implementation of the supported interfaces of the value type shall use the tie mechanism, to tie to the value type implementation. 25.13.3 Abstract Value Types An abstract value type maps to a Java interface that implements ValueBase and contains all the operations and attributes specified in the IDL, mapped using the normal rules for mapping operations and atttributes. Abstract value types cannot be implemented directly. They must only be inherited by other stateful value types or abstract value types. 25.13.4 CORBA::ValueBase CORBA::ValueBase is mapped to java.io.Serializable. The get_value_def() operation is not mapped to any of the classes associated with a value type in Java. Instead it appears as an operation on the ORB pseudo object in Java(see "public static org.omg.CORBA.Object get_value_def(String repId)" in section 25.19.10). Note: This implies fixing up the referenced text in !too 25.19.10 to have the correct signature 25.13.5 Examples In 25.13. 4 Example A In the IDL change init(in long w); to: factory create(in long w); Replace the generated Java by: // generated Java package ExampleA; public abstract class WeightedBinaryTree implements org.omg.CORBA.portable.StreamableValue { // instance variables protected int weight; protected ExampleA.WeightedBinaryTree left; protected ExampleA.WeightedBinaryTree right; abstract public int[] preOrder (); abstract public int[] postOrder (); public org.omg.CORBA.TypeCode _type () {...} public void _read (final org.omg.CORBA.portable.InputStream _input) { // read state information using the wire format ... } public void _write (final org.omg.CORBA.portable.OutputStream _output) { .... } public java.lang.String[] _truncatable_ids () {...} } public final class WeightedBinaryTreeHelper { < ed note: put all the helper methods here> public static WeightedBinaryTree create(ORB orb, int w) { ... } } final public class WeightedBinaryTreeHolder implements org.omg.CORBA.portable.Streamable { ... <Note: the code for this isn't changing so just leave the old code there> } public interface WeightedBinaryTreeValueFactory extends org.omg.CORBA.portable.ValueFactory { public ExampleA.WeightedBinaryTree create (int w); } In 25.13.5 Example B Keep the IDL and the Java mapping of the Printer interface as is. Replace the generated Java for the WeightedBinaryTree with the following: // generated java package ExampleB; public abstract class WeightedBinaryTree implements org.omg.CORBA.portable.StreamableValue, PrinterOperations { protected int weight; protected ExampleB.WeightedBinaryTree left; protected ExampleB.WeightedBinaryTree right; abstract public int[] preOrder (); abstract public int[] postOrder (); public org.omg.CORBA.TypeCode _type () { ... } public void _read (final org.omg.CORBA.portable.InputStream _input) { ... } public void _write (final org.omg.CORBA.portable.OutputStream _output) { ... } public java.lang.String[] _truncatable_ids () { ... } } public final class WeightedBinaryTreeHelper { .... // helper methods... < ed note: put all the helper methods here> } public final class WeightedBinaryTreeHolder { ... <note this hasn't changed, fill in old one here> } // user written code for default ValueFactory public class WeightedBinaryTreeDefaultFactory implements org.omg.CORBA.portable.ValueFactory { public java.io.Serializable read_value (org.omg.CORBA.portable.InputStream is) { //user implements code } } Add a new 25.13.5 Example C // IDL typedef sequence<unsigned long> WeightedSeq; module ExampleC { custom valuetype WeightedBinaryTree { private unsigned long weight; private WeightedBinaryTree left; private WeightedBinaryTree right; factory create(in long w); WeightedSeq preOrder(); WeightedSeq postOrder(); }; }; // generated Java package ExampleC; abstract public class WeightedBinaryTree implements org.omg.CORBA.portable.CustomValue {...} public final class WeightedBinaryTreeHelper {...} public final class WeightedBinaryTreeHolder {...} [ editing note: fill in the ... as an aid to the reader ] 25.13.6 Keep as is currently in the specification 25.13.7 ValueFactory and Marshaling Replace second bullet in factory lookup algorithm by: - If this is not successful and the repository id is a standard IDL repository id that starts with "IDL:",then extract the class name from the repository id by stripping of the "IDL:" header and ":<major>.<minor>" version information trailer and replacing all "/"s with "."s. Then attempt to load a value factory by appending a "DefaultFactory" suffix to the above class name. Replace third bullet in factory lookup algorithm by: - If this is not successful and the repository id is a standard RMI repository id that begins with "RMI:", then extract the class name from the repository id by stripping of the "RMI:" header and the ":<hashcode>:[<suid>]" trailer and applying all necessary conversions(see section 26.****). The ValueHandler interface is used to read in the value, if it does not implement IDL Entity. Replace paragraph following the bullets by: The IDL native type ValueFactory is mapped in Java to org.omg.CORBA.portable.ValueFactory. In 25.14 Mapping for Value Box Type, replace the 3rd paragraph with the following: A boxed value needs to be treated differently than regular values in Java. Boxed values don't have factories and don't implmenent either the StreamableValue or CustomValue interfaces, so their marshalling and unmarshalling is performed by a boxed value helper object. In all cases, code can be generated to unmarshal the boxed type. No user code is required for boxed values. The BoxedValueHelper interface is implemented by all generated Helper classes for boxed valuetypes. The inherited read_value() method is called by the ORB runtime in the process of unmarshalling a boxed valuetype. This is required for types that are immutable either in content (eg, string), or size (eg, sequences). The write_value() method call is used for marshalling the value box. There are two general cases to consider. value boxes of primitive Java types and value boxes for entities that are mapped to java classes. In Section 25.14.1 Replace the first Java class <box_name> to be: public class <box_name> implements ValueBase { public <mapped_primitive_Java_type> value; public <box_name>(<mapped_primitive_Java_type> initial) { value = initial; } private static String[] _ids = { <box_name>Helper.id() }; public String[] _truncatable_ids() { return _ids; } } Replace the third Java class <box_name>Helper to be: final public class <box_name>Helper implements org.omg.CORBA.portable.BoxedValueHelper { public <box_name> read_value(InputStream is) {...} public write_value(OutputStream is, <box_name> value) {....} public String get_id() { ... } .... // other helper methods } In Section 25.14.1.1 Primitive Type example: Replace the MyLong class by: public class MyLong implements ValueBase { public int value; public MyLong(int initial) { value = initial; } private static String[] _ids = { MyLongHelper.id() }; public String[] _truncatable_ids() { return _ids; } } Replace MyLongHelper by: final public class MyLongHelper implements org.omg.CORBA.portable.BoxedValueHelper { public MyLong read_value(InputStream is) {...} public write_value(OutputStream is, MyLong value) {....} public String get_id() { ... } .... // other helper methods } Add to end of paragraph on 25.14.2 //IDL valuetype <box_name> <IDLtype>; final public class <box_name>Helper implements org.omg.CORBA.portable.BoxedValueHelper { public <IDLType> read_value(InputStream is) {...} public write_value(OutputStream is, <IDLType> value) {....} .... // other helper methods } final public class <box_name>Holder implements org.omg.CORBA.portable.Streamable { public <mapped_java_class> value; ... } Add a new section 25.14.3 Examples // IDL module A { valuetype BoxedString string; }; // generated Java package A; public final class BoxedStringHelper implements org.omg.CORBA.portable.BoxedValueHelper { private static final BoxedStringHelper _instance = new BoxedStringHelper(); public static java.lang.String read (final org.omg.CORBA.portable.InputStream _input) { if (!(_input instanceof org.omg.CORBA_2_3.portable.InputStream)) { throw new org.omg.CORBA.BAD_PARAM(); } return (java.lang.String)((org.omg.CORBA_2_3.portable.InputStream)_input).read_value(_instance); } public static void write (final org.omg.CORBA.portable.OutputStream _output, final java.lang.String value) { if (!(_output instanceof org.omg.CORBA_2_3.portable.OutputStream)) { throw new org.omg.CORBA.BAD_PARAM(); } ((org.omg.CORBA_2_3.portable.OutputStream)_output).write_value(value, _instance); } public static void insert (org.omg.CORBA.Any any, java.lang.String value) {...} public static java.lang.String extract (org.omg.CORBA.Any any) {...} public static org.omg.CORBA.TypeCode type () {...} public static java.lang.String id () {...} public java.io.Serializable read_value (org.omg.CORBA.portable.InputStream _input) { java.lang.String result; result = _input.read_string(); return (java.io.Serializable)result; } public void write_value (org.omg.CORBA.portable.OutputStream _output, java.io.Serializable value) { if (!(value instanceof java.lang.String)) { throw new org.omg.CORBA.MARSHAL(); } java.lang.String valueType = (java.lang.String)value; _output.write_string(valueType); } public java.lang.String get_id () { return id(); } } public final class BoxedStringHolder implements org.omg.CORBA.portable.Streamable {....} Section 25.14.3.1 Example B // IDL struct idlStruct { short x; }; module A { valuetype BoxedStruct idlStruct; }; // generated Java package A; public final class BoxedStructHelper implements org.omg.CORBA.portable.BoxedValueHelper { private static final BoxedStructHelper _instance = new BoxedStructHelper(); public static idlStruct read (final org.omg.CORBA.portable.InputStream _input) { if (!(_input instanceof org.omg.CORBA_2_3.portable.InputStream)) { throw new org.omg.CORBA.BAD_PARAM(); } return (idlStruct)((org.omg.CORBA_2_3.portable.InputStream)_input).read_value(_instance); } public static void write (final org.omg.CORBA.portable.OutputStream _output, final idlStruct value) { if (!(_output instanceof org.omg.CORBA_2_3.portable.OutputStream)) { throw new org.omg.CORBA.BAD_PARAM(); } ((org.omg.CORBA_2_3.portable.OutputStream)_output).write_value(value, _instance); } public static void insert (final org.omg.CORBA.Any any, final idlStruct value) {...} public static idlStruct extract (final org.omg.CORBA.Any any) {...} public static org.omg.CORBA.TypeCode type () {...} public static java.lang.String id () {...} public java.io.Serializable read_value (final org.omg.CORBA.portable.InputStream _input) { final idlStruct result; result = idlStructHelper.read(_input); return (java.io.Serializable)result; } public void write_value (final org.omg.CORBA.portable.OutputStream _output, final java.io.Serializable value) { if (!(value instanceof idlStruct)) { throw new org.omg.CORBA.MARSHAL(); } idlStruct valueType = (idlStruct)value; idlStructHelper.write(_output, valueType); } public java.lang.String get_id () { return id(); } } public final class BoxedStructHolder implements org.omg.CORBA.portable.Streamable { .... } In Section 25.19.10 ORB in the definition of the org.omg.CORBA_2_3.ORB class: Change the signature of register_value_factory to: public org.omg.CORBA.portable.ValueFactory register_value_factory(String id, org.omg.CORBA.portable.ValueFactory factory); Change the return type lookup_value_factory() from: org.omg.CORBA.portable.ValueHelper to: org.omg.CORBA.portable.ValueFactory In Section 25.21.4 In the definition of the org.omg.CORBA_2_3.portable.InputStream: Change both declarations of read_Value to read_value In the 2nd overloaded read_Value change the parameter type from: ValueHelper helper to: java.lang.String rep_id Change both declarations of read_Abstract to read_abstract_interface Add the following new methods: public java.io.Serializable read_value(org.omg.CORBA.portable.BoxedValueHelper factory) { throw new org.omg.CORBA.NO_IMPLEMENT(); } public java.io.Serializable read_value(java.io.Serializable) { throw new org.omg.CORBA.NO_IMPLEMENT(); } In the definition of the org.omg.CORBA_2_3.portable.OutputStream: Change both declarations of write_Value to write_value In the 2nd overloaded write_Value change the 2nd parameter type from: ValueHelper value to: java.lang.String rep_id Change the declaration of write_Abstract to write_abstract_interface Delete the start_block and end_block methods Add the following new method: public void write_value(java.io.Serializable value, org.omg.CORBA.portable.BoxedValueHelper factory) { throw new org.omg.CORBA.NO_IMPLEMENT(); }
Actions taken:
September 18, 1998: received issue
February 26, 1999: moved from obv_rtf to java rtf
June 4, 1999: closed issue

Discussion:


Issue 1993: create_lname & create_lname_context (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The naming service states that LName and LNameComponent are created
 in C/C++ using the create_lname and create_lname_context functions
 respectively.
 No mention is made as to how this is achieved in Java.
 
 Should it be possible to simply create an instance of the class using new,
 or is there a need for a factory class?
 
 
 

Resolution: These functions (library) has been deprecated by the newly adopted Interoperable Naming Service.
Revised Text:
Actions taken:
September 23, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 1994: Local stubs proposal (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Add the following new paragraph after the third paragraph of Section 
 25.20.5.1 "Stub/Skeleton Architecture":
 
 Local stubs shall copy all valuetypes passed to them either as
 parameters or as data within parameters, and shall pass the resulting 
 copies to the Servant in place of the originals.  The valuetypes shall
 be copied using the same "deep copy" semantics as would result from
 GIOP marshaling and unmarshaling.
 

Resolution:
Revised Text:
Actions taken:
September 24, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 2079: Potential problem with Java Mapping ORB init for Applet (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: While working on the revised interoperable naming specification,
 a java issue came up with regard to arguments to CORBA ORB_init.
 
 The PIDL reads as:
   module CORBA {
      typedef string ORBid;
      typedef sequence <string> arg_list;
      ORB ORB_init(inout arg_list argv, in ORBid orb_identifier);
   }
 
 However the java mapping for init in an applet is:
 // public static ORB init(Applet app, Properties props);
 
 Using a property list for the argument list results in considerably
 different behavior than the PIDl sequence<string> definition, mainly
 no preservation of sequence order and no repeating elements 
 (properties). 
 

Resolution: resolved
Revised Text:
Actions taken:
October 14, 1998: received issue
June 4, 1999: closed issue

Discussion:
This is the proper design behavior. The use of sequence in PIDL does not necessarily imply any specific semantics with regards to such things. (There is
no primitive set concept which could be used in PIDL. Each language mapping maps PIDL as it sees fit. The current specification is the natural mapping for Java. 
Revised Text: none


Issue 2096: Issue with Mapping for Constants within an interface (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: In Chapter 25 (IDL/Java) of CORBA V2.3-1.3 (Aug 1998), section 25.5.1,
 "Constants Within An Interface", the text says "Constants declared
 within an IDL interface are mapped to fields in the Java interface
 corresponding to the IDL interface". 
 
 The problem is that there are now two Java interfaces produced for an IDL 
 interface, the Operations interface and the Signature interface.
 
 The current client programming model for accessing constants within
 an interface is to say "t.c" (instead of "tOperations.c"). 
 
 Therefore, in order to avoid changing the client programming mode, 
 I propose that section 25.5.1 be revised to say that constants within
 an IDL interface "are mapped to fields in the Java signature interface..."
 

Resolution: closed, no action
Revised Text:
Actions taken:
October 19, 1998: received issue
June 4, 1999: closed issue

Discussion:
This is an editorial issue, that got missed when updating the spec to take into account the split into the signature and operations interfaces. The editor
has already made the change. 
Revised Text: 
Actions taken: Close, no action


Issue 2228: typedefs in IDl when generating Java code (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: A question came up regarding the use of typedefs in idl when generating Java
 >code.  Since Java has no support for typedefs the alias is not available to
 >any Java code other than the idl generated code.  This seems to be a flaw in
 >the design of the idl to Java mapping specification.  
 

Resolution: The helper is generated for all aliases, it can be used if needed.
Revised Text:
Actions taken:
November 25, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 2233: Helper "narrow" exception clarification (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Referring to 23_java-2_3base.pdf, section 23.11.1, page 23-26, second
 paragraph, "The IDL exception CORBA::BAD_PARAM is thrown if the narrow
 fails."
 
 This statement can be interpreted in two different ways. Does it mean that 
 BAD_PARAM is thrown no matter what goes wrong in the narrow call, or that 
 BAD_PARAM is thrown only when the parameter doesn"t support the interface 
 being narrowed to?
 
 

Resolution: The latter. A different exception shall be raised to indicate other errors.
Revised Text: In Section 23.12.1 Basics: Replace the last sentence of the 3rd paragraph: The IDL exception CORBA::BAD_PARAM is thrown if the narrow fails. with: The IDL exception CORBA::BAD_PARAM shall be thrown if the narrow fails because the object reference does not support the requested type. A different system exception shall be raised to indicate other kinds of errors. Trying to narrow a null will always succeed with a return value of null. Actions taken: Close, incorporate text
Actions taken:
December 1, 1998: received issue
June 4, 1999: closed issue

Discussion:


Issue 2251: Java LocalStub (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: From IDL/Java specification (draft version 3.4 - August 9):
 
     The remote stub must be named _<interface_name>Stub where
     <interface_name> is the IDL interface name this stub is
     implementing. The local stub must be named _<interface_name>LocalStub
     where <interface_name> is the same IDL interface  name. Local stubs
     are defined to be direct subclasses of remote stubs.
 
   and:
 
   The _is_local() method is provided so Helper classes may determine if a
   particular object is implemented by a local servant and if so create a
   local stub, rather than a remote stub. This function would typically
   be called from within the narrow() method  of a Helper class. The
   _is_local() method may only return true if the servant incarnating the
   object is located in the same Java VM. The method may return false if
   the servant is not local or the ORB does not support local stubs for
   that particular servant. The default behavior of _is_local() is to
   return false.
 
 The design described in the specification seems to make it very difficult,
 if not impossible, to do the following:
 
 - Create a proxy that refers to some remote servant
 - Upon a request to the remote servant, a LocationForward is generated that
   refers to a colocated servant.
 

Resolution: Merge the two stub classes together as one class with as minimal impact on the APIs and performance.
Revised Text: Replace the first five paragraphs of section 25.21.5.1 "Stub/Skeleton Architecture" with the following text: "The mapping defines a single stub which may be used for both local and remote invocation. Local invocation provides higher performance for collocated calls on Servants located in the same process as the client. Local invocation is also required for certain IDL types which contain parameter types which cannot be marshalled remotely. Remote invocation is used to invoke operations on objects which are located in an address space separate from the client. While a stub is using local invocation it shall provide complete location transparency. To provide the correct semantics, compliant programs shall comply with the parameter passing semantics defined in Section 25.11.2, "Parameter Passing Modes". When using local invocation the stub shall copy all valuetypes passed to them, either as in parameters, or as data within in parameters, and shall pass the resulting copies to the Servant in place of the originals. The valuetypes shall be copied using the same deep copy semantics as would result from GIOP marshaling and unmarshaling. The following sections describe the characteristics of the stubs and skeletons. The examples are based on the following IDL:" In Section 25.21.5.1.1 "Stub Design" replace the second paragraph with the following: "The stub shall be named _<interface_name>Stub where <interface_name> is the IDL interface name this stub is implementing. Stubs shall support both local invocation and remote invocation, except in the following cases: 1. The stub is implementing an IDL interface which may only be invoked locally (e.g. PortableServer::POA). In this case, the stub may choose to implement only local invocation. " In Section 25.21.5.1.1, remove the fourth paragraph. Replace the example in Section 25.21.5.1.3 "Stream-based Stub example" with the following: package Example; public class _AnInterfaceStub extends org.omg.CORBA.portable.ObjectImpl implements AnInterface { public java.lang.String[] _ids () { return __ids; } private static java.lang.String[] __ids = { "IDL:Example/AnInterface:1.0" }; final public static java.lang.Class _opsClass = Example.AnInterfaceOperations.class; public int length (java.lang.String s) throws Example.AnException { while(true) { if(!this._is_local()) { try { org.omg.CORBA.portable.OutputStream _output = this._request("length", true); _output.write_string(s); org.omg.CORBA.portable.InputStream _input = this._invoke(_output); return _input.read_long(); } catch (org.omg.CORBA.portable.RemarshalException _exception) { continue; } catch (org.omg.CORBA.portable.ApplicationException _exception) { java.lang.String _exception_id = _exception.getId(); if (_exception_id.equals(Example.AnExceptionHelper.id())) { throw Example.AnExceptionHelper.read(_exception.getInputStream()); } throw new org.omg.CORBA.UNKNOWN("Unexpected User Exception: " + _exception_id); } finally { this._releaseReply(_input); } } else { org.omg.CORBA.portable.ServantObject _so = _servant_preinvoke("length", _opsClass); if (_so == null) { continue; } Example.AnInterfaceOperations _self = (Example.AnInterfaceOperations)_so.servant; try { return _self.length(s); } finally { _servant_postinvoke(_so); } } } } } In Section 25.21.5.2 "Stub and Skeleton Class Hierarchy", Figure 25-1, remove the class "_FooLocalStub". In Section 25.21.5.3.1 "Streaming Stub APIs" replace the second paragraph with the following: "The method _invoke() is called to invoke an operation. The stub provides an OutputStream that was previously returned from a _request() call. The method _invoke() returns an InputStream which contains the marshalled reply. The _invoke() method may throw only one of the following: an ApplicationException, a RemarshalException, or a CORBA system exception. An ApplicationException shall be thrown to indicate the target has raised a CORBA user exception during the invocation. The stub may access the InputStream of the ApplicationException to unmarshal the exception data. A RemarshalException shall be thrown if the stub was redirected to a different target object and remarshalling is necessary, this is normally due to a GIOP object forward or locate forward messages. In this case, the stub shall then attempt to reinvoke the request on behalf of the client after verifying the target is still remote by invoking _is_local() (see section 25.21.5.3.2). If _is_local() returns True, then an attempt to reinvoke the request using the Local Invocation APIs shall be made. If a CORBA system exception is thrown, then the exception shall be passed on directly to the user." Rename section 25.21.5.3.2 "Local Stub APIs" to "Local Invocation APIs". Replace the first three paragraphs with the following: "Local invocation is supported by the following methods and classes: The _is_local() method is provided so stubs may determine if a particular object is implemented by a local servant and hence local invocation APIS may be used. The _is_local() method shall return true if the servant incarnating the object is located in the same process as the stub and they both share the same ORB instance. The _is_local() method returns false otherwise. The default behavior of _is_local() is to return false. The _servant_preinvoke() method is invoked by a local stub to obtain a Java reference to the servant which should be used for this request. The method takes a string containing the operation name and a Class object representing the expected type of the servant as parameters and returns a ServantObject object (Note, ORB vendors may subclass the ServantObject object to return additional request state that may be required by their implementations). The operation name corresponds to the operation name as it would be encoded in a GIOP request. The expected type shall be the Class object associated with the operations class of the stub's interface (e.g. A stub for an interface Foo, would pass the Class object for the FooOperations interface). The method shall return a null value if the servant is not local or the servant has ceased to be local as a result of the call (i.e, due to a ForwardRequest from a POA ServantManager). The method shall throw CORBA::BAD_PARAM if the servant is not of the expected type. If a ServantObject object is returned, then the servant field shall have been set to an object of the expected type (Note, the object may or may not be the actual servant instance). The local stub may cast the servant field to the expected type, and then invoke the operation directly. The ServantRequest object is valid for only one invocation, and cannot be used for more than one invocation."
Actions taken:
December 10, 1998: received issue
February 26, 1999: moved from java-rtf to orb_revision
June 4, 1999: closed issue

Discussion:


Issue 2255: Proposal for persistent valuetypes (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Here is my proposal for how to solve the persistent valuetype problem.
 It allows valuetypes to be used for PSS with getter and setter
 access to the data, without changing the OBV Java language bindings or
 adding new keywords or pragmas to IDL.  Any additions to IDL that may
 be desirable for improved functionality (e.g, query and finder support)
 could be designed jointly by the components submission group and the
 PSS group as part of some future RTF activity.
 
 The proposal is very simple.  It is that persistent valuetypes
 must be abstract valuetypes with attributes.  The attributes would
 be used to specify the persistent state of the object.
 

Resolution: closed, no action
Revised Text:
Actions taken:
December 15, 1998: received issue
June 4, 1999: closed issue

Discussion:
Persistent valuetypes are part of a proposed submission to the PSS RFP which has not  yet been adopted. If and when such a submission is adopted
as an OMG specification, it MAY be appropriate to resubmit this, or a similar issue. Until then, even the filing of this issue is premature at best. 
Revised Text: 
Actions taken: Close, no action.


Issue 2256: PSS requiremnets for the ObV/Java mapping (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The latest ObV/Java mapping, including George"s latest proposal, is not
 usable for values with a persistent implementation.
 I"d really like to solve this issue with the Java & ObV RTF, rather than
 solve it through the adoption of a new spec that updates the Java mapping.
 
 ==== Issue
 - ObV/Java maps value types"s data members to Java data members
 - providing a persistent implementation for such data members would 
   require byte-code post-processing or pre-processing, or
   yet-to-be-specd-and-agreed JVM hooks; we do not see this as viable/
   realistic options.
 
 

Resolution: closed, no action
Revised Text:
Actions taken:
December 15, 1998: received issue
June 4, 1999: closed issue

Discussion:
 Persistent valuetypes are part of a proposed submission to the PSS RFP which has not  yet been adopted. If and when such a submission is adopted
as an OMG specification, it MAY be appropriate to resubmit this, or a similar issue. Until then, even the filing of this issue is premature at best.


Issue 2462: BAD_PARAM issue (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: This issue is with the 1998-08-22 "Mapping of OMG IDL to Java".
 
 ptc/1998-08-22 (the IDL/Java mapping), section 25.3.5, says that
 if a bounded string is too long, MARSHAL is thrown.
 
 Meanwhile, ptc/1998-12-04 (2.3a Core chapters 1-15), section 3.17.1, says
 that MARSHAL is to be used for "A request or reply is structurally invalid
 ...indicates a bug in the runtime". Meanwhile, BAD_PARAM says "a parameter
 passed to a call is out of range or otherwise illegal..." 
 
 Based on these descriptions, I propose that BAD_PARAM should 
 be thrown in Java when a string exceeds its bound rather than MARSHAL.
 

Resolution: Make it so.
Revised Text: In section 25.4.5 Strings replace the 2 occurrences of MARSHAL with BAD_PARAM.
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2514: PortableServer Servant issue (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The currently specified definition of the org.omg.CORBA.PortableServer.Servant
 class does not correctly implement the behavior specified.  In particular, the
 POA returned by PortableServer::Current::get_POA is always used during the
 processing of _this_object() even if _this_object() is not being called on the
 Servant which is currently being invoked as part of the request.  This contradicts
 the behavior defined in the first bullet item for _this_object as defined in 
 section 25.19.2.1 "Mapping of PortableServer::Servant".
 
 Also, the overall behavior of _this() may need some tweaking (see my other email
 "Behavior of POA Servant"s _this()"), which may require us to revisit the
 definition of the Servant class.
 

Resolution: resolved, see revised text
Revised Text: The current definition of org.omg.PortableServer.Servant does not correctly implement the specification defined for Servant as defined by the Java mapping. In particular, it does not correctly implement the semantics of bullet item number one defined for _this_object(). Furthermore, the current definition of Servant hard codes certain functionality and prevents vendors from making fixes or otherwise changing the implementation. To fix this problem, a delegation model for the Servant class similar to that used by stubs is proposed in order to allow vendors full control over the way that certain Servant operations are handled. We believe this is necessary to correctly implement the _this_object() method for which a correct implementation using the currently defined public POA APIs is somewhat problematic. The proposal also allows vendors flexibility in the implementation of the methods way which may allow for better optimization opporutunities. The proposed changes have minimum impact on end user applications as well as minimal impact on ORB vendors (the Visibroker ORB was converted to the new design in less than a day including time to implement _this_object()). The only API change end users will see is the removal of the method: void _orb(org.omg.CORBA.ORB orb); This method does not work well with the new delegation model, and it has been our experience that this method is rarely, if ever, used. The only need a user ever has to set the ORB on a Servant is for the case of implicit activation, and the prefered way is to use the method: org.omg.CORBA.Object _this_object(org.omg.CORBA.ORB orb); The _this_object() method is still provided, but now sets the delegate instead of setting a locally stored ORB variable. We believe this method is required and also commonly used so should remain part of the user API. The proposal defines a new Delegate interface which is defined in a new package org.omg.PortableServer.portable and mirrors the design pattern used by the Stub classes for the Java mapping. Unlike stubs, however, the Servant must have a way of setting its delegate given an instance of the ORB in order to support implicit activation via _this(). To accomplish this our proposal includes the addition of a new method on the ORB class: public void set_delegate(java.lang.Object object); This method will actually appear on org.omg.CORBA_2_3.ORB due to the org.omg.CORBA.ORB class being frozen in the Java 2 core. This method takes an object which is known to the ORB to follow the delegation model and sets it delegate. In this version of the proposal the only type that an ORB is required to support setting the delegate is org.omg.PortableServer.Servant. However, we expect in the future it may be possible to make use of this method to set delegates on stubs which have been reincarnated through Java serialization. Note, we also chose to make the Delegate an interface rather than an abstract class to provide for greater flexibility in the implementation. This proposal as it fixes an important piece of POA functionality and is required for correct operation of the POA. George Scott, gscott@inprise.com Revised Text: In Section 25.19.10 "ORB". Add the following new method to org.omg.CORBA_2_3.ORB: public abstract class ORB extends org.omg.CORBA.ORB { abstract public void set_delegate(java.lang.Object wrapper); } Add the following paragraph following the class definition for org.omg.CORBA_2_3.ORB: Add a new section: 25.19.10.1 set_delegate at the end of section 25.19.10 "The set_delegate() method supports the Java ORB portability interfaces by providing a method for classes which support ORB portability through delegation to set their delegate. This is typically required in cases where instances of such classes were created by the application programmer rather than the ORB runtime. The wrapper parameter is the instance of the object on which the ORB must set the delegate. The mechanism to set the delegate is specific to the class of the wrapper instance. The set_delegate() method shall support setting delegates on instances of the following Java classes: - org.omg.PortableServer.Servant If the wrapper paramter is not an instance of a class for which the ORB can set the delegate, the CORBA::BAD_PARAM exception shall be thrown." In Section 25.20.2.1 "Mapping of PortableServer::Servant", reformat the methods and group them to clarify their use as follows: Add the comment below and group the following 5 methods // Convenience methods for application programmer final public org.omg.CORBA.Object _this_object() {...} final public org.omg.CORBA.Object _this_object(ORB orb) {...} final public org.omg.CORBA.ORB _orb() {...} final public POA _poa() {...} final public byte[] _object_id() {...} Add the comment below and group the following 4 methods: // Methods which may be overriden by the application programmer public POA _default_POA() {...} public boolean _is_a(String repository_id) {...} public boolean _non_existent() {...} public org.omg.CORBA.InterfaceDef _get_interface() {...} Add the comment below and group the following 1 methods: // Methods for which the skeleton or application programmer must // provide an implementation abstract public String[] _all_interfaces(POA poa, byte[] objectId); Delete the following method: final public void _orb(ORB orb) {...} Replace the following paragraph which reads as "The Servant class is an abstract Java class which serves as the base classfor all POA Servant implementations." with the following 3 paragraphs: "The Servant class is an abstract Java class which serves as the base classfor all POA Servant implementations. It provides a number of methods which may be invoked by the application programmer, as well as methods which are invoked by the POA itself and may be overridden by the user to control aspects of Servant behavior. With the exception of the _all_interfaces() and _this_object(ORB orb) methods, all methods defined on the Servant class may only be invoked after the Servant has been associated with an ORB instance. Attempting to invoke the methods on a Servant which has not been associated with an ORB instance shall result in a CORBA::BAD_INV_ORDER exception being raised. A Servant is associated with an ORB instance via one of the following means: 1. Through a call to _this_object(ORB orb) passing an ORB instance as parameter. The Servant will become associated with the specified ORB instance. 2. By explicitly activating a Servant with a POA by calling either POA::activate_object or POA::activate_object_with_id. Activating a Servant in this fashion will associate the Servant with the ORB instance which contains the POA on which the Servant has been activated. 3. By returning a Servant instance from a ServantManager. The Servant returned from PortableServer::ServantActivator::incarnate() or PortableServer::ServantLocator::preinvoke() will be associated with the ORB instance which contains the POA on which the ServantManager is installed. 4. By installing the Servant as a default servant on a POA. The Servant will become associated with the ORB instance which contains the POA for which the Servant is acting as a default servant. It is not possible to associate a Servant with more than one ORB instance at a time. Attempting to associate a Servant with more than one ORB instance will result in undefined behavior. Replace Section 25.20.2.1.2 _orb with: The _orb() method is a convenience method which returns the instance of the ORB which is currently associated with the Servant." In Section 25.20.2.1.1 _this_object Replace the fourth bullet item with the following text: " * The _this_object(ORB orb) method first associates the Servant with the specified ORB instance and then invokes _this_object() as normal." In Section 25.21.2 "Overall Architecture" Add the following bullet after the "Portable Delegate" bullet: " * Portable Servant Delegate - provides the vendor specific implementation of PortableServer::Servant" In Section 25.21.2.1 "Portability Package" Change the first sentence to the following: "The APIs needed to implement portability are found in the org.omg.CORBA.portable and org.omg.PortableServer.portable packages." Add the following new sections after section 25.21.6 "Delegate": (ORB becomes 25.21.9) " 25.21.7 "Servant" The Servant class is the base class for all POA-based implementations. It delegates all functionality to the Delegate interface defined in section 25.21.6. package org.omg.PortableServer; import org.omg.CORBA.ORB; import org.omg.PortableServer.portable.Delegate; abstract public class Servant { private transient Delegate _delegate = null; final public Delegate _get_delegate() { if (_delegate == null) { throw new org.omg.CORBA.BAD_INV_ORDER("The Servant has not been associated with an ORB instance"); } return _delegate; } final public void _set_delegate(Delegate delegate) { _delegate = delegate; } final public org.omg.CORBA.Object _this_object() { return _get_delegate().this_object(this); } final public org.omg.CORBA.Object _this_object(ORB orb) { try { ((org.omg.CORBA_2_3.ORB)orb).set_delegate(this); } catch(ClassCastException e) { throw new org.omg.CORBA.BAD_PARAM("POA Servant requires an instance of org.omg.CORBA_2_3.ORB"); } return _this_object(); } // access to the ORB final public ORB _orb() { return _get_delegate().orb(this); } // convenience methods to the POA Current final public POA _poa() { return _get_delegate().poa(this); } final public byte[] _object_id() { return _get_delegate().object_id(this); } // Methods which may be overriden by the user public POA _default_POA() { return _get_delegate().default_POA(this); } public boolean _is_a(String repository_id) { return _get_delegate().is_a(this, repository_id); } public boolean _non_existent() { return _get_delegate().non_existent(this); } public org.omg.CORBA.InterfaceDef _get_interface() { return _get_delegate().get_interface(this); } // methods for which the user must provide an implementation abstract public String[] _all_interfaces(POA poa, byte[] objectId); } 25.21.8 "Servant Delegate" The Delegate interface provides the ORB vendor specific implementation of PortableServer::Servant. package org.omg.PortableServer.portable; import org.omg.PortableServer.Servant; import org.omg.PortableServer.POA; public interface Delegate { org.omg.CORBA.ORB orb(Servant self); org.omg.CORBA.Object this_object(Servant self); POA poa(Servant self); byte[] object_id(Servant self); POA default_POA(Servant self); boolean is_a(Servant self, String repository_id); boolean non_existent(Servant self); org.omg.CORBA.InterfaceDef get_interface(Servant self); } Rename Section 25.21.6 "Delegate" to "Stub Delegate".
Actions taken:
March 5, 1999: received issue
June 4, 1999: closed issue

Discussion:


Issue 2517: orb.properties search should include home directory (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The search for an orb.properties file to set a default ORB class and
 ORB Singleton class looks only in the JDK lib directory.  In many
 installations, this is read-only (e.g., on a shared drive) and not
 updatable by users.  To allow users of these JDK installations to
 set a default ORB, the search order should be:
  1. The user"s home directory (user.home system property)
  2. The <java.home>/lib directory.
 

Resolution:
Revised Text: Make the search order for the file orb.properties: 1. The user's home directory (user.home system property) 2. The <java.home>/lib directory.
Actions taken:
March 8, 1999: received issue
January 9, 2001: closed issue

Discussion:


Issue 2518: Incorrect search order for ORB implementation class name (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The first bullet of the search order for an ORB implementation class
 name in section 25.21.7 is:
  . check in Applet parameter or application string array, if any
 This seems wrong

Resolution:
Revised Text:
Actions taken:
March 8, 1999: received issue
February 27, 2001: closed issue

Discussion:
Delete the words

     "or application string array, if any"

from the first bullet in Section 21.9 (note that section

numbering has changed since this issue was filed).


Issue 2519: Need SerializableHolder class (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: There is currently no defined way to map out or inout parameters of
 type ValueBase to Java.  Since ValueBase maps to java.io.Serializable, 
 there shoud be an org.omg.CORBA.SerializableHolder class.
 
 Proposed Resolution:
 
 Add SerializableHolder to section 25.4.1.4.
 

Resolution: Close, no change.
Revised Text: Close, no change. The ValueBaseHolder class defined in Section 13.1.1 satisfies the mapping need.
Actions taken:
March 8, 1999: received issue
February 27, 2001: closed issue

Discussion:
Add SerializableHolder to section 25.4.1.4.


Issue 2520: Standard properties should include initial host and port (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The standard properties listed in section 25.21.7.1 allow the ORB
 class and ORB singleton class to be set.  There should also be
 standard properties to allow the initial host and port for the naming
 service to be set.
 
 

Resolution: Close no change.
Revised Text:
Actions taken:
March 8, 1999: received issue
May 13, 2002: closed issue

Discussion:
As was pointed out in the discussion in the archives, this function is achieved better with the Interoperable name service. The -ORBInitRef and -ORBDefaultInitRef arguments directly translate to org.omg.CORBA.ORBInitRef and org.omg.CORBA.ORBDefaultInitRef properties which can be used to configure services such as the name service, including the host and port. This issue should be closed no change.



Issue 2528: Mapping Messaging sendc_ (and sendp_) methods to Java (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary:     I am having a hard time determining just where the sendc_ methods should be declared when the AMI spec is mapped to Java (this issue is evident on sendp_"s as well, but I don"t care right now:).  I am sure that someone has determined this, but it is not obvious in the spec. 
 

Resolution: Close no change
Revised Text:
Actions taken:
March 11, 1999: received issue
April 3, 2001: moved from the Messaging RTF to the java RTF
May 13, 2002: closed issue

Discussion:
The sendc and sendp operations should almost certainly go into the signature interface rather than the operations interface, but the IDL to Java RTF are better placed to make changes in their specification. 
Move to IDL to Java RTF. The sendc and sendp operations should almost certainly go into the signature interface rather than the operations interface, but the IDL to Java RTF are better placed to make changes in their specification. Move to IDL to Java RTF
This issue is subsumed by issue 3068, so close this issue and handle the problem in issue 3068.


Issue 2531: Serializable objects in Anys need reference semantics (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Section 25.16 (fifth paragraph) says that Streamable types have
 reference semantics.  The same should apply to Serializable types,
 for consistency and so that valuetypes can be sent across DII.
 

Resolution: see below
Revised Text: Insert the following paragraph after the 5th paragraph in Section 16: The insert and extract methods for Serializables implement reference semantics. For a serializable type, an Any is a container in which the data is inserted and held. The Any does not copy or preserve the state of the serializable object that it holds when the insert method is invoked. The contents of the Any are not serialized until the write_value() method is invoked, or the create_input_stream() method is invoked. Invoking create_output_stream() and writing to the Any, or calling read_value(), will update the state of the last serializable object that was inserted into the Any, if one was previously inserted. Similarly, calling the extract_Value() method multiple times will return the same contained serializable object.
Actions taken:
March 12, 1999: received issue
February 27, 2001: closed issue

Discussion:


Issue 2532: Mapping of AbstractBase and abstract interfaces (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: There is a problem with current mapping of abstract interface types
 to Java.  These do not implement org.omg.CORBA.portable.IDLEntity.
 Even if they did, it would not be possible for the Java to IDL mapping
 to distinguish them from abstract valuetypes, which also map to
 Java interfaces that implement org.omg.CORBA.portable.IDLEntity.
 

Resolution: Close, no change
Revised Text:
Actions taken:
March 12, 1999: received issue
October 3, 2001: closed issue

Discussion:


Issue 2540: _servant_postinvoke (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary:   It would be extremely useful for the _servant_postinvoke call to include
   the operation name since this is a logical place to hook into the POA"s
   servant locator postinvoke method - which needs the operation name.
 
   Without a provided operation name argument, this information must be
   saved in some other, potentially inconvenient, place.
 
 

Resolution: closed, no change
Revised Text:
Actions taken:
March 15, 1999: received issue
January 9, 2001: closed issue

Discussion:
CLOSE, NO CHANGE because "This is typically stored in the ServantObject


returned by _servant_preinvoke (or more correctly a vendor specific


subclass of ServantObject).  Considering that you have to store much


more than just the operation name (i.e. the Cookie for ServantLocators)


I'm not sure why the operation name is of particular concern."



Issue 2550: Dealing with reserved suffixes (e.g. POA) (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: ptc/98-10-14 changes the mapping of names for skeleton classes; for:
 
     Module M {
       interface Face {};
     };
 
 the name of the skeleton and tie classes are now M.FacePOA and M.FacePOATie
 instead of the C++-style POA_M.Face and POA_M.Face_tie.
 

Resolution: Close, no change.
Revised Text:
Actions taken:
March 18, 1999: received issue
February 27, 2001: closed issue

Discussion:
Close, no change. Section 2.1 seems clear that the mapping rules apply to names of the form *interface*POA, not
to plain POA


Issue 2608: Java - Mapping for Struct issue (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The Mapping of OMG IDL to Java, Section 25-20, Mapping for Struct, has a
 String field that is not initialized.  I would like to consider that the
 String value is initialized to a empty String within a Struct eg., String
 foo = new String();
 
 I have an application with a Sequence of Structs.  The Struct has two
 attributes, a boolean and String.  The boolean is initialized to "false"
 but the String is not initialized.  When I try to add the containing
 object, the attribute of Sequence of Structs fails.  I do not want to
 require the use to initialize each Struct within the Sequence  before
 createing the object.
 
 
 

Resolution:
Revised Text:
Actions taken:
April 14, 1999: received issue
January 9, 2001: closed issue

Discussion:
In Section 25-20, Mapping for Struct, have the String value be initialized to


an empty String within a Struct eg., String foo = "";



Issue 2609: Issues with ObjectImpl implementations (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: I have some issues with the defined implementation of methods on
 org.omg.CORBA.portable.ObjectImpl.
 
 First, document 98-10-14 says the definitive place to find the
 implementation for this class is in some zip file which I haven"t been able
 to find.  Is it available somewhere?  Since I couldn"t find the zip file,
 I"m depending on 98-10-14 for the implementation.
 
 Second, given that all ObjectImpl methods delegate their implementation to
 a locally contained Delegate, if any given ObjectImpl subclass has not been
 connected to an ORB, then it does not have a delegate, and calling any of
 these methods causes a NullPointerException to be thrown.  Is there a
 "friendlier" way to fail?  Or at least a more intuitively obvious
 exception?
 
 Finally, toString, hashCode, and equals are methods common to ALL Java
 Objects.  These methods should ALWAYS behave as expected, ie., no
 exceptions should be thrown.  These were NOT defined to be implemented on
 ObjectImpl in CORBA 2.2.  They are defined to be implemented by document
 98-10-14.  These methods should either:  not be implemented at all on
 ObjectImpl; or be implemented in such a way that they do not throw
 NullPointerException.
 

Resolution: Close, no change
Revised Text:
Actions taken:
April 15, 1999: received issue
February 27, 2001: closed issue

Discussion:
Close, no change. All the points made in the issue are addressed in the current specification.
If Delegate is not set, BAD_OPERATION is thrown.
The implementations of toString, hashCode, and equals test for null Delegate and do reasonable things if it is.
(Perhaps this one got resolved earlier and somehow didn't get marked as closed?)


Issue 2647: Modification of Constant Mapping (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: When we split the mapping of interfaces into the operations and signature
 interfaces, we had to make a decision what to do with constants that are
 declared within interfaces.
 At the time it seemed that most analogous thing to do was to leave it on
 the signature interface.
 Upon further consideration it would probably be better if it were on the
 operations interface. This would make it available on the server side. This
 is a backwards compatible change because operations is inherited by the
 signature interface so the contstant would still be visible to clients
 without changing their code. It only involves a small change to the
 generated code.
 

Resolution:
Revised Text: An Interface: Para 1: change "in either the Java signature interface" to "in either the Java operations interface" Add a new para following para 1: "Note that because the signature interface extends the operations interface for non-abstract IDL interfaces, the constant is available in all the mapped Java interfaces." In the example: Move the declaration: int aLongerOne = (int) (-321L) from interface Face to interface FaceOperations
Actions taken:
May 10, 1999: received issue
January 9, 2001: closed issue

Discussion:


Issue 2661: Valuetype packages (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: For certain IDL types defined in an interface Foo, the Java classes are
 placed in the package FooPackage. The reason given in the mapping document
 is that Java classes cannot be defined in Java interfaces, therefore a new
 package is required.
 
 However, since valuetypes are defined as abstract classes, does that imply
 that IDL types such as struct, exception, etc., that are defined within a
 valuetype are mapped to nested classes of the valuetype class?  Or is a
 separate package used, a la interfaces?
 

Resolution:
Revised Text: In section 1.2.1, change the fifth bullet to: * The nested scope Java package name <type>Package, where <type> is the name of an IDL interface, valuetype, struct, union or exception (Section 1.17, "Mapping for Certain Nested Types," on page 1-61). And in section 1.17, change the text to: IDL allows type declarations nested within interfaces. Java does not allow classes to be nested within interfaces. Hence those IDL types that map to Java classes and that are declared within the scope of an interface must appear in a special "scope" package when mapped to Java. For consistency, the "scope" package is also used for those IDL type declarations nested within valuetypes, structs, unions and exceptions. IDL types that contain these nested type declarations will generate a scope package to contain the mapped Java class declarations. The scope package name is constructed by appending Package to the IDL type name.
Actions taken:
May 25, 1999: received issue
January 9, 2001: closed issue

Discussion:


Issue 2721: DII and SystemException semantics (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
There needs to be a clarification of the expected semantics for DII
Request objects when a system exception is received over-the-wire
after a call to invoke().

Resolution: Close no change
Revised Text:
Actions taken:
June 9, 1999: received issue
January 19, 2000: Deferred
May 13, 2002: closed issue

Discussion:
This issue is lacking in detail and discussion


Issue 2770: Java substitutability issue: value instance -> interface type (java-rtf)

Click
here for this issue's archive.
Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com)
Nature: Uncategorized Issue
Severity:
Summary:
How is it possible to substitute an instance of a value type, that supports
an interface, to a parameter whose formal type is the interface?

Resolution: Close no change.
Revised Text:
Actions taken:
June 25, 1999: received issue
May 13, 2002: closed issue

Discussion:
This is addressed in section 5.2.5.1 of the CORBA 2.5 specification: it is not possible to do what is requested, because the value type is not a subtype of the interface. Therefore this issue should be closed.


Issue 2823: Java mapping for PolicyType... (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
formal-99-07-53 (IDL to Java Language Mapping Specification) has the following
method signature in ORB (page 1-83):
public Policy create_policy(short policy_type, Any val)
     throws org.omg.CORBA.PolicyError
whereas formal-98-12-01 (CORBA) has PolicyType defined as (page 4-20):
typedef unsigned long PolicyType; Thus, shouldn't the Java mapping be?:
public Policy create_policy(int policy_type, Any val) throws org.omg.CORBA.PolicyError

Resolution: closed, editorial change
Revised Text:
Actions taken:
July 28, 1999: received issue
January 19, 2000: Deferred
April 17, 2001: closed issue

Discussion:


Issue 2889: Should Any.extract_string work for bounded strings? (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: It is not clear from the OMG specs or from looking at existing Java ORB
 products what behavior is intended for the following case:
  1. Create an Any with a TypeCode for a bounded string.
  2. Call extract_string on the Any object.
 
 I have tried this on two Java ORBs and it fails in both cases.  It works
 when the Any"s TypeCode is for an unbounded string.  The spec is silent on
 whether or not this should work.  The only relevant statement in the spec is
 the following from section 1.16:
 

Resolution: close no change
Revised Text:
Actions taken:
September 15, 1999: received issue
April 28, 2003: closed issue

Discussion:
I can't see any reason why this should not work. It works in the current Sun ORB. I also do not see any place in the mapping spec or in the core spec where this question is addressed. It seems that this issue really has more to do with the core CORBA architecture than the Java mapping. As no one has made any comment on this issue in over 3 years, I propose that we close it no change. 


Issue 2979: Java SystemException should contain nested exception field (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
The Java org.omg.CORBA.SystemException class should contain a nested exception
field.  This would assist debugging when a Java exception occurs locally 
within the client ORB when marshalling a request or unmarshalling a reply.
At present, when generic system exceptions such as COMM_FAILURE or BAD_PARAM
are returned to the application by the client ORB, it can be difficult to 
identify the precise lower-level failure that caused the problem.

This issue applies specifically to system exceptions arising locally within
a Java client, not those returned by the server to the client.

Resolution: see above
Revised Text:
Actions taken:
November 4, 1999: received issue
May 13, 2002: closed issue

Discussion:
JDK 1.4 has added nested exceptions to all exceptions. Any Throwable can have a nested Throwable added simply by calling the initCause method. This supports general exception chaining. Given this change in Java, we should leave this aspect of error handling as an implementation detail. So, close this issue no change. 


Issue 3068: Messaging sendc and sendp missing from portability interfaces (java-rtf)

Click
here for this issue's archive.
Source: Ericsson (Mr. Chris Smith, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
The Messaging Specification was adopted before Java Portability
layer was really in place. In order to make portability work
with the asynchronous stubs which will in future be generated, 
some things may be added to the portability interface.


Each stub has a sendc_<op> and sendp_<op> operation which
will need to call on the portable stub layer.

A first glance at the requirements to make a portable 
implementation suggest that a sendc_invoke and sendp_invoke
operation will probably need to be added to ObjectImpl and
Delegate.

I dont know if this is viewed as a "compatible" class change
for JDK, or whether we will need to put derived classes 
in CORBA_3_0 package....

Resolution:
Revised Text:
Actions taken:
November 23, 1999: received issue
April 3, 2001: moved from the Messaging RTF to the Java RTF

Discussion:
Move to Java RTF?  Clearly an IDL Java mapping issue. Send to IDL-Java RTF 


Issue 3204: ORB Init problems (java-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Russell Butek, )
Nature: Uncategorized Issue
Severity:
Summary:
 Being new to this game, what is the "Java ORB instance" problem that you
> tried solving?  There is another problem with the Java ORB that I'd also
> like to bring up, but I don't know the proper place to do it.  Would the
> Java RTF address it?
> 
> The problem:  the spec talks about an ORB ID.  The Java mapping, for some
> reason, chose to ignore the ID.  I'd like to understand the reason why.
> Could you enlighten us?

Resolution: see above
Revised Text:
Actions taken:
December 6, 1999: received issue
May 13, 2002: closed issue

Discussion:
ORBId is now provided as a result of the Object Reference Template spec. Close no change


Issue 3209: Illegal return statement (java-rtf)

Click
here for this issue's archive.
Source: NetAcquire Corporation (Mr. Joachim Achtzehnter, joachima(at)netacquire.com)
Nature: Uncategorized Issue
Severity:
Summary:
The method _releaseReply in class org.omg.CORBA.portable.ObjectImpl
has a return value of type void, yet the specification requires this
implementation:

public void _releaseReply(org.omg.CORBA.portable.InputStream is) {
  return _get_delegate().releaseReply(this, is);
}

The return statement is illegal in a method with a void return type. Should
delete the word 'return' from the specification.

PS: Editorial: the diagram on page 1-115 has 'CORBA' missing from some
of the class names.

Resolution: Closed...editorial issue
Revised Text:
Actions taken:
January 11, 2000: received issue
February 7, 2000: closed issue

Issue 3267: How to create marshalel data of java.lang.Throwable instance? (java-rtf)

Click
here for this issue's archive.
Source: Fujitsu (Mr. Masayoshi Shimamura, shima.masa(at)jp.fujitsu.com)
Nature: Uncategorized Issue
Severity:
Summary:
I don't understand that how to create marshaled data of
java.lang.Throwable instance to set it to context_data in
UnknownExceptionInfo.
 
In CORBA 2.3.1, section "13.6.7 Object Service Context" on 13-25 page
says:

    UnknownExceptionInfo identifies a CDR encapsulation of a marshaled instance
    of a java.lang.throwable or one of its subclasses as described in Java
    to IDL Language Mapping, Section 1.4.8.1, "Mapping of UnknownExceptionInfo
    Service Context," on page 1-32.

In Java to IDL Language Mapping specification revised by RTF
(ptc/99-03-09), section "28.4.8.1 Mapping of UnknownExceptionInfo
Service Context" on page 28-32 says:

    CORBA UNKNOWN exceptions whose GIOP Reply message includes an
    UnknownExceptionInfo service context containing a marshaled
    instance of java.lang.Throwable or one of its subclasses are mapped
    to RMI exceptions according to the type of the object contained in
    the service context, as shown in follows:
    -------------------------------------------------------------------
    UnknownExceptionInfo          RMI Exception
    -------------------------------------------------------------------
    java.lang.Error               java.rmi.ServerError
    java.rmi.RemoteException      java.rmi.ServerException
    java.lang.RuntimeException    java.rmi.ServerRuntimeException(JDK 1.1)
                                  java.lang.RuntimeException(Java 2)   
    -------------------------------------------------------------------

It seems to me that these specifications above are not clear. How to
create the context_data from java.lang.Throwable instance? I guess the
context_data should be created by one of following two ways. Which way
is correct? Or is there any other correct way?

1. A instance of java.lang.Throwable or its subclasses should be
   serialized by Java language specific serialization function and then
   should be set to the context_data as sequence of octet.

2. A instance of java.lang.Throwable or its subclasses should be
   marshaled as CORBA Value type data and then should be set to the
   context_data as sequence of octet.


Resolution: see revised text below
Revised Text: Add the following sentence to the end of section 1.4.7: "The Java exception is marshaled using the rules for CDR marshaling of value types as defined by the GIOP specification, applied in conjunction with the rules for mapping RMI/IDL value types to IDL as defined in section 1.3.5 of this specification."
Actions taken:
February 1, 2000: received issue
May 24, 2001: closed issue

Discussion:
Section 1.4.7 states that "All other Java exceptions are marshaled as CORBA UNKNOWN system exceptions whose GIOP
Reply message includes an UnknownExceptionInfo service context containing the marshaled Java exception thrown by the server
implementation." 
The phrase "marshaled Java exception" should be clarified to avoid possible confusion as to how this marshaling is done.


Issue 3320: Java language mapping: Tie classes for local interfaces. (java-rtf)

Click
here for this issue's archive.
Source: ICL (Mr. Chris Wood, )
Nature: Uncategorized Issue
Severity:
Summary:
The new java mapping as specified in 99-10-10 for local classes generates a
class which is subclassed much as previous implementations subclassed the
POA class. 

ie:

local interface Test {
	void call();
};

maps to:

class Test extends org.omg.CORBA.portable.LocalImpl implements
TestOperations {}

then implementers subclass Test to get desired functionality.

I believe there is a need for a tie class similar to the POATie class:

class TestTie extends Test {
	public TestTie(TestOperations delegate) {
		_delegate = delegate; 
	}

	private TestOperations _delegate;

	public void call() {
		_delegate.call();
	}
}



Also the implementation for _hash is not correct :

public int _hash(int max) {
	// return hashCode(); // incorrect, return value exceeds max.
	return hashCode() % (max+1);
}

Resolution: Incorporate revised text and close issue
Revised Text: In section 1.20.2.7, add a new subsection at the end of the section titled: Ties for local interface implementations Ties for local interfaces are defined in a manner very similar to the normal POA-based Ties. The major difference is that no POA is present in the Tie, since local interfaces do not use the POA. Ties are useful for local interfaces for the same reason as they are for normal interfaces: java does not support multiple inheritance. For each local interface <interface_name> the mapping defines a Java local tie class as follows: //Java public class <interface_name>LocalTie extends LocalBase { private <interface_name>Operations _impl; public <interface_name>LocalTie ( <interface_name>Operations delegate ) { this._impl = delegate; } public <interface_name>Operations _delegate() { return this._impl; } public void _delegate (<interface_name>Operations delegate ) { this._impl = delegate; } // For each <method> defined in <interface_name>Operations // (the return statement is present for methods with non-void // <method_return_type>): public <method_return_type> <method>( <params> ) { [return] _impl.<method>( <param_names> ); } } Assume that we have the interface Alocal defined as follows: local interface A { short op1() ; void op2( in long val ) ; } ; Then the LocalTie class for ALocal is as follows: public class ALocalTie extends ALocalBase { public ALocalTie ( AOperations delegate ) { this._impl = delegate; } public AOperations _delegate() { return this._impl; } public void _delegate (AOperations delegate ) { this._impl = delegate; } public short op1 () { return _impl.op1(); } public void op2 (int val) { _impl.op2(val); } private AOperations _impl; } To implement a local interface using the Tie approach, a developer must write an implementation class, which implements the operations class associated with the interface they wish to implement. The developer then instantiates an instance of the implementation class and uses this instance in the constructor of the LocalTie class associated with the interface. The Tie class then provides an implementation of the local interface.
Actions taken:
February 16, 2000: received issue
May 13, 2002: closed issue

Discussion:
.


Issue 3323: Need clarification on custructor(s) for stream-based stubs/skeletons (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
In OMG IDL to Java Language Mapping spec, $1.21.51 "Stub/Skeleton Architecture" there are examples of stream- and DSI- based stubs/skeletons. These examples do not provide any constructors (this mean thay have only default ones). But, it seems that signatures of constructors should be clarified, because orb vendors have a freedom in defining these signatures. For example, the VisiBroker's 4.0 idl2java compiler generates stubs that have only default constructors, but in jdk 1.2 there stubs that have only constructors that take org.omg.CORBA.portable.Delegate as a single parameter. This leads to impossibility for generated stubs to extend the jdk 1.2 provided ones.

Resolution: closed, duplicate of issue 3707
Revised Text:
Actions taken:
February 11, 2000: received issue
October 23, 2000: closed issue

Issue 3410: IDL/Java: methods marked final in PortableServer.Servant (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
The Java language mapping  says (p 1-89) that the following four
methods in PortableServer.Servant may be overridden by application
programmers:

_is_a, _default_POA(), _non_existent(), _get_interface().

The Java source files provided with the written spec. have all 
these methods marked as final, so they cannot be overridden. While
the spec. says the source files are authoritative, this seems to
be a clear contradiction between text and code. 

If the intention whether or not these methods may be overridden has 
changed, this needs to be explained in the text (for application
programmers). Otherwise, it might just be an editorial issue, i.e. 
the Java source files need to be corrected.

Resolution: see below
Revised Text: Remove "final" from the _is_a, _default_POA(), _non_existent(), and _get_interface() methods in the source code file org/omg/PortableServer/Servant.java
Actions taken:
March 11, 2000: received issue
February 27, 2001: closed issue

Issue 3570: org.omg.CORBA.portable.UnknownException does not have all constructors (java-rtf)

Click
here for this issue's archive.
Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
All system exceptions have the following constructors, (BAD_PARAM as eg.)

BAD_PARAM();
BAD_PARAM(int minor_code, CompletionStatus status);
BAD_PARAM(String message);
BAD_PARAM(String message, int minor_code, CompletionStatus status);

UnknownException however has only one. This seems inconsistent.

Proposal:

Add the following constructors to org.omg.CORBA.portable.UnknownException
UnknownException(Throwable orig, int minor_code, CompletionStatus status);
UnknownException(Throwable orig, String message);
UnknownException(Throwable orig, String message, int minor_code,
CompletionStatus status);

Resolution:
Revised Text: Add the following constructors to org.omg.CORBA.portable.UnknownException UnknownException(Throwable orig, int minor_code, CompletionStatus status); UnknownException(Throwable orig, String message); UnknownException(Throwable orig, String message, int minor_code, CompletionStatus status);
Actions taken:
April 19, 2000: received issue
January 9, 2001: closed issue

Issue 3575: Custom marshal does not work for certain valuetypes (java-rtf)

Click
here for this issue's archive.
Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
This was discussed in the core rtf in boston, and the consensus was that this
would be a java only issue and could be fixed in the language mapping directly.

The issue:
Boxed valuetypes, abstract interfaces and regular valuetypes (these can be
marshaled but not in optimized format) cannot be marshaled or unmarshaled when
using custom marshaling. This is because the Data*Stream APIs do not provide the
requisite interfaces.

Proposal:

Add two new interfaces in java defined as follows
package org.omg.CORBA;

public interface CustomOutputStream extends org.omg.CORBA.DataOutputStream {
  public void write_Value(java.io.Serializable value, java.lang.String repId);
// optimized valuetype writes
  public void write_Value(java.io.Serializable value,
org.omg.CORBA.portable.BoxedValueHelper helper); //boxed valuetypes
  public void write_Abstract(java.lang.Object obj); // abstract interfaces
}

public interface CustomInputStream extends org.omg.CORBA.DataInputStream {
    public java.io.Serializable read_value(java.lang.String repId); // optimized
valuetype reads
    public java.io.Serializable read_value(java.lang.Class expected); // Is this
needed???
    public java.lang.Object read_abstract_interface(); // abstract interfaces
    public java.lang.Object read_abstract_interface(java.lang.Class expected);
// Is this needed???
    public java.io.Serializable
read_value(org.omg.CORBA.portable.BoxedValueHelper helper); // boxed valuetypes
}

Resolution: resolved, see below
Revised Text: Add paragraph to section 1.13.1.3 CustomMarshal interface The stream APIs that are passed as arguments for the marshal and unmarshal methods are not sufficient to marshal all valuetypes. In order to support custom marshaling of valuetypes, the ORB shall actually pass an instance of CustomOutputStream and CustomInputStream to these methods respectively (see section 1.21.5 for information on Custom stream APIs). Add section following Streaming APIs (section 1.21.4), and adjust section numbers following; also add the CustomOutputStream and CustomInputStream interfaces to the Source zip file, in the org.omg.CORBA package 1.21.5 Custom Streaming APIs The Custom streaming APIs provide for the reading and writing of all the different valuetypes that may be custom marshaled. The semantics of the methods in these interfaces are identical to their counterparts (with identical signatures) in the CORBA_2_3 portable streaming APIs. public interface CustomOutputStream extends org.omg.CORBA.DataOutputStream { public void write_value(java.io.Serializable value); public void write_value(java.io.Serializable value, java.lang.String repId); public void write_value(java.io.Serializable value, org.omg.CORBA.portable.BoxedValueHelper helper); public void write_abstract_interface(java.lang.Object obj); } public interface CustomInputStream extends org.omg.CORBA.DataInputStream { public java.io.Serializable read_value(); public java.io.Serializable read_value(java.lang.String repId); public java.io.Serializable read_value(java.lang.Class expected); public java.lang.Object read_abstract_interface(); public java.lang.Object read_abstract_interface(java.lang.Class expected); public java.io.Serializable read_value( org.omg.CORBA.portable.BoxedValueHelper helper); // boxed valuetypes }
Actions taken:
April 20, 2000: received issue
October 3, 2001: closed issue

Issue 3633: Request clarification for use of alias typecodes in typedef helper classes (java-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity:
Summary:
I've noticed that there appears to be a lack of consistency between ORB vendors
when it comes to the use of alias typecodes in Java helper classes generated for
IDL typedefs.

Specifically, both Visibroker 4 and Orbix 2000 return an appropriate alias
typecode from the helper class's type () method. However, the Visibroker 4
generated helper class does not use it in either the insert or extract methods,
whilst the Orbix 2000 helper class uses it to set the typecode of the Any passed
to the insert method and to check that the Any passed to the extract method is
of the correct type.

Would it be possible to clarify which of these approaches is correct? From the
specification of the IDL to Java mapping, it appears that typdef types are
intended to be 'unwound' to the first non-typedef type, which would suggest that
the first approach is OK. However, if this is the case, for what purpose is the
alias typecode produced, if not for the setting/checking of typecodes of Anys
containing instances of the associated type?

Resolution: close no change
Revised Text:
Actions taken:
May 19, 2000: received issue
April 28, 2003: closed issue

Discussion:
Either approach appears to be valid, especially since the typecode equality semantics simply unwind tk_alias typecodes until they reach a non-tk_alias typecode. I think no change is needed here


Issue 3643: Description of ORB.init parameters insufficient (java-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Mr. Russell Butek, )
Nature: Uncategorized Issue
Severity:
Summary:
I have a number of questions/concerns about the description/usage of
ORB.init arguments/properties.

1.  There are only two properties described in the Java mapping spec:
org.omg.CORBA.ORBClass and org.omg.CORBA.ORBSingletonClass.  Setting these
via property are described, but not setting these via application string
array (ie., args in main).  Yet the spec says these values can be obtained
via the args array.  I believe most folks assume "-ORBClass xxx" is the
convention, since that's what the JDK's ORB uses, but it's not documented.


2.  Ditto for applet parameters.  It's assumed that they are of the form

<param name = "org.omg.CORBA.ORBClass" value = "xxx">

but it is not documented.


3.  Can this convention be generalized to accommodate the argument naming
convention in the core spec?  If we follow the convention that says
org.omg.CORBA.ORBClass becomes -ORBClass; then can we say that a parameter
-ORBXXX may also be specified by the property or applet parameter
org.omg.CORBA.ORBXXX?


4.  The text around the ORB arguments is tightly coupled to only ORBClass
and ORBSingletonClass.  It does not seem to expect other args/properties.
For example:  "...when creating an ORB instance, the class names of the ORB
implementation are located using the following search order: ...".  I
assume the following search order also applies to any args/props.


5.  The spec doesn't allow for extensions.

"See Table 1-3 for a list of the property names and values that are
recognized by
ORB.init. Any property names not in this list shall be ignored by
ORB.init()."

Has the INS spec updated this table with -ORBInitRef and
-ORBDefaultInitRef, for example?  And the interceptor spec assumes that
services are allowed to have their own arguments.  And what about
proprietary extensions?  Given the word "shall", any extensions are
non-CORBA-compliant.


6.  Repeated arguments fall apart when presented as Properties.  For
example, the INS spec allows for the following invocation:

java myapp -ORBInitRef XX=xx -ORBInitRef YY=yy -ORBInitRef ZZ=zz

Since Properties entries are <key, value> pairs, and only one pair for a
given key can exist, then if we tried entering the above as Properties we'd
only get on of them, not all.  I'm not sure how to fix this.  Dictate that
XX, YY, ZZ be the end of the ORBInitRef string rather than the start of a
new string, perhaps?  So then, specifying these as system properties for
example, we'd have:

java myapp -Dorg.omg.CORBA.ORBInitRefXX xx -Dorg.omg.CORBA.ORBInitRefYY yy
-Dorg.omg.CORBA.ORBInitRefZZ zz

That causes ugly parsing problems.  We'd have to search the whole list of
properties that contained a key that merely BEGAN with
"org.omg.CORBA.ORBInitRef".  And this falls apart in applets; we can get a
list of all Properties, but we cannot get a list of all applet parameters.
Personally I think this is a failing in the applet class, but that's life
as we know it.


I'm sorry to raise this as one issue instead of six, but most of these
points are tightly coupled, so I didn't want to distance them from each
other.  And I'd like them all to be answered together anyway.

Resolution:
Revised Text:
Actions taken:
May 25, 2000: received issue

Issue 3654: OMG ZIP FILE ISSUES for IDL to Java RTF (01) (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Anita Jindal, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
We notice the following discrepancies with org.omg.PortableServer package
published as part of 00-02-01.tar at the OMG web site.  We need to get
these issues resolved as soon as possible (especially before the next release
of JDK).

(1).  Following specified interfaces have an extra inheritance from 
an org.omg.CORBA.Object interface.
	
	org.omg.PortableServer.Current.java
	org.omg.PortableServer.ServantActivator
	org.omg.PortableServer.ServantLocator

e.g., the actual inheritance hierarchy for Current should be:

	public interface Current extends CurrentOperations, 
		org.omg.CORBA.Current, org.omg.CORBA.portable.IDLEntity

        whereas, in the OMG published interfaces it is:

	public interface Current extends 
org.omg.PortableServer.CurrentOperations,
                             org.omg.CORBA.Current,
                             org.omg.CORBA.portable.IDLEntity,
                             org.omg.CORBA.Object

	PLS. NOTE AN EXTRA INHERITANCE FROM org.omg.CORBA.Object interface,
	which should not be there, since there is already an inheritance from
	org.omg.CORBA.Current. Same for other interfaces.
	

Resolution:
Revised Text: Remove inheritance from org.omg.CORBA.Object from org.omg.PortableServer.Current.java org.omg.PortableServer.ServantActivator org.omg.PortableServer.ServantLocator
Actions taken:
May 30, 2000: received issue
January 9, 2001: closed issue

Issue 3655: OMG ZIP FILE ISSUES for IDL to Java RTF (02) (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Anita Jindal, nobody)
Nature: Uncategorized Issue
Severity: Significant
Summary:
(2).  Wrong mapping for all Enum types, specifically method from_int() is not 
according to IDL to Java mapping spec.

	According to ptc/00-01-08.pdf, the mapping for from_int() method is
	
	// get enum with specified value public 
	static <enum_name> from_int(int value);

whereas in the OMG published interfaces for all Enums, the mapping for this
signature is something like:

	public static IdAssignmentPolicyValue from_int(int val)
                       throws org.omg.CORBA.BAD_PARAM
         
        PLS. NOTE THAT IT IS THROWING AN EXCEPTION NOT SPECIFIED BY THE MAPPING.

Resolution: Close, duplicate of 3669
Revised Text:
Actions taken:
May 30, 2000: received issue
January 9, 2001: closed issue

Issue 3656: OMG ZIP FILE ISSUES for IDL to Java RTF (03) (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Anita Jindal, nobody)
Nature: Uncategorized Issue
Severity: Significant
Summary:
(3).   org.omg.PortableServer.ServantLocatorPackage.CookieHelper.java is 
published for "native" Cookie.  The IDL to Java specification does not specify
mapping for Helper classes for native types, nor does it mention that one
exists for native types.  This should be removed as part of the ZIP file
or the IDL to Java specification needs to be modified to completely specify the
mapping for CookieHelper.java

Resolution:
Revised Text: Remove org.omg.PortableServer.ServantLocatorPackage.CookieHelper.java from the ZIP file.
Actions taken:
May 30, 2000: received issue
January 9, 2001: closed issue

Issue 3657: OMG ZIP FILE ISSUES for IDL to Java RTF (04) (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Anita Jindal, nobody)
Nature: Uncategorized Issue
Severity: Significant
Summary:
(4).  The "const" mapping does not specify "public static final", please note
that without this, no one will be able to directly access the value specified
for the const's directly.

Resolution: close, no change
Revised Text:
Actions taken:
May 31, 2000: received issue
January 9, 2001: closed issue

Discussion:
Close, no change.  The Java language automatically declares


constants in an interface "public static final".


Issue 3658: OMG ZIP FILE ISSUES for IDL to Java RTF (05) (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Anita Jindal, nobody)
Nature: Uncategorized Issue
Severity: Significant
Summary:
(5).  The OMG ZIP file is missing the following interfaces:

	ServantActivatorHelper.java
	ServantActivatorPOA.java
	_ServantActivatorStub.java
	ServantLocatorHelper.java
	ServantLocatorPOA.java
	_ServantLocatorStub.java

In order to enable, application programmers, register their own servant managers
these need to be provided as part of the PortableServer package (in the absence
of the local interfaces).

Resolution: close, no change
Revised Text:
Actions taken:
May 31, 2000: received issue
January 9, 2001: closed issue

Discussion:
CLOSE, NO CHANGE, because "these files are generated from standard IDL and


are vendor-specific. There would actually be more files on the "missing"


list, except that "dummy" versions were generated so that everything


provided would compile."



Issue 3659: OMG ZIP FILE ISSUES for IDL to Java RTF (06) (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Anita Jindal, nobody)
Nature: Uncategorized Issue
Severity: Significant
Summary:
(6).  The mapping for org.omg.PortableServer.Servant.java specifies the 
following signature for _get_interfaces.

    final public org.omg.CORBA.InterfaceDef _get_interface() {
        return _get_delegate().get_interface(this);
    }

Also, for org.omg.PortableServer.portable.Delegate.java

    org.omg.CORBA.InterfaceDef get_interface(
                    org.omg.PortableServer.Servant self);


The above mapping for server-side should be changed to match the
client side mapping.  Please note, that in the 
org.omg.CORBA.portable.ObjectImpl, the following signature has been deprecated.

    /**
    *@deprecated Deprecated by CORBA 2.3
    */
    public org.omg.CORBA.InterfaceDef _get_interface() {
        return _get_delegate().get_interface(this);
    }

the new signature according to CORBA 2.3 spec is:

    public org.omg.CORBA.Object _get_interface_def() {
        return _get_delegate().get_interface_def(this);
    }

Resolution: see below
Revised Text: - Add the following paragraph after the third paragraph in section 1.19.11: The _get_interface() and _get_interface_def() operations both return an InterfaceDef object that defines the runtime type of the CORBA::Object on which they are invoked. The deprecated _get_interface() method returns the InterfaceDef directly as an InterfaceDef. Because this operation is deprecated, new applications should not use it, and it may be removed in a future release of this specification. The _get_interface_def() operation returns the InterfaceDef as a CORBA::Object, and the invoker of _get_interface_def() must narrow the CORBA::Object to an InterfaceDef in order to use it. - Replace the first paragraph of section 1.20.2.1 with the following paragraphs: The PortableServer module for the Portable Object Adapter (POA) defines the native Servant type. In Java, the Servant type is mapped to the Java org.omg.PortableServer.Servant class. The implementation of the Servant must delegate all operations to the org.omg.PortableServer.portable.Delegate class defined in Section 1.21.8, "Servant Delegate", on page 1-127. The Servant class is defined as follows: - In section 1.20.2.1, replace the three occurrences of the type Delegate with org.omg.PortableServer.portable.Delegate to match the code in ptc/00-07-04.zip. - In section 1.20.2.1, change the signature: public org.omg.CORBA.InterfaceDef _get_interface() { return _get_delegate().get_interface(this); } to: /** @deprecated Deprecated by CORBA 2.4 */ public org.omg.CORBA.InterfaceDef _get_interface() { return _get_delegate().get_interface( this ) ; } public org.omg.CORBA.Object _get_interface_def() { return _get_delegate().get_interface_def(this); } - In section 1.20.2.1 on page 1-92, replace the description of _get_interface with the following text: The _get_interface_def() operation returns an InterfaceDef object as a CORBA::Object that defines the runtime type of the CORBA::Object that is implemented by the Servant. The invoker of _get_interface_def must narrow the result to an InterfaceDef in order to use it. Servant provides a default implementation of _get_interface_def() that can be overridden by derived servants if the default behavior is not adequate. As defined in the CORBA 2.3.1 specification, section 11.3.1, the default behavior of _get_interface_def() is to use the most derived interface of a static servant or the most derived interface retrieved from a dynamic servant to obtain the InterfaceDef. This behavior must be supported by the Delegate that implements the Servant. - Delete section 1.21.7, as it does not add anything after the above changes to 1.20.2.1. The Delegate should be defined under Portability, while the Servant should be completely defined under Server-Side mapping. - In section 1.21.8, and in the Source code for PortableServer.portable.Delegate, replace the text org.omg.CORBA.InterfaceDef get_interface( org.omg.PortableServer.Servant self); with the text /** @deprecated Deprecated by CORBA 2.4 */ org.omg.CORBA.InterfaceDef get_interface( org.omg.PortableServer.Servant self); org.omg.CORBA.Object get_interface_def( org.omg.PortableServer.Servant self); - In the Source code for PortableServer.Servant: change the _get_interface method to /** @deprecated Deprecated by CORBA 2.4 */ public org.omg.CORBA.InterfaceDef _get_interface() { return _get_delegate().get_interface( this ) ; } and add the following method: public org.omg.CORBA.Object _get_interface_def() { // First try to call the delegate implementation class's // "Object get_interface_def(..)" method (will work for ORBs // whose delegates implement this method). // Else call the delegate implementation class's // "InterfaceDef get_interface(..)" method using reflection // (will work for ORBs that were built using an older version // of the Delegate interface with a get_interface method // but not a get_interface_def method). org.omg.PortableServer.portable.Delegate delegate = _get_delegate(); try { // If the ORB's delegate class does not implement // "Object get_interface_def(..)", this will throw // an AbstractMethodError. return delegate.get_interface_def(this); } catch( AbstractMethodError aex ) { // Call "InterfaceDef get_interface(..)" method using reflection. try { Class[] argc = { org.omg.PortableServer.Servant.class }; java.lang.reflect.Method meth = delegate.getClass().getMethod("get_interface", argc); Object[] argx = { this }; return (org.omg.CORBA.Object)meth.invoke(delegate, argx); } catch( java.lang.reflect.InvocationTargetException exs ) { Throwable t = exs.getTargetException(); if (t instanceof Error) { throw (Error) t; } else if (t instanceof RuntimeException) { throw (RuntimeException) t; } else { throw new org.omg.CORBA.NO_IMPLEMENT(); } } catch( RuntimeException rex ) { throw rex; } catch( Exception exr ) { throw new org.omg.CORBA.NO_IMPLEMENT(); } } }
Actions taken:
May 31, 2000: received issue
February 27, 2001: closed issue

Issue 3665: Java ORB Id (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Harold Carr, Ph.D., nobody)
Nature: Uncategorized Issue
Severity:
Summary:
There are several reasons that Java ORB.init should support
ORBId (without compromising security).  For example:

- Services built on Portable Interceptors work in relation to the ORB
with which they are registered.  There needs to be some means of
identifying this ORB (besides its reference) so other services or
facades (e.g., JNDI) can use the same ORB.

- A Server Activation Framework needs an ORB Id to identify a particular
orb (which hosts a persistent POA) within a server.  The triple:
server id, orb id, poa name is *conceptually* embedded in the adapter
id of a POA making it unique.

Resolution:
Revised Text:
Actions taken:
May 30, 2000: received issue
August 18, 2000: moved from interceptors ftf to java RTF

Discussion:
  Incorporate change and close issue. However, this is out-of-scope for the interceptors FTF. It is being
transferred to the IDL to java RTF.


Issue 3668: Possible problem with IDL to Java mapping of fixed-point decimal types (java-rtf)

Click
here for this issue's archive.
Source: SAP AG (Mr. Evan Ireland, eireland(at)sybase.com)
Nature: Uncategorized Issue
Severity:
Summary:
I'm wondering how other folks interpret the following section from CORBA 2.3.1
(for the CDR Transfer Syntax).

15.3.2.8 Fixed-Point Decimal Type

  The IDL fixed type has no alignment restrictions, and is represented as shown in Table
  15-4 on page 15-13. Each octet contains (up to) two decimal digits. If the fixed type
  has an odd number of decimal digits, then the representation begins with the first (most
  significant) digit — d0 in the figure. Otherwise, this first half-octet is all zero, and the
  first digit is in the second half-octet — d1 in the figure. The sign configuration, in the
  last half-octet of the representation, is 0xD for negative numbers and 0xC for positive
  and zero values.

I interpret this to mean that the encoded size of any given fixed-point
decimal IDL type is determined statically according to the 'digits' and 'scale'
in the fixed<digits,scale> IDL definition, rather than dynamically by the
number of digits in the value to be encoded.

Unfortunately if my interpretation is correct, there appears to be a problem
in the IDL to Java mapping for fixed-point decimals, as we have
in org.omg.CORBA.portable.OutputStream:

  public void write_fixed(java.math.BigDecimal value) ...

Since a Java BigDecimal has a scale but no precision, I would think there
would be a problem if the BigDecimal value "1.23" was to be encoded as
a fixed<5,2>, since the write_fixed method has no 'digits' parameter,
so it doesn't know the correct size for the CDR encoding.
The 'read_fixed' method on the InputStream class has similar problems.

Has anyone encountered this issue before, and if so what was the resolution?

Resolution: see below
Revised Text: In Section 21.4 and in the Source Code: Change org.omg.CORBA.portable.InputStream.read_fixed to /** @deprecated Deprecated by CORBA 2.4 */ java.math.BigDecimal org.omg.CORBA.portable.InputStream.read_fixed() { throw new org.omg.CORBA.NO_IMPLEMENT(); } java.math.BigDecimal org.omg.CORBA.portable.InputStream.read_fixed( short digits, short scale) { throw new org.omg.CORBA.NO_IMPLEMENT(); } Change org.omg.CORBA.portable.OutputStream.write_fixed to /** @deprecated Deprecated by CORBA 2.4 */ void org.omg.CORBA.portable.OutputStream.write_fixed(java.math.BigDecimal value) { throw new org.omg.CORBA.NO_IMPLEMENT(); } void org.omg.CORBA.portable.OutputStream.write_fixed( java.math.BigDecimal value, short digits, short scale) { throw new org.omg.CORBA.NO_IMPLEMENT(); } Add a new subsection at the end of Section 21.4.1: read_fixed The short parameters indicate the digits and scale of the fixed-point decimal. These parameters are needed because when the fixed is read off the stream, the BigDecimal can't be reconstructed to the original digits and scale without explicitly passing in the digits and scale. Add a new subsection at the end of Section 21.4.2: write_fixed The short parameters indicate the digits and scale of the fixed-point decimal. These parameters are needed because the information of the maximum number of digits and scale is lost when the IDL fixed is mapped to a BigDecimal for write_fixed.
Actions taken:
May 31, 2000: received issue
February 27, 2001: closed issue

Issue 3669: Enum mapping issue (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
The IDL to Java mapping spec (ptc/00-02-07) defines the
mapping for IDL to Enums to Java.  The generated enum
class contains a method

public static <TYPE> from_int( int i )

However, the mapping spec does not call for an exception
to be thrown if the parameter does not correspond to a
valid enum for this enum type.

ptc/00-02-08 defines the standard Java classes for
the PIDL native types and the ORB portability interfaces.
It includes several IDL enums in org.omg.CORBA:

AttributeMode, CompletionStatus, DefinitionKind, OperationMode,
ParameterMode, PrimitiveKind, SetOverrideType, and TCKind.

All have signatures similar to:

public static TCKind from_int( int val ) throws org.omg.CORBA.BAD_PARAM

This is not compliant with the specification.

If we look at the definition of BAD_PARAM, it is a SystemException, which
extends java.lang.RuntimeException, so BAD_PARAM, like all system exceptions,
is an unchecked java exception.  Consequently there is no need to declare
BAD_PARAM in the signature of the from_int methods.  However, the behavior is
useful and should be specified.

I think this issue should be resolved with the following changes:

1. Update ptc/00-02-08.zip to remove the "throws BAD_PARAM" clauses
   on all from_int methods for enums.
   
2. Update ptc/00-02-07 section 1.7 as follows:

replace the paragraph

	"The java class for the enum has an additional method from_int(),
	which returns the enum with the specified value."
	
with

	"The java class for the enum has an additional method from_int(),
	which returns the enum with the specified value if the specified
	value corresponds to an element of the enum.  If the specified
	value is out of range, a BAD_PARAM exception with a minor code
	of XXX is raised."
	
where as usual XXX needs to be filled in with an appropriate minor code.

Resolution:
Revised Text: 1. Update ptc/00-02-08.zip to remove the "throws BAD_PARAM" clauses on all from_int methods for enums. 2. Update ptc/00-02-07 section 1.7 as follows: replace the paragraph "The java class for the enum has an additional method from_int(), which returns the enum with the specified value." with "The java class for the enum has an additional method from_int(), which returns the enum with the specified value if the specified value corresponds to an element of the enum. If the specified value is out of range, a BAD_PARAM exception with a minor code of XXX is raised." where as usual XXX needs to be filled in with an appropriate minor code.
Actions taken:
May 30, 2000: received issue
January 9, 2001: closed issue

Issue 3686: How can org.omg.CORBA.portable.InputStream.read_fixed possibly work? (java-rtf)

Click
here for this issue's archive.
Source: SAP AG (Mr. Evan Ireland, eireland(at)sybase.com)
Nature: Uncategorized Issue
Severity:
Summary:
If you look at the signature of org.omg.CORBA.portable.InputStream.read_fixed,
you will see that it does not accept parameters for the fixed digits and scale.
Since the GIOP CDR encoding for fixed-point decimals does not include meta-data
on the wire (e.g. the scale is not explicit in the wire-encoding), how can the
Java portable InputStream's read_fixed method reliably determine the scale of
the value being read? Maybe I'm missing something, or maybe the mapping spec is
just plain broken. Can someone please shed some light on this.

Resolution: Close, Duplicate of 3668
Revised Text:
Actions taken:
June 9, 2000: received issue
February 27, 2001: closed issue

Issue 3707: Need clarification on custructor(s) for stream-based (java-rtf)

Click
here for this issue's archive.
Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
In OMG IDL to Java Language Mapping spec, $1.21.5.1 "Stub/Skeleton Architecture" there
are examples of stream- and DSI- based   stubs/skeletons. These examples do not
provide any constructors (this mean thay have only default ones). But, it seems that
signatures of constructors should be clarified, because orb vendors have a freedom in
defining these signatures. For example, the VisiBroker's 4.0 idl2java compiler
generates stubs that have only default constructors, but in jdk 1.2 there stubs that
have only constructors that take org.omg.CORBA.portable.Delegate as a single
parameter. This leads to impossibility for generated stubs to extend the jdk 1.2
provided ones.

Since the example is not normative, vendors are free to add whatever constructors they
would like. This makes it impossible to generate code for interfaces that are
inherited from interfaces for which code is generated by another vendor, which is true
especially in the case of Java 2 and its inclusion of some stubs.

I would like to propose the following:
To Seciton 1.21.5.1 under subheading Stub Design, add a bullet:

Stubs are not required to define any constructors. However, if they do define special
constructors, a constructor with no arguments must also be defined.

This ensures that all stubs are guaranteed to have the no argument constructor
irrespective of whether they have other constructors or not.

Resolution: see below
Revised Text: To Section 1.21.5.1 under subheading Stub Design, add a bullet: Stubs are not required to define any constructors. However, if they do define special constructors, a constructor with no arguments must also be defined.
Actions taken:
June 14, 2000: received issue
February 27, 2001: closed issue

Issue 3750: SystemExceptionHelper missing (java-rtf)

Click
here for this issue's archive.
Source: IONA (Mr. Mark Spruiell, )
Nature: Uncategorized Issue
Severity:
Summary:
There is no standard way for an application to insert/extract
a SystemException into/from an Any. This would be especially
useful for Portable Interceptors, where an exception is provided
in the form of an Any.

In the absence of a SystemExceptionHelper.extract() method, an
application is forced to a) use DynAny or b) compare the
exception's repository ID against dozens of system exception
IDs in order to determine which Helper to use.

Proposal:

Add org.omg.CORBA.SystemExceptionHelper. All of the standard
exception Helper methods are implemented.

Resolution: see below
Revised Text: In section 1.15.2, add the following paragraph after the first paragraph: "A Helper class is provided for each concrete system exception. In addition, a Helper class is provided for org.omg.CORBA.SystemException which can be used to manipulate system exceptions when the concrete type is unknown. The Helper classes for system exceptions follow the normal rules defined in Section 1.5, "Helpers", on page XX."
Actions taken:
July 19, 2000: received issue
February 27, 2001: closed issue

Discussion:
Proposal:



Add org.omg.CORBA.SystemExceptionHelper. All of the standard

exception Helper methods are implemented.


Issue 3788: Mapping for Sequences -> <sequence_class>Holder (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ram Jeyaraman, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Re : ptc/00-01-08 IDL to Java Language mapping spec, Section 1.10

The <sequence_class>Holder class shown below does not implement org.omg.CORBA.portable.Streamable
interface, whereas the basic type holders like ShortHolder implement the Streamable interface.

final public class <sequence_class>Holder {
	public <sequence_element_type>[] value;
	public <sequence_class>Holder() {};
	public <sequence_class>Holder(
		<sequence_element_type>[] initial)
		{...};
	public void _read(
		org.omg.CORBA.portable.InputStream is)
		{...}
	public void _write(
		org.omg.CORBA.portable.OutputStream os)
		{...}
	public org.omg.CORBA.TypeCode _type() {...}

Resolution: see below
Revised Text: Add "implements org.omg.CORBA.portable.Streamable" to final public class <sequence_class>Holder in Section 10.
Actions taken:
August 19, 2000: received issue
February 27, 2001: closed issue

Issue 3794: IDLEntity interface has to be public. (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Hemanth Puttaswamy, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Interface IDLEntity is declared as package private in the IDL To Java document
(ptc/00-01-08.pdf) Section 14.1.2. I propose it to change it to public.

from 

package org.omg.CORBA.portable; 
interface IDLEntity extends java.io.Serializable {}

to 

package org.omg.CORBA.portable; 
public interface IDLEntity extends java.io.Serializable {}

Resolution: editorial fix, issue closed
Revised Text:
Actions taken:
August 29, 2000: received issue
August 31, 2000: closed issue, editorial

Issue 3795: Incorrect method declaration in CORBA_2_3/portable/InputStream.java and Out (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Hemanth Puttaswamy, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Looks like there is a typo in the IDL to Java document(ptc/00-01-08) Section 
1.21.4. 

The method signature 

public java.io.Serializable read_value( org.omg.CORBA.BoxedValueHelper factory)

has to be 

public java.io.Serializable read_value( org.omg.CORBA.portable.BoxedValueHelper 
factory) 

Because BoxedValueHelper belongs to org.omg.CORBA.portable package.

Also The method signature

public void write_value( java.io.Serializable value,       
                         org.omg.CORBA.BoxedValueHelper factory)
                         
                         has to be
                         
public void write_value( java.io.Serializable value,       
                         org.omg.CORBA.portable.BoxedValueHelper factory)
                         
Again for the same reason.

Resolution: editorial fix, issue closed
Revised Text:
Actions taken:
August 29, 2000: received issue
August 31, 2000: closed issue, editorial

Issue 3801: policy_type should map to a Java int. (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Masood (Max) Mortazavi, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
It appears that there's an error in the OMG specification ptc/00-01-08
OMG IDL to Java Language Mapping. In the mapping for ORB as given in the
org.omg.CORBA.ORB in section 1.19.10, the IDL signature

    Policy create_policy(
        in PolicyType type,
        in any val
    ) raises (PolicyError);

has been mapped to

    public Policy create_policy(short policy_type, Any val)
            throws org.omg.CORBA.PolicyError


However, note that in formal/99-10-07, as in elsewhere, it's clearly
stated that PolicyType is unsigned long

    4.9.1 Definition of Policy Object

    typedef unsigned long PolicyType;
    // Basic IDL definition
    interface Policy {
        readonly attribute PolicyType policy_type;
        Policy copy();
        void destroy();
    };

and that the Java mapping for unsigned long is an "int" not a
"short," as erroneously implied in 1.19.10 of  ptc/00-01-08.

I believe this is an error in the  ptc/00-01-08 OMG IDL to Java Language
Mapping that needs to be cleared.

Resolution: closed issue, editorial change
Revised Text:
Actions taken:
August 29, 2000: received issue
April 17, 2001: closed issue

Issue 3818: Operations signatures include throws clauses on system exceptions. (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
There are several places in the IDL to Java mapping spec
(ptc/00-01-08) where operations signatures include
throws clauses on system exceptions.  Since system 
exceptions are unchecked Java exceptions, they need
never be declared in operation signatures.  As normal
Java practice only declares checked exceptions, the throws
clauses for unchecked exceptions should be removed.

I have found this problem in the following places in the spec:

p. 58-61 various methods throw DATA_CONVERSION, MARSHAL, and BAD_OPERATION
p. 85 get_value_def throws BAD_PARAM
p. 122 _invoke(...) throws SystemException


Resolution: see below
Revised Text: Remove the "throws" clause from the following places in the chapter, and from the corresponding places in the source code: Section 1.16 class Any abstract public void read_value( org.omg.CORBA.portable.InputStream is, org.omg.CORBA.TypeCode t) throws org.omg.CORBA.MARSHAL; abstract public short extract_short() throws org.omg.CORBA.BAD_OPERATION; abstract public int extract_long() throws org.omg.CORBA.BAD_OPERATION; abstract public long extract_longlong() throws org.omg.CORBA.BAD_OPERATION; abstract public short extract_ushort() throws org.omg.CORBA.BAD_OPERATION; abstract public int extract_ulong() throws org.omg.CORBA.BAD_OPERATION; abstract public long extract_ulonglong() throws org.omg.CORBA.BAD_OPERATION; abstract public float extract_float() throws org.omg.CORBA.BAD_OPERATION; abstract public double extract_double() throws org.omg.CORBA.BAD_OPERATION; abstract public boolean extract_boolean() throws org.omg.CORBA.BAD_OPERATION; abstract public char extract_char() throws org.omg.CORBA.BAD_OPERATION; abstract public void insert_char(char c) throws org.omg.CORBA.DATA_CONVERSION; abstract public char extract_wchar() throws org.omg.CORBA.BAD_OPERATION; abstract public byte extract_octet() throws org.omg.CORBA.BAD_OPERATION; abstract public org.omg.CORBA.Any extract_any() throws org.omg.CORBA.BAD_OPERATION; abstract public org.omg.CORBA.Object extract_Object() throws org.omg.CORBA.BAD_OPERATION; abstract public java.io.Serializable extract_Value() throws org.omg.CORBA.BAD_OPERATION; abstract public void insert_Value( java.io.Serializable v, org.omg.CORBA.TypeCode t) throws org.omg.CORBA.MARSHAL; abstract public void insert_Object( org.omg.CORBA.Object obj, org.omg.CORBA.TypeCode t).1 throws org.omg.CORBA.BAD_PARAM; abstract public String extract_string() throws org.omg.CORBA.BAD_OPERATION; abstract public void insert_string(String s) throws org.omg.CORBA.DATA_CONVERSION, org.omg.CORBA.MARSHAL; abstract public String extract_wstring() throws org.omg.CORBA.BAD_OPERATION; abstract public void insert_wstring(String s) throws org.omg.CORBA.MARSHAL; abstract public org.omg.CORBA.TypeCode extract_TypeCode() throws org.omg.CORBA.BAD_OPERATION; public org.omg.CORBA.Principal extract_Principal() throws org.omg.CORBA.BAD_OPERATION public org.omg.CORBA.portable.Streamable extract_Streamable() throws org.omg.CORBA.BAD_INV_ORDER public void insert_fixed( java.math.BigDecimal value, org.omg.CORBA.TypeCode type) throws org.omg.CORBA.BAD_INV_ORDER Section 19.10 package org.omg.CORBA_2_3; public abstract class ORB extends org.omg.CORBA.ORB { public org.omg.CORBA.Object get_value_def( String repid) throws org.omg.CORBA.BAD_PARAM Section 21.5.4 public interface InvokeHandler { OutputStream _invoke( String method, InputStream is, ResponseHandler handler) throws org.omg.CORBA.SystemException;
Actions taken:
September 8, 2000: received issue
February 27, 2001: closed issue

Discussion:


Issue 3819: Issues with Java mapping of Typecode (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
In the IDL to Java spec (ptc/00-01-08) there are several minor
editorial errors in the Java mapping for Typecode:

1. p. 74 the example has 

      class TypeCode extends IDLEntity

   However, IDLEntity is an interface, so this must be implements,
   not extends.  

2. p. 75 the declaration

      public abstract short member_visibility( long index )

   should be 

      public abstract short member_visibility( int index )

   since the IDL for member_visibility has a long argument,
   and IDL long type maps to int in Java.

3. Throughout class Typecode on pp. 74-75, TypeCodePackage.BadKind
   and TypeCodePackage.Bounds are illegal java.  The exception names
   must either be fully qualified or unqualified with appropriate 
   import statements.


Resolution: closed issue...editorial
Revised Text:
Actions taken:
September 8, 2000: received issue
April 17, 2001: closed issue

Issue 3903: mapping for Request.target will not compile (java-rtf)

Source: Oracle (Dr. Harold Carr, Ph.D.,
nobody)
Nature: Uncategorized Issue
Severity:
Summary:
This is a IDL to Java issue.

	ptc/00-01-08 specifies the mapping for Request.

	The mapping of target is specified on p 69 as:

		public abstract Object target();

	It should say:
		
		public abstract org.omg.CORBA.Object target();

	Otherwise it will not compile.

Resolution: closed issue, editorial change
Revised Text:
Actions taken:
September 20, 2000: received issue
April 17, 2001: closed issue

Issue 3904: ptc/00-01-08: Conflict 1.15.1 paragraph 2 - 1.19.2 paragraph 2 (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Harold Carr, Ph.D., nobody)
Nature: Uncategorized Issue
Severity:
Summary:
This is a IDL to Java issue.

ptc/00-01-08

	1.15.1 paragraph 2 states that the "string reason parameter
	... is concatenated to the id before calling the base
	UserException constructor."

	However, 1.19.2 paragraph 2 states that "no holder and helper
	classes are define for these exceptions," (i.e., Bounds, BadKind,
	InvalidName) ... they are mapped as normal user exceptions."

	Since a helper class is not generated it is impossible to to
	concatenate an id before calling the base UserException constructor in
	these cases.

	Therefore they are not mapped as normal user exceptions.  They
	are mapped as normal user exceptions EXCEPT that the additional "full"
	constructor does not concatenate an id before calling the base
	UserException constructor.
	
	The text and non-normative examples should be updated to make 
	this clear.

Resolution: see below
Revised Text: Rewrite the second paragraph of Section 19.2, to say "No holder classes are defined for these exceptions, nor are they in the interface repository. However, so that users can treat them as "normal exceptions" for programming purposes, they are otherwise mapped as normal user exceptions, including the generation of helper classes."
Actions taken:
September 20, 2000: received issue
February 27, 2001: closed issue

Discussion:
The Source Zip Files actually have Helpers for the exceptions in Section 19.2, and these Helpers are used in the
Source for the exceptions themselves, to do the concatenation as described in Section 15.1.
Resolution:


Issue 3911: Incomplete union mapping (java-rtf)

Click
here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:
it appears that the Java mapping for unions is incomplete. For example:

	enum E { A, B, C };

	union U switch (E) {
	case A:
		long l;
	};

Something like this is actually used in the trader specification. For
a discriminator value of B or C, the union contains no member (but does
contain the discriminator value, of course). The problem arises because
the semantics of an operation can differ depending on the discriminator
value. For example:

	interface foo {
		SomeType op(in U param);
	};

op() can do different things (and indeed, *does* do different things in the
trader spec), depending on whether the discriminator value for the union
is B or C.

The problem is that the Java mapping does not offer a modifier for
the discriminator, thereby making it impossible to control the discriminator
value if more than one discriminator value is possible for the same union
member.

Resolution: withdrawn by submitter
Revised Text:
Actions taken:
September 28, 2000: received issue
September 28, 2000: closed issue

Issue 3912: How is an ORB to determine whether or not it is in an applet context? (java-rtf)

Click
here for this issue's archive.
Source: Improv Technologies (Dr. Mary Leland, )
Nature: Uncategorized Issue
Severity:
Summary:
How is an ORB to determine whether or not it is in an applet context?
The nearest that I can see is to check for the presence of
a SecurityManager. If we are in an applet context, then there is a
SecurityManager present, but the inverse (that the presence of a
SecurityManager implies that we are in an applet) is not true.
It is however the case that whenever a SecurityManager is present,
potentially untrusted code is present, so the same constraints on the
singleton ORB are probably appropriate.
Therefore, I propose that the specification be changed to state
that if System.getSecurityManager() returns a non-null result,
the singeton ORB should be constrained to creating TypeCodes and Anys.

Resolution: see below
Revised Text: Replace the second paragraph under "Default Initialization" in Section 21.9.3 (bottom of page 129 in ptc/2000-07-03) with the following 2 paragraphs. They preserve the useful information about the Applet case, but make it clear that the singleton ORB returned by the no-argument ORB.init is constrained in any context. Replacement Text: "The primary use of the no-argument version of ORB.init() is to provide a factory for TypeCodes for use by Helper classes implementing the type() method, and to create Any instances that are used to describe union labels as part of creating a union TypeCode. In the case of an ORB within a browswer, these Helper classes may be baked-in to the browser (e.g., for the interface repository stubs or other wildly popular IDL) and so may be shared across untrusted applets downloaded into the browser. The returned ORB instance is shared across all applets and therefore must have sharply restricted capabilities so that unrelated applets can be isolated from each other. It is not intended to be used directly by applets."
Actions taken:
September 28, 2000: received issue
February 27, 2001: closed issue

Discussion:
This is a re-submission of Issue 1751, which disappeared from
the database without ever being actually resolved.


Issue 3913: Vendor-specific ORB_init methods (java-rtf)

Click
here for this issue's archive.
Source: Improv Technologies (Dr. Mary Leland, )
Nature: Uncategorized Issue
Severity:
Summary:
The first two bullets in Section 1.1.1.1 of ptc/2000-07-03
refer to the fields DEFAULT_ORB and DEFAULT_ORB_SINGLETON in
omg/omg/CORBA/ORB.java.  However, these fields do not exist
in that file (nor are they in org/omg/CORBA_2_3/ORB.java).
The intention of these bullets is to permit vendors to
appropriately modify the implementations of the ORB_init
methods, but since these methods are not implemented using
those fields, the intention is not achieved.

Proposed resolution:
   Add a point #3 to Section 1.1, along the lines of
   "In certain rare cases, the actual body of a method
   must be replaced by a vendor-specific implementation.
   These cases are clearly identified in this specification
   and by comments in the org.omg.* packages."

   Change the first two bullets in Section 1.1.1.1 to
   "Vendor-specific implementations for the ORB_init
   methods of org.omg.CORBA.ORB must be supplied.
   Since these methods are static, they cannot be
   overridden by the vendor-specific ORB subclass,
   but must be provided in the org.omg.CORBA.ORB class
   itself."

   Add a comment 
       /* VENDOR MUST SUPPLY IMPLEMENTATION */
   to the ORB_init methods, and a line in the
   header comments of the org/omg/CORBA/ORB.java
   file saying that implementations of the ORB_init
   methods are required.

Resolution:
Revised Text: Add a point #3 to Section 1.1, saying "In certain rare cases, the actual body of a method must be replaced by a vendor-specific implementation. These cases are clearly identified in this specification and by comments in the org.omg.* packages." Change the first two bullets in Section 1.1.1.1 to "Vendor-specific implementations for the init methods of org.omg.CORBA.ORB must be supplied. Since these methods are static, they cannot be overridden by the vendor-specific ORB subclass, but must be provided in the org.omg.CORBA.ORB class itself." Add a comment /* VENDOR MUST SUPPLY IMPLEMENTATION */ to the init methods, and a line in the header comments of the org/omg/CORBA/ORB.java file saying that implementations of the init methods are required.
Actions taken:
September 28, 2000: received issue
February 27, 2001: closed issue

Discussion:
Proposed resolution:

   Add a point #3 to Section 1.1, along the lines of

   "In certain rare cases, the actual body of a method

   must be replaced by a vendor-specific implementation.

   These cases are clearly identified in this specification

   and by comments in the org.omg.* packages."



   Change the first two bullets in Section 1.1.1.1 to

   "Vendor-specific implementations for the init

   methods of org.omg.CORBA.ORB must be supplied.

   Since these methods are static, they cannot be

   overridden by the vendor-specific ORB subclass,

   but must be provided in the org.omg.CORBA.ORB class

   itself."



   Add a comment 

       /* VENDOR MUST SUPPLY IMPLEMENTATION */

   to the init methods, and a line in the

   header comments of the org/omg/CORBA/ORB.java

   file saying that implementations of the init

   methods are required.


Issue 3923: #pragma prefix issue (java-rtf)

Click
here for this issue's archive.
Source: SciTegic Inc. (Scott Markel, Ph.D., nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Section 1.5.3 of the OMG's IDL Style Guide (ab/98-06-03) indicates that

  #pragma prefix "omg.org"

should appear in any IDL file belonging to an OMG-approved
specification.  With the use of this prefix, the RepositoryID of a
valuetype V in module M would be

  "IDL:omg.org/M/V:1.0"

Section 1.13.8 of the IDL to Java Language Mapping Specification
(formal/99-07-53) specifies the algorithm to be used in determining the
location of a valuetype and its corresponding default factory, where
location is in the Java package sense.  If an ORB vendor follows this
algorithm, the default value factory will be assumed to be in the Java
package given by

  omg.org.M

Following the Java convention of reversing a domain name to obtain a
package hierarchy, one would expect to have implementation code in

  org.omg.M

This mismatch requires users to register default value factories, which
seems to go against the spirit of the second paragraph of section 5.4.3
of the CORBA 2.3.1 Specification (formal/99-10-07) where the term
"implicit registration" is used.

Proposed resolution:

  In the IDL to Java language mapping the omg.org prefix is reversed to
  org.omg.

Comments?

Resolution: see below
Revised Text: Add a sub-bullet to the second bullet in Section 13.8: If this is not successful and the first two components of the Java class name are "omg.org", then reverse the order of these components to be "org.omg" and repeat the above step.
Actions taken:
September 28, 2000: received issue
February 27, 2001: closed issue

Discussion:
In the IDL to Java language mapping the omg.org prefix is reversed to

  org.omg.



Comments?


Issue 3946: CompletionStatus needs to implement org.omg.CORBA.portable.IDLEntity (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Everett Anderson, )
Nature: Uncategorized Issue
Severity:
Summary:
IDL to Java specification
ptc-00-01-08
Section 1.15.2
Page 56

Problem:

CompletionStatus needs to implement org.omg.CORBA.portable.IDLEntity
since it's mapped as an enum.

IDLEntity extends java.io.Serializable, and that is crucial for
CompletionStatus since it's a member of SystemExceptions.  If it isn't
Serializable, then none of the exceptions are, either.

Solution:

OLD:
public final class CompletionStatus {

NEW:
public final class CompletionStatus 
    implements org.omg.CORBA.portable.IDLEntity {

Resolution: closed issue...editorial change
Revised Text:
Actions taken:
October 10, 2000: received issue
April 17, 2001: closed issue

Issue 3979: IDL to Java Spec Issue : need to add SystemExceptions introduced in CORBA 2 (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ram Jeyaraman, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
The mapping from IDL names to Java Class names provided in Page 1-55 Table 1-2 should include the
following exceptions (introduced in CORBA 2.4) as well.

TRANSACTION_MODE
TRANSACTION_UNAVAILABLE

Resolution: see below
Revised Text: Add the following at the end of Table 1.2 in Section 15.2 CORBA::TRANSACTION_MODE org.omg.CORBA.Transaction_Mode CORBA::TRANSACTION_UNAVAILABLE org.omg.CORBA.Transaction_Unavailable Add Source Code files for org.omg.CORBA.Transaction_Mode and org.omg.CORBA.Transaction_Unavailable, modeling them on the existing source code files for other System Exceptions.
Actions taken:
October 23, 2000: received issue
February 27, 2001: closed issue

Discussion:


Issue 3994: Valuetype unmarshalling (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
The rules for valuetype unmarshalling in section 1.13.8 of the IDL to
Java mapping spec need to be expanded.  There are two issues with the
algorithm currently described:

 1. The algorithm described is based purely on the repository ID, 
    which may either be read off the wire or passed as an argument on
    the read_value() call.  However, if the expected type is passed
    as an argument on the read_value() call, then this should be taken
    into account in the unmarshalling algorithm.
 2. In some cases, the unmarshaller does not have enough information
    to distinguish between a boxed valuetype (which is unmarshalled
    using a helper object) and a regular valuetype (which is unmarshalled
    using a value factory).  An additional step in the unmarshalling
    algorithm is needed to cover these cases.

Proposed resolution:

In section 1.13.8, add a new bullet before the existing second bullet
as follows:
• If this is not successful and an expected type clz was passed on the
read_value call, and if clz implements IDLEntity but not ValueBase, then
unmarshal the valuetype as a boxed IDL type by calling the read method
of <clz>Helper.

In section 1.13.8, add a new bullet before the existing third bullet
as follows:
• If this is not successful and the RepositoryId is a standard repository id that starts
with “IDL:”, then attempt to generate the boxed value helper class name to use by
stripping off the “IDL:” header and “:<major>.<minor>” version information
trailer, and replacing the “/”s that separate the module names with “.”s and
appending “Helper.”

In section 1.13.8, add a new bullet before the existing fourth bullet
as follows:
• If this is not successful and an expected type clz was passed on the
read_value call, and if clz does not implement IDLEntity, then use the
ValueHandler interface to read in the value (see the Java to IDL Language
Mapping document, Section 1.5.1.3, “ValueHandler,” on page 1-40).

Resolution: Incorporate the revised text and close the issue
Revised Text: In section 1.13.8, add a new bullet before the existing second bullet as follows: If this is not successful and an expected type clz was passed on the read_value call, and if clz implements IDLEntity but not ValueBase, then unmarshal the valuetype as a boxed IDL type by calling the read method of Helper. In section 1.13.8, add a new bullet before the existing third bullet as follows: If this is not successful and the RepositoryId is a standard repository id that starts with “IDL:”, then attempt to generate the boxed value helper class name to use by stripping off the “IDL:” header and “:<major>.<minor>” version information trailer, and replacing the “/”s that separate the module names with “.”s and appending “Helper.” Add a sub-bullet under the previous new bullet as follows: If this is not successful and the first two components of the Java class name are "omg.org", then reverse the order of these two components to be "org.omg" and repeat the above step. In section 1.13.8, add a new bullet before the existing fourth bullet as follows: If this is not successful and an expected type clz was passed on the read_value call, and if clz does not implement IDLEntity, then use the ValueHandler interface to read in the value (see the Java to IDL Language Mapping document, Section 1.5.1.3, “ValueHandler,” on page 1-40).
Actions taken:
October 25, 2000: received issue
May 13, 2002: closed issue

Discussion:


Issue 3995: Copying boxed valuetypes on local calls (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
n section 1.12.2 of the IDL to Java mapping spec, the second bullet
should be clarified to state that the copying it describes applies
only to non-boxed valuetypes and not to boxed valuetypes.

Valuetypes need to be copied (unlike structs, which aren't copied)
because the methods of a valuetype can modify its state and it is
not reasonable to require the callee to know whether or not calling
a valuetype method has resulted in a change to the valuetype's state.

This does not apply to boxed valuetypes, which cannot have methods.
Therefore, with respect to this copying, they should be treated like
IDL constructed types, which are not copied.

Proposed resolution:

In section 1.12.2, second bullet, change "For IDL in parameters that
are valuetypes" to "For IDL in parameters that are non-boxed valuetypes:"

In section 1.12.2, second bullet, change "With the exception of value
types" to "With the exception of non-boxed value types".

In section 1.12.2, add new third bullet:
• For IDL in parameters that are boxed valuetypes:
• Java objects passed for boxed valuetype IDL in parameters are created and owned
by the caller. The callee must not modify boxed valuetype in parameters or retain
a reference to the in parameter beyond the duration of the call. Violation of
these rules can result in unpredictable behavior.

In section 1.21.5.1, second paragraph, change "the stub copies all
valuetypes" to "the stub copies all non-boxed valuetypes".

Resolution: close no change
Revised Text:
Actions taken:
October 25, 2000: received issue
April 28, 2003: closed issue

Discussion:
As was noted in the discussion 2 years ago on this issue, the situation is not quite as simple as the issue originally supposed. For IDL, copying comes done to the following simple idea: 

- If the only way that an IDL entity can be modified is by an explicit write accessor method of some sort, or the object is immutable, no copy is required. 
- If an IDL entity can have methods with unpredictable side effects on the state of the entity, it must be copied when marshalled. 
In addition, all aliasing must be preserved, both within a single value, and between different arguments to the same invocation. In situations where a boxed value type can indirectly reference a value that is passed in the same call in a different argument, the boxed value type must be copied so that it refers to the same copy of the value that is used elsewhere in the call. 

However, I am not sure that this is the only problem here. Simon makes reference to the idea that any type that refers to a non-boxed valuetype must be copied when passed as an in parameter, so for example a struct S containing a reference to a valuetype V must also be copied. But this directly directly contradicts the first bullet in section 1.12.2, which implies that non-valuetypes (like S) are not copied. Clearly if an instance s1 of S that refers to an instance v1 of V is created, and s1 and v1 are both passed in the same call, we would expect that sharing would be preserved. But that would require copying s1. 

Given this problem, which is independent of whether we are considering boxed valuetypes or not, and the fact that no one has worked on this issue for over 2 years, I would like to close this issue in the current RTF. I would rather see an issue created to deal with defects in the copying of parameters than just address the narrow boxed valuetype question. 



Issue 4009: Union exceptions (java-rtf)

Click
here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:
Given a union such as:

	union u switch (long) {
	case 2:
	case 3:
	case 4:
		string string_member;
	case 5:
		double double_member;
	};

I get a modifier

	public void string_member(int d, string v);

What should happen if I call string_member(99, "hello")?

Clearly, this is meaningless, but the spec doesn't say what should happen.
I would suggest to throw BAD_PARAM.

					

Resolution: see below
Revised Text: In section 1.9, for the paragraph that begins "If there is more than one case label corresponding to a branch, ...", add to the end of the paragraph: The extra modifier method should throw a BAD_PARAM exception with a minor code of XXX when a value is passed for the discriminator that is not among the case labels for the branch. In section 1.9, for the paragraph that begins "If the branch corresponds to the default case label,...", add to the end of the paragraph: The extra modifier method should throw a BAD_PARAM exception with a minor code of XXX when a value is passed for the discriminator that is not among the case labels for the default branch.
Actions taken:
October 31, 2000: received issue
May 13, 2002: closed issue

Issue 4010: Should valuetype helper insert/extract make copies? (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
The adopted resolution for issue 2531 has clarified that the Any.insert_Value
and Any.extract_Value methods don't make copies of the Serializable parameter
passed to insert_Value.  Should the same be true for the valuetype helper's
insert and extract methods?  The IDL to Java mapping spec does not say
anything about the copying semantics of helper insert and extract methods.

Resolution: Incorporate change and close issue
Revised Text: Add the following sentence at the end of the first paragraph of section 1.5.2: "The Any insert and extract operations for Valuetype helper classes do not copy their arguments: they implement reference semantics just like Any.insert_Value and Any.extract_Value."
Actions taken:
November 1, 2000: received issue
April 28, 2003: closed issue

Issue 4013: Usage of ExceptionDetailMessage service context (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
The interop RTF resolved issue 3405 by adding a new service context called
ExceptionDetailMessage.  The usage of this service context was
left to language mappings to define.  We need to define this usage for Java.

Writing the service context:

There are a few possibilities that come to mind:
 1) The result of calling getMessage() on the exception.
 2) The result of calling toString() on the exception.
 3) The result of calling printStackTrace(PrintWriter) on the exception.

I'm inclined to think that option 3 is best, since the callee's stack trace
is often very valuable debugging information.

Reading the service context:

The wstring from the service context should become the Java error message
in the unmarshalled exception object.

Resolution: issue has been resolved, see ptc/01-10-20
Revised Text:
Actions taken:
November 1, 2000: received issue
April 18, 2002: closed issue

Issue 4057: Displaying SystemExceptions (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
The definition of org.omg.CORBA.SystemException in section 1.15.2 of the
IDL to Java mapping spec has no code to format and display system exceptions
in string form.  It would be useful to display the minor code as a hexadecimal
number and the completion status as a string.

The current implementation in the JDK contains a toString() method that
displays the minor code as a decimal number and the completion status as a
string.  Displaying the minor code as a decimal number is a readability issue
for both OMG standard minor codes and vendor-specific minor codes.  For example,
the OMG standard minor code 0x4f4d0001 would be formatted as 1330446337 and a 
vendor proprietary minor code 0xc9c25401 would be formatted as 3384955905
(or -910011391 if using signed 32-bit arithmetic).  Displaying the minor code
in hexadecimal form solves this problem.

Proposed resolution:

Add the following implementation of org.omg.CORBA.SystemException.toString()
to section 1.15.2 of the IDL to Java mapping spec and to the zip file:

public String toString() {

    String completedString;
    String superString = super.toString();
    String minorString = "  minor code: 0x" + Integer.toHexString(minor).toUpperCase();     
    switch (completed.value()) {
    case CompletionStatus._COMPLETED_YES:
        completedString = "  completed: Yes";
        break;
    case CompletionStatus._COMPLETED_NO:
        completedString = "  completed: No";
        break;
    case CompletionStatus._COMPLETED_MAYBE:
    default:
        completedString = " completed: Maybe";
        break;
    }
    return superString + minorString + completedString;
}

Resolution: Incorporate change and close issue
Revised Text: In section 1.19.10: - Add the following to the end of the pseudo interface ORB declaration: String exception_to_string( in SystemException exc ) ; - Add the following to the end of the org.omg.CORBA.ORB abstract class: public String exception_to_string( SystemException exc ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } - Add the following after the end of the org.omg.CORBA_2_5.ORB abstract class: package org.omg.CORBA_3_0 ; public abstract class ORB extends org.omg.CORBA_2_5.ORB { public String exception_to_string( SystemException exc ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } } - Add new section 1.19.10.3: exception_to_string The exception_to_string method produces a human readable description of a system exception. This may include translations of known VMCIDs into readable vendor identification strings, decoding of the minor code into a hexidecimal form, and any other information that an implementation finds useful. The description should include the exception type and the completion status. Information about chained exceptions should also be included on Java platforms that support exception chaining
Actions taken:
November 16, 2000: received issue
December 11, 2002: closed issue

Issue 4059: When to honor the servant delegate in POA? (java-rtf)

Click
here for this issue's archive.
Source: Borland Software Corporation (Mr. Vishy Kasar, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Java language mapping gives the user ability to set the delegate on a
servant through:

abstract public class Servant {
  public void _set_delegate(org.omg.PortableServer.portable.Delegate
delegate) {
    _delegate = delegate;
  }
}

POA implementation must also set this delegate in many instances where
user provides POA with a servant.  activate_object, set_servant etc. In
normal cases user does not set any delegate of his own. In special cases
user may set his delegate on a servant before passing the servant to
POA.

There are also cases where user written servant manager may return the
same servant over and over again.

It is unclear from the language spec if POA is supposed to honor the
already set delegate or set its own Delegate no matter what. It seems
beneficial to me to look at the existing servant to see if this already
has a Delegate and set it only if it has none. Comments? If that is a
good idea shall we change the language spec to state that explicitly? If
we do not state this explicitly, user code may behave differently when
moved from one ORB implementation to the other.

Resolution: see above
Revised Text:
Actions taken:
November 17, 2000: received issue
May 13, 2002: closed issue

Discussion:
No change is really needed here, since the spec indicates when the delegate should be set (see 1.20.2.2). It is also stated that a Servant can only be associated with one ORB at a time. So, the clear interpretation is that the explicit set of operations sets the Servant delegate, regardless of how it is set. Close no change.


Issue 4064: Any extract operations for tk_abstract_interface (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
It is not clear from the IDL to Java language mapping spec whether a 
valuetype or object reference can be inserted into an "any" whose TypeCode is 
tk_abstract_interface.  Neither is it clear whether a valuetype or object
reference that has been passed across the wire inside an "any" with a 
tk_abstract_interface TypeCode can be extracted using the normal extract
operations for valuetype or object reference.

Proposed resolution:

Add the following text to section 1.16:

An object reference can be inserted into an "any" that has a matching tk_objref
TypeCode.  If the object reference inherits from an abstract interface, then 
it can also be inserted into an "any" that has a matching tk_abstract_interface
TypeCode.  A nil object reference can be inserted into any "any" that has
a tk_objref or tk_abstract_interface TypeCode.

A valuetype can be inserted into an "any" that has a matching tk_value or
tk_value_box TypeCode.  If the valuetype supports an abstract interface, then
it can also be inserted into an "any" that has a matching tk_abstract_interface
TypeCode.  A null valuetype can be inserted into any "any" that has a tk_value,
tk_value_box, or tk_abstract_interface TypeCode.

The extract_Object operation can be used to extract an object reference
(including a nil object reference) from an "any" that has a TypeCode of tk_objref.
It can also be used to extract an object reference (including a nil object
reference) from an "any" that has a TypeCode of tk_abstract_interface and a
boolean discriminator of true.

The extract_Value operation can be used to extract a valuetype (including a
null valuetype) from an "any" that has a TypeCode of tk_value or tk_value_box.
It can also be used to extract a valuetype (including a null valuetype) from
an "any" that has a TypeCode of tk_abstract_interface and a boolean discriminator
of false.

Resolution: Incorporate changes from Simon's proposal and close issue
Revised Text: Add the following text to section 1.16 after the paragraph that begins "The insert and extract methods for Serializables...": An object reference can be inserted into an "any" that has a matching tk_objref TypeCode. If the object reference inherits from an abstract interface, then it can also be inserted into an "any" that has a matching tk_abstract_interface TypeCode. A nil object reference can be inserted into any "any" that has a tk_objref or tk_abstract_interface TypeCode. A valuetype can be inserted into an "any" that has a matching tk_value or tk_value_box TypeCode. If the valuetype supports an abstract interface, then it can also be inserted into an "any" that has a matching tk_abstract_interface TypeCode. A null valuetype can be inserted into any "any" that has a tk_value, tk_value_box, or tk_abstract_interface TypeCode. The extract_Object operation can be used to extract an object reference (including a nil object reference) from an "any" that has a TypeCode of tk_objref. It can also be used to extract an object reference (including a nil object reference) from an "any" that has a TypeCode of tk_abstract_interface and a boolean discriminator of true. The extract_Value operation can be used to extract a valuetype (including a null valuetype) from an "any" that has a TypeCode of tk_value or tk_value_box. It can also be used to extract a valuetype (including a null valuetype) from an "any" that has a TypeCode of tk_abstract_interface and a boolean discriminator of false.
Actions taken:
November 18, 2000: received issue
May 13, 2002: closed issue

Issue 4076: System Exceptions REBIND, TIMEOUT, BAD_QOS (java-rtf)

Click
here for this issue's archive.
Source: Improv Technologies (Dr. Mary Leland, )
Nature: Uncategorized Issue
Severity:
Summary:
The mapping from IDL names to Java Class names provided in Page 1-56 Table 
1-2 should include the following exceptions.

REBIND, TIMEOUT, BAD_QOS

Proposed Resolution:

Add the following at the end of Table 1.2 in Section 15.2
CORBA::REBIND	org.omg.CORBA.REBIND
CORBA::TIMEOUT	org.omg.CORBA.TIMEOUT
CORBA::BAD_QOS	org.omg.CORBA.BAD_QOS

Add Source Code files for these, modeling them on the
existing source code files for other System Exceptions.

Resolution: Incorporate the revised text and source code changes and close the issue
Revised Text: Add the following at the end of Table 1.2 in section 15.2: CORBA::REBIND org.omg.CORBA.REBIND CORBA::TIMEOUT org.omg.CORBA.TIMEOUT CORBA::BAD_QOS org.omg.CORBA.BAD_QOS Add source code for these system exceptions modelled on the standard system exception pattern in the omg.zip archive.
Actions taken:
November 22, 2000: received issue
May 13, 2002: closed issue

Issue 4158: publication of messaging / unchecked_narrow (java-rtf)

Click
here for this issue's archive.
Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com)
Nature: Uncategorized Issue
Severity:
Summary:
Incorporate Messaging changes relevant to the Java mapping, as shown in
orbos/98-05-05 pages 115 and 116 together with any changes made to them
by the Messaging RTF, into the IDL-Java mapping chapter.

Resolution: see below
Revised Text: Replace 1.5.2 second paragraph with: The helper class for a mapped IDL interface or abstract interface also has narrow and unchecked_narrow operation(s) define in the template below. In section 1.5.2, in the generated java helper code: For each narrow method, add an identical unchecked_narrow method with the same parameters are the narrow method. In section 1.12.1, add the following paragraph after the fourth paragraph: The helper class holds a static unchecked_narrow method that allows an org.omg.CORBA.Object to be narrowed to the object reference of a more specific type. No type-checking is performed to verify that the object actually supports the requested type. The IDL exception CORBA::BAD_OPERATION can be expected if unsupported operations are invoked on the new returned reference, but no failure is expected at the time of the unchecked_narrow.
Actions taken:
January 19, 2001: received issue
May 13, 2002: closed issue

Issue 4271: IDL/Java issue, Mapping for IDL enum (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
an earlier issue (#1752) described the problem that the singleton 
assumption for Java enum objects does not hold if these Java
objects are serialized, i.e. stored in a file.

The issue was closed without any comments, it seems 
(http://cgi.omg.org/issues/issue1752.txt.) However, the problem 
remains and is aggravated by the fact that in the more recent documents
mappend Java enum classes are required to transitively implement 
java.io.Serializable! This means that the "singleton assumption" 
is broken as soon as an enum object is read in from a file, and
equality tests fail, e.g. in generated code of unions that have
enum switch types!

I would thus ask for the same thing as Bruce Schuchardt did back 
then (quoted from the original mail for issue #1752):

> Please consider revising the mapping of enums to require generation
> of equality and hash methods that are class and value based.
> Application developers should then be advised to use equals() 
> when comparing enum objects.

This is the only way to reconcile enums with Java serialization! 

Regards, Gerald Brose.

Resolution: Incorporate the revised text and close issue
Revised Text: In section 1.7, first paragraph: replace with An IDL enum is mapped to a Java class which implements IDLEntity with the same name as the enum type which declares a value method, two static data members per label, an integer conversion method, a protected constructor, and a readResolve method as follows: In section 1.7, add to the end of public class : Object readResolve() throws java.io.ObjectStreamException { ... } In section 1.7, add to the end of the paragraph that begins "There shall be only one instance of an enum.": Note that it is necessary to supply a readResolve method to enforce uniqueness of enum elements, as otherwise serialization followed by deserialization will create a new element. In section 1.7.1, add to the end of public class EnumType: Object readResolve() throws java.io.ObjectStreamException { return from_int( value() ) ; }
Actions taken:
April 14, 2001: received issue
May 13, 2002: closed issue

Discussion:
issue related to issue 1752 (which has been closed)


Issue 4286: Clarification of serialization of Anys and Typecodes (java-rtf)

Click
here for this issue's archive.
Source: IONA (Mr. John Cosgrove, )
Nature: Clarification
Severity:
Summary:
I have a request for clarification of the IDL to Java language mapping
concerning the serialization of Anys and Typecodes. Both classes implement
IDLEntity and so would be expected to be serializable. Is this the intention
of the mapping?

I would also expect that TCKind should also implement IDLEntity and have a
readResolve() method as suggested in the recent discussions of Issue 1752
revising the mapping for enums. Is this correct?

Resolution: see below
Revised Text: Incoporate revised text for section 1.4.1.3, Fix the incorrect java code in section 1.19.9, update the OMG.zip file (including adding the missing TCKindHelper and TCKindHolder classes), and close the issue. Revised Text: Add the following bullet to the end of the bullet list in section 1.4.1.3: - Any class that implements IDLEntity
Actions taken:
April 26, 2001: received issue
May 13, 2002: closed issue

Discussion:
Any class that implements IDLEntity must be serializable. However, the spec does not explicitly say this. It should be updated in section 1.4.1.3 to clarify this.

The resolution to issue 4271 adds a readResolve method to all enum classes. Looking at the current spec, TCKind is defined to be an enum. but the java code in the spec does not include IDLEntity. 


Issue 4323: local interface mapping underspecified (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Harold Carr, Ph.D., nobody)
Nature: Uncategorized Issue
Severity:
Summary:
The IDL-to-Java ptc/00-11-03 specification says that an implementation
of a local interface would extend org.omg.CORBA.LocalObject instead of
org.omg.CORBA.Object.  This is underspecified.  It does not say
anything about the generated classes for a local interface, their
relationships, nor which one should be implemented by an
implementation.  This MUST be specified for local interface
implementations to be portable.

I suggest for local interface X the following generated classes:

    interface X extends XOperations, org.omg.CORBA.Object

This is similar to a non-local mapping except that it does not extend
org.omg.CORBA.portable.IDLEntity.  Although that would not hurt
anything it is not necessary since a local interface cannot be
marshaled.

I suggest the following specification for implementations of local interfaces:

    class XImpl
        extends org.omg.CORBA.LocalObject 
        implements X

An instance would be create using the usual language construct:

    XImpl x = new XImpl(...);


The above must be specified just like the current spec says what to do
with a POA-based implementation of a non-local interface, e.g.,:

    class YImpl extends YPOA

Resolution: see below
Revised Text: In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local Interfaces", on page 1-29: ------------------------- BEGIN EXISTING TEXT Local Interfaces An IDL local interface is mapped in a fashion similar to that of a non-local interface. However because it may not be marshaled the implementation extends a special base interface, org.omg.CORBA.LocalObject, (see Section 1.20.2.1, "Mapping for Local Interface", on page 1-88) instead of org.omg.CORBA.Object. Issue Does it extend org.omg.CORBA.portable.IDLEntity since it can't be marshaled? Issue The CCM submission did not precisely define whether local interfaces have signature and operation interfaces. This assumes that theydo. A holder class is generated as for non-local interfaces. A helper class is also generated according to the normal rules, see Section 1.5, "Helpers," on page 1-13. ORB implementations shall detect attempts to marshal local objects and throw a CORBA::MARSHAL exception. Issue An example for local interface should be added. END EXISTING TEXT ------------------------- with: BEGIN REPLACEMENT TEXT Local Interfaces A new interface in org.omg.CORBA called LocalInterface is defined as: public interface LocalInterface extends org.omg.CORBA.Object { } A local interface <typename> is mapped to the the following java classes: interface <typename> extends <typename>Operations, org.omg.CORBA.LocalInterface, org.omg.CORBA.portable.IDLEntity where interface <typename> and <typename>Operations are identical to the mapping for a non-local interface. An implementation of <typename> may then be specified as: class <typename>Impl extends org.omg.CORBA.LocalObject implements <typename> and an instance would be created using the usual Java language construct: <typename>Impl ti = new <typename>Impl(...); A holder class is generated as for non-local interfaces. A helper class is also generated according to the normal rules, see Section 1.5, "Helpers," on page 1-13. ORB implementations shall detect attempts to marshal local objects and throw a CORBA::MARSHAL exception. Issue An example for local interface should be added. END REPLACEMENT TEXT
Actions taken:
May 25, 2001: received issue
October 3, 2001: closed issue

Issue 4549: Missing elements of the local mapping (java-rtf)

Click
here for this issue's archive.
Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, nobody)
Nature: Uncategorized Issue
Severity: Critical
Summary:
In the latest spec of the idl-to-java mapping, I don't see a mapping for
create_local_interface_tc() on the ORB. Also missing is
tk_local_interface in TCKind. These need to be fixed quickly as this
leaves the local mapping incomplete in Java.

Proposal:

Section 1.19.9:

Add tk_local_interface to TCKind
enum TCKind {
tk_null, tk_void,
tk_short, tk_long, tk_ushort, tk_ulong,
tk_float, tk_double, tk_boolean, tk_char,
tk_octet, tk_any, tk_TypeCode, tk_Principal, tk_objref,
tk_struct, tk_union, tk_enum, tk_string,
tk_sequence, tk_array, tk_alias, tk_except,
tk_longlong, tk_ulonglong, tk_longdouble,
tk_wchar, tk_wstring, tk_fixed,
tk_value, tk_value_box,
tk_native,
tk_abstract_interface,
tk_local_interface
};


// java (add at the appropriate location)

public static final int _tk_local_interface = 33;
TCKind tk_local_interface = new TCKind(_tk_local_interface);

Section 1.19.10
Copy the new ORB PIDL from CORBA 2.4 spec (which basically adds)

TypeCode create_local_interface_tc(
in RepositoryId id,
in Identifier name
);

and add to the Java section:

package org.omg.CORBA_2_4;
import org.omg.CORBA.TypeCode;
public abstract class ORB extends org.omg.CORBA_2_3.ORB {
   public abstract TypeCode create_local_interface_tc(String id, String
name);
}

Resolution: Incorporate the revised text and close issue. Also make corresponding changes in the standard source
Revised Text: In section 1.19.9: Add tk_local_interface to TCKind enum as follows: enum TCKind { tk_null, tk_void, tk_short, tk_long, tk_ushort, tk_ulong, tk_float, tk_double, tk_boolean, tk_char, tk_octet, tk_any, tk_TypeCode, tk_Principal, tk_objref, tk_struct, tk_union, tk_enum, tk_string, tk_sequence, tk_array, tk_alias, tk_except, tk_longlong, tk_ulonglong, tk_longdouble, tk_wchar, tk_wstring, tk_fixed, tk_value, tk_value_box, tk_native, tk_abstract_interface, tk_local_interface } ; Then near the end of the TCKind Java declaration add (after the definition of tk_abstract_interface): public static final int _tk_local_interface = 33 ; TCKind tk_local_interface = new TCKind( _tk_local_interface ) ; In section 1.19.10, update the ORB PIDL from CORBA 2.5, which adds: TypeCode create_local_interface_tc( in RepositoryId id, in Identifier name ) In section 1.19.10, in the Java section, add to org.omg.CORBA.ORB the new method public TypeCode create_local_interface_tc( String id, String name ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } Note: We do not need to create another version of the org.omg.CORBA package for this, for the following reasons: The new preferred classes mechanism allows vendors to substitute a newer standard version of APIs in packages under org.omg into their JDK implementation. Even without 1, we can evolve classes across major releases of the JDK by adding new methods. Ultimately we could consider moving the CORBA_2_3 methods into the CORBA base classes and deprecating the CORBA_2_3 classes.
Actions taken:
August 30, 2001: received issue
May 13, 2002: closed issue

Issue 4624: support for local objects (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
The CORBA spec Section 3.7.6.1 includes the following:
- The usage of client side language mappings for local types shall be
identical to
those of equivalent unconstrained types.
- Language mappings shall specify server side mechanisms, including base
classes
and/or skeletons if necessary, for implementing local objects, so that
invocation
overhead is minimized.
- Invocations on local objects are not ORB mediated. Specifically,
parameter copy
semantics are not honored, interceptors are not invoked, and the execution
context
of a local object does not have ORB service Current object contexts that
are
distinct from those of the caller.

The IDL to Java spec section Section 1.12 Mapping for Interface,
subsection Local Interfaces states that:
-  A local interface <typename> is mapped to interface <typename> which
extends <typename>Operations,  [... which an implementation can extend]
- A holder class is generated as for non-local interfaces.
- A helper class is also generated according to the normal rules, see
Section 1.5,
"Helpers", on page 1-13.
No mention is made of Stubs, Ties or skeletons.

Section 1.20.2.1 Mapping for Local Interface states:
In the Java language mapping, the LocalObject class is used as a base class
for
implementations of a local interface.

I take it from the above that, quite reasonably, since "invocations on
local objects are
not ORB mediated", skeletons/Ties are not required for Java.

I can't see why Stubs should be required either, but
Section 1.21.6.1 Stub/Skeleton Architecture states:
Stubs support both local invocation and remote invocation, except in the
following
case: The stub is implementing an IDL interface that may only be invoked
locally (e.g.,
PortableServer::POA). In this case, the stub may choose to implement only
local
invocation.
which suggests that Stubs may be required (although the POA interface is
constrained
to be invoked locally, but not actually defined as local - is that the
difference?)

Resolution: Incorporate revised text and close issue
Revised Text: In section 1.21.6.1 "Stub/skeleton architecture", first paragraph, remove the sentence that reads: Local invocation is also required for certain IDL types, which contain parameter types that cannot be marshalled remotely. In section 1.21.6.1 "Stub/skeleton architecture", add the following as a new second paragraph: Note that neither stubs nor skeletons are required for interfaces that are defined as local. In section 1.21.6.1 "Stub/skeleton architecture", subsection "Stub Design", remove the first bullet that reads The stub is implementing an IDL interface that may only be invoked locally (e.g. PortableServer::POA). In this case, the stub may choose to implement only local invocation. and also the preceding sentence: Stubs support both local invocation and remote invocation, except in the following case: It is clear from a careful reading that there should only have been one bullet here, not three, so change the last two bullets to single paragraphs: The stub class supports either the DII or the streaming style APIs. Stubs are not required to define any constructors. However, if they do define special constructors, a constructor with no arguments must also be supplied.
Actions taken:
October 22, 2001: received issue
May 13, 2002: closed issue

Issue 4699: is_a support in Java for local interfaces (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
With the recent adoption of the resolution to issue 4623 (support
is_a on local interfaces), we need to answer the question of how 
is_a is implemented in Java.  I would like to create a new
Java RTF issue for this, and propose a solution to hopefully start
some discussion on this issue.

Proposed solution:

Change org.omg.CORBA.LocalObject to an abstract class as follows:

abstract public class LocalObject implements org.omg.CORBA.Object {

    ...

    abstract public String[] _ids() ;

    public _is_a( String repository_id) 
    {
	String[] ids = _ids() ;
	for (int i=0; i<ids.length; i++) {
	    if (repository_id.equals( ids[i] )
		return true ;
	}

	return false ;
    }
}

Then the IDL compiler generates a local implementation base class as follows:

class <typename>LocalBase extends org.omg.CORBA.LocalObject 
	implements <typename> {

	private String[] _type_ids() = { ... }
	
	public String[] _ids() 
	{
		return _type_ids.clone() ;
	}
}

where _type_ids contains a list of repository IDs of the local
interface and all of its superinterfaces in order from most derived
to org.omg.CORBA.Object.


The implementer of a local interface then simply writes

class MyImpl extends <typename>LocalBase {

	// implement the declared methods
}

and instantiates the local interface by calling

new MyImpl( ... ).

Note: a full proposed resolution to this issue should include a static
delegate for LocalObject, so that the implementation of _is_a and any
other non-trivial methods can be made pluggable in the JDK.  I will raise
another issue for get_interface_def after we have an issue number for
this issue.

Resolution: Incorporate the revised text, make corresponding changes in the standard source files, close
Revised Text: In section 1.12.1, replace the local interfaces sub-section with: A new interface in org.omg.CORBA called LocalInterface is defined as: public interface LocalInterface extends org.omg.CORBA.Object {} A local interface <typename> is mapped to the following Java classes: public interface <typename> extends <typename>Operations, org.omg.CORBA.LocalInterface, org.omg.CORBA.portable.IDLEntity where interface <typename> and interface <typename>Operations are identical to the mapping for a non-local interface, except for the inheritance relationship of interface <typename>. In order to support _is_a, it is necessary to have information about the repository_ids of all super-interfaces of the local interface. This requires generating a base class that is used for implementations of local interfaces. This base class must satisfy the following requirements: The base class is a public abstract class named _<typename>LocalBase. It must define the _ids() method, which is an abstract method in org.omg.CORBA.LocalObject. The list of strings returned from the _ids() method must start with the repository ID of the most derived interface. An implementation of <typename> may then be written as follows: class <typename>Impl extends <typename>LocalBase { // whatever constructors this implementation needs ... // implementation of methods defined in <typename>Operations ... } and an instance would be created using the usual Java language construct: <typename> obj = new <typename>Impl( ... ) ; A holder class is generated as for non-local interfaces. A helper class is also generated according to normal riles, see Section 1.5, "Helpers", on page 1-13. ORB implementations shall detect attempts to marshal local objects and throw a CORBA::MARSHAL exception. For example, consider the following IDL definition: local interface Test { long ping( in long arg ) ; } ; This results in the following classes: public interface Test extends TestOperations, org.omg.CORBA.LocalInterface, org.omg.CORBA.IDLEntity { } public interface TestOperations { public int ping( int arg ) ; } public abstract class _TestLocalBase extends org.omg.CORBA.LocalObject implements Test { private String[] _type_ids = { "IDL:Test:1.0" } ; public String[] _ids() { return (String[])_type_ids.clone() ; } } In section 1.20.2.1, replace the _is_a method with: public boolean _is_a( String repository_id ) { String ids[] = _ids() ; for (int i=0; i<ids.length; i++) { if (repository_id.equals( ids[i] ) return true ; } return false ; } and also add abstract public String[] _ids() ; before the _is_a method.
Actions taken:
November 12, 2001: received issue
May 13, 2002: closed issue

Issue 4701: Colocated calls in Java (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Note: this is NOT issue 3754, but it is related.  A new issue is needed
as described below:
--------------------------------------------------------------------------
Issue 3754 (colocated call optimization and portable interceptors) was
raised some time ago by Harold Carr.  This issue discusses the problems
of supporting portable interceptors for RMI-IIOP calls when the colocated
call optimization is used.  The basic issue is that there is no way for the
ORB to detect whether a local dispatch to a servant completed normally or
completed by throwing an exception.  This problem exists because the
current is_local/servant_preinvoke/servant_postinvoke mechanism has no
way to report normal or exceptional completion of a local dispatch.

The same problem arises in the IDL stub case as well.
Both Java mappings can share the same solution here, but a solution requires
changing part of the portable stub API which is shared by both mappings.

In the discussion of 3754, Simon Nash asked to reassign the issue from the 
Java to IDL RTF to the Java mapping RTF.  We really need two separate issues
here.  I propose that we do the following:

1. Move 3754 back to the Java to IDL RTF since Harold wrote the issue with the
   RMI-IIOP mapping in mind.

2. Create a new Java mapping issue for the same problem.  The bulk of this message
   should be the new issue.

Both RTFs will need to consider the issues.  The new Java mapping issue will need
to propose extensions to the portable stub APIs and document the required changes
in the IDL based stubs, while the resolution to 3754 will need to adopt the
same new portable stub API and document the required changes in the RMI-IIOP stubs.

To start a discussion, here is my initial proposal for solving this problem in
the Java mapping RTF:

We need to add methods to report the result of the local dispatch.  I propose that
we extend the portable definition of ServantObject as follows:

abstract public class ServantObjectExt extends ServantObject 
{
    abstract public void normalCompletion() ;

    abstract public void exceptionalCompletion( Throwable thr ) ;
}

Another alternative is to extend the Delegate class instead.  I prefer the
ServantObject approach because the method signatures are simpler: 
adding these methods on the Delegate would require passing ServantObject 
as an argument, since multiple threads could be simultaneously invoking 
methods on the same object reference, which would share the same delegate.

Making this change makes it necessary to consider what happens in
mixed versions.

Old stub, Old ServantObject: 
    no change

New stub, new ServantObject: 
    stub always invokes either normalCompletion or
    exceptionalCompletion, so the ORB has enough information to correctly implement
    portable interceptor behavior.  Note that a location forward (e.g. from a 
    ServantManager) is not a problem today, since it happens inside of     
    _servant_preinvoke,
    which allows the ORB to correctly handle that case.

New stub, old ServantObject: 
    If a new stub is written to do an instanceof check on
    the ServantObject it gets from _servant_preinvoke, it can correctly determine
    whether or not to call the new methods.  There are a number of possibilities
    for the check:

    1. Just use (so instanceof ServantObjectExt) and rely on the ServantObjectExt
       class to be defined somewhere in the environment.  New stubs that wanted to
       be compatible with old ORBs would need to be packaged somehow with this 
       class in their classpath.  The stubs would need the ServantObjectExt class
       both at compile time and at runtime.

    2. A stub could be written to entirely use reflection for the instanceof check
       and the method invocation.  This would avoid the requirement to have 
       ServantObjectExt in the classpath, but would require more code in the stubs,
       plus run a little slower (probably about 2X slower in JDK 1.4, but in
       earlier JDKs the penalty could easily be 10-20X).

Old stub, new ServantObject: 
    In this case, neither method is ever invoked, so the
    ORB can tell the difference between normal completion and an old stub.
    The PI implementation in this case is free to do anything.  However, probably the
    best approach is to extend RequestInfo::reply_status with a new value
    PortableInterceptor::UNKNOWN.  Then the local case would always use the
    interceptor points send_other and receive_other with a reply_status set to
    UNKNOWN.  This extension requires a new core issue.

It is worth noting here that the PI change makes it reasonable to consider simply
changing PI, and avoid changing the ServantObject API and 2 language mappings.
In this case, a user of PI cannot tell what is happening with colocated calls
in a very basic sense: did the operation complete successfully or not?
Many applications of PI (for example, transactions and security) often do not
require the use of PI in the colocated case.  However, one important application
is best done this way: logging/tracing in a complex system.  I believe this
argues strongly for extending the mapping, since a log entry that cannot distinguish
success from failure is of little use.

With the instanceof check, the local code for the sample stub then becomes 
(from page 1-114 of ptc/01-06-04):

    org.omg.CORBA.portable.ServantObject _so =
	_servant_preinvoke( "length", _opsClass ) ;
    if (_so == null)
	continue ;

    Example.AnInterfaceOperations _self = 
	(Example.AnInterfaceOperations)_so.servant ;

    try {
	int result = _self.length(s) ;
	if (so instanceof ServantObjectExt)
	    ((ServantObjectExt)so).normalCompletion() ;
	return result ;
    } catch (Throwable thr) {
	if (so instanceof ServantObjectExt)
	    ((ServantObjectExt)so).exceptionalCompletion( thr ) ;
	throw thr ;
    } finally {
	_servant_postinvoke( _so ) ;
    }
    
Note that the instanceof checks are quite fast in modern JVMs,
so I don't think this adds significantly to the overhead of the operation.
A reflective solution is also possible, but I am not including that here.
In any case, the precise code generation should be left to the implementation.
All that the spec should require is:

1. If the invocation on the servant completes without throwing an exception,
   then the stub code must call servant.normalCompletion after the invocation
   completes.
   
2. If the invocation on the servant throws exception exc, then the stub code
   must call servant.exceptionalCompletion( exc ) after the invocation completes.
   
In either case, the servant completion call must occur before the 
_servant_postinvoke call.

Resolution: Incorporate the revised text, make corresponding changes in the standard source files, close
Revised Text: In section 1.21.6.3, add the class ServantObjectExt after ServantObject as follows: abstract public class ServantObjectExt extends ServantObject { abstract public void normalCompletion() ; abstract public void exceptionalCompletion( Throwable thr ) ; } In section 1.21.6.3, add a new paragraph before the last paragraph (the last paragraph begins "The _servant_postinvoke() method is invoked..."): If the ServantObject returned by the _servant_preinvoke() call is an instance of ServantObjectExt, the local invocation code must also satisfy the following conditions: If the invocation on the servant completes without throwing an exception, then the stub code must call servant.normalCompletion after the invocation completes. If the invocation on the servant throws exception exc, then the stub code must call servant.exceptionalCompletion( exc ) after the invocation completes. In either case, the servant completion call must occur before the _servant_postinvoke call. Note that an older stub may fail to satisfy these conditions. In this case, any request interceptors that run during local invocations will be unable to correctly report the completion of the request in the PortableInterceptor::RequestInfo reply_status field. In section 1.21.6.1, sub-section "Stream-base Stub Example", replace the local optimization (the last else clause) with: org.omg.CORBA.portable.ServantObject _so = _servant_preinvoke( "length", _opsClass ) ; if (_so == null) continue ; Example.AnInterfaceOperations _self = (Example.AnInterfaceOperations)_so.servant ; try { int result = _self.length(str) ; if (_so instanceof org.omg.CORBA.portable.ServantObjectExt) ((org.omg.CORBA.portable.ServantObjectExt)_so).normalCompletion() ; return result ; } catch (Example.AnException exc) { if (_so instanceof org.omg.CORBA.portable.ServantObjectExt) ((org.omg.CORBA.portable.ServantObjectExt)_so).exceptionalCompletion( exc ) ; throw exc ; } catch (RuntimeException re) { if (_so instanceof org.omg.CORBA.portable.ServantObjectExt) ((org.omg.CORBA.portable.ServantObjectExt)_so).exceptionalCompletion( re ) ; throw re ; } catch (Error err) { if (_so instanceof org.omg.CORBA.portable.ServantObjectExt) ((org.omg.CORBA.portable.ServantObjectExt)_so).exceptionalCompletion( err ) ; throw err ; } finally { _servant_postinvoke( _so ) ; }
Actions taken:
November 12, 2001: received issue
May 13, 2002: closed issue

Issue 4710: Mapping for Character and String Types (java-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Ms. Anne E. Collins, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Sections 1.4.3 and 1.4.5 of the IDL to Java spec state that
character and string range and bounds checking should be performed
at marshal time. Since it is possible to receive IDL characters,
e.g UTF16 surrogate pairs, that cannot, at present, be mapped to
Java characters, could we clarify that this checking should be
performed at both marshaling and demarshaling time, per section
4.11.3.25 DATA_CONVERSION of the CORBA 2.5 spec which states:-
   This exception is raised if an ORB cannot convert the
   representation of data as marshaled into its native
   representation or vice-versa.

Also, could anyone please comment on the meaning of the term
"character set" in the sentence beginning "If the char falls
outside the range defined by the character set,..." in section
1.4.3. Does this refer to the TCS, NCS or both?

Resolution: Incorporate changes and close issue
Revised Text: replace old 1.4.3: IDL characters are 8-bit quantities representing elements of a character set while Java characters are 16-bit unsigned quantities representing Unicode characters. In order to enforce type-safety, the Java CORBA runtime asserts range validity of all Java chars mapped from IDL chars when parameters are marshaled during method invocation. If the char falls outside the range defined by the character set, a CORBA::DATA_CONVERSION exception shall be thrown. The IDL wchar maps to the Java primitive type char. If the wchar falls outside the range defined by the character set, a CORBA::DATA_CONVERSION exception shall be thrown. with new 1.4.3: IDL characters are 8-bit quantities representing elements of a character set while Java characters are 16-bit unsigned quantities representing Unicode characters. In order to enforce type safety, the Java CORBA runtime asserts range validity of all Java chars mapped to or from IDL chars when parameters are marshaled or unmarshaled during method invocation. Assume that a Java ORB has a particular native character set (NCS) and some transmission character set (TCS) has been negotiated for a particular object reference. The following rules apply for reporting errors in character encoding during data marshalling and unmarshalling in a method invocation on that object reference: If an attempt is made to marshal a char represented in the sending ORB's NCS which cannot be represented in the sending ORB's TCS, a CORBA::DATA_CONVERSION exception with a minor code of 1 is thrown. If an attempt is made to unmarshal a char represent in the receiving ORB's TCS that cannot be represented in the receiving ORB's NCS, a CORBA::DATA_CONVERSION exception with a minor code of TBD is thrown. Similarly, the following rules apply for reporting errors in wchar encoding during data marshalling and unmarshalling in a method invocation on that object reference: If an attempt is made to marshal a wchar represented in the sending ORB's NCS which cannot be represented in the sending ORB's TCS, a CORBA::DATA_CONVERSION exception with a minor code of 1 is thrown. If an attempt is made to unmarshal a wchar represent in the receiving ORB's TCS that cannot be represented in the receiving ORB's NCS, a CORBA::DATA_CONVERSION exception with a minor code of TBD is thrown. Replace section 1.4.5: The IDL string, both bounded and unbounded variants, are mapped to java.lang.String. Range checking for characters in the string as well as bounds checking of the string is done at marshal time. Character range violations cause a CORBA::DATA_CONVERSION exception to be raised. Bounds violations cause a CORBA::BAD_PARAM exception to be raised. The IDL wstring, both bounded and unbounded variants, are mapped to java.lang.String. Bounds checking of the string is done at marshal time. Character range violations cause a CORBA::DATA_CONVERSION exception to be raised. Bounds violations cause a CORBA:: BAD_PARAM exception to be raised. with the new section 1.4.5: The IDL string type, in both the bounded and unbounded variants, is mapped to java type java.lang.String. Range checking for characters in the string as well as bounds checking of the string is done at marshal time. Character range violations cause a CORBA::DATA_CONVERSION exception to be raised as described in section 1.4.3, "Character Types". Bounds violations cause a CORBA::BAD_PARAM exception to be raised. The IDL wstring type, in both the bounded and unbounded variants, is mapped to java type java.lang.String. Bounds checking of the string is done at marshal time. Character range violations cause a CORBA::DATA_CONVERSION exception to be raised as described in section 1.4.3, "Character Types". Bounds violations cause a CORBA:: BAD_PARAM exception to be raised.
Actions taken:
November 21, 2001: received issue
April 28, 2003: closed issue

Issue 4741: New issue on register_initial_reference (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
The portable interceptors specification added a new method to the
ORB for registering initial references.  This method needs to
be added to the standard org.omg.CORBA.ORB class.

We should simply add the register_initial_reference method to 
org.omg.CORBA.ORB and not create another version of the ORB 
class for this purpose.

Proposed Resolution: Incorporate edits and close issue

Revised Text:

In section 1.19.10
    in the PIDL section, add before resolve_initial_references:

    void register_initial_reference( in ObjectId identifier, 
	in Object obj ) raises (InvalidName) ;

    in the Java section, add before resolve_initial_references:

    public void register_initial_reference( String id, 
        org.omg.CORBA.Object obj ) throws InvalidName ;
	
Also update the org.omg.CORBA.ORB class in the omg.zip file.

Resolution: Incorporate joint resolution changes and close issue
Revised Text: In section 1.19.10, add the following to the pseudo interface ORB: After the list_initial_services declaration: void register_initial_reference( in ObjectId id, in Object obj ) raises (InvalidName) ; After the create_abstract_interface_tc declaration: TypeCode create_local_interface_tc( in RepositoryId id, in Identifier name ) ; After the typedef for ObjectIdList: ORBId id() ; In section 1.19.10, delete the paragraph that begins "All types defined in this chapter are either part of the CORBA or ...". All of the IDL level definitions are in the pseudo interface ORB, which has nothing to do with Java packages. In section 1.19.10, add the following to the Java abstract class org.omg.CORBA.ORB: After the list_initial_services method: public void register_initial_reference( String object_name, org.omg.CORBA.Object object ) throws org.omg.CORBA.ORBPackage.InvalidName { throw new org.omg.CORBA.NO_IMPLEMENT() ; } After the create_abstract_interface_tc method: public TypeCode create_local_interface_tc( String id, String name ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } Also, fix the implementation of the create_abstract_interface_tc method to throw new org.omg.CORBA.NO_IMPLEMENT (it was missing the new). At the beginning, add: public String id() { throw new org.omg.CORBA.NO_IMPLEMENT() ; } At the end, add: public org.omg.CORBA.Object get_value_def( String repid ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public org.omg.CORBA.portable.ValueFactory register_value_factory( String id, org.omg.CORBA.portable.ValueFactory factory ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public void unregister_value_factory( String id ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public org.omg.CORBA.portable.ValueFactory lookup_value_factory( String id ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public void set_delegate( java.lang.Object wrapper ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } In section 1.19.10, add the following Java definition to the very end: package org.omg.CORBA_2_5 ; public abstract class ORB extends org.omg.CORBA_2_3.ORB { public String id() { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public void register_initial_reference( String object_name, org.omg.CORBA.Object object ) throws org.omg.CORBA.ORBPackage.InvalidName { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public TypeCode create_local_interface_tc( String id, String name ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } }
Actions taken:
December 7, 2001: received issue
May 13, 2002: closed issue

Issue 4748: Naming issues for new ORB methods (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
As we all know, naming things is the hardest part.
I am writing this as a general reply to the concerns that Simon Nash,
Ann Dalton, and Franz Hauck have raised about packaging of new APIs.
This is also relevant to the discussion Simon and I had about a
relevant JCK rule (I'm still waiting on details from the JCK team at
Sun on that one).

I want to focus on just the ORB methods here, which seems to be the
major problem, although the same ideas should apply elsewhere.

The APIs that we are talking about are:

New in CORBA_2_5.ORB (which extends CORBA_2_3.ORB) :
    ORB.id
    ORB.create_local_interface_tc
    ORB.register_initial_references

In CORBA_2_3.ORB:
    ORB.register_value_factory
    ORB.unregister_value_factory
    ORB.lookup_value_factory
    ORB.get_value_def
    ORB.set_delegate

This affects the following issues:
    4741 (register_initial_reference)
    4559 (create_local_interface_tc)
    moving CORBA_2_3 APIs into CORBA (I have not yet filed this)
    4699 (is_a support on local interfaces)
    need support for ORB::id (no issue for this yet)

(4699 does not involved ORB methods, but it's the same issue, because
vendors have shipped PI implementations before is_a support became
necessary on local interfaces).

Here are the goals I would like to achieve:

    1. Add new methods to the CORBA ORB so that users have a better API.

    2. Make CORBA_2_3::ORB methods available in CORBA::ORB.

    3. Still support user code using the CORBA_2_3::ORB methods.

    4. Allow JDK 1.3 licensees to implement the new features legally.

    5. Allow CORBA 2.3 ORB implementations to work unchanged with the
       CORBA 2.5 APIs.

Proposal:

    1. Add all the CORBA 2.5 methods to CORBA.ORB as concrete methods that 
       throw NO_IMPLEMENT.

    2. Also add all the new methods to CORBA_2_5.ORB as concrete methods 
       that throw NO_IMPLEMENT.

    3. Copy all of the CORBA_2_3 methods to CORBA.ORB (all of which are
       currently concrete methods that throw NO_IMPLEMENT).

To evaluate my proposal, let's consider the different combinations of
JDK and CORBA versions:

    - JDK: 
	1.3: No endorsed classes mechanism, CORBA 2.3 ORB 
	1.4: Endorsed classes mechanism, CORBA 2.3 ORB 
	1.5: Endorsed classes mechanism, CORBA 2.5 ORB

    - CORBA:
	2.3: the current standard in JDK 1.3, and also ptc/01-10-20
	2.5: the next version, probably aligned with the CORBA 3.0(?)
	     standards

Results:

CORBA 2.5 on JDK 1.5:
    This is what Sun will ship in JDK 1.5.
    Other vendors can use the files in JDK 1.5, or replace with a
	later version if desired.
    User writes new code to CORBA.ORB.
    User code written to CORBA_2_3.ORB and CORBA_2_5.ORB still works.

CORBA 2.5 on JDK 1.4:
    Vendor swaps in CORBA 2.5 files.
    User writes new code to CORBA.ORB.
    User code written to CORBA_2_3.ORB CORBA_2_5.ORB still works.

CORBA 2.5 on JDK 1.3:
    Vendor adds new CORBA_2_5 package.  CORBA.ORB is unchanged.
    User codes to CORBA_2_5.ORB
    User code written to CORBA_2_3.ORB still works.

CORBA 2.3 on JDK 1.5:
    Vendor ORB works unchanged: new 2.5 features are not supported.

CORBA 2.3 on JDK 1.4:
    This is what Sun ships in JDK 1.4.
    Vendor ORB works unchanged.
    User code works unchanged.

CORBA 2.3 on JDK 1.3:
    This is the baseline that everyone has

Resolution: Incorporate joint resolution changes and close issue
Revised Text: In section 1.19.10, add the following to the pseudo interface ORB: After the list_initial_services declaration: void register_initial_reference( in ObjectId id, in Object obj ) raises (InvalidName) ; After the create_abstract_interface_tc declaration: TypeCode create_local_interface_tc( in RepositoryId id, in Identifier name ) ; After the typedef for ObjectIdList: ORBId id() ; In section 1.19.10, delete the paragraph that begins "All types defined in this chapter are either part of the CORBA or ...". All of the IDL level definitions are in the pseudo interface ORB, which has nothing to do with Java packages. In section 1.19.10, add the following to the Java abstract class org.omg.CORBA.ORB: After the list_initial_services method: public void register_initial_reference( String object_name, org.omg.CORBA.Object object ) throws org.omg.CORBA.ORBPackage.InvalidName { throw new org.omg.CORBA.NO_IMPLEMENT() ; } After the create_abstract_interface_tc method: public TypeCode create_local_interface_tc( String id, String name ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } Also, fix the implementation of the create_abstract_interface_tc method to throw new org.omg.CORBA.NO_IMPLEMENT (it was missing the new). At the beginning, add: public String id() { throw new org.omg.CORBA.NO_IMPLEMENT() ; } At the end, add: public org.omg.CORBA.Object get_value_def( String repid ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public org.omg.CORBA.portable.ValueFactory register_value_factory( String id, org.omg.CORBA.portable.ValueFactory factory ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public void unregister_value_factory( String id ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public org.omg.CORBA.portable.ValueFactory lookup_value_factory( String id ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public void set_delegate( java.lang.Object wrapper ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } In section 1.19.10, add the following Java definition to the very end: package org.omg.CORBA_2_5 ; public abstract class ORB extends org.omg.CORBA_2_3.ORB { public String id() { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public void register_initial_reference( String object_name, org.omg.CORBA.Object object ) throws org.omg.CORBA.ORBPackage.InvalidName { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public TypeCode create_local_interface_tc( String id, String name ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } }
Actions taken:
December 14, 2001: received issue
May 13, 2002: closed issue

Issue 4749: New issue: Error in resolution of issue 4699 (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
The resolution to issue 4699 introduced a new method in 
org.omg.CORBA.LocalObject as follows:

	abstract public String[] _ids() ;
	
Unfortunately this causes a big problem for current users of 
portable interceptors: any user of PI who implements a local
interface (for example ServerRequestInterceptor) according to the
CORBA 2.5 spec will have written code that will not function correctly
under the CORBA 3.0 revision, due to the addition of this new abstract 
method.

The fix for this is simple: just change the _ids method to

	public String[] _ids()
	{
		return new String[0] ;
	}
	
This causes the _is_a method to always return false for old implementations
of local interfaces, which is a reasonable result, since old implementations
were written before is_a support was available.

Resolution: Incorporate revised text and closed issue
Revised Text: Note: this is the resolution from Vote 2. I have highlighted the modification for issue 4749 like this. In section 1.12.1, replace the local interfaces sub-section with: A new interface in org.omg.CORBA called LocalInterface is defined as: public interface LocalInterface extends org.omg.CORBA.Object {} A local interface <typename> is mapped to the following Java classes: public interface <typename> extends <typename>Operations, org.omg.CORBA.LocalInterface, org.omg.CORBA.portable.IDLEntity where interface <typename> and interface <typename>Operations are identical to the mapping for a non-local interface, except for the inheritance relationship of interface <typename>. In order to support _is_a, it is necessary to have information about the repository_ids of all super-interfaces of the local interface. This requires generating a base class that is used for implementations of local interfaces. This base class must satisfy the following requirements: The base class is a public abstract class named _<typename>LocalBase. It must define the _ids() method, which is an abstract method in org.omg.CORBA.LocalObject. The list of strings returned from the _ids() method must start with the repository ID of the most derived interface. An implementation of <typename> may then be written as follows: class <typename>Impl extends <typename>LocalBase { // whatever constructors this implementation needs ... // implementation of methods defined in <typename>Operations ... } and an instance would be created using the usual Java language construct: <typename> obj = new <typename>Impl( ... ) ; A holder class is generated as for non-local interfaces. A helper class is also generated according to normal riles, see Section 1.5, "Helpers", on page 1-13. ORB implementations shall detect attempts to marshal local objects and throw a CORBA::MARSHAL exception. For example, consider the following IDL definition: local interface Test { long ping( in long arg ) ; } ; This results in the following classes: public interface Test extends TestOperations, org.omg.CORBA.LocalInterface, org.omg.CORBA.IDLEntity { } public interface TestOperations { public int ping( int arg ) ; } public abstract class _TestLocalBase extends org.omg.CORBA.LocalObject implements Test { private String[] _type_ids = { "IDL:Test:1.0" } ; public String[] _ids() { return (String[])_type_ids.clone() ; } } In section 1.20.2.1, replace the _is_a method with: public boolean _is_a( String repository_id ) { String ids[] = _ids() ; for (int i=0; i<ids.length; i++) { if (repository_id.equals( ids[i] ) return true ; } return false ; } and also add public String[] _ids() { throw new org.omg.CORBA.NO_IMPLEMENT() ; } before the _is_a method.
Actions taken:
December 14, 2001: received issue
May 13, 2002: closed issue

Issue 4750: Make CORBA_2_3.ORB methods available in CORBA.ORB (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
It would be much better for CORBA users if the methods are currently 
in org.omg.CORBA_2_3.ORB were available in the org.omg.CORBA.ORB class.
The best approach seems to be simply to copy the method definitions
into the ORB class.

Resolution: Incorporate joint resolution changes and close issue
Revised Text: In section 1.19.10, add the following to the pseudo interface ORB: After the list_initial_services declaration: void register_initial_reference( in ObjectId id, in Object obj ) raises (InvalidName) ; After the create_abstract_interface_tc declaration: TypeCode create_local_interface_tc( in RepositoryId id, in Identifier name ) ; After the typedef for ObjectIdList: ORBId id() ; In section 1.19.10, delete the paragraph that begins "All types defined in this chapter are either part of the CORBA or ...". All of the IDL level definitions are in the pseudo interface ORB, which has nothing to do with Java packages. In section 1.19.10, add the following to the Java abstract class org.omg.CORBA.ORB: After the list_initial_services method: public void register_initial_reference( String object_name, org.omg.CORBA.Object object ) throws org.omg.CORBA.ORBPackage.InvalidName { throw new org.omg.CORBA.NO_IMPLEMENT() ; } After the create_abstract_interface_tc method: public TypeCode create_local_interface_tc( String id, String name ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } Also, fix the implementation of the create_abstract_interface_tc method to throw new org.omg.CORBA.NO_IMPLEMENT (it was missing the new). At the beginning, add: public String id() { throw new org.omg.CORBA.NO_IMPLEMENT() ; } At the end, add: public org.omg.CORBA.Object get_value_def( String repid ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public org.omg.CORBA.portable.ValueFactory register_value_factory( String id, org.omg.CORBA.portable.ValueFactory factory ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public void unregister_value_factory( String id ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public org.omg.CORBA.portable.ValueFactory lookup_value_factory( String id ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public void set_delegate( java.lang.Object wrapper ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } In section 1.19.10, add the following Java definition to the very end: package org.omg.CORBA_2_5 ; public abstract class ORB extends org.omg.CORBA_2_3.ORB { public String id() { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public void register_initial_reference( String object_name, org.omg.CORBA.Object object ) throws org.omg.CORBA.ORBPackage.InvalidName { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public TypeCode create_local_interface_tc( String id, String name ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } }
Actions taken:
December 14, 2001: received issue
May 13, 2002: closed issue

Issue 4792: exceptions on valuetype initializers (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
The CORBA components updates to the Interface Repository defined in ptc/01-11-03
include the addition of exceptions on valuetype initializers.  There is a 
separate
issue that is required to change the IDL grammar and other text in chapter 3
to include this.  For the purposes of discussion in this issue,  
I am assuming that the appropriate syntax is:

<init_dcl>	::= "factory" <identifier> "(" [ <init_param_decls> ] ")" [ 
<raises_expr> ] ";"

Proposed revised text:

In section 1.13.2, replace the paragraph that begins "The value type's generated 
value factory" with:

    The value type's generated value factory interface extends 
    org.omg.CORBA.portable.ValueFactory and contains one method corresponding to 
each 
    factory declared in the IDL.  The name of the method is the same as the name 
of 
    the factory, and the factory arguments are mapped in the same way as in 
parameters 
    are for IDL operations.  If the factory raises exceptions, then the 
corresponding
    Java method must throw Java exceptions corresponding to the listed IDL 
exceptions.

Resolution: Incorporate the revised text and close the issue
Revised Text: In section 1.13.2, replace the paragraph that begins "The value type's generated value factory..." with: The value type's generated value factory interface extends org.omg.CORBA.portable.ValueFactory and contains one method corresponding to each factory declared in the IDL. The name of the method is the same as the name of the factory, and the factory arguments are mapped in the same way as in parameters are for IDL operations. If the factory raises exceptions, then the corresponding Java method must throw Java exceptions corresponding to the listed IDL exceptions
Actions taken:
December 18, 2001: received issue
May 13, 2002: closed issue

Issue 4793: attribute exceptions (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
The CCM (ptc/01-11-03) has added exceptions to attributes.  
The IDL to Java mapping needs to be updated to reflect this addition.
Also, the mapping currently says essentially nothing about the mapping of 
exceptions 
on operations or attributes in any context.

Proposed revised text:

In section 1.13.2, replace the paragraph

    The mapped Java class contains abstract method definitions that correspond
    to the operations and attributes defined on the value type in IDL.

with

    The mapped Java class contains abstract method definitions that correspond
    to the operations and attributes defined on the value type in IDL.  
Attributes
    are mapped in the same way as in interfaces, to modifer and accessor 
methods.
    Exceptions are mapped as follows:

    1. If an operation raises exceptions, then the corresponding Java method 
must throw
       Java exceptions corresponding to the listed IDL exceptions.  

    2. If a readonly attribute raises exceptions, then the Java read accessor 
method must throw 
       Java exceptions corresponding to the listed IDL exceptions.

    3. If an attribute has a getRaises clause, the the Java accessor method must
       throw Java exceptions corresponding to the listed IDL exceptions.

    4. If an attribute has a setRaises clause, the the Java modifier method must
       throw Java exceptions corresponding to the listed IDL exceptions.

In section 1.12.1, replace the third paragraph with the following two 
paragraphs:

    The Java operations interface contains the mapped operation signatures.
    If an operation raises exceptions, then the corresponding Java method must 
throw
    Java exceptions corresponding to the listed IDL exceptions.  

    The Java signature interface extends the operations interface, the (mapped)
    base org.omg.CORBA.Object, as well as org.omg.portable.IDLEntity.
    Methods can be invoked on the signature interface. Interface inheritance 
    expressed in IDL is reflected in both the Java signature interface and 
    operations interface hierarchies.

In section 1.12.1, insert after the sixth paragraph:

    Attribute exceptions are mapped as follows:

    1. If a readonly attribute raises exceptions, then the Java read accessor 
method must 
       throw Java exceptions corresponding to the listed IDL exceptions.

    2. If an attribute has a getRaises clause, the the Java accessor method must
       throw Java exceptions corresponding to the IDL exceptions listed in the 
       getRaises clause.

    3. If an attribute has a setRaises clause, the the Java modifier method must
       throw Java exceptions corresponding to the IDL exceptions listed in the
       setRaises clause.

Resolution: Incoporate the revised text and close the issue
Revised Text: In section 1.13.2, replace the paragraph The mapped Java class contains abstract method definitions that correspond to the operations and attributes defined on the value type in IDL. with The mapped Java class contains abstract method definitions that correspond to the operations and attributes defined on the value type in IDL. Attributes are mapped in the same way as in interfaces, to modifer and accessor methods. Exceptions are mapped as follows: If an operation raises exceptions, then the corresponding Java method must throw Java exceptions corresponding to the listed IDL exceptions. If a readonly attribute raises exceptions, then the Java read accessor method must throw Java exceptions corresponding to the listed IDL exceptions. If an attribute has a getRaises clause, the the Java accessor method must throw Java exceptions corresponding to the listed IDL exceptions. If an attribute has a setRaises clause, the the Java modifier method must throw Java exceptions corresponding to the listed IDL exceptions. In section 1.12.1, replace the third paragraph with the following two paragraphs: The Java operations interface contains the mapped operation signatures. If an operation raises exceptions, then the corresponding Java method must throw Java exceptions corresponding to the listed IDL exceptions. The Java signature interface extends the operations interface, the (mapped) base org.omg.CORBA.Object, as well as org.omg.portable.IDLEntity. Methods can be invoked on the signature interface. Interface inheritance expressed in IDL is reflected in both the Java signature interface and operations interface hierarchies. In section 1.12.1, insert after the sixth paragraph: Attribute exceptions are mapped as follows: If a readonly attribute raises exceptions, then the Java read accessor method must throw Java exceptions corresponding to the listed IDL exceptions. If an attribute has a getRaises clause, the the Java accessor method must throw Java exceptions corresponding to the IDL exceptions listed in the getRaises clause. If an attribute has a setRaises clause, the the Java modifier method must throw Java exceptions corresponding to the IDL exceptions listed in the setRaises clause.
Actions taken:
December 18, 2001: received issue
May 13, 2002: closed issue

Issue 4794: OMG Java Language Mapping and the use of Java null (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
We here at Nortel Networks use CORBA extensively. However, we
have a question regarding the use of Java null, and the most
recent OMG spec seems to have some mixed messages.

Section 1.4.1.5 has been there for some time, and it is pretty
clear what is legal and what is illegal.

However, in section 1.4.1.4, it seems to say that in the Holder
class, the Java Strings are initialized to null rather than "".

We are asking this question because it is affecting one of
our software products.  We are getting org.omg.CORBA.BAD_PARAM
exception once in a while.

We are using Sun's JRE ORB(JRE 1.3.1_01).

Resolution: close issue no change
Revised Text:
Actions taken:
December 18, 2001: received issue
May 13, 2002: closed issue

Issue 4802: Should a holder class for ProtectingEntity get generated (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
>There is something that is unclear in your CORBA spec that I think is causing 
incompatibility problems between various IDL compilers.
>> >
>> >Given the following IDL:
>> >
>> >-------------------------------------------------
>> >struct Protection
>> >{
>> > string str;
>> >};
>> >
>> >typedef Protection ProtectedEntity;
>> >
>> >typedef sequence<ProtectedEntity>  ProtectedEntityList;
>> >
>> >typedef ProtectedEntityList ProtectingEntity;
>> >-------------------------------------------------
>> >
>> >Should a holder class for ProtectingEntity get generated?  I ask this because some IDL 
compilers generate it and others do not (very frustrating!).
>> >
>> >In section 1.18.2 of the OMG IDL mapping document ptc/00-01-08 spec I found this: 
"Holder classes are generated for sequence and array typedefs only. The "unwound" type's 
Holder class is used for the other cases.".
>> >
>> >Since this is a typedef of a typedef, but the original item was a sequence, should the 
ProtectingEntityHolder.java file get generated or not?

Resolution: Incorporate change and close issue
Revised Text: Replace the second paragraph of section 1.18.2 with: Holder classes are generated for sequence and arrays typedefs only. The unwound type's Holder class is used for the other cases. No Holder class is generated for a typedef of a typedef. That is, given the IDL typedef XXX A ; typedef A B ; no Holder is generated for B. A holder is generated for A only if XXX is a sequence or an array. When a holder for B is needed, one of two cases occurs: XXX is an array or sequence. In this case, AHolder exists and is used. XXX is not an array or sequence. In this case, XXXHolder exists and is used.
Actions taken:
January 9, 2002: received issue
December 11, 2002: closed issue

Issue 4804: section 1.18.2 of the OMG IDL mapping document ptc/00-01-08 (java-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:
There is something that is unclear in your CORBA spec that I think is causing incompatibility problems between various IDL compilers. 

Given the following IDL: 

------------------------------------------------- struct Protection { string str; }; 

typedef Protection ProtectedEntity; 

typedef sequence<ProtectedEntity> ProtectedEntityList; 

typedef ProtectedEntityList ProtectingEntity; ------------------------------------------------- 

Should a holder class for ProtectingEntity get generated? I ask this because some IDL compilers generate it and others do not (very frustrating!). 

In section 1.18.2 of the OMG IDL mapping document ptc/00-01-08 spec I found this: "Holder classes are generated for sequence and array typedefs only. The "unwound" type's Holder class is used for the other cases.". 

Since this is a typedef of a typedef, but the original item was a sequence, should the ProtectingEntityHolder.java file get generated or not? 

Resolution: duplicate of 4802
Revised Text:
Actions taken:
January 14, 2002: received issue
January 14, 2002: closed issue

Issue 4805: Java mapping changes for core issue 4337 (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
The recent passage of issue 4337 in the core RTF creates a need to update the Java
mapping to include support for the _repository_id operation.  Here is the proposed 
set of updates to the latest (unofficial) Java mapping specifiction (ptc/02-01-01):

--------------------------------------------------------------

In section 1.19.11, add the following method to Object after _get_interface_def:

	string _repository_id() ;
	
In section 1.20.2.1, add the following method to LocalObject after _get_interface_def
(this is the local interface part, I am assumming here that local interfaces
support repository_id.  If not, this should just throw a NO_IMPLEMENT exception):

	public String _repository_id() {
		String[] ids = _ids() ;
		return ids[0] ;
	}
	
In section 1.20.2.2, add the following method to Servant after _get_interface_def:

	public String _repository_id() {
		return _get_delegate().repository_id(this) ;
	}
	
Also in section 1.20.2.2, add the following paragraph after the section
on _get_interface:

	_repository_id
	
	Servant provides a default implementation of _repository_id() that
	can be overridden by derived servants if the default behavior is
	not adequate.  As defined in the CORBA 3.0 specification, 
	section 11.3.1, the default behavior of _repository_id is to 
	return the most derived interface of a static servant or the
	most derived interface retrieved from a dynamic servant.
	This behavior shall be supported by the Delegate that implements
	the servant.
	
In section 1.21.6.3, add the following method to ObjectImpl after _get_interface_def():

	public String _repository_id() {
		return _get_delegate().repository_id(this) ;
	}
	
In section 1.21.7, add the following method to Delegate after get_interface_def:

	public abstract String repository_id( 
	    org.omg.CORBA.Object self) ;
	    
In section 1.21.8, add the following method to Delegate after get_interface_def:

	String repository_id( Servant self ) ;

Resolution: Incorporate changes and close issue
Revised Text:
Actions taken:
December 11, 2002: closed issue

Issue 5108: J2EE ORB Socket Factory API (java-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Ms. Anne E. Collins, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
In order to meet the interoperability compliance requirements,
ORBs must include an IIOP implementation using TCP/IP plain text
sockets. J2EE implementations are required to support CSIv2 and
thus need additional control over the sockets an ORB creates.
It may be necessary
-  to get the ORB to listen on additional sockets, of differing
   types
-  to get the ORB to connect to alternative sockets, of different
   types, for a given IOR
-  for information about these sockets to be included in object
   references exported by the ORB
-  for socket data to be available to request interceptors, e.g
   SSL certificates


Portable IORInterceptors can be used to add this information as
tagged components in the profiles within an IOR.


A mechanism is required to modify the ORB's behaviour to allow
it to handle different socket types, listen on additional sockets,
connect to alternative sockets and make additional data available
to interceptors.


Since this is a J2EE requirement which needs speedy resolution,
it seems appropriate to resolve it by the addition of Java
specific APIs in the IDL to Java specification. For example,


-  a pluggable ORB socket factory could be introduced which would
   be used whenever the ORB needed to create a serverSocket or an
   outbound socket for a given IOR or end point


-  a means of registering such a socket factory would be required.
   Options for this include:-
   . adding an ORB method: this may cause problems in initialisation
   . adding a Java specific extension to the PI ORBInitInfo interface
     so that the registration would need to be called from the
     pre_init/post_init methods in an ORBInitializer: this ties the
     Socket Factory with PIs, but both are likely to be required
     for J2EE.


-  a means of specifying ports on which an ORB/POA should listen
   would be useful but this may be infeasible as part of this issue
   due to the variety of ORB/POA implementations.


-  the PI Client and ServerRequestInfo and IORInfo interfaces may
   need to be extended to support access to Connection related data


Resolution:
Revised Text:
Actions taken:
April 9, 2002: received issue

Issue 5465: Default UnknownException behavior (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com)
Nature: Uncategorized Issue
Severity:
Summary:
On page 133, bullet 3 reads:


• If the CORBA system exception org.omg.CORBA.portable.UnknownException
is thrown, then the stub does one of the following:
• Translates it to org.omg.CORBA.UNKNOWN.
• Translates it to the nested exception that the UnknownException contains.
• Passes it on directly to the user.


It is unfortunate that there is no recommended default since for RMI-IIOP at least, option (2) is by far to be preferred. I would like to change it therefore to add the text:


"In order to preserve RMI semantics ORBs implementing the RMI-IIOP protocol should always translate it to the nested exception that the UnknownException contains"

Resolution: Incorporate revised text and close issue
Revised Text: Add the following paragraph after the third bullet mentioned above in the summary: In order to preserve RMI semantics ORBs implementing the RMI-IIOP protocol must always translate the UnknownException to the nested exception given by UnknownException.originalEx.
Actions taken:
July 12, 2002: received issue
April 28, 2003: closed issue

Issue 5468: Anys obtained using the singleton ORB (java-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Ms. Anne E. Collins, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
The IDL to Java spec is very clear about what methods can (and by
implication what methods can't) be used with the singleton ORB and
one of those is create_any(), however it does not mention any
restrictions on the use of Anys obtained in this way.  I think this
leads to some inconsistencies and potential problems, for example:


1.  You cannot use create_output_stream() on the singleton ORB but
you can use create_output_stream() on an Any obtained from the
singleton.  Where has this OutputStream come from?  Presumably from
the Any's singleton ORB (calling the orb() method on that OutputStream
would return the ORB).  At best this seems inconsistent.


2.  The problem is worse if you now marshal an object reference into
that OutputStream then call create_input_stream() and try to read back
the object reference using a read_Object() call.  If the read_Object()
is to return an object reference it needs to have an ORB to associate
it with, but the only ORB available to it is the original Any's
singleton ORB, which cannot support object references.  Should this
read_Object() succeed or fail?  If it should succeed what ORB should
it be using?


There may be similar problems writing and reading other types to these
streams.


I feel the spec should state explicitly that operations on an Any
created using the singleton ORB will be limited by the restrictions
applicable to the singleton ORB.


I don't think this would affect the intended use of Anys from the
singleton, which is stated as being to describe union labels when
creating a union TypeCode.


Proposed resolution:


Add the following sentence to the end of the subsection "Default
initialization" in section 1.21.9.3 ORB Initialization Methods in
the IDL to Java spec:


Operations on an Any created using the singleton ORB will be
limited by the restrictions applicable to the singleton ORB;
those which require the use of a fully functional ORB will result
in a NO_IMPLEMENT system exception.


Resolution: resolved
Revised Text: Add the following sentence to the end of the subsection "Default initialization" in section 1.21.9.3 ORB Initialization Methods in the IDL to Java spec: Operations on an Any created using the singleton ORB will be limited by the restrictions applicable to the singleton ORB; those which require the use of a fully functional ORB will result in a NO_IMPLEMENT system exception.
Actions taken:
July 9, 2002: received issue
April 28, 2003: closed issue

Issue 5586: interfaces that do not extend org.omg.CORBA.portable.ValueBase (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
The two files org\omg\CORBA\DataInputStream.java and org/omg\CORBA\DataOutputStream.java 
contain interfaces that do not extend org.omg.CORBA.portable.ValueBase. 

The CORBA IDL shows: 

abstract valuetype DataInputStream { ... 
abstract valuetype DataOutputStream { ... 

And the IDL to Java mapping spec states that abstract value types 
map to a Java interface that extends ValueBase. 

Which is correct? 


Resolution: resolved
Revised Text: Modify the two interfaces org.omg.CORBA.DataInputStream and org.omg.CORBA.DataOutputStream so that the extend org.omg.CORBA.portable.ValueBase in the zip archive
Actions taken:
August 20, 2002: received issue
April 28, 2003: closed issue

Issue 5595: Should javadoc statement be removed or should method be removed? (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
The org\omg\CORBA\Object.java includes: 

/**
*@deprecated Deprecated by CORBA 2.3
*/
org.omg.CORBA.InterfaceDef _get_interface(); 

Which causes the the application code: 

public abstract class x extends org.omg.CORBA.LocalObject implements xl {}
public interface xl extends org.omg.CORBA.LocalInterface, org.omg.CORBA.portable.IDLEntity {} 

to compile with a warning: 

x.java:1: warning: _get_interface() in org.omg.CORBA.Object has been deprecated 

I'm wondering whether the javadoc statement should be removed or whether the method should be removed? 


Resolution: close issue
Revised Text:
Actions taken:
August 26, 2002: received issue
April 28, 2003: closed issue

Issue 5615: Streaming Interfaces (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
the DataInputStream and
DataOutputStream are specified in IDL as abstract valuetypes in Chapter
5, and they do not follow the standard language mapping for abstract
valuetypes at least in the Java Language Mapping. So does this imply
that we should move the source file from CORBA_IDL directory to
CORBA_PIDL directory? The thing compiles alright as IDL but in case of
Java it does not produce the right Java code

Resolution: Make the required changes to the standard Java source files as described in the revised text
Revised Text: Modify the source code for DataInputStream and DataOutputStream so that both interfaces extend org.omg.CORBA.portable.ValueBase
Actions taken:
August 22, 2002: received issue
August 29, 2002: moved from Core to Java RTF
December 11, 2002: closed issue

Issue 5638: Typo on getRaises and setRaises in formal/2002-08-05 (java-rtf)

Click
here for this issue's archive.
Source: INRIA (Dr. Philippe Merle, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
In the IDL to Java Language Mapping Specification Version 1.2
(formal/2002-08-05), at pages 1-29 and 1-40, all occurrences
of getRaises and setRaises must be replaced respectively by
getraises and setraises according to the Chapter 3 of the
CORBA Specification Version 3.0 (formal/02-06-01).


getRaises and setRaises were replaced by getraises and setraises
during the CORBA Components December 2000 FTF (see final
report ptc/01-11-02).

Resolution: Incorporate changes and close issue
Revised Text: Replace all occurrences of "getRaises" and "setRaises" with "getraises" and "setraises", respectively
Actions taken:
August 29, 2002: received issue
April 28, 2003: closed issue

Issue 5646: Java source code for org.omg.PortableServer.POAOperations (java-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
The Java source code for org.omg.PortableServer.POAOperations in ptc/02-06-14 defines the method create_reference_with_id as throwing org.omg.PortableServer.POAPackage.WrongPolicy. However, the CORBA/IIOP 2.4 specification (formal/00-10-01) specifies this operation as NOT raising any exceptions (see section 11.3.8.19). Which is correct?

Resolution:
Revised Text:
Actions taken:
September 19, 2002: received issue

Issue 5693: POA changes missing in Java source archive (java-rtf)

Click
here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Uncategorized Issue
Severity:
Summary:
Summary:
The following CORBA 2.4  additions to the PortableServer module are missing from the latest Java source archive (http://cgi.omg.org/cgi-bin/doc?ptc/02-06-14):
- in enumeration ThreadPolicyValue: the MAIN_THREAD_MODEL value
- in Current: operations get_reference and get_servant


Proposed Resolution:
I believe all changes should be binary compatible with the existing distribution. Therefore, no PortableServer_2_4 package should be necessary. It should be sufficient to apply these patches to the next distribution:


diff -r1.1 CurrentOperations.java
7a8,9
> import org.omg.CORBA.Object;
>
13a16,20
>
>     public Object get_reference() throws org.omg.PortableServer.CurrentPackage.NoContext;
>
>     public Servant get_servant() throws org.omg.PortableServer.CurrentPackage.NoContext;
>


diff -r1.1 ThreadPolicyValue.java
33a34,37
>     public static final int _MAIN_THREAD_MODEL = 2;
>     public static final ThreadPolicyValue MAIN_THREAD_MODEL =
>         new ThreadPolicyValue(_MAIN_THREAD_MODEL);
>
44a49,50
>     case _MAIN_THREAD_MODEL:
>         return MAIN_THREAD_MODEL;


Resolution: Incorporate changes and close issue
Revised Text: Add the following methods to org.omg.PortableServer.CurrentOperations: public org.omg.CORBAObject get_reference() throws org.omg.PortableServer.CurrentPackage.NoContext; public Servant get_servant() throws org.omg.PortableServer.CurrentPackage.NoContext; Add the following static data members to org.omg.PortableServer.ThreadPolicyValue: public static final int _MAIN_THREAD_MODEL = 2; public static final ThreadPolicyValue MAIN_THREAD_MODEL = new ThreadPolicyValue(_MAIN_THREAD_MODEL); Add the following to the org.omg.PortableServer.ThreadPolicyValue.from_int(int) method, just before the default label in the switch statement: case _MAIN_THREAD_MODEL: return MAIN_THREAD_MODEL;
Actions taken:
October 21, 2002: received issue
April 28, 2003: closed issue

Issue 5694: What is the IDL for ServiceInformation and/or what is correct Java mapping? (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Are both of these correct? 
[It seems like the Java maps 
  "sequence <ServiceDetailType> service_details" instead of "sequence <ServiceDetail> service_details"] 



from formal/02-06-33 "CORBA 3.0 full specification 
typedef unsigned long ServiceOption; 
typedef unsigned long ServiceDetailType; 
struct ServiceDetail { 
  ServiceDetailType service_detail_type; 
  sequence <octet> service_detail; 
}; 
struct ServiceInformation { 
  sequence <ServiceOption> service_options; 
  sequence <ServiceDetail> service_details; 
}; 

from ptc/02-09-09 "Revision of the interim Java RTF Java .zip archive 

package org.omg.CORBA; 

public final class ServiceInformation implements 
      org.omg.CORBA.portable.IDLEntity { 

    public int[] service_options; 
    public int[] service_details; 

    public ServiceInformation() { 
    } 

    public ServiceInformation (int[] service_options, int[] service_details) { 
        this.service_options = service_options; 
        this.service_details = service_details; 
    } 

} 

Resolution: Incorporate changes and close issue
Revised Text: In class org.omg.CORBA.ServiceInformation in the zip file, change public int[] server_details to public org.omg.CORBA.ServiceDetail[] service_details Also, change public ServiceInformation (int[] service_options, int[] service_details) { to public ServiceInformation (org.omg.CORBA.ServiceDetail[] service_options, int[] service_details) {
Actions taken:
October 21, 2002: received issue
April 28, 2003: closed issue

Discussion:


Issue 5696: Package name issue (java-rtf)

Click
here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:
This is an issue for the Java RTF. Related issue in Core RTF is Issue
5327.


Originally from Michi Henning:


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.


Discussion from Jishnu Mukerji:


It seems to me that this is more of a language mapping issue. I don't
think that the Repository Ids have any requirement to be of the same
shape as a valid IDL identifier. It would be kind of hard to have GUIDs
as RepId if that were the case.


But even for IDL type RepIds 12345.com seems to be a perfectly good 
domain name as is 2ab.com. I don't see why these perfectly valid 
domain names should be disallowed because the Java language mapping 
is unable to deal with them.


Further discussion from Michi Henning:


One way to fix it would be to state that:


    1) For the Java mapping, any prefix that starts with a digit gets
       translated with an underscore prefix, so 2ab would turn into
       _2ab for the Java mapping.


    2) Characters that can appear in a prefix pragma are limited to
       some set we'd have to agree on. (Probably the same as for IDL
       identifiers, plus '.' and possibly hyphen ('-').)


Further discussion from Jishnu Mukerji:


Item 1 in Michi's list needs to be handled by the IDL-Java RTF. This
message to issues@omg.org is requesting the creation of an issue
covering this item for the Java RTF.


Item 2 can be taken care of in the resolution for Core Issue 5327.

Resolution: close no change
Revised Text:
Actions taken:
October 23, 2002: received issue
April 28, 2003: closed issue

Discussion:
Discussion from Jishnu Mukerji:

It seems to me that this is more of a language mapping issue. I don't think that the Repository Ids have any requirement to be of the same shape as a valid IDL identifier. It would be kind of hard to have GUIDs as RepId if that were the case. 

But even for IDL type RepIds 12345.com seems to be a perfectly good domain name as is 2ab.com. I don't see why these perfectly valid domain names should be disallowed because the Java language mapping is unable to deal with them.

Further discussion from Michi Henning:

One way to fix it would be to state that:

For the Java mapping, any prefix that starts with a digit gets translated with an underscore prefix, so 2ab would turn into _2ab for the Java mapping. 
Characters that can appear in a prefix pragma are limited to some set we'd have to agree on. (Probably the same as for IDL identifiers, plus '.' and possibly hyphen ('-').) 
Further discussion from Jishnu Mukerji:

Item 1 in Michi's list needs to be handled by the IDL-Java RTF. This message to issues@omg.org is requesting the creation of an issue covering this item for the Java RTF.

Item 2 can be taken care of in the resolution for Core Issue 5327
Discussion:

#pragma prefix affects only the repository ID, not the actual package into which the interface is placed. In fact, there are no #pragmas defined in the IDL to Java mapping. Various IDL to Java compilers include mechanisms to map IDL types into specific Java packages. For example, Sun's idlj supports a flag 

    -pkgPrefix <t> <prefix>
which puts the <prefix> in front of the normal mapping of <t>. Since all such mechanisms are proprietary, no spec change is needed here.



Issue 5728: How does a Java ORB implement a write_fixed/read_fixed? (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
From the OMG mapping specs: 

org.omg.CORBA.portable.OutputStream [as of formal/01-06-06] defines: 

public void write_fixed(java.math.BigDecimal value, short digits, short scale) { 

throw new org.omg.CORBA.NO_IMPLEMENT(); 

} 

org.omg.CORBA.portable.OutputStream [as of formal/01-06-06] defines: 

public java.math.BigDecimal read_fixed(short digits, short scale) { 

throw new org.omg.CORBA.NO_IMPLEMENT(); 

} 

JDK 1.4 (and prior versions) do not implement the first two items, 
so no portable bindings could be used for these. 

Should there been an 
org.omg.CORBA_2_4.portable.OutputStream and org.omg.CORBA_2_4.portable.InputStream 
that inherit from org.omg.CORBA_2_3.portable.In/OutStream and add these? 


Resolution: Close no change
Revised Text:
Actions taken:
October 28, 2002: received issue
April 28, 2003: closed issue

Discussion:
Both the IDL to Java mapping specification and the .zip archive have the correct methods, so there is no OMG specification change required here. However, the two methods are indeed missing in J2SE 1.4, and so the originator of this issue should file a bug against the J2SE 1.4 CORBA implementation. (Wearing my Sun hat for a minute, I'll tell you that this error cannot be fixed until J2SE 1.5, since it requires adding new methods to a public interface). 


Issue 5782: Missing operations on org.omg.CORBA.Object (java-rtf)

Click
here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
While reviewing the latest CORBA 3.1 draft, I noticed that a number of methods recently
added to CORBA::Object are missing from org.omg.CORBA.Object.  The list of missing methods
is:


get_client_policy
get_policy_overrides
validate_connection
get_component


A group of related issues in the core RTF (core issues 3403/3772/3793/3322) are all
centered on questions about access to ORB operations.  The solution to this problem
has converged on making the ORB available on every object reference.  I am including this change in
this issue as well.  It turns out that the Java mapping requires updating 4 separate
standard classes for every new method that is added to CORBA::Object.  2 of the 4
classes in the mapping already have an ORB accessor.  The main change required to
support access to the ORB is in the LocalObject implementation.


I plan to include this issue in the next java-rtf vote.  Please note the question inline
below, and let me know if you have any strong opinions one way or the other.

Resolution: Incorporate changes and close issue
Revised Text: Clearly we need to map these operations into the Object interface. Note that LocalObject, org.omg.CORBA.portable.ObjectImpl, and org.omg.CORBA.portable.Delegate are also affected by these methods. In the case of get_orb, note that ObjectImpl and Delegate already have an ORB accessor method (_orb() and orb() respectively). For consistency with the rest of the mapping, we will map CORBA::Object.get_orb() to the java method orb.omg.CORBA.Object._get_orb(). This then makes the ORB available to all org.omg.CORBA.Object instances without needing to access the underlying ObjectImpl or LocalObject that implements the interface. We will also need to extend LocalObject with an additional constructor that allows setting of a private transient ORB data member. Note that all of these changes described for the spec must also be applied to the corresponding classes in the source file archive: org.omg.CORBA.Object org.omg.CORBA.LocalObject org.omg.CORBA.portable.ObjectImpl org.omg.CORBA.portable.Delegate Changes required: In section 1.19.11, add the following methods at the end of org.omg.CORBA.Object: Policy _get_client_policy( int type ) ; PolicyList _get_policy_overrides( int[] types ) ; boolean _validate_connection( PolicyListHolder inconsistent_policies ) ; org.omg.CORBA.Object _get_component() ; org.omg.CORBA.ORB _get_orb() ; In section 1.20.2.1, add the following data member at the start of the class: private transient org.omg.CORBA.ORB orb = null ; add the following constructor immediately following LocalObject(): public LocalObject( ORB orb ) { this.orb = orb ; } add the following methods at the end of LocalObject: public Policy _get_client_policy( int type ) { throw new NO_IMPLEMENT() ; } public PolicyList _get_policy_overrides( int[] types ) { throw new NO_IMPLEMENT() ; } public boolean _validate_connection( PolicyListHolder inconsistent_policies ) { throw new NO_IMPLEMENT() ; } public org.omg.CORBA.Object _get_component() { throw new NO_IMPLEMENT() ; } public ORB _get_orb() { if (orb == null) throw new OBJECT_NOT_EXIST( TBD, CompletionStatus.COMPLETED_NO ) ; return orb ; } where TBD is the standard OMG minor code signifying that no ORB is associated with the local object. In section 1.21.6.3, add the following methods at the end of org.omg.CORBA.portable.ObjectImpl: Policy _get_client_policy( int type ) { return _get_delegate().get_client_policy( type ) ; } PolicyList _get_policy_overrides( int[] types ) { return _get_delegate().getPolicy_overrides( types ) ; } boolean _validate_connection( PolicyListHolder inconsistent_policies ) { return _get_delegate().validate_connection( inconsistent_policies ) ; } org.omg.CORBA.Object _get_component() { return _get_delegate().get_component() ; } In section 1.21.7, add the following methods to abstract class Delegate after the set_policy_override method: public Policy _get_client_policy( int type ) { throw new NO_IMPLEMENT() ; } public PolicyList _get_policy_overrides( int[] types ) { throw new NO_IMPLEMENT() ; } public boolean _validate_connection( PolicyListHolder inconsistent_policies ) { throw new NO_IMPLEMENT() ; } public org.omg.CORBA.Object _get_component() { throw new NO_IMPLEMENT() ; } In the section titled "local interfaces" of section 1.12.1, add the following after item 3. in the numbered list: 4. The _<typename>LocalBase class has 2 public constructors defined as follows: public _<typename>LocalBase() { super() ; } public _<typename>LocalBase( ORB orb ) { super( orb ) ; } In the section titled "local interfaces" of section 1.12.1, replace the phrase "and an instance would be created using the usual Java language construct:" with: and an instance would be created using the usual Java language construct <typename>Impl ti = new <typename>Impl( ... ) ; The constructor(s) defined in <typename>Impl may pass an ORB parameter to the super class constructor using an explicit constructor invocation such as super( orb ). If this is done, the orb passed in the constructor is returned by the _get_orb() method on the local object instance. If the <typename>Impl() constructor is used, a call to _get_orb() will result in an OBJECT_NOT_EXIST exception with a standard minor code of TBD
Actions taken:
December 2, 2002: received issue
April 28, 2003: closed issue

Issue 5783: Stub handling of UnknownException (java-rtf)

Click
here for this issue's archive.
Source: International Business Machines (Ms. Anne E. Collins, nobody)
Nature: Uncategorized Issue
Severity:
Summary:
Problem summary:
Following resolution of issue 5465 in vote 4, Section 1.21.6.3
"Streaming Stub APIs" 3rd main bullet reads as follows:


- If the CORBA system exception org.omg.CORBA.portable.UnknownException
  is thrown, the stub does one of the following:
  - Translates it to org.omg.CORBA.UNKNOWN
  - Translates it to the nested exception taht the UnknownException
contains.
  - Passes it on directly to the user


  In order to preserve RMI semantics ORBs implementing the RMI-IIOP
protocol
  must always translate the UnknownException to the nested exception given
  by UnknownException.originalEx.


I think there are problems with the new final paragraph
a. It's unclear whether the additional paragraph requires a change to
   Stub code or to the ORB runtime.
b. It's undesirable, and unnecessary in this case, to differentiate
   between ORBs which do and do not implement RMI. The rule can, and
   should, be the same for all Java ORBs.
c. It is incorrect to mandate that any ORB must translate the
   UnknownException to the nested exception because, as the nested
   exception is defined as a Throwable, this isn't always possible.



Proposal:
I think it would be preferable to simply reword Section 1.21.6.3
  "Streaming Stub APIs" 3rd main bullet, as follows:


- If the CORBA system exception org.omg.CORBA.portable.UnknownException
  is thrown, the stub translates it to the nested exception that the
  UnknownException contains, if possible. If this is not possible, the
  stub passes the UnknownException on directly to the user.


Resolution: Incorporate change and close issue
Revised Text: Replace Section 1.21.6.3 "Streaming Stub APIs" 3rd main bullet with the following: If the CORBA system exception org.omg.CORBA.portable.UnknownException is thrown, the stub translates it to the nested exception that the UnknownException contains, if possible. If this is not possible, the stub passes the UnknownException on directly to the user
Actions taken:
December 3, 2002: received issue
April 28, 2003: closed issue

Issue 5806: response_expected value for colocated invocations (java-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
For optimized (SII) colocated invocations, how is it possible for the
ORB to determine the value of "response_expected" flag (so as to pass it
to the client/server request interceptor). Is there a portable way to
get this info? This is specially a problem when a oneway method is
invoked and sync scope policy is not set; since both oneway and two-way
void methods have a void return type. At the moment, I think such
information can only be passed to the ORB through the stub.

Resolution: see above
Revised Text:
Actions taken:
November 5, 2002: received issue
January 10, 2003: received issue
August 29, 2003: moved to Java RTF
April 26, 2010: closed issue
April 26, 2010: closed issue
April 26, 2010: closed issue

Discussion:
At UML 2.0 a multiplicity can have only one range so the issue does not
apply.
Disposition: Closed, no change


Issue 5893: definition of FixedHolder should have been removed (java-rtf)

Click
here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Uncategorized Issue
Severity:
Summary:
The resolution of issue #3668 should have removed the definition of FixedHolder. There is no need for a Holder for an anonymous Fixed type since none can be defined. Type specific Holders are necessary in order to define the correct read and write operations that use the write_fixed and read_fixed defined by the resolution of 3668.


Proposed resolution:
Remove the definition of FixedHolder from section 1.4.1.4 (page 1-11).

Resolution:
Revised Text:
Actions taken:
April 1, 2003: received issue

Issue 7846: wrong enumeration value for SetOverrideType (java-rtf)

Click
here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Uncategorized Issue
Severity:
Summary:
In ptc/02-01-01, the latest (?) compendium of predefined code for the IDL to Java mapping, the enumerations values captured in org.omg.CORBA.SetOverrideType are SET_OVERRIDE and ADD. The correct values are SET_OVERRIDE and ADD_OVERRIDE.

Resolution:
Revised Text:
Actions taken:
October 7, 2004: received issue

Issue 9795: section 1.21.3 IDLEntity (java-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:
http://www.omg.org/docs/formal/02-08-05.pdf section 1.21.3 IDLEntity inclides the Serializable interface, but if an IDLEntity has a union, it will result in Holder classes (i.e. FloatHolder) which do not implement the Serializable interface. This results in NotSerializable exceptions being created when trying to use such objects with java serialization. The quick fix would be to specify that "public interface Streamable" should extend java.io.Serializable, since the holder classes extend from that as well. 

Resolution:
Revised Text:
Actions taken:
May 26, 2006: received issue

Issue 15709: Specification does not provide mapping spec for Home, Component and Event (java-rtf)

Click
here for this issue's archive.
Source: Remedy IT (Mr. Martin Corino, mcorino(at)remedy.nl)
Nature: Enhancement
Severity: Significant
Summary:
The specification does not provide mapping descriptions for Home and Event IDL definitions (already part of CORBA 3.0) or Component (new in CORBA 3.1).

Resolution:
Revised Text:
Actions taken:
October 8, 2010: received issue