Class with @JsonTypeInfo cannot be @JsonUnwrapped

[pschanely]

... in version 2.0.6. It yields an internal error "Can not start object, expecting field name".

package scratch;

import static org.junit.Assert.*;

import org.junit.Test;

import com.fasterxml.jackson.annotation.JsonTypeInfo;
import com.fasterxml.jackson.annotation.JsonTypeInfo.As;
import com.fasterxml.jackson.annotation.JsonTypeInfo.Id;
import com.fasterxml.jackson.annotation.JsonUnwrapped;
import com.fasterxml.jackson.databind.ObjectMapper;

public class ScratchTest {

  @JsonTypeInfo(use=Id.CLASS, include=As.PROPERTY, property="_obj_cls")
  public class SubObject {}

  public class MainObject {
    @JsonUnwrapped
    public SubObject subObject;
  }

  @Test
  public void test() throws Exception {
    MainObject item = new MainObject();
    item.subObject = new SubObject();
    ObjectMapper mapper = new ObjectMapper();
    String encoded = mapper.writer().writeValueAsString(item);
  }

}

com.fasterxml.jackson.core.JsonGenerationException: Can not start an object, expecting field name
    at com.fasterxml.jackson.core.base.GeneratorBase._reportError(GeneratorBase.java:412)
    at com.fasterxml.jackson.core.json.WriterBasedJsonGenerator._verifyValueWrite(WriterBasedJsonGenerator.java:824)
    at com.fasterxml.jackson.core.json.WriterBasedJsonGenerator.writeStartObject(WriterBasedJsonGenerator.java:261)
    at com.fasterxml.jackson.databind.jsontype.impl.AsPropertyTypeSerializer.writeTypePrefixForObject(AsPropertyTypeSerializer.java:48)
    at com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeWithType(BeanSerializerBase.java:437)
    at com.fasterxml.jackson.databind.ser.impl.UnwrappingBeanPropertyWriter.serializeAsField(UnwrappingBeanPropertyWriter.java:102)
    at com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:525)
    at com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:143)
    at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider.serializeValue(DefaultSerializerProvider.java:108)
    at com.fasterxml.jackson.databind.ObjectWriter._configAndWriteValue(ObjectWriter.java:570)
    at com.fasterxml.jackson.databind.ObjectWriter.writeValueAsString(ObjectWriter.java:494)
    at scratch.ScratchTest.test(ScratchTest.java:26)

Appears to me it's because UnwrappingBeanSerializer is not overriding serializeWithType(). The fix doesn't look simple, though, as the TypeSerializer interface seems to assume an embedded object.

[cowtowncoder]

Yes, this would be tricky to support properly, and requires both serialization and deserialization to work around the complications. There is a chance that this combination can not be supported; but if so, it could either throw a more descriptive exception, or just ignore unwrapping handling. Both approaches have their downsides.

Not sure what Afterburner does, although I would guess that it might just disable unwrapping handling altogether?

[pschanely]

Yeah, I was incorrect before; afterburner is simply ignoring the @JsonUnwrapped annotation. I would have assumed that an error would be the most appropriate response, personally.

[cowtowncoder]

Afterburner code is bit fragile since it relies on inheritance, and as unwrapped struct handling is newer than AB, it has not been updated to try to figure out unwrapping aspects if any. But it would probably make sense for AB to avoid optimizing Bean(De)Serializers that do unwrapping and leave it to default handling.
I'll add an RFE for afterburner project.

[aleksz]

What is the recommended workaround?

[UnquietCode]

I have managed to patch this locally by simply skipping the writing of type id information for properties being unwrapped. Hopefully this is a valid solution? It prevents the error from happening but obviously we still lose the type information. I think that's an ok start, as it at least enables the classes to be used in a top level and unwrapped scenario without error.

[cowtowncoder]

I added notes on #455; basically I am bit worried about default behavior of skipping writing of type info. But I agree in that failing when trying to write is also not much of a solution... so perhaps a SerializationFeature would be a reasonable starting point.

[UnquietCode]

@cowtowncoder Would the feature basically give Jackson permission to omit type information for these cases?

[cowtowncoder]

@UnquietCode Right, it would do that. So just guard this feature to be used only when explicitly enabled -- I am still worried about side effects, or this hiding some other problems. It is easier to explain alternative processing when it is explicitly enabled.

[UnquietCode]

Sounds good to me. I added some stubs to #455 for such a feature. Probably some cleanup or renaming is required. I wasn't able to get the full JSON path information into the exception message.

[cowtowncoder]

Merged #455, so this is sort of supported now.