Jackson JSON Processor
  1. Jackson JSON Processor
  2. JACKSON-539

"Unrecognized field X, not marked as ignorable" error

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7.4
    • Fix Version/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      I checked in a (disabled, commented-out) test case that currently fails when doing a serialization/deserialization round-trip.

      See org.codehaus.jackson.jaxb.TestSerializationToAtomContent (uncomment the last line of the test).

      I haven't had time to dig much deeper than that yet, but I wanted to get the issue logged.

        Activity

        Hide
        Tatu Saloranta added a comment -

        The problem with XmlTransient and XmlAttribute is the definition of priorities: whether ignoral is to occur before joining getter/setter pair, renaming or afterwards. So exact resulting combination needs to be carefully defined – order matters. For example, one could see @XmlTransient as applied to remove the whole property; which is not what test is expecting. And with renaming it all gets rather muddy.

        As to rewrite, I mean that existing JaxbAnnotationIntrospector has enough fundamental flaws that it must be significantly rewritten. For example it relies on JDK property descriptors which only look for public methods, which obviously won't work when annotations can indicate "publicness". Code has many other issues too but that's the obvious one from last changes I made.

        On plus side, jackson native pieces also need to be rewritten, if for slightly different reasons – here the issue is that getters and setters are not linked as there is no logical concept of property; so this should be added, and from thereon things can both work better and implementation can be simplified.
        Given this it should be possible to reduce code duplication a bit, as it may be possible to have more shared discovery code.

        Of course if a patch can be found for this particular test I am all for it, even if we will have to do more drastic rewrite down the road.

        Show
        Tatu Saloranta added a comment - The problem with XmlTransient and XmlAttribute is the definition of priorities: whether ignoral is to occur before joining getter/setter pair, renaming or afterwards. So exact resulting combination needs to be carefully defined – order matters. For example, one could see @XmlTransient as applied to remove the whole property; which is not what test is expecting. And with renaming it all gets rather muddy. As to rewrite, I mean that existing JaxbAnnotationIntrospector has enough fundamental flaws that it must be significantly rewritten. For example it relies on JDK property descriptors which only look for public methods, which obviously won't work when annotations can indicate "publicness". Code has many other issues too but that's the obvious one from last changes I made. On plus side, jackson native pieces also need to be rewritten, if for slightly different reasons – here the issue is that getters and setters are not linked as there is no logical concept of property; so this should be added, and from thereon things can both work better and implementation can be simplified. Given this it should be possible to reduce code duplication a bit, as it may be possible to have more shared discovery code. Of course if a patch can be found for this particular test I am all for it, even if we will have to do more drastic rewrite down the road.
        Hide
        Ryan Heaton added a comment -

        JAXB works with properties, so the application of the annotations for the JaxbAnnotationIntrospector should happen after "joining" the getter/setter pairs, but before any "renaming". Also, as you noticed, it relies heavily on JDK property descriptors because that's how JAXB works. It works on either public properties or private/protected/public fields. JAXB ignores any private or protected methods, even if there are any annotations applied to them. So there really is a fundamental difference between the way the Jackson introspector works and the way the Jaxb introspector should work. Maybe there's a way for the introspector to indicate which way it works, but that makes it especially tricky in the cases where introspectors are "chained".

        Show
        Ryan Heaton added a comment - JAXB works with properties, so the application of the annotations for the JaxbAnnotationIntrospector should happen after "joining" the getter/setter pairs, but before any "renaming". Also, as you noticed, it relies heavily on JDK property descriptors because that's how JAXB works. It works on either public properties or private/protected/public fields. JAXB ignores any private or protected methods, even if there are any annotations applied to them. So there really is a fundamental difference between the way the Jackson introspector works and the way the Jaxb introspector should work. Maybe there's a way for the introspector to indicate which way it works, but that makes it especially tricky in the cases where introspectors are "chained".
        Hide
        Tatu Saloranta added a comment -

        Your description makes sense, and is close to my understanding wrt. first joining properties, then applying renames. This is actually how I would want to change Jackson in future, as it would help with a few things.

        However: public vs private, related to property introspector: this is why I suggested that perhaps test case itself is not correct, since it has protected method(s) with annotations, and assumes they ought to be found. I did not mean to imply that test as intended would be wrong, just that test might have a bug. Does this make sense?

        Show
        Tatu Saloranta added a comment - Your description makes sense, and is close to my understanding wrt. first joining properties, then applying renames. This is actually how I would want to change Jackson in future, as it would help with a few things. However: public vs private, related to property introspector: this is why I suggested that perhaps test case itself is not correct, since it has protected method(s) with annotations, and assumes they ought to be found. I did not mean to imply that test as intended would be wrong, just that test might have a bug. Does this make sense?
        Hide
        Tatu Saloranta added a comment -

        Hmmmh. Ok, looks like I mixed up my thoughts with this issue and JACKSON-354.

        Anyway: after reading JAXB javadocs, and testing, I think you are actually incorrect wrt private/protected methods, fields; they are considered if annotated (with @XmlAttribute / @XmlElement); see for example javadocs of @XmlAccessorType javadocs.
        So basic JDK property introspection functionality is unfortunately not enough to properly support all usage; but this matters more with JACKSON-354 – here simple renaming would actually work properly.

        Show
        Tatu Saloranta added a comment - Hmmmh. Ok, looks like I mixed up my thoughts with this issue and JACKSON-354 . Anyway: after reading JAXB javadocs, and testing, I think you are actually incorrect wrt private/protected methods, fields; they are considered if annotated (with @XmlAttribute / @XmlElement); see for example javadocs of @XmlAccessorType javadocs. So basic JDK property introspection functionality is unfortunately not enough to properly support all usage; but this matters more with JACKSON-354 – here simple renaming would actually work properly.
        Hide
        Tatu Saloranta added a comment - - edited

        Fixed as a result of the property detection rewrite (see JACKSON-242) – should now work as expected in 1.9.

        Show
        Tatu Saloranta added a comment - - edited Fixed as a result of the property detection rewrite (see JACKSON-242 ) – should now work as expected in 1.9.

          People

          • Assignee:
            Tatu Saloranta
            Reporter:
            Ryan Heaton
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: