[
https://issues.apache.org/jira/browse/SOLR-4021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14606430#comment-14606430
]
Peter Davis commented on SOLR-4021:
-----------------------------------
Using HttpSolrServer, the default settings work and object's toString() .
Using CloudSolrServer, suddenly custom objects we were passing as values are
serialized as "<classname>:<value>" -- a default that makes no sense and causes
silent corruption!
So this is really an insidious issue due to the different behavior of
HttpSolrServer and CloudSolrServer! Forgetting to call toString() on our
custom objects and BigDecimals leads to silent corruption with CloudSolrServer!
> 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: Hoss Man
>
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]