@JsonProperty(access = Access.READ_ONLY) - unexpected behaviour

[weaselmetal]

Hey,

I was hoping to make use of @JsonProperty(access = Access.READ_ONLY), but failed.

Assume this class:

public class TestPojo
{
    private String firstName;

    private String lastName;

    @JsonProperty(access = Access.READ_ONLY)
    public String getFullName()
    {
        return firstName + " " + lastName;
    }

    public String getFirstName()
    {
        return firstName;
    }

    public void setFirstName(String firstName)
    {
        this.firstName = firstName;
    }

    public String getLastName()
    {
        return lastName;
    }

    public void setLastName(String lastName)
    {
        this.lastName = lastName;
    }
}

I couldn't find a way to stop the deserializer from attempting to deserialize the field "fullName".
The only thing that helps is to create a setter and annotate it with @JsonIgnore. However, that setter does not make sense and I don't want to have it. Is this a bug in behaviour or am I missing something? Thanks

[cowtowncoder]

That does sound like a bug indeed. Which version are you using?

[cowtowncoder]

Whoa. There is no unit test coverage for value of READ_ONLY. That should not be the case... No wonder there could be a bug lurking in there.

[cowtowncoder]

I can reproduce this with 2.6. Looks like READ_ONLY does actually hide/remove setter method (my test fails with "unknown property"), but will not mark it as ignorable, which it probably should do.

[cowtowncoder]

I added a failing test case for this, but not sure how easy it will be to pipe "do ignore" information.

Thank you for reporting the problem again.

[weaselmetal]

Thanks for dealing with the issue and sorry for the lack of details in my description. Afaik Access.READ_ONLY has just been added in 2.6. I also got the UnrecognizedPropertyException: Unrecognized field "fullName" ... not marked as ignorable

[cowtowncoder]

Correct, it's 2.6 only which is why I realized that asking for version wasn't fully necessary (but only after asking).

The fix would be to essentially carry along the name as "ignorable" property, similar to how @JsonIgnore is tracked. But I'll need to see how that plumbing is handled, since discovery occurs in bit different place.

[mewert]

Hi,

is there some easy workaround, until this is fixed? I mean instead of implementing a noop setter method?

The annotation @JsonIgnoreProperties sounds like it could help here. But it also has no effect, if I add it to a getter, regardless which values I choose for allowGetters or allowSetters.

Update: It seems that I found a solution by adding

@JsonIgnoreProperties(value="some_field", allowGetters = true, allowSetters = false)

to the class. So this could be a solution, if we don't need the @JsonIgnoreProperties annotation on class level for other purposes.

[cowtowncoder]

@plattfish thank you for sharing this. I am hoping to address this, along with some issues with creator property handling, in 2.8.

[thedoctor]

Any movement here? I just bumped into this issue.

[heruan]

Don't know if related, but I'm experiencing this with a Map:

public class Ticket {

    @JsonProperty(access = Access.READ_ONLY)
    @JsonSerialize(using = MapToArraySerializer.class)
    public SortedMap<Timer, Integer> getServiceTimers() {
        // ...
    }

}

All works on serialization, but on deserialization of Ticket I get this exception:

Can not find a (Map) Key deserializer for type [simple type, class Timer]
 at [Source: java.io.SequenceInputStream@1100946d; line: 1, column: 1]
    at com.fasterxml.jackson.databind.JsonMappingException.from(JsonMappingException.java:261)

I'm on Jackson 2.8.

[jyothri]

+1
I also have come across this issue. I am using spring boot which pulled in Jackson version 2.6.5

[msfanous]

This disabling this feature on your ObjectMapper helped me avoid this issue.
ObjectMapper mapper = new ObjectMapper(); mapper.disable(MapperFeature.USE_GETTERS_AS_SETTERS);

[philbayer]

Hi @cowtowncoder - any word on a fix for this? I am using 2.8.5, and it appears the issue persists. @plattfish's solution did not work for me.
I don't mind trying to isolate the issue myself if it will speed up development of a patch.