[
https://issues.apache.org/jira/browse/THRIFT-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12864686#action_12864686
]
david herviou commented on THRIFT-772:
--------------------------------------
Indeed, putting fields 'optional' will does the trick. But actually the thing
that make me a little bit embarass is the non identity of
unserialize(serialize(object)) behavior for the bit set.
If this is something assumed and not to be used this way, that's ok.
Do you want this issue status to be changed ? or is this something you want to
keep an eye on ?
> __isset_bit_vector state before serialization differs from state after
> unserialization on native field
> ------------------------------------------------------------------------------------------------------
>
> Key: THRIFT-772
> URL: https://issues.apache.org/jira/browse/THRIFT-772
> Project: Thrift
> Issue Type: Bug
> Components: Library (Java)
> Affects Versions: 0.2
> Environment: Linux, thrift release 0.2.0 with patch Thrift-746 and
> Thrift-663
> Reporter: david herviou
> Attachments: thrift-issue-bitset-nativefields.tgz
>
>
> Once java classes have been generated it is possible to test if the fields
> have been set or not using the method isSetXXX().
> Once one of this java class is instanciated, all call to field.isSetXXX() are
> returning false which is a good thing (this method ask for
> __isset_bit_vector.get(XXX))
> Now if you serialize the previous object and unserialize it (without doing
> any changes on it) the following occured : all fields that corresponds to
> native data are returning true when isSetXXX() is invoked.
> Consequently, the operation unserialise(serialize(object)) is not an identity
> function.
> This is mainly due that the __isset_bit_vector is not serialize and rebuild
> during the unserialize operation.
> Any idea how to fix this ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
