Transient fields serialized when @XmlAccessorType(XmlAccessType.FIELD) is present

[dsharp1]

private transient fields are serialized when the class is annotated with XmlAccessType.FIELD.

The cause is related to the way that the _addFields method in POJOPropertiesCollector determines if the field should be skipped. If the field is transient AND the field name is null (where the field name is determined by XmlElement, XmlElementWrapper, etc), the field is marked as not visible and gets skipped.

When the isVisible method in JaxbAnnotationIntrospector returns true if the annotated class has a XmlAccessType.FIELD class annotation, this causes the name to be returned as PropertyName.USE_DEFAULT instead of null. This means that the name is not null (its and empty string) when _addFields method checks the transient field and therefore it does not check if the field is transient.

The attached unit test demonstrates the use case and results in a stackoverflow due to infinite recursion. Removing the @XmlAccessorType(XmlAccessType.FIELD) will allow the test to run without an error.
simple.zip

[dsharp1]

The changed that exposed this issue was made a couple months ago in POJOPropertiesCollector. The check for hasName is true since USE_DEFAULT is an empty string.

        if (f.isTransient()) {
            // 20-May-2016, tatu: as per [databind#1184] explicit annotation should override
            //    "default" `transient`
            if (!hasName) {
                visible = false;
                if (transientAsIgnoral) {
                    ignored = true;
                }
            }
        }

[cowtowncoder]

Thank you for reporting this. I hope to look into it soon.

[cowtowncoder]

Unfortunately I can not reproduce this locally with JSON output, with version 2.8.1, using classes shown in simple.zip.

[dsharp1]

I am not sure why that would be. The issue occurs for me in 2.8.1, 2.8.2-SNAPSHOT, and 2.8.3-SNAPSHOT. Let me detail my steps a little further and maybe you can compare against the steps that you performed.

1. cloned and pulled jackson-module-jaxb-annotations (branch = master)
2. With the attached simple.zip, I extracted the zip into the src/test/java folder.
3. Added the dataformat dependency to the root pom.xml:
   
   com.fasterxml.jackson.dataformat
   jackson-dataformat-xml
   ${version.jackson.core}
   test
   
4. run "mvn clean test"

If I run the same test in the jackson-dataformat-xml project, I do not need to add the extra dependency, and the result is the same.

[dsharp1]

I added an assertion to the code to see if that makes a difference for you when you run it. Also, I am attaching the pom.xml with the dependency required to run this.
simple2.zip

[rpatrick00]

jaxb-annotations-bug-61.zip is a simple example to reproduce the problem with Jackson 2.8.1. Simply unzip and run mvn test and see the failure.

If you set the jacksonVersion property to 2.7.6 in pom.xml and re-run the test, you will see that the test works properly.

[rpatrick00]

Any idea when you might have time to review Derek's proposed fix. This regression is preventing us from uptaking Jackson 2.8+. Thanks!

[cowtowncoder]

@rpatrick00 I haven't had time to look into this. From above I am not 100% what the suggested fix is, although as it is related to name handling of JAXB module, perhaps it can be handled here, locally.
That'd be good since changes to jackson-databind often have higher risk of regression.

[cowtowncoder]

Downloaded zip, can reproduce the failure now.
I can also reproduce with json output, when using JAXB annotations.

[cowtowncoder]

Looks like this has to do with auto-detection; should not see the getter...

[rpatrick00]

Whatever it is, this change caused the regression. I hope you are able to find a fix...