Java Serializable classes can define their own readObject/writeObject
methods which take java.io.ObjectInputStream and
java.io.ObjectOutputStream parameters, respectively.

What is the proper behavior of the readUTF and writeUTF methods on these
streams in RMI-IIOP? The Java to IDL specification doesn't mention
these methods.

Proposed resolution:

In RMI-IIOP, java.io.ObjectOutputStream's writeUTF method should write a
CORBA wstring. Similarly, readUTF should read a CORBA wstring.

Discussion:

One must override these methods to avoid using the internal java.io
implementations. Looking at the JDK 1.3 code, the behavior is specific
to Java serialization. If one doesn't override writeUTF and readUTF,
Java serialization mechanisms such as blocks (similar to chunks) may be
introduced on the wire in RMI-IIOP.

See revised text below

The Java to IDL spec
(http://cgi.omg.org/cgi-bin/doc?ptc/00-01-06, section 1.5.1.4 page 47)
says:

"The isLocal method has the same semantics as the ObjectImpl._is_local
method, except that it can throw a RemoteException."

However, it does not specify under what conditions a remote exception
is thrown.

Either the exception condition(s) should be specified or the exception
should be removed from the signature.

See revised text below

There is a problem in the stream format for custom marshalled RMI types.
The Java serialization spec requires that when a class with a writeObject
method calls defaultWriteObject and then writes optional data, the receiver
must be able to skip the optional data if the readObject does not consume
it or the class is not in the receiver's hierarchy. So if the sender's
hierarchy consists of serializable classes Base and Derived, both of which
call defaultWriteObject and then write optional data, there must be a way
for the unmarshaller to first skip to the end of the Base data, then skip
to the end of the Derived data. With the current stream format, this is
not possible.

see below

The local mapping makes it impossible to determine which ending point
to call.

ptc/00-01-06 says:

BEGIN_QUOTE

1.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 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
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 following is an example of a stub class that provides this
optimized call path.

// Java
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))

else {
// local call path
org.omg.CORBA.portable.ServantObject so =
_servant_preinvoke("echo", Aardvark.class);
if (so == null)
return echo;
try

catch (Throwable ex)

finally

}
}
}

END_QUOTE

ClientRequestInterceptor::send_request would need to be invoked by the
ORB inside _servant_preinvoke.

ClientRequestInterceptor::receive_reply or receive_exception would
need to be called inside _servant_postinvoke.

(Note that receive_other would not happen since, if a POA were
involved inside _servant_preinvoke and a servant manager raised
ForwardRequest, this should cause _servant_preinvoke to return null
resulting in a recursive call to the method. In this case the ORB
would not call send_request in the first place, or, if it did, it
would handle the call to the receive_other internally inside of
_servant_preinvoke.)

One is tempted to say that the ORB could remember if
javax.rmi.CORBA.Util.copyObject was called on behalf of this request.
In that case, when _servant_postinvoke is called it would know there
was an exception (and would have it hands on the exception object -
which needs to be available via Portable Interceptors).

However, this does not work. The example does not show it, but if the
method returns values those values are filtered through
javax.rmi.CORBA.Util.copyObject before being returned to the client.
Exception objects are legal return values. So there is no way to
determine if copyObject was called to copy return values or exception
objects resulting from an actually exception. Therefore this trick
will not work.

Bottom line: there is no reliable way to determine which Portable
Interceptor ending point to call in the Java reverse mapping local
case.

see below

The Java to IDL Language Mapping (formal/99-07-59) seems to contradict the CORBA/IIOP 2.3.1 Specification (formal/99-10-07) over exceptions being raised by valuetype initialisers.

Section 1.3.5.4 of 99-07-59, point 3 states that exceptions thrown by a constructor of an object-by-value class are mapped to the corresponding OMG IDL exception.

On the other hand, section 2.8.1.5 of 99-10-07 does not allow initialisers to include a raises clause (contrast this with the syntax for an operation declaration in section 3.12).

This is a significant inter-operability problem. In my case the IDL generated by the IBM/SUN RMI-IIOP Java-to-IDL compiler (which includes 'raises' clauses in valuetype initialisers) is rejected as syntactically invalid by the MICO IDL-to-C++ compiler.
submit: Submit Issue Report

Close, no change. Core RTF issue 4785 has added exceptions to IDL valuetype initializers, which reso

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. This usage has been defined for the IDL to Java
mapping (issue 4013) but not for the Java to IDL mapping.

The resolution for issue 4013 defines how this service context shall be used
when marshaling and unmarshaling system exceptions. However, an RMI-IIOP client
never receives a system exception, but instead receives a mapped RemoteException
or RuntimeException that was created by applying the rules specified in
section 1.4.8. Currently these rules do not take account of any detail message
that the system exception has acquired from the ExceptionDetailMessage service
context by applying the mappings specified by the resolution of issue 4013.

In order to ensure that this valuable diagnostic information is available on
exceptions received by RMI-IIOP clients as well as IDL clients, I propose the
following change to section 1.4.8 of the Java to IDL mapping spec.

Proposed resolution:

After table 1-2, replace

"In all cases, ..."

by

"If the getMessage() method of the CORBA system exception returns a non-null
and non-empty string, the RMI exception is created with this string as its
detail string. In all other cases, ..."

see above

A Serializable or Externalizable can define methods which take
java.io.ObjectOutputStreams. There are four methods on that class
that are well defined in Java, but the mapping to CORBA may need to be
clarified:

writeByte(int)
writeChar(int)
writeBytes(String)
writeChars(String)

Please see the Java docs for these methods:

http://java.sun.com/j2se/1.3/docs/api/java/io/DataOutput.html#writeByte(int)
http://java.sun.com/j2se/1.3/docs/api/java/io/DataOutput.html#writeChar(int)
http://java.sun.com/j2se/1.3/docs/api/java/io/DataOutput.html#writeBytes(java.lang.String)
http://java.sun.com/j2se/1.3/docs/api/java/io/DataOutput.html#writeChars(java.lang.String)

Based on those detailed definitions, I'd say the mapping would be:

writeByte(int)

• write_octet of the lower 8 bits of the int

writeChar(int)

• two write_octet calls in the order as shown in the java docs

writeBytes(String)

• For each char in the String, call charAt, take the lower 8 bits, and
  call write_octet

writeChars(String)

• For each char in the String, call charAt, split the char into two
  bytes, and make two write_octet calls in the order shown in the java
  docs

Another interpretation might be to use wstrings or wchar arrays for
writeChars. The problem I see there is that since there isn't a
readChars method, the user will be using the DataInput methods
readFully or multiple readChar calls to reconstruct the String. Since
the wire format of wstrings/wchars depends on the code set, he might
start to see code set specific bytes instead of the expected bytes
detailed in the java docs of writeChars and writeChar.

see below

The Java to IDL mapping spec says that serializable Java classes that
have a writeObject method are mapped to IDL custom valuetypes. This
should also apply to any Java subclasses of these classes, since otherwise
the generated IDL is illegal. (An IDL non-custom valuetype can't
inherit from an IDL custom valuetype.)

Proposed resolution:

In section 1.3.5.6 of the Java to IDL mapping spec, change the first sentence
of the second paragraph from

If the class does not implement java.io.Externalizable but does have a
writeObject method, ...

to:

If the class does not implement java.io.Externalizable but does have a
writeObject method, or extends such a class directly or indirectly, ...

Closed, accepted. See revised text below

When using the local stub with for example an EJB application, we discovered the following critical issue.

Let's take an simple example :

public interface HelloWorld extends javax.rmi.EJBObject

The generated Stub according to the mapping rules contains the methods for the inherited interface as for example 'getEJBHome'.

For a local invocation on 'getEJBHome' the following part of the stub will be used :

public javax.ejb.EJBHome getEJBHome() throws java.rmi.RemoteException { while( true ) { if (!javax.rmi.CORBA.Util.isLocal(this) )

else { org.omg.CORBA.portable.ServantObject _so = _servant_preinvoke("EJBHome", HelloWorld.class);

if ( _so == null ) return getEJBHome();

try

catch ( Throwable ex )

finally {_servant_postinvoke(_so); } } } }

The '_servant_preinvoke' method will return a servant class of type 'HelloWorld' that implements the 'getEJBHome' operation.

Thus, the '_HelloWorld_Tie' servant is returned.

Then, the cast to convert the returned servant to 'javax.ejb.EJBObject' will fail since the servant doesn't implement this interface ( it only inherits from org.omg.PortableServer.Servant and implements javax.rmi.CORBA.Tie ).

Thus, by using the local stub, it is not possible to invoke an inherited operation.

Solution :

The returned servant is always implementing 'javax.rmi.CORBA.Tie'. To allow the correct cast to 'javax.ejb.EJBObject' we need to access the final target instead of the servant itself. So the following solution can be always applied :

javax.rmi.CORBA.Tie tie = ((javax.rmi.CORBA.Tie)_so.servant);

return ((javax.ejb.EJBObject)tie.getTarget()).getEJBHome();

Closed, accepted. See revised text below.

I'd like to raise the following as an urgent issue for the Java to IDL
RTF:

RuntimeExceptions/Errors are broken in RMI-IIOP when interoperating
between J2SE 1.3 and 1.4 (or "class evolution in service contexts is
broken").

When an unchecked exception (RuntimeException, Error) occurs in
RMI-IIOP, it is translated into a CORBA UNKNOWN system exception, and
the real Java exception is marshaled as a CDR encapsulation in the
UnknownExceptionInfo service context. (Java to IDL formal 01-06-07
1.4.7, 1.4.8.1)

In J2SE 1.4, java.lang.Throwable has evolved to add several new
non-transient fields including

private Throwable cause;
private StackTraceElement[] stackTrace;

This means that when J2SE 1.3.x talks to 1.4 and an unchecked
exception occurs, there is a class evolution scenario occurring inside
of the UnknownExceptionInfo service context. Normally, class
evolution is handled by using the SendingContextRunTime CodeBase to
find out what the sender put on the wire. This service context is
sent by the client on the first request on a connection and by the
server on the first reply on a connection. (Java to IDL formal
01-06-07 1.5.1)

This presents two problems:

1. Since the UnknownExceptionInfo service context has the Throwable
in an encapsulation, technically it has no connection information.

2. Even if we assumed that we use the connection on which this
encapsulation is transmitted, we would need to make sure that the
SendingContextRunTime service context is unmarshaled BEFORE the
UnknownExceptionInfo service context so that the connection has the
CodeBase to use to unmarshal the evolved Throwable class.

Here are two possible solutions:

1. Service context ordering proposal (strawman):

Require that service context encapsulations use the connection on
which they are sent if they need the CodeBase, and that the
UnknownExceptionInfo service context must be unmarshaled after the
SendingContextRunTime service context. Specifically, add this
language to the Java to IDL spec in section 1.4.8.1.

Note: We may need to be careful not to generalize to all service
contexts. For instance, code sets for wstring/wchar inside of service
context encapsulations should probably be explicitly stated when
defining the service context at the spec level.

2. New service context & backwards compatibility proposal:

Add a new UnknownExceptionInfo service context called something like
UnknownExceptionInfoPlusCodeBase service context. It contains the
CodeBase IOR followed by the java.lang.Throwable. Thus, all necessary
information is contained, and we can support evolution going forward
in this particular service context. Older receivers would just
disregard it.

For backwards compatibility with J2SE 1.3 and before, we must still
also send the original UnknownExceptionInfo service context containing
something that looks like the J2SE 1.3 java.lang.Throwable class.
Thus, we must define the format of this new structure and how to
translate from J2SE 1.4 or later Throwables to it.

see below

Ie RemoteException and subclasses are not RMI/IDL Exception types. (Note
> > >however,
> > >that the section refered to doesn't explicitly state that. That is a spec
> > >problem). The spec provides these options:
> > >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.
> > >
> > >This option is needed because, some userdefined runtime exception, say,
> > >may not
> > >have an equivalent implementation on the receiving end. If we fix remote
> > >exception to always result in the "right" exception on the wire, this case
> > >occurs
> > >only when there is an unexpected exception (such as a null pointer), which
> > >should
> > >be OK. The intent here was to talk about base classes and not individual types, but I
> > >agree this is not explicit. Ideally, only remote exceptions that don't
> > >have the
> > >explicit reverse (rmi-to-system) mapping should result in a ServerException.
> >
> > Right, your first point makes this not so bothersome.
> >
> > > > >2. What about C++ clients ? The server should have converted any Java
> > > > >Exception into a CORBA SYSTEM/USER exception where this is possible,
> > > so that
> > > > >any non-Java clients can deal with the Exceptions. Especially for the
> > > > >TRANSACTION exceptions where a one-to-one mapping is possible, so that C++
> > > > >clients know about those events from an RMI-IIOP server. Unfortunately the
> > > > >Table 1-2, CORBA and RMI Exceptions (p. 1-33), has no one-to-one
> > > mapping, so
> > > > >Then mapping into the other direction some information will get lost.
> > > >
> > > > The problem is actually worse than this. If the server throws an exception
> > > > that is a subclass of a declared exception, the client will get the Java
> > > > IDL mapped exception (e.g. FooException -> FooEx) but
> > > > there_is_no_way_for_the_client_to_handle_it because the IDL does not
> > > > declare FooEx - and IDL does not allow exception inheritance. I would like
> > > > to propose therefore that in the "standard" exception mapping that only
> > > > exceptions of the declared type are thrown and that any exception
> > > > inheritance is represented in the detail which is the actual java
> > > > exception. We are actually doing this already in our server because it is
> > > > the only reasonable way to make C++ clients work with EJBs.

Closed, accepted. See revised text below

"The mapSystemException method maps a CORBA system exception to a java.rmi.RemoteException or a java.rmi.RuntimeException."

There is no java.rmi.RuntimeException, instead it should read: java.lang.RuntimeException !

Closed, accepted. See revised text below