User defined error handling

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:
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?

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) (the URL is good at the time of posting, I can't guarantee that the Spring project won't move their API in the future)

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.

I used the solution from the CustomMapperTest but now my implicit fields don't seem to work, for example a field mapped like this:

@XStreamImplicit
ArrayList<T> contents;

Is ignored now. Any tips on how to get around this?

The following implementation passed unit tests for me; basically, if definedIn == Object.class, we couldn't find a field, and so we check whether that field name maps to a class. This probably won't work if I get unexpected fields in something that is not an implicit collection and the field has a name matching an existing class. I'll try and mess with this some more to see if I can resolve that issue.

/**

• Allow and ignore unexpected xml tags
  */
  protected MapperWrapper wrapMapper(MapperWrapper next) {
  return new MapperWrapper(next) {
  @SuppressWarnings("unchecked")
  public boolean shouldSerializeMember(Class definedIn, String fieldName)
  Unknown macro: { try { return definedIn != Object.class || realClass(fieldName) != null; } catch(CannotResolveClassException cnrce) { return false; } }

  };
  }

I did a test and it appears that the problem I mentioned above doesn't come up ... here's the code again with proper formatting:

    protected MapperWrapper wrapMapper(MapperWrapper next) {
        return new MapperWrapper(next) {
            @SuppressWarnings("unchecked")
            public boolean shouldSerializeMember(Class definedIn, String fieldName) {
                try {
                    return definedIn != Object.class || realClass(fieldName) != null;
                } catch(CannotResolveClassException cnrce) {
                    return false;
                }
            }
        };
    }

Note: the solution in my comment above no longer works with xstream 1.3.1 but it does work in 1.3.

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: 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 ?

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.