I think I found the cause: a faulty implementation of load(asInputStream, aCAS, typeSystem).
Looking at the code, the 3rd argument is not used! It looks like something happened when migrating from V2 -> V3 code base, because it's OK in the v2 code base. Maybe I can blame the cat (she sometimes jumps up onto my desk, landing on my keyboard, and randomly pressing keys...) :-) Apologies, and thank goodness for testing... -Marshall On 10/10/2017 4:45 PM, Richard Eckart de Castilho wrote: > On 10.10.2017, at 22:03, Richard Eckart de Castilho <r...@apache.org> wrote: >> On 09.10.2017, at 16:35, Marshall Schor <m...@schor.com> wrote: >>> I think this will need a test case - can you provide one? >> I can see the extended error message and will try to produce a reduced unit >> test. >> >> org.apache.uima.cas.CASRuntimeException: Deserializing Compressed Form 6, a >> type code: 71 has no corresponding type. currentFsId: 1 nbrFSs: 0 >> nextFsAddr: 1 >> at >> org.apache.uima.cas.impl.BinaryCasSerDes6.deserializeAfterVersion(BinaryCasSerDes6.java:1812) >> at >> org.apache.uima.cas.impl.BinaryCasSerDes.reinit(BinaryCasSerDes.java:594) >> at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:382) >> at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:344) >> ... > This seems to happen only when CasIOUtils.load(casInputStream, aCAS, > typeSystem) is used. > I tried to set up a minimal test which serializes a CAS into one byte-array > for the contents > and a second one for the type system, then deserializes this into a new CAS > using the > method above. However, this doesn't seem to trigger the problem. So it might > be related > to the fact that in the failing DKPro Core test, there are also two > collection reader components > and an analysis engine (actually a writing component) involved. > > I'll try to expand the test until it fails. If you have any additional > pointers, please > let me know. > > Cheers, > > -- Richard
