Hi Richard,
I'm guessing that the code which has the line
typeSystem.commit();
is part of DKPro. I'm wondering if you could change this to
typeSystem = typeSystem.commit();
The reason: UIMA V3 consolidates equal type systems; so if the type system that
was just created is equal to (has the same types and features as) another
committed type system, then the new type system is thrown away and the already
committed equal type system.
Code which calls commit for type systems needs to take this into account, in two
ways:
a) by using the ts = ts.commit() form, and
b) if the type system, prior to being committed, was accessed to get particular
type and feature instances,
and those instances are being referred to by some local variables or
fields,
and those local variables or fields continue to be used after the commit,
then
those local variables and fields need to be reinitialized incase the type
system was switch to
an already committed equal one.
You can see this in some v3 test cases, where the type system was built up
programmatically, and some variables were used subsequently. Here's one case:
The uimaj-core testcase class CASInitializer has a method "initCas". For v3,
this was modified to take an extra parameter, "reinitTypeSystem". If it is not
null, then the caller supplied a lambda which reinitializes fields after the
type system is committed.
Please search for all ".commit(" strings in dkpro to find all instances where
type systems are being committed, and update all of them :-)
-Marshall
On 10/12/2017 4:23 PM, Richard Eckart de Castilho wrote:
> On 12.10.2017, at 15:08, Marshall Schor <m...@schor.com> wrote:
>> Maybe the test is expecting the CAS's existing type system & index def to be
>> replaced, but didn't specify REINIT?
>>
>> Or, of course, there might be a bug.
>>
>> What was the CasLoadMode for this test, and can you confirm the receiving CAS
>> did not have a committed type system?
> The test doesn't expect the CAS to be reinitialized. It is a lenient loading
> test in which the extra typesystem provides the knowledge about the types
> in the case that is being deserialized into the target CAS.
>
> I have debugged this further. The type system which is passed as the third
> parameter to CasUtils.load(stream, cas, typesystem) is loaded using the
> following code:
>
> CASMgrSerializer casMgr = readCasManager();
> typeSystem = casMgr.getTypeSystem();
> typeSystem.commit();
>
> The problem appears to be in the third line. Although commit() is called
> explicitly here, isCommitted() still returns "false" afterwards.
>
> Btw. DKPro Core build against UIMAv3 will soon be stable. There is this
> issue and after that, one additional different exception:
>
> java.lang.ArrayIndexOutOfBoundsException: -1
> at
> org.apache.uima.cas.impl.CasTypeSystemMapper.getToFeature(CasTypeSystemMapper.java:197)
> at
> org.apache.uima.cas.impl.CasTypeSystemMapper.getSrcFeature(CasTypeSystemMapper.java:172)
> at
> org.apache.uima.cas.impl.BinaryCasSerDes6.deserializeAfterVersion(BinaryCasSerDes6.java:1875)
> 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)
> ...
>
> Cheers,
>
> -- Richard
>
>
>
