|
History
| Log In
|
|
|
|
This issue is more than a 'nice to have'. With this feature, XStream could be used to make a 'best guess' parsing of XML files generated from a wider variety of sources than ones rigidly under the control of the programmer.
An example of this kind of 'ignoreUnmappedElements' / 'requiredElements' / 'optionalElements' strategy is to be found in the Spring framework's ServletRequestDataBinder classes. (http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/web/bind/ServletRequestDataBinder.html I'm working on a large scale project and assessing XStream versus other object serializers. The ability to control error handling when encountering unexpected xml is essential to us and is a dealbreaker in this case.
We're creating a fairly mature migration feature, which requires serialized data to be forwards and backwards compatible. We'd love to use XStream, but without fixing this bug there seems to be no support for continuing deserialization after encountering unexpected xml... This is a pretty serious drawback, and I think its fair to say that many projects are running into this same problem. Having an "ignore errors" flag should be easy enough and would go a long way. An equally cheap alternative that would be helpful is delegation of xml parsing errors via some callback object. At this point, I don't think anyone here is being especially picky – any simple solution would be extremely helpful. For a simple solution for the special problem of unexpected XML you may have a look at the acceptance test CustomMapperTest.testCanBeUsedToOmitUnexpectedElements().
Using the solution in the acceptance test worked. It would still be useful to simply be able to configure xstream via a property or something of that sort to make this the default for an installation. Thanks for the test reference, it appeared to only work in 1.2.2 for us.
Funilly enough, we are having exactly the opposite problem on our project. We're using XStream v1.2.2 with JDK 1.4 and we want XStream to throw an error if it attempts to de-serialize an XML which can't be mapped exactly to a POJO.
In other words, with the test defined above, we are not getting the error. Any suggestions why we don't and/or how to get the default behaviour would be very helpful. @Nikolay: Please use the user's list for questions.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
User defined error handling
–
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:
public class SomeObject{
String field1;
String field2;
//No property for "field3" ... causes error
//Setters/Getters
}
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?