Hi Richard, Here's one idea: Since I thought this had been fixed a while ago, and you seemed (previously) to get beyond this point, I'm wondering if the build you did for "trunk" somehow got mixed up levels. I see the build is from 3.0.1-beta-SNAPSHOT v3 branch - but I'm guessing that's some local folder you have ( didn't see it in https://svn.apache.org/repos/asf/uima/uv3/uimaj-v3/branches)?
Also, the technique for garbage collecting by using compressed serialization needs a fixup - if you have set the global mode to the v2Refs, then the serializations include the non-reachables. You can easily work around this by surrounding the serialize code with a try-with-resources to turn-off the v2 mode. I'm going to try to set up a test case to see if I can reproduce this. What I'm planning to do is to have two type systems, T1, and T2, where T1 has a type with no features, and T2 has the same type with a feature. I'll make a JCas class which has the type defined with the feature. Then I'll create a CAS with T1, and confirm the JCas class loads and has the feature offset for the feature set to -1 (to cause a runtime exception if referenced). Then I'll create a CAS with T2. If this test case matches what's happening for you, that should trigger the exception you see. If I've misunderstood what's going on and you think this is not the right test, please let me know :-). -Marshall On 1/3/2018 6:16 PM, Richard Eckart de Castilho wrote: > Hi again, > > I have once again switched my local environment to a UIMA v3 mode: > > - UIMA SDK v3 (3.0.1-beta-SNAPSHOT v3 branch) > - uimaFIT (3.0.0-SNAPSHOT v3 branch) > - DKPro Core (2.0.x branch) > - WebAnno (feature/issue1115-uimav3 branch) > > Last time, I ran into trouble because the IDs loaded from serialized CAS > files were no longer accessible. > I programmatically set "uima.default_v2_id_references" to "true" during > startup now to avoid that. > > > But what seems to be happening even before getting there is that I run again > in JCas <-> Type System problems. > When a user opens a document for annotation in WebAnno, WebAnno loads the > serialized CAS (CasCompleteSerializer), > serializes the CAS into a byte array (compressed form 6), creates a new CAS > with the current type system definition, > and deserializes the data again into that CAS. The idea is that the lenient > loading of the compressed form 6 allows > > a) new types / features to be added in that way > b) unreachable FSes to be garbage collected > > So, it is not an uncommon case here that the data stored with the > CasCompleteSerializer used a different type system than the CAs into which it > is loaded - and in fact it can be the case that the data stored with the > CasCompleteSerializer had used different JCas wrappers at the time then what > is available at the time of loading > the data again. Afaik in there should be no truely incompatible changes in > the type system though - i.e. only new features / types were added; no > features were removed. Still, I get a lot of this type of error: > >> org.apache.uima.cas.CASRuntimeException: The JCas cannot be initialized. >> The following errors occurred: >> In JCAS class >> "de.tudarmstadt.ukp.dkpro.core.api.lexmorph.type.morph.MorphologicalFeatures", >> UIMA field >> "de.tudarmstadt.ukp.dkpro.core.api.lexmorph.type.morph.MorphologicalFeatures:verbForm" >> was set up when this class was previously loaded and initialized, to have >> an adjusted offset of "-1" but now the feature has a different adjusted >> offset of "5"; this may be due to something else other than type system >> commit actions loading and initializing the JCas class, or to having a >> different non-compatible type system for this class, trying to use a common >> JCas cover class, which is not supported. >> <snip> >> at >> org.apache.uima.cas.impl.FSClassRegistry.reportErrors(FSClassRegistry.java:870) >> ~[classes/:?] >> at >> org.apache.uima.cas.impl.FSClassRegistry.loadJCasForTSandClassLoader(FSClassRegistry.java:342) >> ~[classes/:?] >> at >> org.apache.uima.cas.impl.FSClassRegistry.getGeneratorsForClassLoader(FSClassRegistry.java:904) >> ~[classes/:?] >> at >> org.apache.uima.cas.impl.TypeSystemImpl.getGeneratorsForClassLoader(TypeSystemImpl.java:2651) >> ~[classes/:?] >> at >> org.apache.uima.cas.impl.TypeSystemImpl.commit(TypeSystemImpl.java:1393) >> ~[classes/:?] >> at org.apache.uima.cas.impl.CASImpl.commitTypeSystem(CASImpl.java:1607) >> ~[classes/:?] >> at >> org.apache.uima.util.CasCreationUtils.doCreateCas(CasCreationUtils.java:614) >> ~[classes/:?] >> at >> org.apache.uima.util.CasCreationUtils.createCas(CasCreationUtils.java:362) >> ~[classes/:?] >> at >> org.apache.uima.util.CasCreationUtils.createCas(CasCreationUtils.java:313) >> ~[classes/:?] >> at >> org.apache.uima.fit.factory.JCasFactory.createJCas(JCasFactory.java:147) >> ~[classes/:?] >> at >> de.tudarmstadt.ukp.clarin.webanno.api.dao.AnnotationSchemaServiceImpl.upgradeCas(AnnotationSchemaServiceImpl.java:640) >> ~[classes/:?] > I have the feeling that this is what happens: > > 1) a CasCompleteSerialized-CAS is loaded - it was created at a time when the > MorphologicalFeatures did not yet have a feature called "verbForm". > 2) I create a new JCas, now using a type system description where > MorphologicalFeatures includes the "verbForm" feature > > At step 2, the above error seems to be triggered. I actually do not even get > to the point where I would temporarily serialize into form 6 and back. The > code already crashes when trying to set up the target task with the updated > type system. > > Any ideas? > > Cheers, > > -- Richard
