Question: Why isn't there an option to include DefaultTyping for all classes (even final) ?

[Farid Zakaria]

I'm just curious why there's isn't the option to include DefaultTyping for all classes.

I have an Immutable class of an interface and it is sealed (i.e. final).

I've set my ObjectMapper to `mapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);`

Since the class is sealed (final) the type information is not included and on deserialize, Jackson throws an Exception since it could not find any type information.

[Tatu Saloranta]

Set of DefaultTyping options was based on use cases that seemed useful at the time.

It may be, however, that the semantics of the check are wrong: I think it should be implied that it only applies to concrete (non-abstract) types. So I think this is a bug.

Could you file a bug for this?

-+ Tatu +-

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
To post to this group, send email to jackso...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tatu Saloranta]

I'll actually filed it as https://github.com/FasterXML/jackson-databind/issues/1166.

-+ Tatu +-

[Tatu Saloranta]

One more question on this: I realized that `final` is not allowed for interface types.

But sealing refers, I think, to a property of a jar instead. Does that actually change the definition of interface to indicate it was `final`? That would seem odd.

Do you happen to have specific test case to share, or at least point to a public type that is relevant here?

-+ Tatu +-

On Wed, Mar 16, 2016 at 1:51 PM, Farid Zakaria <farid.m...@gmail.com> wrote:

--

[Farid Zakaria]

I had a class such as:

public interface ValueObject {
  String name();
  List<Integer> counts();
  Optional<String> description();
}

public final class ImmutableValueObject {

   ....

}

With my ObjectMapper set to NON_FINAL it serialized the ImmutableValueObject or ValueObject without type information.

Since my ObjectMapper is set to recognize type information, I was unable to deserialize it back.

(a simple back &forth test with the same objectmapper)

Farid Zakaria

You received this message because you are subscribed to a topic in the Google Groups "jackson-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jackson-user/NOfSs51OfSE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jackson-user...@googlegroups.com.

[Tatu Saloranta]

On Thu, Mar 17, 2016 at 12:08 AM, Farid Zakaria <farid.m...@gmail.com> wrote:

I had a class such as:

public interface ValueObject {
  String name();
  List<Integer> counts();
  Optional<String> description();
}

public final class ImmutableValueObject {

   ....

}

With my ObjectMapper set to NON_FINAL it serialized the ImmutableValueObject or ValueObject without type information.

Since my ObjectMapper is set to recognize type information, I was unable to deserialize it back.

(a simple back &forth test with the same objectmapper)

Ok, I misunderstood your problem then.

If so, you would need to define custom `TypeResolverBuilder` to implement logic you want.

DefaultTyping choices were chosen based on likely usage, and although it is possible to add new values I am not sure how many more I'd like to add.

For this specific case the problem seems to come to type discrepancy: if you are serializing type as root value, serialization sees base type as `ImmutableValueObject` but deserialization as `ValueObject`, and this causes difference in handling. This can be worked around by different type resolver, but it is a problem to overcome in general.

-+ Tatu +-