RFR 8009581: Xpathexception does not honor initcause() (original) (raw)

Aleksej Efimov aleksej.efimov at oracle.com
Tue May 21 11:02:28 UTC 2013

Jason, Thank you for looking into this patch. Actually, the readObject calls the super.initCause, because there is no initCause in XPathException. About 'super.getCause() == null' check: yes it can be done in such way. In current version I caught the IllegalStateException to correctly process the situation when the cause was already initialized. If you think its better to use getCause() instead of it - I'll fix it in final review version.

-Aleksej

On 05/17/2013 11:59 PM, Jason Mehrens wrote:

Aleksej,

Should readObject call super.initCause instead of this.initCause? Maybe initCause should be only called if scause != null && super.getCause() == null. If super.getCause is not null initCause will always fail. Jason ---------------------------------------- Date: Fri, 17 May 2013 23:34:35 +0400 From: aleksej.efimov at oracle.com To: core-libs-dev at openjdk.java.net; david.holmes at oracle.com; Alan.Bateman at oracle.com Subject: Re: RFR 8009581: Xpathexception does not honor initcause()

Alan, David and other team! Resending the previous RFR 8009581 v.1. It might lost among the pack posts. Best regards, Aleksej On 11.05.2013 23:43, Aleksej Efimov wrote: Hello Alan, David and other experts,

I presents the second version of fix for XPathException class for your review: http://cr.openjdk.java.net/~dmeetry/8009581/webrev.1/ <http://cr.openjdk.java.net/%7Edmeetry/8009581/webrev.1/> The serialized form remains the same in this patch, as was suggested. I have also done some tests with serialization/deserialization of XPathException class with different JDK versions. The class serialized on JDK with patch was successfully deserialized by JDK versions (6,7,8) without fix and vice versa. -Aleksej On 04/30/2013 11:08 AM, David Holmes wrote: On 29/04/2013 11:45 PM, Aleksej Efimov wrote: Alan, The XPathException class doesn't have any fields only methods (it had a 'cause' method, but it was deleted in suggested fix). It had a cause field that was deleted not a method, hence the change to the serialized form that Alan is highlighting.

David ----- And, as I can see, there is no need to control what information is saved or to append additional information to the serialization stream. So, I think the readObject/writeObject is not required here.

-Aleksej On 04/24/2013 10:17 PM, Alan Bateman wrote: On 24/04/2013 14:53, Aleksej Efimov wrote: Hi all,

Can I have a reviews for the following change: http://cr.openjdk.java.net/~dmeetry/8009581/webrev.0/ <http://cr.openjdk.java.net/%7Edmeetry/8009581/webrev.0/> Summary: There is an erroneous behavior in 'initCause' method of javax.xml.xpath.XPathException class. Lets look at the following situation: XPathException is created with 'XPathException(String )' constructor and then the cause is initialized with 'initCause' method. Such initialization sequence of actions isn't restricted by XPathException [1] and Throwable [2] docs. After that a cause is retrieved by 'getCause()' method: this call returns incorrect cause = 'null'. It should return the same cause as was used in 'initCause'. And this is the erroneous behavior. Suggested fix (with regression test) is applicable both for JDK 8 and 7. Exceptions are serializable so I think this may require further investigation to see if a readObject/writeObject is required. -Alan.

More information about the core-libs-dev mailing list