Issue 4698: mapSystemException server mapping (java2idl-rtf) Source: (Mr. Simon C. Nash, ) Nature: Uncategorized Issue Severity: Summary: 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. Resolution: Closed, accepted. See revised text below Revised Text: 1. Change the title of section 1.4.7 from: Mapping RMI Exceptions to CORBA System Exceptions to: Mapping RMI Exceptions to CORBA Exceptions 2. In section 1.4.7, replace the following sentence: Exceptions that are instances of (or subclasses of) RMI/IDL exception types declared by the method are marshaled as user exceptions in the usual way. by the following text: Any exception that is an instance of an RMI/IDL exception type declared by the method or any subclass of these type (other than java.rmi.RemoteException and its subclasses) is marshaled as the mapped IDL exception corresponding to the declared RMI/IDL exception (see section 1.3.7.2) containing a mapped IDL valuetype corresponding to the actual runtime RMI/IDL exception type (see section 1.3.7.1). On the client side, the mapped IDL valuetype is unmarshaled and thrown back to the application. For example, if a method in an RMI/IDL remote interface declares an exception type MammalException and its implementation throws an instance of WombatException (a subclass of MammalException), then this exception is marshaled as an IDL exception MammalEx containing an IDL valuetype WombatException, and a WombatException is thrown to the client application. 3. In the table in section 1.4.8.1, change java.lang.Error to java.lang.Error (or subclass) java.rmi.RemoteException to java.rmi.RemoteException (or subclass) java.lang.RuntimeException to java.lang.RuntimeException (or subclass) Actions taken: November 11, 2001: received issue May 13, 2002: closed issue Discussion: End of Annotations:===== Date: Sun, 11 Nov 2001 23:42:48 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Vijaykumar Natarajan CC: Andy Piper , Michael Rumpf , java2idl-rtf@omg.org Subject: (read second) mapSystemException server mapping References: <4.3.2.7.2.20011109113451.021f19d0@san-francisco.beasys.com> <4.3.2.7.2.20011109155924.017a0b18@san-francisco.beasys.com> <3BEC9099.EF19B4CD@inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: g9]d9>5Qe9=[Y!!Wf2!! Vijay, Vijaykumar Natarajan wrote: > > Andy > > Andy Piper wrote: > > > At 03:48 PM 11/9/2001 -0800, Vijaykumar Natarajan wrote: > > > > I think your interpretation is correct, but I also think the spec is flawed > > > > in this area. > > > > > >Not true. The java/idl spec also states that: > > >"All checked exception classes used in method declarations (other than > > >java.rmi.RemoteException and its subclasses) are conforming RMI/IDL > > >exception types (see Section 1.2.6, "RMI/IDL Exception Types," on page 1-5)." > > > > > >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). > > > > Sorry, my mistake. You are correct. > > > > > > In addition these orbs (the RI and J2SE at least) do not unpick the Unknown > > > > exception at the other end they simply throw an UnknownException. Although > > > > the spec says you are allowed to do this (at least according to the > > > > javadoc) I think it should mandate that the nested exception is rethrown - > > > > otherwise RMI-IIOP behaviour is different to other flavours of RMI. > > > > > >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. > > > > But in general I think this is not true, i.e. I think that option (3) copes > > with an edge case and that option (2) should be mandated when the client is > > able to load the exception definition (which I believe is usually the > > case). Otherwise anarchy ensues IMO. > > Agreed. > I agree. This wording (in the IDL to Java mapping spec) was originally intended to accomodate the behavior of older Java ORBs that didn't understand UnknownException or RMI-IIOP. To change it someone will need to raise an IDL-to-Java issue. > > > > > > >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. > > > > > >The IDL does declare FooEx and the method does declare > >raises(FooEx). FooEx in > > > > Not true. Take javax.ejb.FinderException, the IDL will declare > >FinderEx but > > the server will almost always throw something else e.g. > > javax.ejb.ObjectNotFoundException which as it stands the server > >will > > marshal as ObjectNotFoundEx which the IDL client knows nothing > >about. > > Ah, now I understand what you're saying. However, I think the last > >part (ie "the > server will marshal as ObjectNotFoundEx") would be a bug in the > >implementation. > Since the raises indicates FinderEx, the server is incorrect in > >marshaling an > ObjectNotFoundEx (which is a violation of the IDL contract). So, you > >are correct in > what you are doing, but I disagree that the spec says otherwise. The > >spec only says > that when mapping to IDL, ObjectNotFoundException maps to an > >ObjectNotFoundEx. > Extrapolating that to runtime is what I think is incorrect. > Yes, I agree. Section 1.4.7 contains the runtime mapping rules. The > >problem is that the sentence "Exceptions that are instances of (or subclasses of) RMI/IDL > >exception types declared by the method are marshaled as user exceptions in the usual way." is too vague and is capable of different interpretations. This needs > >to be made much more explicit, preferably with an example. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: "Michael Rumpf" To: "Simon Nash" Cc: , , References: <4.3.2.7.2.20011109113451.021f19d0@san-francisco.beasys.com> <4.3.2.7.2.20011109155924.017a0b18@san-francisco.beasys.com> <3BEC9099.EF19B4CD@inprise.com> <3BEF0CF8.7CFDD10@hursley.ibm.com> Subject: Re: (read second) mapSystemException server mapping Date: Mon, 12 Nov 2001 14:17:47 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ;OZd99%(e97$N!!>-id9 Hi all, I draw the following conclusions, i.e. cleaing up the replies: 1. Java2IDL (01-06-07): 1.2.6: Add an explicit statement that RemoteExceptions are conforming exceptions. Wouldn't it be less confusing when RemoteExceptions are declared to be non-conforming exceptions ? In this case you would not need to add the exclusion to section 1.4.7 (see below). But maybe this breaks some other definition.... 2. Java2IDL (01-06-07): 1.4.7: Change the sentence "Exceptions that are instances of (or subclasses of) RMI/IDL exception types declared by the method are marshaled as user exceptions in the usual way." to "Exceptions that are instances of (or subclasses of) RMI/IDL exception types declared by the method (other than java.rmi.RemoteException and its subclasses) are marshaled as user exceptions in the usual way." 3. Java2IDL (01-06-07): 1.4.8.1: This section needs to state explicitly that these rules apply to all subclasses of the listed types as well. 4. Raise an IDL2Java issue to add that bullet number 2 in 1.21.5.2 (p. 1-120) should be declared the mandatory behaviour. To the exception problem in general I read that the EJB spec. should be updated to include the server side mapping of those exceptions that need to be seen without the ServerException wrapper on the client side. There is a common sense on this issue by the Java2Idl RTF and the RMI group, but noone has discussed this with the EJB folks yet. BTW, the ejb-2_0-fr2 (final draft) states (p.372): 18.1.2 Goals for exception handling The EJB specification for exception handling is designed to meet these high-level goals: - An application exception thrown by an enterprise bean instance should be reported to the client precisely (i.e., the client gets the same exception). This can only be achieved when the EJB server runtime maps all RMI exceptions to CORBA System exceptions before passing them to the RMI-IIOP layer... Michael ----- Original Message ----- From: "Simon Nash" To: "Vijaykumar Natarajan" Cc: "Andy Piper" ; "Michael Rumpf" ; Sent: Montag, 12. November 2001 00:42 Subject: (read second) mapSystemException server mapping > Vijay, > > Vijaykumar Natarajan wrote: > > > > Andy > > > > Andy Piper wrote: > > > > > At 03:48 PM 11/9/2001 -0800, Vijaykumar Natarajan wrote: > > > > > I think your interpretation is correct, but I also think the >spec is flawed > > > > > in this area. > > > > > > > >Not true. The java/idl spec also states that: > > > >"All checked exception classes used in method declarations >(other than > > > >java.rmi.RemoteException and its subclasses) are conforming >RMI/IDL > > > >exception types (see Section 1.2.6, "RMI/IDL Exception Types," >on page 1-5)." > > > > > > > >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). > > > > > > Sorry, my mistake. You are correct. > > > > > > > > In addition these orbs (the RI and J2SE at least) do not >unpick the Unknown > > > > > exception at the other end they simply throw an >UnknownException. Although > > > > > the spec says you are allowed to do this (at least according >to the > > > > > javadoc) I think it should mandate that the nested exception >is rethrown - > > > > > otherwise RMI-IIOP behaviour is different to other flavours >of RMI. > > > > > > > >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. > > > > > > But in general I think this is not true, i.e. I think that >option (3) copes > > > with an edge case and that option (2) should be mandated when >the client is > > > able to load the exception definition (which I believe is >usually the > > > case). Otherwise anarchy ensues IMO. > > > > Agreed. > > > I agree. This wording (in the IDL to Java mapping spec) was >originally intended > to accomodate the behavior of older Java ORBs that didn't understand UnknownException > or RMI-IIOP. To change it someone will need to raise an IDL-to-Java issue. > > > > > > > > > > >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. > > > > > > > >The IDL does declare FooEx and the method does declare >raises(FooEx). FooEx in > > > > > > Not true. Take javax.ejb.FinderException, the IDL will declare FinderEx but > > > the server will almost always throw something else e.g. > > > javax.ejb.ObjectNotFoundException which as it stands the server >will > > > marshal as ObjectNotFoundEx which the IDL client knows nothing >about. > > > > Ah, now I understand what you're saying. However, I think the last >part (ie "the > > server will marshal as ObjectNotFoundEx") would be a bug in the implementation. > > Since the raises indicates FinderEx, the server is incorrect in marshaling an > > ObjectNotFoundEx (which is a violation of the IDL contract). So, >you are correct in > > what you are doing, but I disagree that the spec says >otherwise. The spec only says > > that when mapping to IDL, ObjectNotFoundException maps to an ObjectNotFoundEx. > > Extrapolating that to runtime is what I think is incorrect. > > > Yes, I agree. Section 1.4.7 contains the runtime mapping rules. >The problem is > that the sentence > "Exceptions that are instances of (or subclasses of) RMI/IDL >exception types declared > by the method are marshaled as user exceptions in the usual way." > is too vague and is capable of different interpretations. This >needs to be made > much more explicit, preferably with an example. > > Simon > -- > Simon C Nash, Chief Technical Officer, IBM Java Technology > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > From: "Michael Rumpf" To: "Simon Nash" Cc: , , Subject: Re: (read second) mapSystemException server mapping Date: Mon, 12 Nov 2001 14:47:47 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: VHbd9Up2!!(KE!!://e9 Hi again, > Hi all, > > I draw the following conclusions, i.e. cleaing up the replies: > > 1. Java2IDL (01-06-07): 1.2.6: Add an explicit statement that > RemoteExceptions are conforming exceptions. > Wouldn't it be less confusing when RemoteExceptions are declared to >be > non-conforming exceptions ? > In this case you would not need to add the exclusion to section >1.4.7 (see > below). But maybe this breaks some other definition.... > > 2. Java2IDL (01-06-07): 1.4.7: Change the sentence > "Exceptions that are instances of (or subclasses of) RMI/IDL >exception types > declared by the method are marshaled as user exceptions in the >usual way." > to > "Exceptions that are instances of (or subclasses of) RMI/IDL >exception > types > declared by the method (other than java.rmi.RemoteException and >its > subclasses) > are marshaled as user exceptions in the usual way." > > 3. Java2IDL (01-06-07): 1.4.8.1: This section needs to state >explicitly that > these rules apply to all subclasses of the listed types as well. > > 4. Raise an IDL2Java issue to add that bullet number 2 in 1.21.5.2 >(p. > 1-120) should be declared the mandatory behaviour. > > To the exception problem in general I read that the EJB spec. should >be > updated to include the server side mapping of those exceptions that >need to > be seen without the ServerException wrapper on the client side. > There is a common sense on this issue by the Java2Idl RTF and the >RMI group, > but noone has discussed this with the EJB folks yet. > > BTW, the ejb-2_0-fr2 (final draft) states (p.372): > 18.1.2 Goals for exception handling > The EJB specification for exception handling is designed to meet >these > high-level goals: > - An application exception thrown by an enterprise bean instance >should be > reported to the client precisely (i.e., the client gets the same exception). > > This can only be achieved when the EJB server runtime maps all RMI > exceptions to CORBA System exceptions before passing them to the >RMI-IIOP > layer... OK, forget the last remark above, I have just overseen that this deals with "application exceptions" only. But, for EJB 1.1 there is a document on CORBA interoperability available (ejb1_1-corba.pdf) and it has already been integrated into the EJB 2.0 spec.! On page 393, 19.5.3 Mapping of system exceptions, you can see the reverse mapping table we were talking about: "Java system exceptions, including the java.rmi.RemoteException and its subclasses, may be thrown by the EJB container. If the client's invocation was made over IIOP, the EJB server is required to map these exceptions to CORBA system exceptions and send them in the IIOP reply message to the client, as specified in the following table: javax.transaction.TransactionRolledbackException -> TRANSACTION_ROLLEDBACK javax.transaction.TransactionRequiredException -> TRANSACTION_REQUIRED javax.transaction.InvalidTransactionException -> INVALID_TRANSACTION java.rmi.NoSuchObjectException -> OBJECT_NOT_EXIST java.rmi.AccessException -> NO_PERMISSION java.rmi.MarshalException -> MARSHAL java.rmi.RemoteException -> UNKNOWN For EJB clients, the ORB's unmarshaling machinery maps CORBA system exceptions received in the IIOP reply message to the appropriate Java exception as specified in the Java Language to IDL mapping. This results in the original Java exception being received by the client J2EE component." So, no further action with the EJB folks has to be taken... Thanks, Michael > Michael > > ----- Original Message ----- > From: "Simon Nash" > To: "Vijaykumar Natarajan" > Cc: "Andy Piper" ; "Michael Rumpf" ; > > Sent: Montag, 12. November 2001 00:42 > Subject: (read second) mapSystemException server mapping > > > > Vijay, > > > > Vijaykumar Natarajan wrote: > > > > > > Andy > > > > > > Andy Piper wrote: > > > > > > > At 03:48 PM 11/9/2001 -0800, Vijaykumar Natarajan wrote: > > > > > > I think your interpretation is correct, but I also think >the spec > is flawed > > > > > > in this area. > > > > > > > > > >Not true. The java/idl spec also states that: > > > > >"All checked exception classes used in method declarations >(other > than > > > > >java.rmi.RemoteException and its subclasses) are conforming >RMI/IDL > > > > >exception types (see Section 1.2.6, "RMI/IDL Exception >Types," on > page 1-5)." > > > > > > > > > >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). > > > > > > > > Sorry, my mistake. You are correct. > > > > > > > > > > In addition these orbs (the RI and J2SE at least) do not >unpick > the Unknown > > > > > > exception at the other end they simply throw an UnknownException. > Although > > > > > > the spec says you are allowed to do this (at least >according to > the > > > > > > javadoc) I think it should mandate that the nested >exception is > rethrown - > > > > > > otherwise RMI-IIOP behaviour is different to other >flavours of > RMI. > > > > > > > > > >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. > > > > > > > > But in general I think this is not true, i.e. I think that >option (3) > copes > > > > with an edge case and that option (2) should be mandated when >the > client is > > > > able to load the exception definition (which I believe is >usually the > > > > case). Otherwise anarchy ensues IMO. > > > > > > Agreed. > > > > > I agree. This wording (in the IDL to Java mapping spec) was >originally > intended > > to accomodate the behavior of older Java ORBs that didn't >understand > UnknownException > > or RMI-IIOP. To change it someone will need to raise an >IDL-to-Java > issue. > > > > > > > > > > > > > > >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. > > > > > > > > > >The IDL does declare FooEx and the method does declare raises(FooEx). > FooEx in > > > > > > > > Not true. Take javax.ejb.FinderException, the IDL will declare > FinderEx but > > > > the server will almost always throw something else e.g. > > > > javax.ejb.ObjectNotFoundException which as it stands the >server will > > > > marshal as ObjectNotFoundEx which the IDL client knows nothing about. > > > > > > Ah, now I understand what you're saying. However, I think the >last part > (ie "the > > > server will marshal as ObjectNotFoundEx") would be a bug in the > implementation. > > > Since the raises indicates FinderEx, the server is incorrect in > marshaling an > > > ObjectNotFoundEx (which is a violation of the IDL contract). So, >you are > correct in > > > what you are doing, but I disagree that the spec says >otherwise. The > spec only says > > > that when mapping to IDL, ObjectNotFoundException maps to an > ObjectNotFoundEx. > > > Extrapolating that to runtime is what I think is incorrect. > > > > > Yes, I agree. Section 1.4.7 contains the runtime mapping rules. >The > problem is > > that the sentence > > "Exceptions that are instances of (or subclasses of) RMI/IDL >exception > types declared > > by the method are marshaled as user exceptions in the usual >way." > > is too vague and is capable of different interpretations. This >needs to > be made > > much more explicit, preferably with an example. > > > > Simon > > -- > > Simon C Nash, Chief Technical Officer, IBM Java Technology > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > > > Date: Mon, 12 Nov 2001 15:06:39 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Michael Rumpf CC: java2idl-rtf@omg.org, andyp@bea.com, vnatarajan@borland.com Subject: Re: (read second) mapSystemException server mapping References: <4.3.2.7.2.20011109113451.021f19d0@san-francisco.beasys.com> <4.3.2.7.2.20011109155924.017a0b18@san-francisco.beasys.com> <3BEC9099.EF19B4CD@inprise.com> <3BEF0CF8.7CFDD10@hursley.ibm.com> <005001c16b7c$6cd6fcb0$c51811ac@brokat.de> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: _(Ae9Tl/!!6g#"!"1ad9 Michael, Michael Rumpf wrote: > > Hi all, > > I draw the following conclusions, i.e. cleaing up the replies: > > 1. Java2IDL (01-06-07): 1.2.6: Add an explicit statement that > RemoteExceptions are conforming exceptions. > I'm willing to do think if the RTF thinks it's necessary. However, I think it's clear from the current definition that RemoteException itself is conforming. Note that some subclasses of RemoteException may not be conforming because of the second bullet and the 1.2.4 rules. > Wouldn't it be less confusing when RemoteExceptions are declared to be > non-conforming exceptions ? > In this case you would not need to add the exclusion to section 1.4.7 (see > below). But maybe this breaks some other definition.... > I'd prefer not to change this in case it breaks something else. It's simple (and consistent with other usage) to add the qualifier to 1.4.7. > 2. Java2IDL (01-06-07): 1.4.7: Change the sentence > "Exceptions that are instances of (or subclasses of) RMI/IDL exception types > declared by the method are marshaled as user exceptions in the usual way." > to > "Exceptions that are instances of (or subclasses of) RMI/IDL exception > types > declared by the method (other than java.rmi.RemoteException and its > subclasses) > are marshaled as user exceptions in the usual way." > Agree. > 3. Java2IDL (01-06-07): 1.4.8.1: This section needs to state explicitly that > these rules apply to all subclasses of the listed types as well. > Agree. > 4. Raise an IDL2Java issue to add that bullet number 2 in 1.21.5.2 (p. > 1-120) should be declared the mandatory behaviour. > Agree. > To the exception problem in general I read that the EJB spec. should be > updated to include the server side mapping of those exceptions that need to > be seen without the ServerException wrapper on the client side. > There is a common sense on this issue by the Java2Idl RTF and the RMI group, > but noone has discussed this with the EJB folks yet. > It's already there, as you pointed out in your other note. > BTW, the ejb-2_0-fr2 (final draft) states (p.372): > 18.1.2 Goals for exception handling > The EJB specification for exception handling is designed to meet these > high-level goals: > - An application exception thrown by an enterprise bean instance should be > reported to the client precisely (i.e., the client gets the same exception). > > This can only be achieved when the EJB server runtime maps all RMI > exceptions to CORBA System exceptions before passing them to the RMI-IIOP > layer... > No, as you pointed out in your other note. In addition, the runtime mapping of application exception subclasses should be clarified in section 1.4.7 (the Andy/Vijay discussion). Simon. -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Nov 2001 11:09:05 -0800 To: Simon Nash , Vijaykumar Natarajan From: Andy Piper Subject: Re: (read second) mapSystemException server mapping Cc: Michael Rumpf , java2idl-rtf@omg.org In-Reply-To: <3BEF0CF8.7CFDD10@hursley.ibm.com> References: <4.3.2.7.2.20011109113451.021f19d0@san-francisco.beasys.com> <4.3.2.7.2.20011109155924.017a0b18@san-francisco.beasys.com> <3BEC9099.EF19B4CD@inprise.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: #Dad9l3/e9FkS!!G&dd9 Lets dig into this a bit more: At 11:42 PM 11/11/2001 +0000, Simon Nash wrote: > Ah, now I understand what you're saying. However, I think the last part (ie "the > server will marshal as ObjectNotFoundEx") would be a bug in the implementation. > Since the raises indicates FinderEx, the server is incorrect in marshaling an > ObjectNotFoundEx (which is a violation of the IDL contract). So, you are correct in > what you are doing, but I disagree that the spec says otherwise. The spec only says > that when mapping to IDL, ObjectNotFoundException maps to an ObjectNotFoundEx. > Extrapolating that to runtime is what I think is incorrect. > Yes, I agree. Section 1.4.7 contains the runtime mapping rules. The problem is that the sentence "Exceptions that are instances of (or subclasses of) RMI/IDL exception types declared by the method are marshaled as user exceptions in the usual way." is too vague and is capable of different interpretations. This needs to be made much more explicit, preferably with an example. If the IDL mapping cannot be extrapolated to the runtime then there is actually *no* description of what the runtime behavior should be. Moreover, there is no description of what the client-side runtime behaviour should be. Ideally the client should throw the exception represented by the value-type rather than the IDL exception, but the J2SE Orb and RI certainly do not do this. As it stands I think the only reasonable interpretation *is* to extrapolate the IDL mapping to the runtime, with all of the problems I have already mentioned. andy Date: Mon, 12 Nov 2001 19:24:56 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Boldt Subject: Re: (read second) mapSystemException server mapping References: <4.3.2.7.2.20011109113451.021f19d0@san-francisco.beasys.com> <4.3.2.7.2.20011109155924.017a0b18@san-francisco.beasys.com> <3BEC9099.EF19B4CD@inprise.com> <3BEF0CF8.7CFDD10@hursley.ibm.com> <005001c16b7c$6cd6fcb0$c51811ac@brokat.de> <4.3.2.7.2.20011112122302.00e6aba0@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: g2-!!eOY!!lY,e9 > Simon, > > are there issue numbers assigned to this thread? ... should I assign numbers? > > -Juergen > > At 03:06 PM 11/12/2001 +0000, you wrote: > >Michael, > > > >Michael Rumpf wrote: > > > > > > Hi all, > > > > > > I draw the following conclusions, i.e. cleaing up the replies: > > > > > > 1. Java2IDL (01-06-07): 1.2.6: Add an explicit statement that > > > RemoteExceptions are conforming exceptions. > > > > >I'm willing to do think if the RTF thinks it's necessary. However, I think > >it's clear from the current definition that RemoteException itself is > >conforming. > >Note that some subclasses of RemoteException may not be conforming because of > >the second bullet and the 1.2.4 rules. > > > > > Wouldn't it be less confusing when RemoteExceptions are declared to be > > > non-conforming exceptions ? > > > In this case you would not need to add the exclusion to section 1.4.7 (see > > > below). But maybe this breaks some other definition.... > > > > >I'd prefer not to change this in case it breaks something else. It's simple > >(and consistent with other usage) to add the qualifier to 1.4.7. > > > > > 2. Java2IDL (01-06-07): 1.4.7: Change the sentence > > > "Exceptions that are instances of (or subclasses of) RMI/IDL exception > > types > > > declared by the method are marshaled as user exceptions in the usual > > way." > > > to > > > "Exceptions that are instances of (or subclasses of) RMI/IDL exception > > > types > > > declared by the method (other than java.rmi.RemoteException and its > > > subclasses) > > > are marshaled as user exceptions in the usual way." > > > > >Agree. > > > > > 3. Java2IDL (01-06-07): 1.4.8.1: This section needs to state explicitly > > that > > > these rules apply to all subclasses of the listed types as well. > > > > >Agree. > > > > > 4. Raise an IDL2Java issue to add that bullet number 2 in 1.21.5.2 (p. > > > 1-120) should be declared the mandatory behaviour. > > > > >Agree. > > > > > To the exception problem in general I read that the EJB spec. should be > > > updated to include the server side mapping of those exceptions that need to > > > be seen without the ServerException wrapper on the client side. > > > There is a common sense on this issue by the Java2Idl RTF and the RMI > > group, > > > but noone has discussed this with the EJB folks yet. > > > > >It's already there, as you pointed out in your other note. > > > > > BTW, the ejb-2_0-fr2 (final draft) states (p.372): > > > 18.1.2 Goals for exception handling > > > The EJB specification for exception handling is designed to meet these > > > high-level goals: > > > - An application exception thrown by an enterprise bean instance should be > > > reported to the client precisely (i.e., the client gets the same > > exception). > > > > > > This can only be achieved when the EJB server runtime maps all RMI > > > exceptions to CORBA System exceptions before passing them to the RMI-IIOP > > > layer... > > > > >No, as you pointed out in your other note. > > > >In addition, the runtime mapping of application exception subclasses should be > >clarified in section 1.4.7 (the Andy/Vijay discussion). > > > > Simon. > >-- > >Simon C Nash, Chief Technical Officer, IBM Java Technology > >Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > >Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > URL: www.omg.org > > ================================================================ -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 12 Nov 2001 19:29:06 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Andy Piper CC: Vijaykumar Natarajan , Michael Rumpf , java2idl-rtf@omg.org, juergen@omg.org Subject: Re: (read second) mapSystemException server mapping References: <4.3.2.7.2.20011109113451.021f19d0@san-francisco.beasys.com> <4.3.2.7.2.20011109155924.017a0b18@san-francisco.beasys.com> <3BEC9099.EF19B4CD@inprise.com> <4.3.2.7.2.20011112095948.02331ab0@san-francisco.beasys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Sh$e9[A$!!C]ed9TBZ!! Andy, I cannot disagree with you. We will fix the spec to make it explicit as to the correct runtime behavior. Are you OK with combining this with Michael's original issue, or would you like this treated as a separate Java to IDL issue? Simon Andy Piper wrote: > > Lets dig into this a bit more: > > At 11:42 PM 11/11/2001 +0000, Simon Nash wrote: > > > Ah, now I understand what you're saying. However, I think the last part > > (ie "the > > > server will marshal as ObjectNotFoundEx") would be a bug in the > > implementation. > > > Since the raises indicates FinderEx, the server is incorrect in > > marshaling an > > > ObjectNotFoundEx (which is a violation of the IDL contract). So, you > > are correct in > > > what you are doing, but I disagree that the spec says otherwise. The > > spec only says > > > that when mapping to IDL, ObjectNotFoundException maps to an > > ObjectNotFoundEx. > > > Extrapolating that to runtime is what I think is incorrect. > > > > >Yes, I agree. Section 1.4.7 contains the runtime mapping rules. The > >problem is > >that the sentence > > "Exceptions that are instances of (or subclasses of) RMI/IDL exception > > types declared > > by the method are marshaled as user exceptions in the usual way." > >is too vague and is capable of different interpretations. This needs to > >be made > >much more explicit, preferably with an example. > > If the IDL mapping cannot be extrapolated to the runtime then there is > actually *no* description of what the runtime behavior should be. Moreover, > there is no description of what the client-side runtime behaviour should > be. Ideally the client should throw the exception represented by the > value-type rather than the IDL exception, but the J2SE Orb and RI certainly > do not do this. As it stands I think the only reasonable interpretation > *is* to extrapolate the IDL mapping to the runtime, with all of the > problems I have already mentioned. > > andy -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Nov 2001 13:21:40 -0800 To: Simon Nash From: Andy Piper Subject: Re: (read second) mapSystemException server mapping Cc: Vijaykumar Natarajan , Michael Rumpf , java2idl-rtf@omg.org, juergen@omg.org In-Reply-To: <3BF02302.ABA5057@hursley.ibm.com> References: <4.3.2.7.2.20011109113451.021f19d0@san-francisco.beasys.com> <4.3.2.7.2.20011109155924.017a0b18@san-francisco.beasys.com> <3BEC9099.EF19B4CD@inprise.com> <4.3.2.7.2.20011112095948.02331ab0@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: FPPd98dUd9X6V!!Mbd!! At 07:29 PM 11/12/2001 +0000, Simon Nash wrote: I cannot disagree with you. We will fix the spec to make it explicit as to the correct runtime behavior. Are you OK with combining this with Michael's original issue, or would you like this treated as a separate Java to IDL issue? Its fine combining it, but I am still confused as to what people believe the correct runtime behaviour should be. andy Date: Tue, 13 Nov 2001 12:19:23 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Andy Piper CC: Vijaykumar Natarajan , Michael Rumpf , java2idl-rtf@omg.org Subject: Re: (read second) mapSystemException server mapping References: <4.3.2.7.2.20011109113451.021f19d0@san-francisco.beasys.com> <4.3.2.7.2.20011109155924.017a0b18@san-francisco.beasys.com> <3BEC9099.EF19B4CD@inprise.com> <4.3.2.7.2.20011112095948.02331ab0@san-francisco.beasys.com> <4.3.2.7.2.20011112132052.023490d0@san-francisco.beasys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 5R=!!XGgd9CHPd90hMe9 Andy, I know examples are not normative, but they are sometimes helpful in indicating the intentions of the spec authors. The Tie example in section 1.5.2.3 shows a catch clause for Boomerang. This will also catch all subclasses of Boomerang. The caught exception (Boomerang or a subclass) will be written to the exception reply stream using write_value(). In all cases, the IDL exception type is BoomerangEx. The Stub examples in sections 1.5.2.1 and 1.5.2.2 show the processing of a BoomerangEx IDL exception. The code reads the valuetype within the exception using read_value(), casts it to Boomerang, and throws it back to the application. This code will also handle subclasses of Boomerang. I think we need to add normative spec words to section 1.4.7 documenting the above semantics. Simon Andy Piper wrote: > > At 07:29 PM 11/12/2001 +0000, Simon Nash wrote: > >I cannot disagree with you. We will fix the spec to make it explicit as to > >the correct runtime behavior. Are you OK with combining this with Michael's > >original issue, or would you like this treated as a separate Java to IDL > >issue? > > Its fine combining it, but I am still confused as to what people believe > the correct runtime behaviour should be. > > andy -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: "Michael Rumpf" To: Cc: Subject: Q: Why is there no symmetric equivalent for mapSystemException() on the server side ? Date: Thu, 8 Nov 2001 18:38:00 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: pI&e9)\;e9*o%e9na;!! Hi, the method mapSystemException, as proposed by the RMI-IIOP spec., converts CORBA System exceptions only on the client side, but where is the mapping for the server side ? The chapter "1.4.7 Mapping RMI Exceptions to CORBA System Exceptions" states: "... Exceptions that are instances of (or subclasses of) RMI/IDL exception types declared by the method are marshaled as user exceptions in the usual way. ..." This means that any subtypes of RemoteException (because RemoteException is declared in the throws clause) would be marshaled in the ususal way. The usual way would be to catch any RemoteException after invocation of the server method and map it to the CORBA IDL type, i.e. passing it as an exception reply to the client (with the actual Java exception included in the value type). This is how I interpret the spec., if this is wrong, then the spec. should be extended to clarify this (I read it now a hundred times) !!! Some ORBs (J2EE RI and OpenORB) marshal only those exceptions in the "usual way" which are declared additionally to the RemoteException. RemoteExceptions itself are handled as CORBA UNKNOWN exceptions with an UnknownExceptionInfo service context. See again "1.4.7 Mapping RMI Exceptions to CORBA System Exceptions": "... All other Java exceptions are marshaled as CORBA UNKNOWN system exceptions whose GIOP Reply message includes an UnknownExceptionInfo service context containing the marshaled Java exception thrown by the server implementation. ..." This means that on the client side all RemoteExceptions will be wrapped by a ServerException, as can be seen in Table 1-3 (1.4.8.1 Mapping of UnknownExceptionInfo Service Context: RemoteException -> ServerException). The consequence is that any RemoteException is never seen directly by the client, instead the client has to extract the actual RemoteException from the ServerException. There are two problems now: 1. A client like Sun's J2EE Compliance Test Suite (CTS) is expecting the RemoteException and not a ServerException. Many of the transactional tests catch the TransactionRollebackException or the TransactionRequiredException and fail because they see a ServerException only. 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 when mapping into the other direction some information will get lost. Having a symmetric mapping, i.e. mapping the RemoteExceptions on the server side to CORBA System exceptions whereever possible and reverting the mapping on the client side would be a solution to both problems. This is exactly the approach the J2EE RI has chosen. The POAProtocolMgr.java has a method mapException() where the following mapping is done: java.rmi.NoSuchObjectException -> OBJECT_NOT_EXIST java.rmi.AccessException -> NO_PERMISSION java.rmi.MarshalException -> MARSHAL javax.transaction.TransactionRolledbackException -> TRANSACTION_ROLLEDBACK javax.transaction.TransactionRequiredException -> TRANSACTION_REQUIRED javax.transaction.InvalidTransactionException -> INVALID_TRANSACTION OpenORB's RMIoverIIOP fails when running the CTS tests because it just sticks to the spec. without doing the mapping on the server side... Best Regards, Michael X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Nov 2001 13:02:01 -0800 To: "Michael Rumpf" , From: Andy Piper Subject: Re: Q: Why is there no symmetric equivalent for mapSystemException() on the server side ? Cc: In-Reply-To: <010b01c1687c$1ccd6220$c51811ac@brokat.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: Q@5!!3>(!!J7 ServerException). The consequence is that any RemoteException is never seen directly by the client, instead the client has to extract the actual RemoteException from the ServerException. I actually took the mapping to be explicit, i.e. only RemoteException itself would be mapped, subclasses would not. I agree that this is a problem if I am wrong. There are two problems now: 1. A client like Sun's J2EE Compliance Test Suite (CTS) is expecting the RemoteException and not a ServerException. Many of the transactional tests catch the TransactionRollebackException or the TransactionRequiredException and fail because they see a ServerException only. In fact because the RI and J2SE are so broken in this respect we do the reverse mapping also. Since clients are obliged to map the CORBA exceptions appropriately this actually achieves what we want (although it violates the spec). 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. Having a symmetric mapping, i.e. mapping the RemoteExceptions on the server side to CORBA System exceptions whereever possible and reverting the mapping on the client side would be a solution to both problems. This is exactly the approach the J2EE RI has chosen. The POAProtocolMgr.java has a method mapException() where the following mapping is done: java.rmi.NoSuchObjectException -> OBJECT_NOT_EXIST java.rmi.AccessException -> NO_PERMISSION java.rmi.MarshalException -> MARSHAL javax.transaction.TransactionRolledbackException -> TRANSACTION_ROLLEDBACK javax.transaction.TransactionRequiredException -> TRANSACTION_REQUIRED javax.transaction.InvalidTransactionException -> INVALID_TRANSACTION I agree that this should be in the spec also. andy Date: Fri, 09 Nov 2001 15:48:34 -0800 From: Vijaykumar Natarajan Subject: Re: Q: Why is there no symmetric equivalent for mapSystemException()on the server side ? To: Andy Piper Cc: Michael Rumpf , java2idl-rtf@omg.org, openorb-dev@exolab.org Message-id: <3BEC6B52.D249E8A0@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <4.3.2.7.2.20011109113451.021f19d0@san-francisco.beasys.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_eyPtP5jutmNvvpauviEFcw)" X-UIDL: NJ;!!WV$!!cPHe9L^Vd9 Status: RO All, Andy Piper wrote: > I've been meaning to write on this issue for a while. Comments in-line. > > At 06:38 PM 11/8/2001 +0100, Michael Rumpf wrote: > >the method mapSystemException, as proposed by the RMI-IIOP spec., converts > >CORBA System exceptions only on the client side, but where is the mapping > >for the server side ? > > > >The chapter "1.4.7 Mapping RMI Exceptions to CORBA System Exceptions" > >states: > > > >"... Exceptions that are instances of (or subclasses of) RMI/IDL exception > >types declared by the method are marshaled as user exceptions in the usual > >way. ..." > > > >This means that any subtypes of RemoteException (because RemoteException is > >declared in the throws clause) would be marshaled in the ususal way. The > >usual way would be to catch any RemoteException after invocation of the > >server method and map it to the CORBA IDL type, i.e. passing it as an > >exception reply to the client (with the actual Java exception included in > >the value type). > >This is how I interpret the spec., if this is wrong, then the spec. should > >be extended to clarify this (I read it now a hundred times) !!! > > I think your interpretation is correct, but I also think the spec is flawed > in this area. Not true. The java/idl spec also states that: "All checked exception classes used in method declarations (other than java.rmi.RemoteException and its subclasses) are conforming RMI/IDL exception types (see Section 1.2.6 , on page 1-5)." 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). > >Some ORBs (J2EE RI and OpenORB) marshal only those exceptions in the "usual > >way" which are declared additionally to the RemoteException. > >RemoteExceptions itself are handled as CORBA UNKNOWN exceptions with an > >UnknownExceptionInfo service context. Agreed this certainly is a problem. > > > In addition these orbs (the RI and J2SE at least) do not unpick the >Unknown > exception at the other end they simply throw an >UnknownException. Although > the spec says you are allowed to do this (at least according to the > javadoc) I think it should mandate that the nested exception is >rethrown - > otherwise RMI-IIOP behaviour is different to other flavours of RMI. 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. > > > >See again "1.4.7 Mapping RMI Exceptions to CORBA System >Exceptions": > > > >"... All other Java exceptions are marshaled as CORBA UNKNOWN >system > >exceptions whose GIOP Reply message includes an >UnknownExceptionInfo service > >context containing the marshaled Java exception thrown by the >server > >implementation. ..." > > > >This means that on the client side all RemoteExceptions will be >wrapped by a > >ServerException, as can be seen in Table 1-3 (1.4.8.1 Mapping of > >UnknownExceptionInfo Service Context: RemoteException -> >ServerException). > >The consequence is that any RemoteException is never seen directly >by the > >client, instead the client has to extract the actual >RemoteException from > >the ServerException. > > I actually took the mapping to be explicit, i.e. only >RemoteException > itself would be mapped, subclasses would not. I agree that this is a > problem if I am wrong. 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. > > > >There are two problems now: > > > >1. A client like Sun's J2EE Compliance Test Suite (CTS) is >expecting the > >RemoteException and not a ServerException. Many of the >transactional tests > >catch the TransactionRollebackException or the >TransactionRequiredException > >and fail because they see a ServerException only. > > In fact because the RI and J2SE are so broken in this respect we do >the > reverse mapping also. Since clients are obliged to map the CORBA >exceptions > appropriately this actually achieves what we want (although it >violates the > spec). Ditto. > >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. The IDL does declare FooEx and the method does declare raises(FooEx). FooEx in turn contains a valuetype FooException which is also declared in IDL, and that does allow inheritance. Yes, the subclasses of the declared exceptions must also be mapped, but this should work. In other words, what you are suggesting is exactly what the spec says. > > > >Having a symmetric mapping, i.e. mapping the RemoteExceptions on >the server > >side to CORBA System exceptions whereever possible and reverting >the mapping > >on the client side would be a solution to both problems. This is >exactly the > >approach the J2EE RI has chosen. The POAProtocolMgr.java has a >method > >mapException() where the following mapping is done: > > > >java.rmi.NoSuchObjectException -> OBJECT_NOT_EXIST > >java.rmi.AccessException -> NO_PERMISSION > >java.rmi.MarshalException -> MARSHAL > >javax.transaction.TransactionRolledbackException -> >TRANSACTION_ROLLEDBACK > >javax.transaction.TransactionRequiredException -> >TRANSACTION_REQUIRED > >javax.transaction.InvalidTransactionException -> >INVALID_TRANSACTION > > I agree that this should be in the spec also. I agree, this should be the case. Thanks, Vijay > > > andy -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. [] vnatarajan.vcf X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Nov 2001 16:07:31 -0800 To: Vijaykumar Natarajan From: Andy Piper Subject: Re: Q: Why is there no symmetric equivalent for mapSystemException()on the server side ? Cc: Michael Rumpf , java2idl-rtf@omg.org In-Reply-To: <3BEC6B52.D249E8A0@inprise.com> References: <4.3.2.7.2.20011109113451.021f19d0@san-francisco.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: !n1!!1%!!!^2E!!pL I think your interpretation is correct, but I also think the spec is flawed > in this area. Not true. The java/idl spec also states that: "All checked exception classes used in method declarations (other than java.rmi.RemoteException and its subclasses) are conforming RMI/IDL exception types (see Section 1.2.6, "RMI/IDL Exception Types," on page 1-5)." 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). Sorry, my mistake. You are correct. > In addition these orbs (the RI and J2SE at least) do not unpick the Unknown > exception at the other end they simply throw an UnknownException. Although > the spec says you are allowed to do this (at least according to the > javadoc) I think it should mandate that the nested exception is rethrown - > otherwise RMI-IIOP behaviour is different to other flavours of RMI. 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. But in general I think this is not true, i.e. I think that option (3) copes with an edge case and that option (2) should be mandated when the client is able to load the exception definition (which I believe is usually the case). Otherwise anarchy ensues IMO. 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. The IDL does declare FooEx and the method does declare raises(FooEx). FooEx in Not true. Take javax.ejb.FinderException, the IDL will declare FinderEx but the server will almost always throw something else e.g. javax.ejb.ObjectNotFoundException which as it stands the server will marshal as ObjectNotFoundEx which the IDL client knows nothing about. turn contains a valuetype FooException which is also declared in IDL, and that does allow inheritance. Yes, the subclasses of the declared exceptions must also be mapped, but this should work. In other words, what you are suggesting is exactly what the spec says. I may be missing something, but I don't agree that is what is says is what I am suggesting. andy Date: Fri, 09 Nov 2001 18:27:37 -0800 From: Vijaykumar Natarajan Subject: Re: Q: Why is there no symmetric equivalent for mapSystemException()onthe server side ? To: Andy Piper Cc: Vijaykumar Natarajan , Michael Rumpf , java2idl-rtf@omg.org Message-id: <3BEC9099.EF19B4CD@inprise.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <4.3.2.7.2.20011109113451.021f19d0@san-francisco.beasys.com> <4.3.2.7.2.20011109155924.017a0b18@san-francisco.beasys.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_+/Itubx0V40Z+DDY9zM/2Q)" X-UIDL: Zj6!!>Np!!(B%e9)^+!! Status: RO Andy Andy Piper wrote: > At 03:48 PM 11/9/2001 -0800, Vijaykumar Natarajan wrote: > > > I think your interpretation is correct, but I also think the spec is flawed > > > in this area. > > > >Not true. The java/idl spec also states that: > >"All checked exception classes used in method declarations (other than > >java.rmi.RemoteException and its subclasses) are conforming RMI/IDL > >exception types (see Section 1.2.6, "RMI/IDL Exception Types," on page 1-5)." > > > >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). > > Sorry, my mistake. You are correct. > > > > In addition these orbs (the RI and J2SE at least) do not unpick the Unknown > > > exception at the other end they simply throw an UnknownException. Although > > > the spec says you are allowed to do this (at least according to the > > > javadoc) I think it should mandate that the nested exception is rethrown - > > > otherwise RMI-IIOP behaviour is different to other flavours of RMI. > > > >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. > > But in general I think this is not true, i.e. I think that option (3) copes > with an edge case and that option (2) should be mandated when the client is > able to load the exception definition (which I believe is usually the > case). Otherwise anarchy ensues IMO. Agreed. > > > >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. > > > >The IDL does declare FooEx and the method does declare >raises(FooEx). FooEx in > > Not true. Take javax.ejb.FinderException, the IDL will declare >FinderEx but > the server will almost always throw something else e.g. > javax.ejb.ObjectNotFoundException which as it stands the server will > marshal as ObjectNotFoundEx which the IDL client knows nothing >about. Ah, now I understand what you're saying. However, I think the last part (ie "the server will marshal as ObjectNotFoundEx") would be a bug in the implementation. Since the raises indicates FinderEx, the server is incorrect in marshaling an ObjectNotFoundEx (which is a violation of the IDL contract). So, you are correct in what you are doing, but I disagree that the spec says otherwise. The spec only says that when mapping to IDL, ObjectNotFoundException maps to an ObjectNotFoundEx. Extrapolating that to runtime is what I think is incorrect. > > > >turn contains a valuetype FooException which is also declared in >IDL, and that > >does allow inheritance. Yes, the subclasses of the declared >exceptions > >must also > >be mapped, but this should work. In other words, what you are >suggesting is > >exactly what the spec says. > > I may be missing something, but I don't agree that is what is says >is what > I am suggesting. > > andy Vijay -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. [] vnatarajan1.vcf