[ 
https://issues.apache.org/jira/browse/UIMA-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16293030#comment-16293030
 ] 

Richard Eckart de Castilho commented on UIMA-5662:
--------------------------------------------------

Well, I suppose it depends on how the ThreadLocal is implemented. Let's see.

Having a completely CAS-unrelated (say) "FSManagement" class seems not very 
attractive because it's existence would not be particularly obvious. E.g.

{noformat}
FSManagement.enableFsMapping();
try {
  deserialize(inputStream, CAS);
}
finally {
  FSManagement.disableFsMapping();
}
{noformat} 

But it seems reasonably if the idea would be to expose this API directly on the 
CAS:

{noformat}
try {
  cas.enableFsMapping();
  deserialize(inputStream, cas);
}
finally {
  cas.disableFsMapping();
}
{noformat}

or even

{noformat}
try (cas.withFsMapping()) {
  deserialize(inputStream, cas);
}
{noformat}

Mind that there is no reason why client code would always turn off the mapping. 
Actually, in my use-case, I'd enable it and keep it enabled.

> 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_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.
> The -Duima.deserialize-preserve_ids global setting is needed to handle the 
> use case of some annotators using low-level APIs, when part of a pipeline is 
> "remoted". 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to