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

declaringClass of "enum-as-POJO" not removed for ObjectMapper with a naming strategy #2365

Closed
tynakuh opened this issue Jun 24, 2019 · 5 comments
Milestone

Comments

@tynakuh
Copy link

tynakuh commented Jun 24, 2019

Happens in 2.9.9.

When you change ObjectMapper to use a different naming strategy, i.e:

ObjectMapper mapper = new ObjectMapper();
mapper.setPropertyNamingStrategy(PropertyNamingStrategy.SNAKE_CASE);

When serialising/using writeToString(Object value) for an object such as:

@JsonFormat(shape = JsonFormat.Shape.OBJECT)
public enum Foo
{
    BAR("Foo", 0),
...

"declaring_class" will be added to the JSON payload.

Normally this is removed at:
com/fasterxml/jackson/databind/ser/BasicSerializerFactory.java:1139 but because in
com.fasterxml.jackson.databind.introspect.BasicBeanDescription#removeProperty (It's only usage as far as I can see) we aren't using InternalName, declaringClass is not removed. Potential fix here is to change prop.getName() to prop.getInternalName(), a quick test of that seemed to work in my case.

@cowtowncoder cowtowncoder changed the title declaringClass not removed for ObjectMappers with a naming strategy declaringClass of "enum-as-POJO" not removed for ObjectMapper with a naming strategy Jul 1, 2019
@cowtowncoder
Copy link
Member

cowtowncoder commented Jan 9, 2020

Interesting. Thank you for reporting this (and apologies for slow follow-up) -- sounds like a bug indeed! I'll verify that suggested fix works: I suspect it should in some form: does for this property, but changing public method to change lookup might break other handling. But either addition of secondary lookup or (if need be) adding new method should work.

@cowtowncoder
Copy link
Member

Interestingly enough, I can reproduce this on 2.10 branch (including 2.10.2) but NOT on 2.11.
So I think something got fixed since 2.10, although none of issues fixed so far seems related.
Still, adding test to verify fix I consider this resolved for 2.11 (and 3.0 via master); will add further notes if I find something explaining which change resulting in fix,.

@LukasKarasek
Copy link

Thanks
I delete my post because first I thought it was fixed in 2.10.1 but then I realize that this is still ongoing ticket with this bug.
I did a workaround on our side and will wait for fixed version.
L.

@cowtowncoder cowtowncoder added this to the 2.11.0 milestone Jan 9, 2020
@cowtowncoder cowtowncoder added 2.11 and removed 2.10 labels Jan 9, 2020
@cowtowncoder
Copy link
Member

Ok. At this point I think I will not try fixing it for 2.10.x partly since it is resolved for 2.11, and partly since I suspect there is non-trivial risk for regression for 2.10.x. And mostly I guess as I really hope to get 2.11.0 released relatively soon (early Feb 2019).

@LukasKarasek
Copy link

OK, thanks , I'll try when it will release .

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

3 participants