R
Size: a a a
2021 February 01
BK
по url в requestmapping выдает json
D
Bohdan Korinnyi
ок, спасибо
VS
кто то сталкивался с проблемой у jackson 2++, при десериализации json в Pojo не могу затащить филд с json c именем type
{"type": "DB"}V
кто то сталкивался с проблемой у jackson 2++, при десериализации json в Pojo не могу затащить филд с json c именем type
{"type": "DB"}как дескриминатор нормально отдается
VS
как дескриминатор нормально отдается
чттттто
V
чттттто
у меня абстрактное DTO с аннтоцией @
JsonTypeInfo, тип как раз в филде «type» передается нормальноVS
у меня абстрактное DTO с аннтоцией @
JsonTypeInfo, тип как раз в филде «type» передается нормальнохм у меня такая дичь
@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, property = "type") // тут тип резолвит норм
class Pojo {
String type; // а уже тут null
}
VS
его не надо в теле обьявлять
а если мне надо ? есть какой то способ вкинуть туда тип, дело в том что внутри идет еще один
@JsonTypeInfo() который завязан на этот же тип
@JsonTypeInfo() который завязан на этот же тип
VP
хм у меня такая дичь
@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, property = "type") // тут тип резолвит норм
class Pojo {
String type; // а уже тут null
}
Логичнее объявить в таком классе абстрактный метод
А так это поле висит в воздухе, и туда можно запихать что угодно, не связанное с типом наследника.
getType(), и пусть наследники переопределяют.А так это поле висит в воздухе, и туда можно запихать что угодно, не связанное с типом наследника.
V
а если мне надо ? есть какой то способ вкинуть туда тип, дело в том что внутри идет еще один
@JsonTypeInfo() который завязан на этот же тип
@JsonTypeInfo() который завязан на этот же тип
чето какой-то изящный пусть выстрела себе в ногу
V
а если мне надо ? есть какой то способ вкинуть туда тип, дело в том что внутри идет еще один
@JsonTypeInfo() который завязан на этот же тип
@JsonTypeInfo() который завязан на этот же тип
получается определение типов и бизнес филд завязаны на одно поле? зачем?
VS
получается определение типов и бизнес филд завязаны на одно поле? зачем?
друг мой, не спрашивай почему.... такую дичь ловим и вот пришлось с этим хоботиться (((
VS
Логичнее объявить в таком классе абстрактный метод
А так это поле висит в воздухе, и туда можно запихать что угодно, не связанное с типом наследника.
getType(), и пусть наследники переопределяют.А так это поле висит в воздухе, и туда можно запихать что угодно, не связанное с типом наследника.
я согласен, но в текущем классе если вложен еще один класс у которого @JsonTypeInfo() завязан на этот же тип 🙈🙊
VS
Логичнее объявить в таком классе абстрактный метод
А так это поле висит в воздухе, и туда можно запихать что угодно, не связанное с типом наследника.
getType(), и пусть наследники переопределяют.А так это поле висит в воздухе, и туда можно запихать что угодно, не связанное с типом наследника.
то есть мне нужно парсить/иметь к нему доступ еще в родителе
VP
я согласен, но в текущем классе если вложен еще один класс у которого @JsonTypeInfo() завязан на этот же тип 🙈🙊
Не очень понял. То есть при десериализации может получиться экземпляр этого самого класса, он не абстрактный?
Э
ну а зачем в приницпе дали такую возможность в языке?)
В функциональных интерфейсах удобно. Например, compose, identity