[
https://issues.apache.org/jira/browse/JOHNZON-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16376830#comment-16376830
]
Steven Walters commented on JOHNZON-152:
----------------------------------------
Sorry, this has been flagged as tech debt on the project, and will likely not
be revisited for some time, due to other higher priority tasks.
As it was already declared as a "won't fix" here, it seems like it should just
be closed, as there's not quite a timeline for coming back to this currently.
> Ability to serialize field of a type from value introspection instead of
> field introspection
> --------------------------------------------------------------------------------------------
>
> Key: JOHNZON-152
> URL: https://issues.apache.org/jira/browse/JOHNZON-152
> Project: Johnzon
> Issue Type: Wish
> Components: Mapper
> Affects Versions: 1.1.5
> Reporter: Steven Walters
> Priority: Minor
>
> In our project, we have a few types that have an Object field that is used to
> accept a few different types of objects.
> * Sometimes the field is an effective primitives (Float, Integer, Long, etc)
> * Sometimes they're Collections (List, Set)
> * Sometimes they're other custom defined objects
> Right now johnzon mapper determines the type of the field based on its
> defined type "Object" which means just about nothing. This almost always
> causes serialization issues (with default behavior) unless its null.
> We would like to have an annotation (such as @JohnzonDynamic) to indicate the
> field is dynamic and its type should be determined via introspection of the
> value, rather than the field's declared type. Similar to how a map's value is
> done.
> For simplicity, this could be considered a read-only field to avoid the
> complexity of trying to set this field to whatever data comes in during
> deserialization.
> Right now we're working around this via a custom ObjectWriter that converts
> the object to a map and then passes the map to serialization, which has some
> inconveniences of maintenance.
> Maybe other projects could see some use of this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
