uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: Design choices for changing type systems with loaded JCas classes [was Re: UIMAv3 & WebAnno}
Date Fri, 05 Jan 2018 23:10:42 GMT
I perhaps overstated the problem.

Here's the specifics:  if the maximal-type system for type T has features f1,
f2, f3, f4, f5, and the JCas class defines all these features, then the load of
that JCas class will bind those.

A subsequent switch to a type system with f1, f2, will work.

But a subsequent switch to a type system with f1, f3 won't work (because the
offset for f3 is set to, say "3", and the length of the feature slots allocated
is only 2.

To work around these, the application needs to use class loader isolation to
force reloading of the JCas classes.
(Or, as mentioned earlier, we could have an API to recalculate the offsets, but
that could really break things if instances of that JCas class exist (perhaps
running in other threads) expecting the other definitions.

So I think any client code doing type system switching, and using JCas classes
where the features are changing, needs to be aware and handle this (currently).

A fix along the lines suggested where the JCas classes augment the type system,
could help, but it would still be exposed to edge cases like this:

TypeSystem 1 defines type T with f1; JCas augments this with f100.

Later a typesystem is loaded which defines types f1, f2, and f100 (in that
order). The JCas for T has bound f100 to (say) slot #2, which is where this type
system has stuck "f2" - so it has the wrong binding for f100.


On 1/5/2018 4:25 PM, Richard Eckart de Castilho wrote:
> On 05.01.2018, at 21:29, Marshall Schor <msa@schor.com> wrote:
>> So, the only work-around I see at the moment is to use class loader isolation,
>> reloading the JCas classes each time.
> Is this something that client code would have to be aware of / to trigger?
> Cheers,
> -- Richard

View raw message