Details
Improvement
Open
Major
Description
When something goes wrong in serialization, I'd like the ability to choose how the error is processed.
Rather than throwing an exception, I'd like a callback (ErrorHandler) to occur so I can choose to barf, ignore, recover, log, etc.
Issue Links
Activity
something like 'ignoreUnmappedElements' is a must have feature when consuming third party REST API's
workaround:
(http://initbinder.com/articles/how-to-tell-xstream-to-not-unmarshall-xml-fields.html)
XStream xstream = new XStream() { @Override protected MapperWrapper wrapMapper(MapperWrapper next) { return new MapperWrapper(next) { @Override public boolean shouldSerializeMember(Class definedIn, String fieldName) { if (definedIn == Object.class) { return false; } return super.shouldSerializeMember(definedIn, fieldName); } }; } };
galmeida
added a comment - - edited workaround:
( http://initbinder.com/articles/how-to-tell-xstream-to-not-unmarshall-xml-fields.html )
XStream xstream = new XStream() {
@Override
protected MapperWrapper wrapMapper(MapperWrapper next) {
return new MapperWrapper(next) {
@Override
public boolean shouldSerializeMember( Class definedIn, String fieldName) {
if (definedIn == Object .class) { return false ; }
return super .shouldSerializeMember(definedIn, fieldName);
}
};
}
};
@galmeida: If you have questions about XStream, please use the user's list, JIRA is no help forum. This code snippet has there been published more than once and the code is part of XStream's acceptance tests for years. And the mailing list's archives also contain the drawbacks of the solution.
Jörg Schaible
added a comment - @galmeida: If you have questions about XStream, please use the user's list, JIRA is no help forum. This code snippet has there been published more than once and the code is part of XStream's acceptance tests for years. And the mailing list's archives also contain the drawbacks of the solution. Is there any ETA on this issues ?
Jimmy Selamy
added a comment - Is there any ETA on this issues ? Remember: This issue features a general error hander for any kind of serialization error. However, most comments have been about unknown elements, which has been solved with XSTR-691.
Jörg Schaible
added a comment - Remember: This issue features a general error hander for any kind of serialization error. However, most comments have been about unknown elements, which has been solved with XSTR-691 . 
This would provide a solution to the following issue posed to user@xstream.codehause.org
Hello all.
Is anyone aware of a way to have XStream ignore elements that don't map? I don't mean the "ommitField" method. What I need is a global setting that instructs XStream to ignore exceptions caused by an element found in the xml being parsed but which has no corresponding property on the java side. We are using XStream to process an XML file that is not only used by us. As a result, the xml file may be modified to included additional fields which are needed by other projects. It would be nice if we didn't have to keep updating our Java objects to include these extra fields. The xml is handled this way because it is third-party generated and not all consumers are java clients.
Example XML:
<someObject>
<field1>test</field1>
<field2>foo</field2>
<field3>bar</field3>
</someObject>
Example POJO:
{ String field1; String field2; //No property for "field3" ... causes error //Setters/Getters }public class SomeObject
Would be nice to have XStream.ignoreUnmappedElements() which would ignore the error generated above. Perhaps with overloaded versions that took a specific class or type to ignore elements that don't map that the specific class or type. Maybe even an overloaded version that takes a regular expression.
Any thoughts?