There may be other use cases to think through; I'm going to think about how this works (or doesn't): - a remote service, written in v3 is sent a CAS - it modifies the CAS (above, and below the line, including removing FSs - it sends back a delta CAS This is supposed to be supported for XCAS, Xmi, Binary (compressed or not).
This might already work fine. There are test cases for (some of) these, I think. -Marshall On 12/4/2017 10:35 AM, Marshall Schor (JIRA) wrote: > Marshall Schor created UIMA-5662: > ------------------------------------ > > Summary: uv3 support CAS deserialization subsequent low level > access > Key: UIMA-5662 > URL: https://issues.apache.org/jira/browse/UIMA-5662 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework > Affects Versions: 3.0.0SDK-beta > Reporter: Marshall Schor > Assignee: Marshall Schor > Priority: Minor > Fix For: 3.0.0SDK > > > Some users depend 1) constant v2-ids for FSs preserved in deserialization and > serialization, and 2) low level cas API access to these. > > V3 normally doesn't maintain tables linking ids to FSs, as these (unless weak > refs are used) prevent GC of unreachable FSs. > > Based on a mode, set by -Duima.deserialize_perserve_v2_ids, and also > controllable by new config option per deserialize call, alter the > deserialization for those deserializers which know about v2 ids, to put these > into the map used for low-level CAS access, using the actual v2 ids, and > change the v3 next available id for future new FSs to be 1 beyond the end. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.14#64029) >
