Jackson JSON Processor

combination of FilterExceptFilter and @JsonUnwrapped filters too many properties

Details

  • Type: Improvement Improvement
  • Status: In Progress In Progress
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.9.2
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

When using @JsonUnwrapped annotation on a property, the filter is applied on the property itself, thus filtering everything.

Let's have a look at the following example :

{ "name" : "home", "latitude" : 127, "longitude" : 345 }

to classes defined as:
@JsonFilter("myFilter")
class Place

{ public String name; @JsonUnwrapped public Location location; }

@JsonFilter("myFilter")
class Location

{ public int latitude, longitude; }

If setting "myFilter" to return only "name" and "latitude", it returns only :

{ "name" : "home" }

While I expect to have :

{ "name" : "home", "latitude" : 127, }

This is due to the fact that "FilterExceptFilter.serializeAsField" method just checks for the name (but did not checked for the unwrap).

Changing one line of the method "FilterExceptFilter.serializeAsField" :
From
if (_propertiesToInclude.contains(writer.getName())) {
To
if (_propertiesToInclude.contains(writer.getName()) || writer instanceof UnwrappingBeanPropertyWriter) {
This works as expected

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tatu Saloranta added a comment -

I have to think about whether this is considered a bug or feature. @JsonUnwrapped is all around nasty feature to support, leading to many potential issues with combinations...
So I can see your point, if the idea is that filtering would be occuring at JSON level, and not at POJO level. It comes down to which ordering of processing is assumed: does unwrapping occur first, before considering filtering, or after; and that determines which behavior is considered correct.

Show
Tatu Saloranta added a comment - I have to think about whether this is considered a bug or feature. @JsonUnwrapped is all around nasty feature to support, leading to many potential issues with combinations... So I can see your point, if the idea is that filtering would be occuring at JSON level, and not at POJO level. It comes down to which ordering of processing is assumed: does unwrapping occur first, before considering filtering, or after; and that determines which behavior is considered correct.
Hide
Permalink
Fabien added a comment -

Sure,

Maybe we can have best of both world. I mean (for example) having a new method :
SimpleBeanPropertyFilter.filterOutAllExcept(Set<String> properties, boolean unwrapFirstAndFilter)

(the existing one could still have one parameter only and set the boolean to false in order to keep the old behaviour...)

This issue is not a big deal for us because a very easy and straightforward workaround is to redefine FilterExceptFilter

Show
Fabien added a comment - Sure, Maybe we can have best of both world. I mean (for example) having a new method : SimpleBeanPropertyFilter.filterOutAllExcept(Set<String> properties, boolean unwrapFirstAndFilter) (the existing one could still have one parameter only and set the boolean to false in order to keep the old behaviour...) This issue is not a big deal for us because a very easy and straightforward workaround is to redefine FilterExceptFilter
Hide
Permalink
Tatu Saloranta added a comment -

It would be good to address this; my main concern is just that ideally there should not be hard-coded casting between the two. However, I think JsonSerializer might have an accessor to indicate whether it is "unwrapping" serializer; if so, filter could definitely use that call (since no casting and direct coupling would be introduced).

Thanks for suggestion!

Show
Tatu Saloranta added a comment - It would be good to address this; my main concern is just that ideally there should not be hard-coded casting between the two. However, I think JsonSerializer might have an accessor to indicate whether it is "unwrapping" serializer; if so, filter could definitely use that call (since no casting and direct coupling would be introduced). Thanks for suggestion!

People

  • Assignee:
    Tatu Saloranta
    Reporter:
    Fabien
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: