uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Design choices for changing type systems with loaded JCas classes [was Re: UIMAv3 & WebAnno}
Date Fri, 05 Jan 2018 16:16:43 GMT
Based on Web Annot's use case, I'm thinking thorough alternatives.

The issue is a sequence related one, with type systems changing:

1) a type system is created, defining type T, with no features
2) a CAS is produced with that type system, causing JCas classes to be looked-up
and loaded

At that time, the JCas class is set up with feature offset constants,
corresponding to how the features are laid out in the type system.
Type T has 0 features, but the JCas type for T might define some.  This is
allowed, but the feature offsets in the JCas class are set to -1, which will
cause a runtime exception if the feature is used (e.g., someone does
myJCasType.getMyFeature() call).

So far - all OK (provided the non-existent features are not accessed, of course).

3) a different type system is created, defining type T with feature f1
4) a CAS is produced with that type system.

Currently this throws an error when the JCas classes are checked for conformance
with the type system. 

A mechanism in the JCas already allows the JCas classes to be "updated" for
feature changes.
However, once the JCas class is loaded with a valid type system, no updating is
allowed (for reasons see below).

The consequence of this is that a user wanting to use one set of JCas classes
with multiple different type systems must use the maximal-feature version of the
type systems (which could be created using a type system merge operation, for
example), as the *first* type system that causes the JCas classes to be loaded.

We could modify the JCas setup to allow updating an already loaded/initialized
JCas class for a new type system with different features present. But it seems
that this has some difficulties; it would only be a valid transformation if no
instances of the JCas class exist.  There's currently no way to tell if this is
true.  In the general case, the JCas classes could be being used for multiple
independent pipelines, running in multiple threads; so even if one CAS was
"reset", others might not be; and furthermore, POJO code could be holding on to
some JCas instances.

One way to support this would be to have the user code tell the UIMA framework
that no reachable instances of JCas classes exist; the user would be responsible
for guaranteeing this.

The other choice would be to not support this (because of the inherent dangers)
and instead require users having multiple type systems with JCas classes
specifying features only in some versions of those type systems, first load the
JCas classes with the feature-maximal versions of the types.

I think I favor the 2nd approach, as it is much safer. 

What do others think we should do?


View raw message