RFR 8009581: Xpathexception does not honor initcause()

[Aleksej Efimov]

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