sorry for the partial sentence below, which should read:
" ... then the new type system is thrown away and the already committed equal
type system is used (replaced/installed into the CAS, if this is called from
casImpl.commitTypeSystem... , for instance) instead."
-Marshall
On 10/13/2017 9:19 AM, Marshall Schor wrote:
> 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
>>
>>
>>
>
