On 06.01.2018, at 00:10, Marshall Schor <m...@schor.com> wrote: > > 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.
Hm, I am wondering if this problem is actually already present in v2 and for some reason I just never hit it. I am not sure if/how I could sensibly use classloader isolation in WebAnno. JCases are passed around all the time and operations on them happen in many locations in the code. And not only that - FeatureStructures extracted from the JCas are also passed around a lot (although always limited to a single web request so that the FSes do not become invalid). It would be very tricky to determine when to reload JCas classes. Reloading the JCas classes every time an operation of the JCas is executed probably would introduce a serious overhead - and it would (probably) break the FeatureStructures that have already been extracted from a CAS and are being passed around. Maybe I could try isolating those places where legacy data is loaded... I suppose, the easiest and safest would to be to give up on using JCas entirely in WebAnno and use only the CAS API - which might also actually be slower than JCas in UIMAv3. I might end up manually writing wrapper classes for certain annotation types that internally use the CAS API. Best, -- Richard
