Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ACCEPT_CASE_INSENSITIVE_PROPERTIES is not respected for creator properties #1438

Closed
apatrida opened this issue Oct 31, 2016 · 3 comments
Closed
Milestone

Comments

@apatrida
Copy link
Member

reported in FasterXML/jackson-module-kotlin#47

When creators with properties are used, databind assumes that the name returned for hte property is literal (i.e. provided with JsonProperty annotation) but in cases where properties are provided implicitly (Java 8, or Kotlin Module) this is not the case, the target property name is provided.

So when the ACCEPT_CASE_INSENSITIVE_PROPERTIES feature is used anything that has a case mismatch fails.

in BeanDeserializer

// in BeanDeserializer...

SettableBeanProperty creatorProp = creator.findCreatorProperty(propName);
// null is returned
if (creatorProp != null) {
                  ...
}

which calls findCreatorProperty() in PropertBasedCreator:

public SettableBeanProperty findCreatorProperty(String name) {
        // fails because does not do case insensitive check when ACCEPT_CASE_INSENSITIVE_PROPERTIES is true
        return _propertyLookup.get(name);
    }

The hash lookup does not use the value of this feature switch like it does when looking for properties to be set after construction.

@cowtowncoder
Copy link
Member

Hmmh. So... Feature ACCEPT_CASE_INSENSITIVE_PROPERTIES refers to matching of differing case property names from data (json etc) into POJO properties -- so that input property "Foo" would match POJO property of foo. But handling of properties during construction of deserializers is different, so I wonder if this extends to matching of case-specific names; like getter "getFileName()" vs "setFilename()"...
Looking at code, those should get canonicalized. So maybe it's just a question of creator-properties not getting properly mangled.

cowtowncoder added a commit that referenced this issue Nov 13, 2016
@cowtowncoder
Copy link
Member

Can reproduce as suggested; add a failing test and hope troubleshoot some more.

@cowtowncoder cowtowncoder removed the 2.8 label Nov 14, 2016
@cowtowncoder cowtowncoder added this to the 2.8.5 milestone Nov 14, 2016
@cowtowncoder
Copy link
Member

Fixed by adding handling in the missing place, PropertyBasedCreator.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants