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

Problem deserialization "raw generic" fields (like Map) in 2.11.2 #2846

Closed
cowtowncoder opened this issue Sep 6, 2020 · 3 comments
Closed
Milestone

Comments

@cowtowncoder
Copy link
Member

cowtowncoder commented Sep 6, 2020

(note: follow-up to #2821)

Looks like there are some problems with passing of type resolution context in case of "raw" references to generic types, something like:

class Generic<T> {
   public Map value;
}

where in resolution is attempted for raw Map (expressed as Class<?> and not GenericType); type resolver gets confused.
Full reproduction provided in #2821 by @MartinTeeVarga is as follows:

    static class GenericEntity<T> {
        T field;

        Map map;

        public void setField(T field) {
            this.field = field;
        }

        public T getField() {
            return field;
        }

        public Map getMap() {
            return map;
        }

        public void setMap(Map map) {
            this.map = map;
        }
    }

    static class SimpleEntity {
        Integer number;

        public void setNumber(Integer number) {
            this.number = number;
        }

        public Integer getNumber() {
            return number;
        }
    }

    public void testTypeRefinementIssue() throws Exception {
        ObjectMapper m = new ObjectMapper();
        final String JSON = "{ \"field\": { \"number\": 1 }, \"map\": { \"key\": \"value\" } }";
        GenericEntity<SimpleEntity> genericEntity = m.readValue(JSON,
                new TypeReference<GenericEntity<SimpleEntity>>() {});
        assertNotNull(genericEntity);
    }
@cowtowncoder
Copy link
Member Author

Ok yes. I think that the original changes for #2796 were the root cause here. Fundamentally I think TypeBindings abstraction is confusing and used in incorrect way here; and as as @lhotari suggested the fix for 2.11(.3) needs to be to apply bit of filtering by callers.
For 2.12 I will try to change TypeFactory API slightly to probably deprecated public JavaType constructType(Type type, TypeBindings bindings), suggesting users not use, and change internal code to call a new similar method but one that knows to NOT apply bindings to Class<?>.

Anyway, I think this might be complete fix for 2.11.3; I wish we had more unit tests for raw generic types as this would have been caught earlier.

@MartinTeeVarga
Copy link

Thanks for this. I am using Jackson in an app using Kotlin, GraphQL Java and Spring Boot - I wasn't able to isolate the problem yet. I will try the next version containing this fix and if it doesn't fix my issue, I will investigate further.

@cowtowncoder
Copy link
Member Author

@MartinTeeVarga thank you for your help here! As I said I wish I had avoided this self-inflicted regression but I think it should be properly resolved now for 2.11.3 (and 2.12.0).

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