[
https://issues.apache.org/jira/browse/UIMA-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor reopened UIMA-5698:
----------------------------------
Redesign this, so the added features are not actually in the type system, and
are just used for computing offsets in the JCas classes. Otherwise, things
that depend on the type system (like binary serialization forms) start to fail.
> uv3 create type systems with JCas features merged in
> ----------------------------------------------------
>
> Key: UIMA-5698
> URL: https://issues.apache.org/jira/browse/UIMA-5698
> 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 use cases involve setting up (over time) multiple CASs with similar but
> not identical type systems, differing in the number of features the types
> have. The use case for this also has JCas class definitions defining
> features. The following currently fails:
> # load type T with no features, load JCas for T with features f1, f2, f3.
> This works correctly.
> # Now load type T with features f1, f2, f3, using the same classloader that
> loaded the JCas for T previously. This fails because the offsets for f1, f2,
> f3 in the JCas were computed previously, and cannot be changed (because
> existing instances of the JCas class for T would stop working).
> Implement a fix for this that works by having the initial setup of the JCas
> feature offsets be preceeded by a step which, prior to committing the type
> system, loads the JCas classes and programmatically adds in to the type
> system any features defined in the JCas but not in the Type system.
> Include logging messages showing what's happening.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
