Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.2
    • Fix Version/s: Upcoming
    • Component/s: Core
    • Labels:
      None

      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

          Hide
          Mahlon Gumbs added a comment -

          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?

          Show
          Mahlon Gumbs added a comment - 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?
          Hide
          Ben Ketteridge added a comment -

          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)

          Show
          Ben Ketteridge added a comment - 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)
          Hide
          Stanley added a comment -

          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.

          Show
          Stanley added a comment - 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.
          Hide
          Jörg Schaible added a comment -

          For a simple solution for the special problem of unexpected XML you may have a look at the acceptance test CustomMapperTest.testCanBeUsedToOmitUnexpectedElements().

          Show
          Jörg Schaible added a comment - For a simple solution for the special problem of unexpected XML you may have a look at the acceptance test CustomMapperTest.testCanBeUsedToOmitUnexpectedElements().
          Hide
          Christopher L Quirk added a comment -

          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.

          Show
          Christopher L Quirk added a comment - 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.
          Hide
          Nikolay Jordanov added a comment -

          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.

          Show
          Nikolay Jordanov added a comment - 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.
          Hide
          Jörg Schaible added a comment -

          @Nikolay: Please use the user's list for questions.

          Show
          Jörg Schaible added a comment - @Nikolay: Please use the user's list for questions.
          Hide
          Dobes Vandermeer added a comment -

          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?

          Show
          Dobes Vandermeer added a comment - 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?
          Hide
          Dobes Vandermeer added a comment -

          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; } }

            };
            }

          Show
          Dobes Vandermeer added a comment - 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; } } }; }
          Hide
          Dobes Vandermeer added a comment -

          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:

          Allow and ignore unexpected xml tags
              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;
                          }
                      }
                  };
              }
          
          Show
          Dobes Vandermeer added a comment - 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: Allow and ignore unexpected xml tags 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 ; } } }; }
          Hide
          Dobes Vandermeer added a comment -

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

          Show
          Dobes Vandermeer added a comment - Note: the solution in my comment above no longer works with xstream 1.3.1 but it does work in 1.3.
          Hide
          Naresh Narayana added a comment -

          I have tested the proposed solution by Dobes Vandermeer and it works in 1.3.1.

          CustomMapperTest(1.3) passes the tests.

          Thank you very much.

          Show
          Naresh Narayana added a comment - I have tested the proposed solution by Dobes Vandermeer and it works in 1.3.1. CustomMapperTest(1.3) passes the tests. Thank you very much.
          Hide
          galmeida added a comment -

          something like 'ignoreUnmappedElements' is a must have feature when consuming third party REST API's

          Show
          galmeida added a comment - something like 'ignoreUnmappedElements' is a must have feature when consuming third party REST API's
          Hide
          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);
                    }
                 };
              }
          };
          
          Show
          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); } }; } };
          Hide
          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.

          Show
          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.
          Hide
          Jimmy Selamy added a comment -

          Is there any ETA on this issues ?

          Show
          Jimmy Selamy added a comment - Is there any ETA on this issues ?
          Hide
          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.

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

            People

            • Assignee:
              Unassigned
              Reporter:
              Joe Walnes
            • Votes:
              23 Vote for this issue
              Watchers:
              18 Start watching this issue

              Dates

              • Created:
                Updated: