Hi, I think that the answer depends on the meaning of the question :-)
It *is* supported if the question is: - step 1, 2, 3, 4 + then starting up a new pipe line in a new class loader. It is *not* supported, (even in v2) if the question is: - step 1, 2, 3, 4 where the JCas classes were loaded with the first type system description, and then, in the same class loader, another type system with the 2nd order is used to create another CAS. ==================== I thought of another use case which also breaks the assumption I was trying to exploit in the "fix" where feature offsets get initialized to the next sequential slot(s). Suppose Type T is defined with slots f1, f2, at first, but a later type system has f1, f2, f3, and f4. Suppose Type Ts is a subtype of Type T, with slots s1, s2. Now if type T (f1, f2) is loaded, and the JCas has f1, f2, f3, and f4, slot f3 and f4 are assigned to the (maybe non-existent except for subtype's existence) next 2 sequential slots. But if that type system includes Ts, then s1 slot will overlay f3, and s2 overlays f4. So a further restriction to make this work is that the Types with extra JCas slots can't have subtypes... This use case affects the work-around proposed earlier, where you arrange the maximal feature type system definition to be loaded first, and the JCas is loaded against that. If subsequently different type systems are loaded with both fewer features for T and subtypes Ts, that same "overlap" problem happens. =================== So, I think that with a lot of restrictions, some form of this can be made to work, but I certainly agree that it's fragile. =================== I'm wondering how hard it would be to have the different type systems run with different JCas class loaders. This probably could be done by only specifying new class loaders for the "UIMA Extension Class Loaders", which are used to load the JCas classes and the annotators. I agree this could be an issue if you need to pass same-named but differently-defined JCas classes among these different type systems. If this is the case, I'd be curious about the semantics - I would guess that only the "common" part of the JCas class (common to all different type systems) would be being accessed. If that's true, I'm wondering if a better approach (but certainly more work) is to refactor so that this common part is a different common (unchanging) type? -Marshall On 1/7/2018 2:22 PM, Richard Eckart de Castilho wrote: > On 07.01.2018, at 06:06, Marshall Schor <m...@schor.com> wrote: >> This only works when the different type definitions for type T keep the >> slots in >> the same order, with no omissions. >> (The JCas initialization for a new type system checks this.) For example, >> valid >> definions for type T would be >> T with features (none) >> T with features f1 >> T with features f1, f2 >> T with features f1, f2, f3 >> T with features f1, f2, f3, f4 >> T with features f1, f2, f3, f4, f5 ... >> >> You could not have T with features f2, f3 (skipping f1). And the feature >> definitions would need to be in this exact order (it would not work for T >> with >> features f2, f1). >> >> Does this cover the case(s) in WebAnno? > It might. But it still looks like a rather fragile construction that > might better be avoided. What does the order of the features depend on? > Alphanumeric sorting? Order in the JCas class / TSD XML? > > Let's say I do this: > > - define a TSD in XML with features in the order f1, f2, f3 > - generate JCas classes from that XML > - refactor the XML for some reason, reordering the features into f3, f2, f1 > - *not* regenerate the JCas classes (since actually the information content > didn't change and the order of fields in Java classes normally don't matter > anyway) > > Is such a thing supported in v3? Was it supported in v2? > > Cheers, > > -- Richard > > >
