Issue 3512: Text attached.

Summary: The javax.rmi.CORBA.Tie.deactivate() method does not declare any exceptions. However, when using a POA
servant, the following exceptions can be thrown by the RMI/IDL tie's implementation of deactivate():
org.omg.PortableServer.POAPackage.ServantNotActive org.omg.PortableServer.POAPackage.WrongPolicy (by the
servant_to_id() method) org.omg.PortableServer.POAPackage.ObjectNotActive
org.omg.PortableServer.POAPackage.WrongPolicy (by the deactivate_object() method) How should these exceptions be
handled by Tie.deactivate()? If they should be rethrown by Tie.deactivate(), what exception(s) should be used? (This issue
was raised by Max Mortazavi of Sun.)
Resolution: See revised text below.
Revised Text: 1. In section 1.5.1.1, add "throws java.rmi.NoSuchObjectException" to the declaration of the Tie.deactivate
method. 2. In section 1.5.1.1, add the following sentence at the end of the paragraph describing the Tie.deactivate method:
"If the target object could not be deactivated (e.g., because it is not currently active), a NoSuchObjectException is thrown."
3. In section 1.5.1.4, add "throws java.rmi.NoSuchObjectException" to the declaration of the Util.unexportObject method.
4. In section 1.5.1.4, add the following sentence at the end of the paragraph describing the Util.unexportObject method: "If
the object is not currently exported or could not be deactivated, a NoSuchObjectException is thrown." 5. In section 1.5.3.2,
add "throws java.rmi.NoSuchObjectException" to the declaration of the UtilDelegate.unexportObject method.
Actions taken:
December 21, 1999: received issue
May 24, 2001: closed issue

----


Email from Simon Nash (IBM)


Everett,
OK, I agree that this clearly says ptc/00-01-06 and therefore does not
include the 3152
resolution which was in ptc/00-12-02. However, Sun did include the 3857
change in
J2SE 1.4 so there is some precedent for including selected issues from
ptc/00-12-02.

What is not clear to me is when Sun plans to implement issue 3152. The
Sun response to
the Business Committee Questionnaire said it would be implemented in
J2SE 1.3 and J2EE 1.2.
However, this change is not source compatible with code that calls
Util.unexportObject()
so it really needs to be made at a major release boundary. If it is not
in J2SE 1.4, then
it will almost certainly have to wait until J2SE 1.5. In that case, IBM
could not implement
it in our 1.4.x JDKs because of the resulting source incompatibility
with Sun's JDKs, which
would mean that user code written to compile with Sun's JDK would not
compile with IBM's JDK
and vice versa.

Making this change now would allow other ORB vendors to fix this problem
with missing
exceptions in the J2SE 1.4 timeframe rather than having to wait until
J2SE 1.5 in 2003.
Since the issue was resolved in 11/2000, it does not seem very
reasonable for all the ORB
vendors to have to wait 3 years before they can put the fix into their
products.

   Simon

Everett Anderson wrote:
>
> Hi Simon,
>
> I found the public link for our J2SE 1.4 CORBA compliance statement:
>
> http://java.sun.com/j2se/1.4/docs/api/org/omg/CORBA/doc-files/compliance.html
>
> There may have been some minor changes since J2SE 1.4 Beta, but that's
> where they'll show up. It's linked off of the new features/CORBA
> section.

--
Simon C Nash, Chief Technical Officer, IBM Java Technology
Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England
Internet: ###@###.### Lotus Notes: Simon Nash@ibmgb

********************************************************************************
###@###.### 2001-10-29

Fix verified OK
- With build: j2sdk-1_4_0-beta3-bin-b84-solsparc-20_oct_2001
- With test: /java/idl/ws/rip/RIP_TEST_MASTER/tests/api/javax/rmi/CORBA/Util/UnexportObjectTests.java
********************************************************************************