Add test case for using JsonUnwrapped on fields of the same class

[kariem]

See FasterXML/jackson#278 for context

I would like to include a bean into a class multiple times. For serialization, this bean should prefix its fields in a specific way so that I can reuse this bean in other classes too.

This is the JSON representation I want to use

{
  "name": "name",  // name.value
  "name_l10n": {   // name.value_l10n
    "de": "name",
    "fr": "nom"
  },
  "description": "description",  // description.value
  "description_l10n": {          // description.value_l10n
    "de": "Beschreibung",
    "fr": "description"
  }
}

The pairs name and name_l10n should be from the same bean instance. The java representation should be simple and reusable

public class MyFancyClass {
	@JsonUnwrapped
	private LocalizedField name;        // → name.value and name.value_l10n
	@JsonUnwrapped
	private LocalizedField description; // → description.value and description.value_l10n

    // ... getters and setters
}

I have provided some test cases to demonstrate the problems I have encountered so far.

1. Without custom serialization configuration, the mapper creates invalid JSON. See testUnwrappingWithDifferentProperties
2. Serialization works find, see testUnwrappingWithCustomSerializer
3. Deserialization does not work, see testUnwrappingWithCustomDeserializer

[JooHyukKim]

Some thoughts...

1. @JsonUnwrapped can be configured with prefix/suffix if that helps.
2. Since you made custom serializer work as you wanted, how about spend some more time making custom deserializer to work?

Without custom serialization configuration, the mapper creates invalid JSON. See testUnwrappingWithDifferentProperties

Because that's how it's configured? Current result is what I would expect from plain configuration of @JsonUnwrapped.

[cowtowncoder]

Bad idea for tests -- should almost never be used: often masks legitimate problems (in production use useful for defensive handling).

[kariem]

Yes, I agree. Removing this, however, will throw a UnrecognizedPropertyException

Unrecognized field "prop1_l10n"

The idea was to see what the configuration was actually doing.

[cowtowncoder]

Right, so it did hide a failure.

[cowtowncoder]

I guess ideally it'd fail with exception? Since definition would instruct output like this.

[cowtowncoder]

What puzzles me is the use of @JsonUnwrapped: if you have custom (de)serializers, there's often no point in using that annotation: custom (de)serializer will replace that handling.
There are ways for custom (de)serializers to support annotation; for JsonSerializer there is

    public JsonSerializer<T> unwrappingSerializer(NameTransformer unwrapper) {
        return this;
    }

that gets called if annotation indicates need; similarly for JsonDeserializer:

    public JsonDeserializer<T> unwrappingDeserializer(NameTransformer unwrapper) {
        return this;
    }

but as I said, these are rarely needed.

So I would just remove @JsonUnwrapped altogether if custom serializer-and-deserializer is needed.

[kariem]

@JooHyukKim thank you for your quick responses

1. @JsonUnwrapped can be configured with prefix/suffix if that helps.

Yes, I had thought this too. But that does not result in what I would like to see

public class MyFancyClass {
	@JsonUnwrapped(prefix = "name_")
	private LocalizedField name;
	@JsonUnwrapped(prefix = "description_")
	private LocalizedField description;
    // ...
}

Will create

{
  "name_value": "name",  // name.value
  "name_value_l10n": {   // name.value_l10n
    "de": "name",
    "fr": "nom"
  },
  "description_value": "description",  // description.value
  "description_value_l10n": {          // description.value_l10n
    "de": "Beschreibung",
    "fr": "description"
  }
}

2. Since you made custom serializer work as you wanted, how about spend some more time making custom deserializer to work?

That's actually my question. If I had the full JSON node, I could select the properties I want to parse. But this is not the case. Is there a way to get the parent node in a JsonUnwrapped property for custom deserialization?

Without custom serialization configuration, the mapper creates invalid JSON. See testUnwrappingWithDifferentProperties

Because that's how it's configured? Current result is what I would expect from plain configuration of @JsonUnwrapped.

I did not expect this. Just wanted to mention it. Wouldn't it be correct to throw a JsonGenerationException?

[cowtowncoder]

Actually, as per my note on the issue (FasterXML/jackson#278), you might be able to change things overriding method findUnwrappingNameTransformer() of [Jackson]AnnotationIntrospector. I am not 100% sure if that allows flexible enough change but should be easy enough to try out. If it works, no custom (de)serializer would be needed.

[cowtowncoder]

I did not expect this. Just wanted to mention it. Wouldn't it be correct to throw a JsonGenerationException?

One of DatabindExceptions or possible JsonGenerationException, depending on which layer. But yes, ideally.
Actually, if StreamWriteFeature.STRICT_DUPLICATE_DETECTION was enabled, JsonGenerationException would be thrown, I think. It is not enabled by default as it adds overhead (similar to how parser side does not check dups by default) but can be enabled.

[JooHyukKim]

Honestly name_value name_value_l10n seem reasonable. You gotta meet half way.

Can you try both serialxiation deserialziation roundtrip with prefix configured? It might work @kariem