[eclipse-collection] can not deserialize concrete class instance inside nested immutable eclipse-collection #71
Comments
|
Looks like example uses Lombok: this is fine in itself, but I think we'd need a post-processed version for testing to see actual methods and annotations in used. Plus tests are not allowed to include Lombok as dependency for practical reasons (no byte- or source-processing extensions allowed) |
I just tried without Lombok and manually coded all getters and constructors by myself. The issue still happens. I can provide a sample source code here @JsonProperty
ImmutableMap<String, ImmutableList<AbstractItem>> keyToItemsList;then the @JsonTypeInfo(use = JsonTypeInfo.Id.NAME, property = "_type")
@JsonSubTypes({
@JsonSubTypes.Type(value = ConcreteItem.class, name = "type 1")
})
public abstract class AbstractItem{
@JsonProperty
private String name;
public AbstractItem(String name) {
this.name= name;
}
protected AbstractItem() {
//for jackson
}
public String getName() {
return this.name;
}
}and the public class ConcreteItem extends AbstractItem{
@JsonProperty
private ImmutableMap<String, String> options;
@JsonProperty
private String path;
public ConcreteItem (String name, ImmutableMap<String, String> options, String path) {
super(name);
this.options = options;
this.path = path;
}
protected ConcreteItem () {
super();
//for jackson
}
}Also, I figured that this issue might happen to all immutable collections. So if I use |
CXwudi
changed the title
|
The issue here is ImmutableList/Map. It works fine with MutableList, because that implements java.util.List. This came up in the initial PR: #30
The issue is that with ImmutableList, we get a call to findBeanDeserializer instead of findCollectionDeserializer or findCollectionLikeDeserializer. In the original PR, this is the core issue that wasn't solved. It's been a while but IIRC the choice of which method is called is done in jackson-databind, so I'm not sure there's a great solution here. |
|
If the problem is that of how to detect But as there are no default deserializers for collection-/map-like types (they are just convenience types that allow better introspection of various things to help simplify (de)serializer implementations), there is probably need for serializer/deserializer implementations too? I am probably forgetting earlier discussions with @yawkat so apologies for lacking necessary context here. |
|
@cowtowncoder A type modifier is enough to fix this apparently! Is that the "proper" solution? The EclipseCollectionsDeserializers already returns the right deserializers if they're passed as collection-like. Also, what branch is the one to PR to, 2.12? |
|
Yes, TypeModifier was designed to allow modules to indicate 3rd party types to behave more like "standard" Map, Collection and Reference (Option[al], AtomicReference) types, and help use some of existing support. It does not have to be used ( As to branch you can choose 2.10, 2.11 or 2.12 -- I can merge forward from any of those. I would probably suggest 2.11. |
… nested list handling [Fixes FasterXML#71]
Hi, the issue is like the following:
I have a field like
where
AbstractDownloaderConfigerationis declared as:and the
MetaYoutubeDlConfigurationclass is:As you can see I have already properly set up the
@JsonTypeInfoand@JsonSubTypeson the abstract class,but I still got:
However, if I change the type of
keyToItemsListfromImmutableMap<String, ImmutableList<AbstractDownloaderConfigeration>>toImmutableMap<String, List<AbstractDownloaderConfigeration>>(using java.util.List inside the eclipse collection map), everything works fine, even though I have used Lombok in my codeI think this is a bug in this Jackson module. So I reported here
The text was updated successfully, but these errors were encountered: