[
https://issues.apache.org/jira/browse/UIMA-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649933#action_12649933
]
Eddie Epstein commented on UIMA-1227:
-------------------------------------
Will a compatible hashcode be a problem for non-Java services?
yes, the binary version of the typesystem should be human readable strings.
All that is necessary should be:
Types: 1:uima.cas.TOP, 2:uima.cas.Integer, 3:uima.cas.Float, 4:uima.cas.String,
...
Features: 1:uima.cas.NonEmptyFSList:head, 2:uima.cas.NonEmptyFSList:tail, ...
FeatureRangeTypes: 1, 11, 3, 14, 2, 17, 4, 20, 2, 4, 4, 1, 4, ...
Other parts of the CAS definition may still be different, such as the type
hierarchy. Do we care?
> Help users debug binary CAS serialization problems
> --------------------------------------------------
>
> Key: UIMA-1227
> URL: https://issues.apache.org/jira/browse/UIMA-1227
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
> Reporter: Eddie Epstein
>
> In order to use binary CAS serialization for remote services, both client and
> service must have identical type systems. If not the same, binary
> deserialization is likely to throw exceptions. The service request handler
> should catch these exceptions when using binary deserialization and add
> message suggesting a likely cause of the problem: unequal type systems.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
