JAV2I12 — mapSystemException server mapping

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