RFR 8009581: Xpathexception does not honor initcause()

[Aleksej Efimov]

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.
>>