[
https://issues.apache.org/jira/browse/SOLR-4021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18132056#comment-18132056
]
Nick Shanin commented on SOLR-4021:
-----------------------------------
>From code reading against apache/main b73f03976fa, JavaBinCodec falls back to
>the reflect writer for unknown classes
>(solr/solrj/src/java/org/apache/solr/common/util/JavaBinCodec.java:280), and
>Utils returns the class name plus ':' and the value for classes with no
>annotated fields
>(solr/solrj/src/java/org/apache/solr/common/util/Utils.java:795). So a
>BigDecimal round-trips as the string "java.math.BigDecimal:1848.66". Is this
>still an issue? If so, the fix is a writer for BigDecimal or a clear error.
🤖 AI-generated 🤖
> JavaBinCodec has poor default behavior for unrecognized classes of objects
> --------------------------------------------------------------------------
>
> Key: SOLR-4021
> URL: https://issues.apache.org/jira/browse/SOLR-4021
> Project: Solr
> Issue Type: Bug
> Components: clients - java
> Affects Versions: 4.0
> Reporter: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-4021.patch
>
>
> It seems that JavaBinCodec has inconsistent serialize/deserialize behavior
> when dealing with objects of classes that it doesn't recognized. In
> particular, unrecnognized objects seem to be serialized with the full
> classname prepented to the "toString()" value, and then that resulting
> concatentated string is left as is during deserialization.
> as a concrete example: serializing & deserializing a BigDecimal value results
> in a final value like "java.math.BigDecimal:1848.66" even though for most
> users the simple toString() value would have worked as intended.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
