Details
-
Type: Improvement
-
Status: Closed
-
Priority: Minor
-
Resolution: Not A Bug
-
Affects Version/s: 1.4.7
-
Fix Version/s: None
-
Component/s: Converters
-
Labels:None
Description
Hi,
I would like to suggest a small fix that would check that the result of a readResolve() call is not null.
While developing with XStream, I forgot to return the object in my readResolve() implementation, and the unmarshaling process continued without throwing any exception, resulting with a null object. It took me several hours to understand that the cause for a null object is my wrong readResolve() implementation. In this case I recommend to throw a descriptive exception that will help the developer to understand that something is wrong with their readResolve() implementation instead of returning a null object.
The suggested fix is to replace line 66 in SerializationMethodInvoker from:
return readResolveMethod.invoke(result);
to:
Object invokeResult = readResolveMethod.invoke(result);
if (invokeResult == null)
throw new ObjectAccessException(resultType.getName() + ".readResolve() returned null");
return invokeResult;
Attached please find SVN patch file. I have run all unit tests and they completed successfully after applying this fix.
Activity
Field | Original Value | New Value |
---|---|---|
Resolution | Not A Bug [ 6 ] | |
Status | Open [ 1 ] | Resolved [ 5 ] |
Status | Resolved [ 5 ] | Closed [ 6 ] |
Originally I though this patch would be a good idea, but null is a valid result from readResolve. At least Java IO serialization has absolutely no problem with it and XStream behaves currently exactly the same. Also it seems that this behavior is actively used as it would break
XSTR-690(and other use cases if you google around). Therefore, many thanks for your patch, but for the sake of compatibility with the Java standard serialization, I cannot apply it. Sorry.