Hi, after DKPro Core can be made to on UIMA v3, I'm looking next into WebAnno. It uses serialized CASes and CAS addresses a lot, so I am very curious if/how well it works with v3.
However, I have a small problem that may or may not be related to the v3 upgrade. As part of upgrading WebAnno from v2 to v3, I am also upgrading it from DKPro Core 1.7.0 to 1.9.0-SNAPSHOT (v3 branch). We have had some changes in the type system from 1.7.0 to 1.9.0 on of which I am now hitting: The supertype of the annotation "de.tudarmstadt.ukp.dkpro.core.api.segmentation.type.Document" has changed from "uima.tcas.Annotation" in 1.7.0 to "de.tudarmstadt.ukp.dkpro.core.api.segmentation.type.Div" in 1.9.0 and it appears that the v3 CAS deserialization code is validating JCas classes against the data being read from a serialized CAS: > 2017-11-30 22:38:58 ERROR [admin] AnnotationPage - Error: The JCas class: > "de.tudarmstadt.ukp.dkpro.core.api.segmentation.type.Document" has supertype: > "de.tudarmstadt.ukp.dkpro.core.api.segmentation.type.Div" which doesn't match > the UIMA type > "de.tudarmstadt.ukp.dkpro.core.api.segmentation.type.Document"'s supertype > "uima.tcas.Annotation". > org.apache.uima.cas.CASRuntimeException: The JCas class: > "de.tudarmstadt.ukp.dkpro.core.api.segmentation.type.Document" has supertype: > "de.tudarmstadt.ukp.dkpro.core.api.segmentation.type.Div" which doesn't match > the UIMA type > "de.tudarmstadt.ukp.dkpro.core.api.segmentation.type.Document"'s supertype > "uima.tcas.Annotation". > at > org.apache.uima.cas.impl.FSClassRegistry.validateSuperClass(FSClassRegistry.java:460) > ~[uimaj-core-3.0.0-beta.jar:3.0.0-beta] > at > org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:391) > ~[uimaj-core-3.0.0-beta.jar:3.0.0-beta] > at > org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:435) > ~[uimaj-core-3.0.0-beta.jar:3.0.0-beta] > at > org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:435) > ~[uimaj-core-3.0.0-beta.jar:3.0.0-beta] > at > org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:435) > ~[uimaj-core-3.0.0-beta.jar:3.0.0-beta] > at > org.apache.uima.cas.impl.FSClassRegistry.loadJCasForTSandClassLoader(FSClassRegistry.java:334) > ~[uimaj-core-3.0.0-beta.jar:3.0.0-beta] > at > org.apache.uima.cas.impl.FSClassRegistry.getGeneratorsForClassLoader(FSClassRegistry.java:871) > ~[uimaj-core-3.0.0-beta.jar:3.0.0-beta] > at > org.apache.uima.cas.impl.TypeSystemImpl.getGeneratorsForClassLoader(TypeSystemImpl.java:2651) > ~[uimaj-core-3.0.0-beta.jar:3.0.0-beta] > at > org.apache.uima.cas.impl.TypeSystemImpl.commit(TypeSystemImpl.java:1393) > ~[uimaj-core-3.0.0-beta.jar:3.0.0-beta] > at org.apache.uima.cas.impl.CASImpl.commitTypeSystem(CASImpl.java:1532) > ~[uimaj-core-3.0.0-beta.jar:3.0.0-beta] > at > org.apache.uima.cas.impl.BinaryCasSerDes.reinit(BinaryCasSerDes.java:314) > ~[uimaj-core-3.0.0-beta.jar:3.0.0-beta] > at > org.apache.uima.cas.impl.Serialization.deserializeCASComplete(Serialization.java:129) > ~[uimaj-core-3.0.0-beta.jar:3.0.0-beta] I wonder if that is really necessary and whether it can be turned off or worked around. Is this just a consistency check or does the deserialization really produce invalid results in such a case? Normally (i.e. v2), I would expect that I should be able to deserialize any CAS data into a CAS instance no matter if there are JCas classes available and no matter what their inheritance hierarchy is. I may not be able to use the JCas classes to access this particular deserialized CAS, but via the CAS interface, it should at least be possible to access all the data. If there is no way to do a "lenient loading" directly from the serialized CAS, at least it would be good if there was a way to load the serialized data into a CAS, write that out again in another format (XMI or an other binary format supporting lenient loading) and to load it back in to the desired target type system, i.e. the one which matches the JCas classes that are on the classpath. Cheers, -- Richard
