Issue 1578: Public method declarations in ResponseHandler interface
Issue 1589: orb() method on InputStream
Issue 1590: Marshalling of Any, Context, Principal, and TypeCode
Issue 1591: Default Constructor for Stubs
Issue 1592: How to make IDLEntity types serializable
Issue 1593: Obtaining a default ORB
Issue 1594: SerializationInputStream and SerializationOutputStream
Issue 1595: Unicode example needs fixing
Issue 1596: Mapping for nested sequences --- fix example
Issue 1597: Need to emit ID pragmas after declarations
Issue 1598: Lexigraphic sort for field names is before mangling
Issue 1599: Narrow signature does not allow use for abstract interfaces
Issue 1600: Section 5.7.4 : mapped IDL issue
Issue 1601: Can toStub take a stub?
Issue 1602: Does toStub return most derived stub?
Issue 1603: Clarify rules for mapping server-side errors and exceptions
Issue 1604: The generated IDL in A2 needs to be changed
Issue 1606: mangling rule for name clashes in IDL needs to be defined
Issue 1607: Do we need to protect non-generated IDL files against multiple inclusion?
Issue 1608: Rules in section 7.4.4 for toStub IIOP/JRMP search not correct
Issue 1609: Should exportObject throw exceptions?
Issue 1610: PortableRemoteObject toStub should throw NoSuchObject Exception
Issue 1619: Abstract Interfaces issue
Issue 1620: Omission in section 5.4.5
Issue 1621: Stub methods for hashCode, equals and toString
Issue 1640: Should Portability APIs throw SystemException?
Issue 1641: Mapping of Java names that are IDL keywords
Issue 1642: Java to IDL identifier mapping
Issue 1662: read_AbstractObject and write_AbstractObject
Issue 1736: Local stubs proposal
Issue 1780: JTS exceptions
Issue 1891: Need to #include orb.id
Issue 1894: Value methods not mapped in spec examples
Issue 1931: Need overloaded write_Value method on OutputStream
Issue 1957: Mapping of non-public types
Issue 1958: Mapping of java.rmi remoteException superclasses
Issue 1960: Mapping of Java arrays
Issue 1965: Eliminating server wait code
Issue 2081: Specifying code downloading
Issue 2082: Mapping of RuntimeException
Issue 2088: The mapping of java.lang.Class to IDL is not specified
Issue 2089: Custom marshalling wire format
Issue 2090: Mapping of Object, Serializable and Externalizable
Issue 2091: Support for serialPersistentFields
Issue 2092: RMI/ORB marshalling interface
Issue 2111: mapping from java.rmi Remote to CORBA::Object
Issue 2225: javax.rmi package use
Issue 2370: Mangling of Java long type not specified
Issue 2466: Mapping private Java methods to IDL
Issue 2467: Change write_* names in Util class
Issue 2468: IIOP/JRMP stubs name clash
Issue 2469: IDLEntity exception types as parameters and results
Issue 2470: Completion status missing from exception string
Issue 2471: RMI/IDL Tie changes
Issue 2472: Interfaces and values should be mapped consistently
Issue 2473: Mappings for non-conforming types
Issue 2474: Mapping for non-conforming class
Issue 2475: Definition of Stub.equals method
Issue 2476: IDLEntity types need to be boxed
Issue 2477: RMI Repository ID proposed change
Issue 2478: Replaceability of javax.* APIs
Issue 2479: Use of "java" as top-level IDL module
Issue 2480: export/unexport errors not well specified
Issue 2481: mapSystemException should preserve original exception
Issue 2482: Mapping of java.rmi.Remote
Issue 2483: NotSerializableException for RMI-IIOP
Issue 2484: Need read_Value(clz) on InputStream
Issue 2503: Need getTarget method on Tie interface
Issue 2504: Misleading wording in section 28.5.1.4
Issue 2505: ::java::lang::Exception is illegal IDL
Issue 2535: Mapping remote interface types to RMI-style repository IDs
Issue 2545: mapping of java.lang.Exception
Issue 2552: Treatment of classes with writeReplace/readResolve methods
Issue 2565: Mapping of Java constructors to init is broken
Issue 2804: stub classes can violate licensing and package sealing
Issue 2805:
Issue 2806:
Issue 2807:
Issue 2808:
Issue 2809:
Issue 2810:
Issue 2813:
Issue 2815:
Issue 2816:
Issue 2818:
Issue 2894: Security problem in JavaToIDL mapping
Issue 3093: PortableRemoteObject.narrow(null)
Issue 3117: Name mangling scheme broken.
Issue 3118: Boolean attributes
Issue 3151: Stream format problem for custom marshalled RMI types
Issue 3152: Tie.deactivate() exception handling
Issue 3160: Definition of serialVersionUID field
Issue 3200: Container/member name clashes
Issue 3433: No factory for javax.rmi.ClassDesc
Issue 3590: loader.loadClass() or Class.forName()?
Issue 3641: Java to IDL mapping contradictive to CORBA/IIOP 2.3.1
Issue 3670: Exception mapping needs fixing
Issue 3754: Java reverse mapping local case cannot properly support Portable Intercepto
Issue 3798: ValueHandler Interface
Issue 3857: Descriptions of readAny and writeAny not precise enough
Issue 3858: Package for PortableRemoteObjectDelegate
Issue 3969: Mapping of CORBA any and TypeCode
Issue 4004: Mapping CORBA minor codes to Java
Issue 4058: Mapping of Java byte constants to IDL
Issue 4296: javax.rmi.CORBA.Util.isLocal RemoteException condition(s) not specified
Issue 4319: Behavior of Java writeUTF/readUTF
Issue 4429: Issue with using the local stub with for example an EJB application
Issue 4497: Mapping subclasses of custom-marshaled Java classes to IDL
Issue 4591: New issue: Behavior of writeByte, writeChar, writeBytes, writeChars
Issue 4656: Mapping of ExceptionDetailMessage service context
Issue 4690: There is a typo on page 1-46.
Issue 4698: mapSystemException server mapping
Issue 4795: RMI-IIOP interop bet. J2SE 1.3 and 1.4
Issue 5330: Stream encoding for omitted optional custom data
Issue 5332: Urgent issue: javax.rmi.CORBA.Stub serialVersionUID
Issue 5454: Java Codebase tagged component and POA
Issue 5723: Issue with ValueHandler.getRunTimeCodeBase and PRO.exportObject
Issue 5741: 1.2.3 RMI/IDL Remote Interfaces 2
Issue 5742: scheme for mapping names is pretty byzantine
Issue 5772: Name mapping rules for non-ASCII characters
Issue 5853: ORB shutdown should be configurable
Issue 5879: Custom Marshaling Format Clarification
Issue 5891: Guidance on RepositoryIDs for primitive types
Issue 5991: Request clarification on copyObject(s) semantics
Issue 6410: Custom marshalled abstract interfaces and Java/IDL
Issue 6411: Custom marshalled abstract interfaces and Java/IDL
Issue 6992: defaultWriteObject clarification
Issue 7217: Mapping CORBA activity exceptions to Java
Issue 7595: No wire format defined for java.lang.reflect.Proxy classes
Issue 10336: Section: 1.3, Page: 1-21
Issue 1578: Public method declarations in ResponseHandler interface (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: This item affects the Java-to-IDL spec, but is also of concern to the
IDL-to-Java RTF because it relates to the new portability stub APIs.
Section 7.2.2 of the Java to IDL mapping specifies a new interface
ResponseHandler with methods createReply and createExceptionReply.
These methods are declared as public.
Section 9.4 of the Java Language Specification states that "Every
method declaration in the body of an interface is implicitly public.
It is permitted, but strongly discouraged as a matter of style, to
redundantly specify the public modifier for interface methods."
I propose that the public modifier be removed from these method
declarations.
Resolution:
Revised Text:
Actions taken:
June 24, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1589: orb() method on InputStream (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: This item affects the Java-to-IDL spec, but is also of concern to the
IDL-to-Java RTF because it relates to the new portability stub APIs.
An orb() method is needed on org.omg.CORBA.portable.InputStream for
SerializationInputStream to call to find which ORB to use for
lookup_value_factory during execution of read_Value.
I propose adding an orb() method to org.omg.CORBA.portable.InputStream.
Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1590: Marshalling of Any, Context, Principal, and TypeCode (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
concern to the IDL-to-Java RTF because it affects the IDL-to-Java
mapping.
How do SerializationInputStream and SerializationOutputStream marshal
Any, Context, Principal, and TypeCode objects? Is the same mechanism
used as for user-defined IDL types, i.e., look for the IDLEntity
marker interface and call the implementation helper class"s write
or read method? If so, we need to clarify that vendor implementation
of these types must implement IDLEntity and provide a Helper class.
I propose that we state in the spec that vendor implementations of
these types must implement IDLEntity and provide a Helper class.
Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1591: Default Constructor for Stubs (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
concern to the IDL-to-Java RTF because it affects the IDL-to-Java
mapping.
When adding support for idlToJava generated Stubs to
"InputStream.read_Object(java.lang.Class clz)" we ran into a small
problem while writing the code. Initially we used "clz.newInstance()"
to create an instance of the Stub object. The problem here is the
Stub does not have a default constructor, so newInstance throws an
exception. We added a default constructor to the stub and everything
worked fine. The question is: should we add a default constructor to
the stubs generated by idlToJava or should we use reflection(cost??) to
invoke the one constructor that is already a member of the stub class?
I propose that we state in the spec that a default constructor is
required on all generated Stubs.
Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1592: How to make IDLEntity types serializable (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
concern to the IDL-to-Java RTF because it affects the IDL-to-Java
mapping.
The Java to IDL mapping spec states that Java types produced by
the direct mapping should implement IDLEntity and be serializable.
This could be accomplished by having IDLEntity extend
Java.io.Serializable, or by having the generated types extend
both IDLEntity and java.io.Serializable. The spec should
specify which of these approaches is to be used.
Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1593: Obtaining a default ORB (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
concern to the IDL-to-Java RTF because it affects the IDL-to-Java
mapping.
There are two places in the Java to IDL mapping spec that imply
the use of a default ORB. One is the toStub method of the
PortableRemoteObject class, and the other is the readObject method
of the javax.rmi.CORBA.Stub class. It is not clear how we can
obtain a suitable default ORB for use in these APIs without either
excessive resource consumption (if we start a new ORB every time)
or violating applet isolation boundaries (if we use the same ORB
every time).
Resolution: Closed, accepted
Revised Text:
Actions taken:
June 29, 1998: received issue
June 4, 1999: closed issue
Discussion: There is a problem with implementing the deserialization of stubs
and the PortableRemoteObject.toStub method. Both of these require
an ORB object to which the returned stub object will be connected
via its delegate. However, there is no well-specified way to obtain
a suitable implicit ORB object in CORBA.
In the case of stub deserialization, it is not possible to pass an
explicit ORB object to the deserialization operation. In the case
of toStub, we do not wish to add an explicit ORB object because this
breaks the "portable RMI" programming model in which application
code refers only to RMI types and not to CORBA types.
Proposal:
Deserialization of javax.rmi.CORBA.Stub creates an "unconnected" stub.
Before being used, it must be connected to an ORB. This will happen
automatically if the unconnected stub is written to a GIOP marshaling
stream by being passed to javax.rmi.CORBA.writeRemoteObject or
javax.rmi.CORBA.writeAbstractObject. However, in other cases, the stub
must be connected explicitly. To enable this, the method
void connect(ORB orb) throws RemoteException { ... }
is added to the javax.rmi.CORBA.Stub class, and the method
static void connect(java.rmi.Remote unconnected,
java.rmi.Remote connected)
throws RemoteException { ... }
is added to the javax.rmi.PortableRemoteObject class.
The Stub.connect method throws RemoteException if called on a stub that
is already connected to an ORB (i.e., has a delegate set). Otherwise,
a delegate is created for this stub and the specified ORB. This method
is not intended to called directly by application code; instead,
application code should call the PortableRemoteObject.connect method,
which will in turn call the Stub.connect method. This allows the
application code to remain portable between IIOP and JRMP.
The PortableRemoteObject.connect method may take an RMI/IDL stub or
an exported RMI/IDL implementation object as its "unconnected" and
"connected" parameters. If "unconnected" is a connected object
(i.e., an RMI/IDL CORBA stub with a delegate or an implementation
object with an RMI/IDL tie that has been associated with an ORB),
then a RemoteException is thrown. Similarly if "connected" is an
unconnected object (i.e., an RMI/IDL CORBA stub without a delegate
or an implementation object whose RMI/IDL tie has not been associated
with an ORB), then a RemoteException is thrown. Otherwise, "unconnected"
is connected to the same ORB as "connected" by setting its delegate if
it is a stub or by associating its tie with an ORB if it is an
implementation object.
RMI/IDL implementation objects may be connected implicitly by being
passed to javax.rmi.CORBA.writeRemoteObject or
javax.rmi.CORBA.writeAbstractObject, or explicitly by means of the
PortableRemoteObject.connect method. Connecting an implementation
object is not the same as exporting it, and RMI/IDL implementation
objects may be unconnected when first exported. RMI/IDL implementation
objects are implicitly connected when they are exported to JRMP, and
RMI-JRMP stubs are implicitly connected when they are created.
The stub returned by PortableRemoteObject.toStub has the same
connection status as the target implementation object passed to toStub.
So if the target object is connected, the returned stub is connected
to the same ORB. If the target object is unconnected, the returned
stub is unconnected.
The javax.rmi.CORBA.Stub.writeObject method writes the following data
to the serialization stream:
1. int - length of IOR type id
2. byte[] - IOR type ID encoded using ISO 8859-1
3. int - number of IOR profiles
4. For each IOR profile:
a. int - profile tag
b. int - length of profile data
c. byte[] - profile data
Issue 1594: SerializationInputStream and SerializationOutputStream (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
concern to the Objects By Value RTF because it affects the Java
ORB implementation of Objects By Value.
The currently specified delegation relationship between
SerializationInputStream and SerializationOutputStream and their
underlying ORB stream classes is inefficient and awkward.
It is awkward because it requires the ORB implementation of the
underlying streams to know about their "wrapper" serialization
streams and to be careful to always pass out a reference to the
wrapper instead of a "this" pointer. It is inefficient because
all items (even primitives) that are written to these streams
need to go through an extra delegation step through the wrapper
class as the underlying stream does not know whether it can
safely bypass the wrapper method.
Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1595: Unicode example needs fixing (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The Unicode example given in the spec (5.2.4) is x\u22aBy
javac diagnoses \u22aB as an invalid character in an identifier.
A Java identifier may only consist of Unicode characters that denote a
letter or a digit in a language. \u22aB (apparently) does not.
Try \u03bC instead. According to 8.2.1 it"s a Greek mu. javac is happy
with it.
Proposed resolution: fix example
Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: close issue
Discussion:
Issue 1596: Mapping for nested sequences --- fix example (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: mapping for nested sequences:
- error in section 5.6 sequence<seq_Y>
- no occurrence of >> so no need for white space
Proposed resolution: fix example in section 5.6
Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion: resolved, close issue
Issue 1597: Need to emit ID pragmas after declarations (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: 10. Need to emit ID pragmas after declarations
Resolution:
Revised Text: resolved, close issue
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1598: Lexigraphic sort for field names is before mangling (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: Lexigraphic sort for field names is before mangling
Proposed resolution: clarify section 5.5.6
Resolution:
Revised Text: clarify section 5.5.6
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1599: Narrow signature does not allow use for abstract interfaces (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: 12. Narrow signature does not allow use for abstract interfaces
Proposed resolution: return java.lang.Object
Resolution:
Revised Text: return java.lang.Object
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1600: Section 5.7.4 : mapped IDL issue (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: In section 5.7.4 the mapped IDL for Thrower includes:
FruitbatException getLastException();
It should be
readonly attribute ::omega::FruitbatException lastException;
Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion: In section 5.7.4, example IDL, change
Issue 1601: Can toStub take a stub? (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: Can toStub take a stub?
Proposed resolution: yes, in which case it"s a no-op.
Resolution:
Revised Text: yes, in which case it"s a no-op.
Actions taken:
June 29, 1998: received issue
February 24, 1999: closed issue
Discussion:
Issue 1602: Does toStub return most derived stub? (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: 15. does toStub return most derived stub, or iterate looking for one?
Resolution:
Revised Text: resolved, close issue
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion: received issue
Issue 1603: Clarify rules for mapping server-side errors and exceptions (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: 17. Need to clarify rules for mapping server-side errors and runtime
exceptions back to client exceptions.
Proposed resolution: use omg.omg.CORBA.UNKNOWN
Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion: issue resolved and fixed
Issue 1604: The generated IDL in A2 needs to be changed (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The generated IDL in A2 needs to be changed.
In particular, forward declares for fred.Test2 and fred.Stuff must
appear before #includes, before sequence defs and before the module
definition. Their #includes must appear at the end. In fact, just follow
the file layout rules described at the beginning of the appendix.
If this is not done, there is a danger that circular references will
lead to undeclared types when the IDL is compiled.
Proposed resolution: fix example
Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1606: mangling rule for name clashes in IDL needs to be defined (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: Need to define a mangling rule for name clashes in IDL between
constant/method/attribute.
Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1607: Do we need to protect non-generated IDL files against multiple inclusion? (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: Do we need to protect non-generated IDL files against multiple
inclusion?
Proposed resolution: no protection
Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion: No.--close issue
Issue 1608: Rules in section 7.4.4 for toStub IIOP/JRMP search not correct (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: Rules in section 7.4.4 for toStub IIOP/JRMP search aren"t quite correct.
If the object has been exported as IIOP (i.e., an IIOP Tie exists),
no attempt will be made to create a JRMP stub even if there is no IIOP
stub class.
Proposed resolution: clarify spec
Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1609: Should exportObject throw exceptions? (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: 25. Should exportObject throw exceptions?
Resolution:
Revised Text: resolved, close issue
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue
Discussion: received issue
Issue 1610: PortableRemoteObject toStub should throw NoSuchObject Exception (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: PortableRemoteObject.toStub should throw NoSuchObjectException if object
has not been exported.
Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
Discussion: received issue
Issue 1619: Abstract Interfaces issue (java2idl-rtf)
Click here for this issue's archive.
Nature: Revision
Severity:
Summary: Summary: The current Java to IDL mapping spec does not fully address support
for abstract interfaces. There is support for these in the
Portability Interfaces chapter, but not in the RMI/IDL Subset or
IDL Mapping chapters.
Resolution:
Revised Text:
Actions taken:
June 30, 1998: received issue
February 24, 1999: closed issue
Discussion:
Issue 1620: Omission in section 5.4.5 (java2idl-rtf)
Click here for this issue's archive.
Nature: Revision
Severity:
Summary: Summary: The text in section 5.4.5 has no mention of String constants.
This seems to be an accidental omission. I propose replacing
the text in this section by the text in section 5.5.5, with
"value type" changed to "interface".
Resolution:
Revised Text:
Actions taken:
June 30, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1621: Stub methods for hashCode, equals and toString (java2idl-rtf)
Click here for this issue's archive.
Nature: Revision
Severity:
Summary: Summary: RMI/JRMP stubs provide overridden implementations for the
hashCode, equals, and toString methods of java.lang.Object.
The stub hashCode method returns the same hash code for
different stubs that refer to the same remote object.
The stub equals method returns true when stubs that refer
to the same remote object are compared. These methods allow
remote objects to be held in Java collections.
The stub toString method returns a string containing information
about the remote object, not the local stub.
RMI/IIOP stubs should provide equivalent methods. The easiest
way to do this is to add implementations of these three methods
to the javax.rmi.CORBA.Stub base class.
I propose that the definition of javax.rmi.CORBA.Stub in
section 7.2.5 be modified to add these methods.
Resolution:
Revised Text:
Actions taken:
June 30, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1640: Should Portability APIs throw SystemException? (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
concern to the IDL-to-Java RTF because it affects the IDL-to-Java
mapping.
Three of the new portability APIs intorduced by the Java to IDL mapping
are declared as throwing org.omg.CORBA.SystemException. These are
the _invoke methods of ObjectImpl and Delegate and the _invoke method
of InvokeHandler. I don"t think this exception hould be declared
explicitly, since it is a subclass of java.lang.RuntimeException and so
is always implictly throwable whether it is declared or not. Also,
other portability APIs can throw this exception even though they do not
declare it explicitly. This inconsistency makes it very difficult for
the reader of the spec to determine which of the portability APIs can
throw CORBA system exceptions, and is likely to cause confusion.
I propose that org.omg.CORBA.SystemException be removed from the throws
clause of the above-mentioned APIs.
Resolution:
Revised Text:
Actions taken:
July 8, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1641: Mapping of Java names that are IDL keywords (java2idl-rtf)
Click here for this issue's archive.
Nature: Revision
Severity:
Summary: Summary: The Java to IDL mapping spec says that a Java name that is an IDL
keyword is mapped to a mangled name consisting of the IDL keyword
followed by a trailing underscore. Now that the Objects By Value
RTF has adopted escaped identifiers with keading underscores, we
should revise this mapping to use escaped identifiers.
I propose that section 5.2.2 of the Java to IDL mapping spec be
changed to state that Java names that collide with IDL keywords
are mapped to IDL by adding a leading underscore, so that typedef
would be mapped to _typedef.
Resolution:
Revised Text:
Actions taken:
July 8, 1998:
February 23, 1999: closed issue
Discussion:
Issue 1642: Java to IDL identifier mapping (java2idl-rtf)
Click here for this issue's archive.
Nature: Revision
Severity:
Summary: Summary: orbos/98-02-01 says:
We have provided name manglings to work around [the limitations],
but we recommend that OMG consider extending the definitions of
IDL identifiers so that a wider range of unicode characters can
be supported and so that case is significant in distinguishing
identifiers.
I would suggest to remove this recommendation because it is pragmatically
unimplementable for implementation languages that do not support
extended character sets. If the OMG were to take this step, it would
effectively alienate CORBA from all such implementation languages, which
I believe would be detrimental to the success of CORBA.
Because overloaded methods are a popular feature in object-oriented
programming languages we recommend that OMG considers extending
IDL to allow overloaded methods.
Again, I suggest to remove the recommendation because it is pragmatically
unimplementable. Steve Vinoski recently posted an interesting article
on this topic in comp.object.corba -- I have attached a copy below.
Resolution:
Revised Text:
Actions taken:
July 8, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1662: read_AbstractObject and write_AbstractObject (java2idl-rtf)
Click here for this issue's archive.
Nature: Revision
Severity:
Summary: Summary: In section 7.1.2, there is a method called read_AbstractObject(clz).
I propose that we change its name to read_Abstract to bring it
into line with the read_Abstract() method introduced in section
8.7.1 of the OBV spec. This is consistent with having methods
called read_Object() and read_Object(clz).
There"s also a typo in section 7.2.6. It says that
Util.write_AbstractObject calls OutputStream.write_AbstractObject.
This should say OutputStream.write_Abstract.
Resolution:
Revised Text:
Actions taken:
July 10, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1736: Local stubs proposal (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: There is currently no standard support for local RMI/IDL stubs.
In contrast, the IDL/Java mapping specifies how support for local
stubs is to be provided. The Java to IDL mapping should also
specify standard APIs for local stubs which are compatible with
the POA and the mechanisms used by IDL/Java local stubs.
Resolution: closed, accepted
Revised Text: dd the following methods to the javax.rmi.CORBA.Util class:
public static RemoteException wrapException(Throwable obj) { ... }
The wrapException method wraps an exception thrown by an implementation
method. It returns the corresponding client-side exception. See section
28.4.8.1 for details.
public static Object copyObject (Object obj, ORB orb)
throws RemoteException { ... }
public static Object[] copyObjects (Object[] obj, ORB orb)
throws RemoteException { ... }
The copyObject method is used by local stubs to copy an actual parameter,
result object, or exception. The copyObjects method is used by
local stubs to copy any number of actual parameters, preserving sharing
across parameters as necessary to support RMI/IDL semantics. The actual
parameter Object array holds the method parameter objects that need to
be copied, and the result Object array holds the copied results.
The stubs are required to call the above methods (or generate equivalent
inline code) to handle Remote objects correctly.
public static boolean isLocal(Stub s) throws java.rmi.RemoteException { ... };
This method has the same semantics as the ObjectImpl._is_local
method, except that it can throw a java.rmi.RemoteException.
Add the following new section after section 28.5.2.1:
28.5.2.2 Local Stubs
The stub class may provide an optimized call path for local server
implementation objects. For a method echo(int x) of a remote interface
Aardvark, the optimized path does the following:
1. Find out if the servant is local by calling
javax.rmi.CORBA.Util.isLocal()
2. If the servant is local, call
this._servant_preinvoke("echo", Aardvark.class)
3. If _servant_preinvoke returned a non-null ServantObject so, call
((Aardvark)so.servant).echo(x)
4. If _servant_preinvoke returned a non-null ServantObject so, call
this._servant_postinvoke(so)
5. If _servant_preinvoke returned null, repeat step 1. The call to
Util.isLocal() will return false, causing the non-optimized path to
be followed.
The _servant_preinvoke method returns non-null if and only if an optimized
local call may be used. It performs any security checking that may be
necessary.
Local stubs are responsible for performing all copying of method parameters,
results and exceptions that is necessary to provide remote/local-transparent
RMI/IDL semantics.
The following is an example of a stub class that provides this optimized
call path.
public class Aardvark_Stub extends javax.rmi.CORBA.Stub
implements Aardvark {
public int echo(int x) throws java.rmi.RemoteException,
Boomerang {
if (!javax.rmi.CORBA.Util.isLocal(this)) {
InputStream in = null;
try {
try {
OutputStream out = _request("echo", true);
out.write_long(x);
in = _invoke(out);
return in.read_long();
} catch (ApplicationException ex) {
in = ex.getInputStream();
String id = in.read_string();
if (id.equals("IDL:BoomerangEx/1.0")) {
throw (Boomerang)
((org.omg.CORBA_2_3.portable.InputStream)in).
read_Value();
} else {
throw new java.rmi.UnexpectedException(id);
}
} catch (RemarshalException ex) {
return echo(x);
}
} catch (SystemException ex) {
throw javax.rmi.CORBA.Util.mapSystemException(ex);
} finally {
_releaseReply(in);
}
} else {
ServantObject so = _servant_preinvoke("echo", Aardvark.class);
if (so == null)
return echo(x);
try {
return ((Aardvark)so.servant).echo(x);
} catch (Throwable ex) {
Throwable ex2 = (Throwable)Util.copyObject(ex, _orb());
if (ex2 instanceof Boomerang)
throw (Boomerang)ex2;
else
throw Util.wrapException(ex2);
} finally {
_servant_postinvoke(so);
}
}
}
}
Actions taken:
July 27, 1998: received issue
June 4, 1999: closed issue
Discussion:
Issue 1780: JTS exceptions (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The Java-to-IDL spec says in section 6.6.1 that certain CORBA system
exceptions are mapped to the Java exceptions
javax.jts.TransactionRequiredException
javax.jts.TransactionRolledBackException
javax.jts.InvalidTransactionException
The names above are obsolete (since Sun revised the JTS/JTA specs),
so the Java-to-IDL spec needs to be changed. Possible mappings are:
1. javax.transaction.<the_same_names_as_above>
(as listed in the JTA spec)
2. java.rmi.RemoteException
3. No mapping (leave them as CORBA system exceptions)
Option 1 implies a dependency of the RMI-IIOP runtime on these
JTA exception classes.
Resolution:
Revised Text:
Actions taken:
August 6, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1891: Need to #include orb.id (java2idl-rtf)
Click here for this issue's archive.
Nature: Revision
Severity:
Summary: Summary: The example in section A.2 of the Java-to-IDL spec uses the
type ::CORBA::WStringValue but does not define this type.
By CORBA convention, the definition will be in the file
orb.idl, which should be #included in the example IDL code.
I propose that this example be changed to #include orb.idl.
l
Resolution: :CORBA::WStringValue but does not define this type.
Revised Text:
Actions taken:
August 26, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1894: Value methods not mapped in spec examples (java2idl-rtf)
Click here for this issue's archive.
Nature: Revision
Severity:
Summary: Summary: The Java to IDL mapping spec specifies rules for how value
methods are mapped to IDL. However, none of the examples
shows any of these methods actually being mapped. Although
this is legal according to the spec, it has led to some
confusion as to which methods would normally be expected to
be mapped, such as the writeObject method in section 5.5.9.
Resolution:
Revised Text:
Actions taken:
August 27, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1931: Need overloaded write_Value method on OutputStream (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: Suppose we are passing an array of declared type Animal[] and
runtime type Wombat[] but whose elements are all of runtime type
Wombat, where Wombat is a subtype of Animal. This array is mapped
to a boxed valuetype in the org.omg.sequences module. In the
RMI-IIOP stub, we need to write this array by making a write_Value
call (so that sharing can be handled correctly). The repository ID
that we need to write is for a type seq_Animal, based on a static
mapping from the declared type of the array (see section 5.6 of the
Java-to-IDL spec). However, if the stub used the normal write_Value
call that takes a single argument of the object to be written, the
runtime will not be able to put the correct repository ID on the
wire because it only knows about the runtime type of the array, not
the declared type. For the IDL case, this is taken care of by
having the stub generate the form of write_Value that takes a
ValueHelper object for the declared type, but in RMI-IIOP there are
no ValueHelper objects.
Resolution: closed, accepted
Revised Text: RMI/IDL arrays must be marshaled with a repository ID
indicating their runtime type. Also, RMI/IDL arrays must be
demarshaled according to the type specified in the repository ID
of the boxed valuetype in the GIOP encoding.
Actions taken:
September 3, 1998: received issue
June 4, 1999: closed issue
Discussion:
Issue 1957: Mapping of non-public types (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The spec needs to say what happens if a Java public RMI/IDL
value class has data members whose types are not public.
Options: Either a) restrict all uses of non-public types, or
b) map all non-public types to public in IDL.
Inprise have proposed that we adopt option b). Comments?
Resolution:
Revised Text:
Actions taken:
September 15, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1958: Mapping of java.rmi remoteException superclasses (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: There is an issue with the currently specified mapping for Java
remote and abstract interfaces containing methods that throw
superclasses of java.rmi.RemoteException but do not throw
java.rmi.RemoteException. In Java 1.1, these are not recognized
as RMI remote interfaces. In Java 1.2, these are recognized as
RMI remote interfaces.
I propose that throwing these superclass exceptions be treated by
the Java to IDL mapping as semantically equivalent to throwing
both RemoteException and the superclass exception. This means
that the section 4.3 rules for RMI/IDL remote interfaces would
be changed to include this case (in point 3), with similar changes
elsewhere in the spec.
Resolution:
Revised Text:
Actions taken:
September 15, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1960: Mapping of Java arrays (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: Generated names in the ::org::omg::sequences module can clash.
For example, a Java array of type foo[][] and a Java array of type
seq_foo[] both map to ::org::omg::sequences::seq_seq_foo.
I propose that instead of using repeated "seq_" prefixes for the
array dimensions, a single prefix "seq<n>_", where <n> is the
number of dimensions, should be used. This ensures no clashes.
In the example above, these Java types would map to seq2_foo and
seq1_seq_foo.
Resolution:
Revised Text: :org::omg::sequences::seq_seq_foo.
Actions taken:
September 16, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 1965: Eliminating server wait code (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: An RMI-JRMP server creates and exports server objects and then
returns. A non-daemon thread created by the JRMP runtime keeps the
server process alive until there are no more objects exported.
For code portability, an RMI-IIOP server needs to work in a similar
way. It is not acceptable to require a call to ORB.run() or the
use of application "wait" code to keep the server process alive.
I propose that the specification of PortableRemoteObject.exportObject
be updated to say that the first call to this creates a non-daemon
thread which keeps the JVM alive until all exported objects have
been unexported by calls to PortableRemoteObject.unexportObject.
Resolution:
Revised Text:
Actions taken:
September 16, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 2081: Specifying code downloading (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The spec should mandate codebase annotation when marshalling in Java,
and should specify how the annotation is selected.
The spec should mandate code downloading using the codebase annotation
when demarshalling in Java, and should specify the classloader semantics.
Resolution: Closed, accepted
Revised Text: Requirements
The spec should allow codebase annotation when marshalling in Java,
and should specify how the annotation is selected for RMI-IIOP
values and object references.
The spec should mandate code downloading using the codebase annotation
for Java demarshalling of RMI-IIOP values, stubs and ties, and should
specify the classloader semantics.
Original Proposal
This proposal is defined in terms of JDK 1.2 APIs.
When sending from Java, for any given java.lang.Class instance C, the
codebase annotation used must be equivalent to the codebase returned by:
java.rmi.server.RMIClassLoader.getClassAnnotation(C);
(with the string parsed into space-separated URL strings).
When receiving in Java, for any given class name N, if there is no codebase
annotation, or if the system property java.rmi.server.useCodebaseOnly is
equal to "true" ignoring case, then the Java class that this name resolves
to must be the same as that returned by:
java.rmi.server.RMIClassLoader.loadClass(N);
Otherwise, if the codebase annotation is CA, then the Java class that this
name resolves to must be the same as that returned by:
java.rmi.server.RMIClassLoader.loadClass(CA, N);
(with CA turned into a single string with space as separator).
Ammended Proposal
Class downloading is supported for stubs, ties, values, and value helpers.
The implementation is based on the original proposal, with enhancements to
enable implementation on JDK 1.1.6 APIs, to enable transmission of
codebase information on the wire for stubs and ties, and to enable usage
of pre-existing ClassLoaders when relevant.
Definitions
"codebase" - A java.lang.String containing a space-separated array of URLs
(e.g. "http://acme.com/classes" or "http://abc.net/classes
http://abc.net/ext/classes"). [Note: the space-separated representation is
preferred over a String[] representation in order to avoid conversion when
calling the 1.2 JDK RMI APIs.]
"localCodebase" - The System Property "java.rmi.server.codebase" whose
value is a codebase or null. Defaults to null.
"remoteCodebase" - The codebase transmitted from a remote system. May be
null.
"useCodebaseOnly" - The System Property "java.rmi.server.useCodebaseOnly"
whose value is either "true" or "false". Defaults to "false". If "true"
(ignoring case), any remote codebase is ignored and only the local codebase
used.
"loadingContext" - A class that specifies a context within which class loading
is initiated. May be null.
Codebase Selection
The following method is added to the javax.rmi.CORBA.Util class:
public static String getCodebase(java.lang.Class clz) { ... }
On JDK 1.2, this method returns the same string as:
java.rmi.server.RMIClassLoader.getClassAnnotation(clz)
On JDK 1.1, this method works as follows:
1. If the name of clz starts with "java.", then return null, else...
2. If clz has a ClassLoader with a URL security context, then return
this URL, else...
3. If there is a security manager with a URL security context, then
return this URL, else...
4 Return localCodebase.
When sending RMI/IDL values from Java, the codebase transmitted over GIOP
must be the codebase that this method would return for the value's class.
When sending RMI/IDL object references from Java, the codebase transmitted
over GIOP is selected by calling the
org.omg.CORBA_2_3.portable.ObjectImpl._get_codebase method (see below) on
the stub object.
Codebase Transmission
For values and value helpers, the OBV specification defines the wire format
for codebase transmission.
For stubs and ties, the codebase is transmitted as a TaggedComponent in
the IOR profile, where the component_data is a CDR encapsulation of the
codebase written as an IDL string. The codebase is a blank-separated
list of one or more URLs.
[NOTE: component_id needs to be assigned by the Interoperability RTF.]
In all cases, the SendingContext.RunTime object may provide a default
codebase that is used if not overridden by a more specific codebase
encoded in a valuetype or IOR.
For object references created using InputStream.read_Object or
InputStream.read_Abstract, the transmitted codebase is stored in the
object reference (stub) and can be retrieved subsequently using the
org.omg.CORBA_2_3.portable.ObjectImpl._get_codebase method, described below.
If no codebase was transmitted, localCodebase is stored in the object
reference (stub).
Codebase Access
In the event that PortableRemoteObject.narrow() must load a stub, a new API
is required to extract codebase information from the original stub. This
API is also used by the OutputStream methods write_Object and write_Abstract
to obtain the codebase to be transmitted in the new TaggedComponent.
The following method is added to org.omg.CORBA_2_3.portable.ObjectImpl, which
is a newly created subclass of org.omg.CORBA.portable.ObjectImpl:
/** Returns the codebase for this object reference.
* @return the codebase as a space delimited list of url strings or
* null if none.
*/
public java.lang.String _get_codebase()
{
return ((org.omg.CORBA_2_3.portable.Delegate)_get_delegate()).get_codebase(this);
}
and a corresponding method is added to org.omg.CORBA_2_3.portable.Delegate,
which is a newly created subclass of org.omg.CORBA.portable.Delegate:
/** Returns the codebase for the object reference provided.
* @param self the object reference whose codebase needs to be returned.
* @return the codebase as a space delimited list of url strings or
* null if none.
*/
public java.lang.String get_codebase(org.omg.CORBA.Object self)
{
return null;
}
The javax.rmi.CORBA.Stub class is changed to extend
org.omg.CORBA_2_3.portable.ObjectImpl instead of org.omg.CORBA.portable.ObjectImpl.
Codebase Usage
The following method is added to the javax.rmi.CORBA.Util class:
public static Class loadClass(String className, String remoteCodebase,
Class loadingContext)
throws ClassNotFoundException { ... }
On JDK 1.2, this method works as follows:
1. Find the first non-null ClassLoader on the call stack, and attempt
to load the class using this ClassLoader. If this fails...
2. If remoteCodebase is non-null and useCodebaseOnly is false, then call
java.rmi.server.RMIClassLoader.loadClass(remoteCodebase, className).
3. If remoteCodebase is null or useCodebaseOnly is true, then call
java.rmi.server.RMIClassLoader.loadClass(className).
4. If a class was not successfully loaded by step 1, 2, or 3, and
loadingContext and loadingContext.getClassLoader() are both non-null,
then call loadingContext.getClassLoader().loadClass(className).
5. If a class was successfully loaded by step 1, 2, 3, or 4, then return
the loaded class.
On JDK 1.1, this method works as follows:
1. If className is an array type, extract the array element type. If this
is a primitive type, then call Class.forName(className), else proceed
using the array element class name as className.
2. Search the call stack for the first non-null ClassLoader. If a ClassLoader
is found, then attempt to load the class using this ClassLoader, else
attempt to load the class using Class.ForName(className). If this fails...
3. If remoteCodebase is non-null and useCodebaseOnly is false, then call
java.rmi.server.RMIClassLoader.loadClass(codebaseURL, className) for
each remote codebase URL in the remoteCodebase string until the class
is found.
4. If remoteCodebase is null or useCodebaseOnly is true, then call
java.rmi.server.RMIClassLoader.loadClass(className).
5. If a class was not successfully loaded by step 1, 2, 3, or 4, and
loadingContext and loadingContext.getClassLoader() are both non-null,
then call loadingContext.getClassLoader().loadClass(className).
6. If a class was successfully loaded by step 1, 2, 3, 4, or 5, then return
the loaded class, unless the className parameter was a non-primitive
array type, in which case return a suitably dimensioned array class
for the element class that was loaded.
When loading classes for RMI/IDL values, stubs, and ties, the class
loaded must be be the same as that returned by this method except where
stated below.
For values and their helper classes, remoteCodebase is the codebase that was
transmitted in the GIOP valuetype encoding (if any), or else the codebase
obtained from the SendingContext.RunTime object associated with the IIOP
connection. loadingContext is null or the expected value class, if known.
For ties created by PortableRemoteObject.exportObject, remoteCodebase is
obtained by calling Util.getCodebase on the class of the implementation object.
loadingContext is null.
For stubs created by InputStream.read_Object(), remoteCodebase is the codebase
transmitted in the new IOR TaggedComponent (if any), or else the codebase
obtained from the SendingContext.RunTime object associated with the IIOP
connection. This method may either create a generic stub for subsequent
narrowing or may attempt to create a stub by loading a stub class that matches
the RepositoryId in the IOR. loadingContext is null.
For stubs created by InputStream.read_Object(clz), remoteCodebase is the same
as for InputStream.read_Object(). The implementation of read_Object(clz) may
either use the actual parameter clz to create a stub or may attempt to create
a stub by loading a stub class that matches the RepositoryId in the IOR.
loadingContext is clz.
For stubs created by PortableRemoteObject.narrow, remoteCodebase is obtained
from the narrowFrom object by calling the ObjectImpl._get_codebase method.
For stubs created by PortableRemoteObject.toStub, Util.writeRemoteObject
or Util.writeAbstractObject, remoteCodebase is obtained by calling
Util.getCodebase on the class of the implementation object. loadingContext
is narrowFrom.
For all stubs, remoteCodebase is stored by the Delegate and can be retrieved
subsequently using the org.omg.CORBA_2_3.portable.ObjectImpl._get_codebase
method.
Other Changes
In section 28.3.5.11, change the definition of javax.rmi.CORBA.ClassDesc to:
// Java
package javax.rmi.CORBA;
public class ClassDesc implements java.io.Serializable {
private String repid;
private String codebase; // blank-separated list of URLs
}
Actions taken:
October 14, 1998: received issue
June 4, 1999: closed issue
Discussion:
Issue 2082: Mapping of RuntimeException (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: If a Java method explictly declares that it throws RuntimeException or
some subclass, the current spec says that these should be retained in
the mapping to IDL. I think this is wrong; they should be dropped
when mapping to IDL. The reasoning is along the same lines as dropping
subclasses of RemoteException.
Resolution:
Revised Text:
Actions taken:
October 14, 1998: received issue
February 23, 1999: closed issue
Discussion: issue resolved and closed
Issue 2088: The mapping of java.lang.Class to IDL is not specified (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The mapping of java.lang.Class to IDL is not specified. An
interesting subquestion is whether it"s possible to transmit a
Class that has not previously been mapped to IDL.
Resolution:
Revised Text:
Actions taken:
October 16, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 2089: Custom marshalling wire format (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The full wire format produced by ObjectOutputStream really needs
to be specified. E.g., I would assume that anything written with
writeObject gets marshalled as an Any. In normal Java
serialization, consecutive primitive writes (writeByte, writeInt,
etc.) are aggregated into chunks with size lengths, and tagged
to distinguish it from other data. In this way, ObjectInputStream
can ensure that major stream corruption never occurs: it can
make sure that a primitive read never eats into object data,
and vice versa. Is a similar format used for IIOP?
Resolution: Closed, accepted
Revised Text: In section 28.3.5.6, change the mapping for Serializable classes with a
writeObject method so that non-public fields are mapped to IDL private
fields in the custom valuetype.
Add the following section after section 28.3.5.6:
28.3.5.7 Custom Marshaling Format
When an RMI/IDL value type is custom marshaled over GIOP, the following
data is transmitted:
1. Serializable objects with a writeObject method.
octet Format version. Always 1.
boolean True if defaultWriteObject was called, false otherwise.
... (optional) Data written by defaultWriteObject. The ordering
of the fields is the same as the order in which they appear
in the mapped IDL valuetype, and these fields are encoded
exactly as they would be if the class did not have a
writeObject method.
... (optional) Additional data written by writeObject, encoded
as specified below.
2. Externalizable objects.
octet Format version. Always 1.
... (optional) Data written by writeExternal, encoded as
specified below.
Primitive Java types are marshaled as their corresponding IDL primitives
(see section 28.3.3). Java objects are marshaled in the form of an IDL
abstract interface, i.e., a union with a boolean discriminator containing
either an object reference if the discriminator is true or a value type
if the discriminator is false.
RMI/IDL stubs, RMI/IDL remote implementations, and IDL stubs are
marshaled as object references (IORs). All other Java objects are
marshaled as value types. The value type encoding is determined from the
object's runtime type by applying the mappings specified in sections
28.3.5, 28.3.6, and 28.3.7.
This encoding ensures that primitive data is marshaled using a chunked
encoding and cannot incorrectly be read in as object data. The GIOP
specification states that custom marshaled types must be marshaled using
a chunked encoding. Therefore, if primitive data is written followed
by a value object, the currently open chunk for the primitive data will
automatically be ended before the value tag is written. This prevents
primitive read operations from consuming a value header (chunk underflow),
and also prevents read_Value operations from consuming primitive data
(chunk overflow).
This mechanism does not prevent primitive reads from consuming non-matching
primitive data, which is also true for Java deserialization. However, it
is possible for primitive reads to consume IOR data, and vice versa.
Reading an incorrect IOR will either cause a MARSHAL error or in rare cases
create an unusable object reference (e.g., incorrect host name, port number,
or object key). Since neither of these violates the integrity of the local
system, this small exposure is acceptable.
Actions taken:
October 16, 1998: received issue
June 4, 1999: closed issue
Discussion:
Issue 2090: Mapping of Object, Serializable and Externalizable (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The proposal here is to map Object, Serializable and Externalizable
to distinct entities, rather than just to an any.
These entities are
module java {
module lang {
typedef any _Object;
};
module io {
typedef any Serializable;
typedef any Externalizable;
};
};
and so
java.lang.Object will map to ::java::lang::_Object,
java.io.Serializable will map to ::java::io::Serializable, and
java.io.Externalizable will map to ::java::io.Externalizable
Resolution:
Revised Text:
Actions taken:
October 16, 1998: received issue
February 23, 1999: closed issue
Discussion:
Issue 2091: Support for serialPersistentFields (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: Moving forward to JDK 1.2, the IDL value type data mapping needs
to factor in the new serialPersistentFields declaration. And there"s
an interesting question whether the existence of a writeReplace method
should influence the decision to map to a custom value.
Resolution:
Revised Text:
Actions taken:
October 16, 1998: received issue
May 16, 2006: closed issue
Discussion: Adopted proposal:
Issue 2092: RMI/ORB marshalling interface (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The ORB should be responsible for marshalling all value headers and
other protocol specific data. The RMI runtime should only marshal
the state of the object. In other words, we exepect the contract
between the ORB and RMI to be the similar to that of the ORB and
an IDL generated ValueHelper.
- The APIs should allow all RMI types supported by the IDL-Java mapping
to be marshalled completely and correctly.
- The APIs should be flexible enough to allow for some change in either
RMI/Serialization semantics or changes to OBV wire protocol.
Resolution: Closed, accepted
Revised Text: 1. Add the following methods to ValueHandler:
java.lang.String getRMIRepositoryID(java.lang.Class clz);
boolean isCustomMarshaled(java.lang.Class clz);
SendingContext.CodeBase getRunTimeCodeBase();
java.io.Serializable writeReplace(java.io.Serializable value);
When marshaling an RMI value, the ORB stream must call Util.getCodeBase
to get the codebase string, ValueHandler.getRMIRepositoryID to get the
repository ID string, and ValueHandler.isCustomMarshaled to see if the
value is custom marshaled and therefore requires a chunked encoding.
The ORB stream writes the value tag, codebase (if any), and repository ID.
It calls ValueHandler.write_Value to write the state of the value.
The ORB stream deals with nulls, indirections, chunking, and end tags.
The ORB obtains the SendingContextRunTime service context from the
ValueHandler by calling the ValueHandler.getRunTimeCodeBase method.
Clients must send this service context on the first GIOP request that
flows over a connection that may be used to send RMI values to the
server. Servers must send this service context on the first GIOP
reply that flows over a connection that may be used to send RMI values
to the client.
The ORB calls the writeReplace method before calling writeValue.
The result from calling this method is passed to ValueHandler.writeValue
unless either
a. it is a previously marshalled value, in which case it is marshalled
as an indirection, or
b. its class implements org.omg.CORBA.Object, in which case it is
marshalled as an object reference.
An ORB stream instance must only call writeReplace once for each value
that it marshals.
2. Change the names of the ValueHandler read_Value and write_Value methods
to readValue and writeValue to be consistent with Java method naming
conventions.
3. Change the readValue method of ValueHandler to the following
signature:
java.io.Serializable readValue(
org.omg.CORBA.portable.InputStream in,
int offset,
java.lang.Class clz,
String repositoryID,
org.omg.SendingContext.RunTime sender) { ... }
When demarshaling an RMI value, the ORB stream must read the value tag,
codebase (if any), and repository ID. The ORB stream calls Util.loadClass
to load the value's class, passing the Java class name contained in the
RMI-style repository ID and the codebase string from the value's GIOP
encoding (if present) or the SendingContextRunTime service context.
The ORB stream calls ValueHandler.readValue to read the state of the
value, passing the current stream offset, the class returned by loadClass,
the repository ID, and the sender's SendingContext.RunTime object reference.
The repository ID is needed so that the ValueHandler can determine if the
class passed in is structurally identical to the class used by the
sender to marshal the value. The ORB stream deals with nulls, indirections,
chunking, and end tags.
4. Add a new exception org.omg.CORBA.portable.IndirectionException:
public class IndirectionException
extends org.omg.CORBA.SystemException {
int offset;
}
The ORB input stream throws this exception when it is called to demarshal
a value that is encoded as an indirection that is in the process of being
demarshalled. This can occur when the ORB stream calls the ValueHandler
to demarshal an RMI value whose state contains a recursive reference to
itself. Because the top-level ValueHandler.readValue call has not yet
returned a value, the ORB stream's indirection table contains no entry
for an object with the stream offset specified by the indirection tag.
This stream offset is returned in the exception's "offset" field.
When the ValueHandler receives this exception, it stores the stream
offset together with a reflective object that can be used later to
update the field to which the result of calling the ORB stream's
read_Value method would have been assigned. These [offset,fieldref]
pairs are stored in a "fixup" table that is associated with the InputStream
that the ValueHandler is using for its current demarshaling operation.
Before the ValueHandler.readValue method returns to the ORB stream, it
checks this fixup table for an entry with the offset passed in on the
readValue call. If an entry matching the offset is found, it performs
a fixup using the reflective fieldref object and the value it is about
to return, then removes this fixup entry. When the top-level readValue
call returns, the fixup table should be empty, indicating that all
fixups have successfully been performed. If the table is not empty,
this indicates an incorrect indirection in the GIOP value encoding,
and a MARSHAL exception is thrown to indicate this.
This scheme deals successfully with recursive references without
introducing new API calls and with minimal overheads in the
common case of a value that does not contain recursive references.
In this case, the only overhead is the need to pass the "offset"
parameter on the call to ValueHandler.readValue.
Actions taken:
October 16, 1998: received issue
June 4, 1999: closed issue
Discussion:
Issue 2111: mapping from java.rmi Remote to CORBA::Object (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: Are we trying to support sending JRMP stubs over IIOP? If so, then
it would seem that the IDL mapping of java.rmi.Remote to CORBA::Object
works against that; it would need to be changed to Any.
Resolution: See revised text below.
Revised Text: In section 1.5.1.4, at the end of the paragraphs describing writeRemoteObject and writeAbstractObject, add the sentence: "This
method cannot be used to write a JRMP object reference to an output stream."
Actions taken:
October 20, 1998: received issue
May 24, 2001: closed issue
Discussion:
Issue 2225: javax.rmi package use (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: It has concerned me for a while the use of the javax.rmi package in the Java
to IDL mapping. I think that PortableRemoteObject and other classes should be
placed in a subpackage. We may in the future put subpackages in javax.rmi and
would like it organized much better than it is currently. The
PortableRemoteObject class should be put in a subpackage "portable" or
something else. I"d like to raise this as an issue to discuss at the RTF.
There are still other issues that are being ironed out, and I think that this
one can be addressed along with the others.
Resolution: Closed, no change
Revised Text:
Actions taken:
November 19, 1998: received issue
June 4, 1999: closed issue
Discussion:
Issue 2370: Mangling of Java long type not specified (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The overloaded method name mangling for the Java long type is not
specified in the spec. My suggestion is to use "long_long".
Resolution: Closed, accepted
Revised Text: In mangled overloaded IDL method names, the IDL type "long long" shall
appear as "long_long".
Actions taken:
February 2, 1999: received issue
June 4, 1999: closed issue
Discussion:
Issue 2466: Mapping private Java methods to IDL (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: Java private methods and constructors should not be mapped to IDL.
This has been agreed by the RTF, but an OMG issue number is needed.
Resolution: Closed, accepted (see summary for text)
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue
Discussion:
Issue 2467: Change write_* names in Util class (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: In the javax.rmi.CORBA.Util class, the following names should be
changed for consistency with the naming convention used in this package:
write_RemoteObject to writeRemoteObject
write_AbstractObject to writeAbstractObject
This has been agreed by the RTF, but an OMG issue number is needed.
Resolution: Closed, accepted (see summary for text)
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue
Discussion:
Issue 2468: IIOP/JRMP stubs name clash (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The names of generated stub classes can be the same in some cases for
IIOP and JRMP. This is a source of user error and confusion.
Resolution: Closed, accepted (see summary for text)
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue
Discussion:
Issue 2469: IDLEntity exception types as parameters and results (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The specified Java to IDL mapping for IDLEntity exception types does
not work for method parameters and results, because IDL exception
types cannot be passed as method parameters and results.
Resolution: Closed, accepted (see summary for text)
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue
Discussion:
Issue 2470: Completion status missing from exception string (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The mapping of CORBA system exceptions to Java remote exceptions
omits the completion status information. This should be preserved
in the detail string.
Resolution: Closed, accepted
Revised Text: Add the following to the end of the description of the detail string for
RMI Exceptions mapped from CORBA system exceptions:
. followed by a space
. followed by the completion status: one of "Yes" "No" "Maybe"
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue
Discussion:
Issue 2471: RMI/IDL Tie changes (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The following changes will improve the code generated for RMI/IDL Ties:
a) RMI/IDL Tie classes shall catch org.omg.CORBA.SystemException and
rethrow it (unwrapped by UnknownException).
b) Change the signature of Util.mapSystemException to
public static java.rmi.RemoteException
mapSystemException(org.omg.CORBA.SystemException ex);
c) RMI/IDL Tie classes shall throw the result from mapSystemException.
d) mapSystemException shall return the mapped exception if it is an
instance of RemoteException or a subclass, and shall throw the
mapped exception in all other cases.
This has been agreed by the RTF, but an OMG issue number is needed.
Resolution: Closed, accepted (see summary for text)
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue
Discussion:
Issue 2472: Interfaces and values should be mapped consistently (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The Java to IDL mapping rules for remote interfaces and value types
should be consistent except where there is clear need for differences.
Resolution: Closed, accepted
Revised Text: a. Change the mapping for exceptions on methods of value types
to not map RemoteException, RuntimeException and their
subclasses to IDL.
b. Change the mapping for property accessors on value types to
be the same as on remote interfaces.
c. Changes a and b also apply to abstract interfaces.
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue
Discussion:
Issue 2473: Mappings for non-conforming types (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The mapping for methods and constants in non-conforming types
should be specified (by cross-reference to the words for value types).
Resolution: Closed, accepted (see summary for text)
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue
Discussion:
Issue 2474: Mapping for non-conforming class (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The mapping of a non-conforming class should be abstract valuetype,
not valuetype. This is because instances of this type are not
serializable, but instances of its subtypes are serializable.
Resolution: Closed, accepted (see summary for text)
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue
Discussion:
Issue 2475: Definition of Stub.equals method (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: The definition of the equals method of javax.rmi.CORBA.Stub should
say that this method returns false when used to compare stubs that
do not represent the same remote object.
Resolution: Closed, accepted (see summary for text)
Revised Text:
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue
Discussion:
Issue 2476: IDLEntity types need to be boxed (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: When IDLEntity types are mapped from Java to IDL, they need to be
mapped as valuetypes to preserve RMI null and sharing semantics.
For most IDLEntity types, this will require the generation of
boxed valuetypes in IDL, similarly to the mapping of Java arrays to
IDL boxed sequences.
Resolution: Closed, accepted
Revised Text: 28.2.1
add two new bullets
- is a conforming CORBA object reference (see section 28.2.7)
- is a conforming IDL entity (see section 28.2.8)
Add new section 28.2.7 CORBA Object References
A conforming CORBA object reference is either
- the Java interface org.omg.CORBA.Object or
- a Java interface that extends org.omg.CORBA.Object directly or
indirectly and conforms to the rules specified in the Java Language
mapping (i.e., could have been generated by applying the mapping to
an IDL definition).
Add new section 28.2.8 IDL Entities
A Java class is a conforming RMI/IDL type if it extends
org.omg.CORBA.portable.IDLEntity and conforms to the rules specified in
the Java Language mapping (i.e., could have been generated by applying
the mapping to an IDL definition), and is not an IDL user exception.
Add 2 new bullets to 28.3.1 after the 5th bullet - RMI/IDL exceptions
- CORBA object references
- IDL entities
Renumber the following sections as below:
28.3.8->28.3.10,
28.3.9->28.3.11,
28.3.10->28.3.12
Change section 28.3.6
globally replace ::org::omg::sequences with ::org::omg::boxedRMI
and org_omg_sequences with org_omg_boxedRMI
After the fourth paragraph, insert a new paragraph:
For each "boxed" value type generated for a Java array, a #pragma ID
is generated to specify an RMI Hashed Format repository ID for the
IDL type.
In the example in section 28.3.6.2, add the following line:
#pragma ID seq1_Dolphin "RMI:[Lomega.Dolphin;:ABCDEF0123456789"
Add new section 28.3.8 Mapping CORBA Object References
A CORBA object reference is mapped directly to its corresponding IDL
interface or to Object if it is org.omg.CORBA.Object.
Add new section 28.3.9 Mapping IDL Entities
An IDL entity that is not a CORBA object reference is mapped to a
"boxed" value type containing the IDL entity.
The containing module for the boxed IDL entity is determined by the IDL
entity's container. A module name is formed by taking the ::org::omg::boxedIDL
prefix and appending the IDL entity's container's fully scoped name. A
boxed value type corresponding to the IDL entity is defined within this
module. The name of the value type is the same as the name of the IDL
definition it is boxing.
For example, assume we have the following IDL and the Java class that
results from applying the forward mapping:
// IDL
module hello {
struct world {
short x;
};
};
// Java
package hello;
public final class world implements org.omg.CORBA.portable.IDLEntity {
...
}
Now assume that hello.world is used as an argument to a method or as a
member of an RMI/IDL value type. The Java class hello.world is mapped
as follows:
hello.world ==> in the module ::org::omg::boxedIDL::hello define
valuetype world ::hello::world;
#pragma ID world "RMI:[Lhello.world;:1234567890ABCDEF"
The exact mechanism by which the IDL for ::hello::world is created is a
tools issue and is not specified.
(Note to rtf: Specifying a conversion algorithm will effectively require
creating a reversible mapping, which is not the intent of this proposal.
There are many ways this can be achieved. One mechanism would be to pass
the original IDL file in the command line of the tool, and read the
definitions from the IDL file.)
Preprocessor guards are placed for these definitions in the same way as
they are done for mapping arrays.
Add new section 28.4.7 (move all sections from 28.4.7 up by one).
28.4.7 Marshaling IDL entities
Marshaling and demarshaling of IDL entities is done by calling
write_Value(java.io.Serializable) and read_Value() on the portable
output and input streams respectively.
Actions taken:
February 22, 1999: received issue
June 4, 1999: closed issue
Discussion:
Issue 2477: RMI Repository ID proposed change (java2idl-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Summary: For the scoped name component, it is far simpler to use the actual class
name of the java class with all the invalid IDL characters unicode escaped.
Resolution: Closed, accepted
Revised Text: Resolution: make it so. This has been modified to correct errors in the RMI format specification and is being put up for vote to approve the mdified and error
corrected version.
Revised Text:
In section 10.6, change text added by resolution to issue 2329 from:
This specification defines four formats: one derived from OMG IDL names,
one that uses OMG IDL names and Java serialization version UIDs, one that
uses DCE UUIDs, and another intended for short-term use, such as in a
development