Issues for IDL/Java Revision Task Force mailing list

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

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 (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, [email protected] 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 SE (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 SE (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

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

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

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.

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:
January 14, 2002: received issue
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 [email protected] 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 [email protected] 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:

https://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