You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Peter Klügl <pe...@averbis.com> on 2017/10/02 08:18:37 UTC
Re: testing uv3 with ...?
Hi,
I have also started testing some of our component repositories with uima v3.
Here are some first observations:
- Some new exceptions are thrown when a method is used in a wrong way,
e.g, annotation.setFeatureValueFromString() with a feature defined for a
different type. That's totally fine.
- Many tests failed because mocking objects of JCas cover classes did
not work anymore, e.g., someting like "Token tokenMock =
Mockito.mock(Token.class);" This is now fixed with the latest changed in
SNAPSHOT
- Some strange exceptions are thrown for tests including a specific type
system:
org.apache.uima.UIMARuntimeException: An internal error occurred, please
report to the Apache UIMA project; nested exception if present: {0}
at org.apache.uima.internal.util.Misc.assertUie(Misc.java:585)
at org.apache.uima.internal.util.Misc.internalError(Misc.java:594)
at
org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCas(FSClassRegistry.java:499)
at
org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:370)
at
org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
at
org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
at
org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
at
org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
at
org.apache.uima.cas.impl.FSClassRegistry.loadJCasForTSandClassLoader(FSClassRegistry.java:325)
at
org.apache.uima.cas.impl.FSClassRegistry.getGeneratorsForClassLoader(FSClassRegistry.java:875)
at
org.apache.uima.cas.impl.TypeSystemImpl.getGeneratorsForClassLoader(TypeSystemImpl.java:2634)
at
org.apache.uima.cas.impl.TypeSystemImpl.commit(TypeSystemImpl.java:1382)
at org.apache.uima.cas.impl.CASImpl.commitTypeSystem(CASImpl.java:1529)
at
org.apache.uima.util.CasCreationUtils.doCreateCas(CasCreationUtils.java:613)
at
org.apache.uima.util.CasCreationUtils.createCas(CasCreationUtils.java:362)
at
org.apache.uima.util.CasCreationUtils.createCas(CasCreationUtils.java:313)
at
org.apache.uima.fit.factory.JCasFactory.createJCas(JCasFactory.java:118)
...
The line calling the JCasFactory looks like "jCas =
JCasFactory.createJCas("TestTypeSystem");" where TestTypeSystem.xml is a
valid description in src/test/resources, which could however be
incompatible with type systems found by uimaFIT's classpath scanning.
And it contains definitions incompatible to the generated JCas cover
classes on the classpath.
Best,
Peter
Am 19.09.2017 um 15:53 schrieb Marshall Schor:
> Hi,
>
> Now that uimaFIT Jenkins build is back to normal, can anyone test uv3 with other
> things, like dk-pro?
>
> When you do this, please pay special attention to how logging is configured.
>
> If you see messages that no logging is being done because no target for the
> slf4j can be found, please try to fix this (possibly by adding a slf4j bridge
> jar to th target of your choice). The default binary distribution of uv3 has
> "runners" that include by default the bridge to the former logger
> (java.util.logger), for example.
>
> Cheers. -Marshall
>
Re: testing uv3 with ...?
Posted by Marshall Schor <ms...@schor.com>.
That looks like a bug - will fix.
Please note fixes now in trunk for:
uimaFIT use of classloaders and
new -Duima.v2_pretty_print_format to have v3 do "toString() of feature
structures exactly like v2 so test cases still work.
Thanks for testing!
-Marshall
On 10/2/2017 5:03 AM, Peter Klügl wrote:
> Just reporting... all problems can be fixed on our side, I think.
>
>
> There are some problems deserializing a legacy XMI:
>
> org.apache.uima.cas.CASRuntimeException: Can''t use standard set methods
> with SofaFS features.
> at org.apache.uima.jcas.cas.Sofa.setFeatureValue(Sofa.java:272)
> at
> org.apache.uima.cas.impl.XmiCasDeserializer$XmiCasDeserializerHandler.finalizeRefValue(XmiCasDeserializer.java:1835)
> at
> org.apache.uima.cas.impl.XmiCasDeserializer$XmiCasDeserializerHandler.lambda$deserializeFsRef$182(XmiCasDeserializer.java:1120)
> at
> org.apache.uima.cas.impl.XmiCasDeserializer$XmiCasDeserializerHandler$$Lambda$166/1594873248.run(Unknown
> Source)
> at
> org.apache.uima.cas.impl.XmiCasDeserializer$XmiCasDeserializerHandler.endDocument(XmiCasDeserializer.java:1779)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endDocument(AbstractSAXParser.java:745)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:515)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
> at
> org.apache.uima.cas.impl.XmiCasDeserializer.deserialize(XmiCasDeserializer.java:2299)
> at
> org.apache.uima.cas.impl.XmiCasDeserializer.deserialize(XmiCasDeserializer.java:2216)
>
>
> Am 02.10.2017 um 10:18 schrieb Peter Klügl:
>> Hi,
>>
>>
>> I have also started testing some of our component repositories with uima v3.
>>
>> Here are some first observations:
>>
>> - Some new exceptions are thrown when a method is used in a wrong way,
>> e.g, annotation.setFeatureValueFromString() with a feature defined for a
>> different type. That's totally fine.
>>
>> - Many tests failed because mocking objects of JCas cover classes did
>> not work anymore, e.g., someting like "Token tokenMock =
>> Mockito.mock(Token.class);" This is now fixed with the latest changed in
>> SNAPSHOT
>>
>> - Some strange exceptions are thrown for tests including a specific type
>> system:
>>
>> org.apache.uima.UIMARuntimeException: An internal error occurred, please
>> report to the Apache UIMA project; nested exception if present: {0}
>> at org.apache.uima.internal.util.Misc.assertUie(Misc.java:585)
>> at org.apache.uima.internal.util.Misc.internalError(Misc.java:594)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCas(FSClassRegistry.java:499)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:370)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.loadJCasForTSandClassLoader(FSClassRegistry.java:325)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.getGeneratorsForClassLoader(FSClassRegistry.java:875)
>> at
>> org.apache.uima.cas.impl.TypeSystemImpl.getGeneratorsForClassLoader(TypeSystemImpl.java:2634)
>> at
>> org.apache.uima.cas.impl.TypeSystemImpl.commit(TypeSystemImpl.java:1382)
>> at org.apache.uima.cas.impl.CASImpl.commitTypeSystem(CASImpl.java:1529)
>> at
>> org.apache.uima.util.CasCreationUtils.doCreateCas(CasCreationUtils.java:613)
>> at
>> org.apache.uima.util.CasCreationUtils.createCas(CasCreationUtils.java:362)
>> at
>> org.apache.uima.util.CasCreationUtils.createCas(CasCreationUtils.java:313)
>> at
>> org.apache.uima.fit.factory.JCasFactory.createJCas(JCasFactory.java:118)
>> ...
>>
>> The line calling the JCasFactory looks like "jCas =
>> JCasFactory.createJCas("TestTypeSystem");" where TestTypeSystem.xml is a
>> valid description in src/test/resources, which could however be
>> incompatible with type systems found by uimaFIT's classpath scanning.
>> And it contains definitions incompatible to the generated JCas cover
>> classes on the classpath.
>>
>>
>> Best,
>>
>>
>> Peter
>>
>>
>>
>> Am 19.09.2017 um 15:53 schrieb Marshall Schor:
>>> Hi,
>>>
>>> Now that uimaFIT Jenkins build is back to normal, can anyone test uv3 with other
>>> things, like dk-pro?
>>>
>>> When you do this, please pay special attention to how logging is configured.
>>>
>>> If you see messages that no logging is being done because no target for the
>>> slf4j can be found, please try to fix this (possibly by adding a slf4j bridge
>>> jar to th target of your choice). The default binary distribution of uv3 has
>>> "runners" that include by default the bridge to the former logger
>>> (java.util.logger), for example.
>>>
>>> Cheers. -Marshall
>>>
>
Re: testing uv3 with ...?
Posted by Marshall Schor <ms...@schor.com>.
I added a null-catcher to the Form 6 deserializer code - that particular value
should never be null; it prints out the typecode that can't be converted into a
type. -M
On 10/9/2017 10:35 AM, Marshall Schor wrote:
> looking at this stack trace, NPE on line 1839 implies tgtType is null.
> Looking up at previous lines, the initPrevIntValue(tgtType) would have thrown a
> NPE if it was executed, so therefore "storeIt" must be false.
> Which means srcType == null.
> If lenient is being used, this probably means the src and target (the
> deserialized form) type systems are different.
>
> So, as far as I can tell, this means that there's a type code in the form being
> deserialized which is a number not in the target type.
> Because this is unlikely, it's more likely something else went amiss, and
> there's some garbage being read for the type code.
>
> I think this will need a test case - can you provide one?
>
> -Marshall
>
>
> On 10/3/2017 6:14 PM, Richard Eckart de Castilho wrote:
>> On 02.10.2017, at 19:33, Marshall Schor <ms...@schor.com> wrote:
>>> this should now be fixed. Can you update to head and retest? Thanks! -Marshall
>> From DKPro Core: a considerable number of tests have been fixed. Several ones need to be updated again due to changes in FS.toString(). However, it seems there are still some issues. Before looking into these, I want to fix the more trivial things first though.
>>
>> That said, here is an example of one of the potentially remaining issues: a stacktrace (completely undiagnosed) that I still get when deserializing a form 6 binary CAS in lenient mode:
>>
>> java.lang.NullPointerException
>> at org.apache.uima.cas.impl.BinaryCasSerDes6.deserializeAfterVersion(BinaryCasSerDes6.java:1839)
>> 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)
>> at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasReader.getNext(BinaryCasReader.java:194)
>> at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasWriterReaderTest.read(BinaryCasWriterReaderTest.java:521)
>> at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasWriterReaderTest.test6Lenient(BinaryCasWriterReaderTest.java:160)
>>
>> Cheers,
>>
>> -- Richard
>
Re: testing uv3 with ...?
Posted by Marshall Schor <ms...@schor.com>.
re: the second failure: (no such element exception) I think that's now fixed in
trunk.
-Marshall
On 10/10/2017 4:03 PM, Richard Eckart de Castilho wrote:
> On 09.10.2017, at 16:35, Marshall Schor <ms...@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)
> ...
>
> With the latest changes, some additional tests are failing with a new stack trace:
>
> Caused by: java.util.NoSuchElementException
> at org.apache.uima.internal.util.CopyOnWriteOrderedFsSet_array$1.next(CopyOnWriteOrderedFsSet_array.java:132)
> at org.apache.uima.internal.util.CopyOnWriteOrderedFsSet_array$1.next(CopyOnWriteOrderedFsSet_array.java:120)
> at org.apache.uima.cas.impl.FSIndexRepositoryImpl$1$1.next(FSIndexRepositoryImpl.java:1578)
> at org.apache.uima.cas.impl.FSIndexRepositoryImpl$1$1.next(FSIndexRepositoryImpl.java:1563)
> at org.apache.uima.cas.impl.AllFSs.getFSsForView(AllFSs.java:115)
> at org.apache.uima.cas.impl.AllFSs.lambda$getAllFSsAllViews_sofas$1(AllFSs.java:89)
> at org.apache.uima.cas.impl.CASImpl.forAllViews(CASImpl.java:4440)
> at org.apache.uima.cas.impl.AllFSs.getAllFSsAllViews_sofas(AllFSs.java:89)
> at org.apache.uima.cas.impl.AllFSs.getAllFSsAllViews_sofas_reachable(AllFSs.java:95)
> at org.apache.uima.cas.impl.BinaryCasSerDes6.processIndexedFeatureStructures(BinaryCasSerDes6.java:2820)
> at org.apache.uima.cas.impl.BinaryCasSerDes6.serialize(BinaryCasSerDes6.java:747)
> at org.apache.uima.cas.impl.Serialization.serializeWithCompression(Serialization.java:247)
> at org.apache.uima.util.CasIOUtils.save(CasIOUtils.java:483)
> ... 34 more
>
> I'll also try to isolate this case.
>
> Best,
>
> -- Richard
>
>
>
Re: testing uv3 with ...?
Posted by Richard Eckart de Castilho <re...@apache.org>.
DKPro Core (a special branch) can now build successfully against UIMAv3 :)
Great work!
Best,
-- Richard
> On 13.10.2017, at 15:52, Marshall Schor <ms...@schor.com> wrote:
>
> 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."
Re: testing uv3 with ...?
Posted by Marshall Schor <ms...@schor.com>.
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 <ms...@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
>>
>>
>>
>
Re: testing uv3 with ...?
Posted by Marshall Schor <ms...@schor.com>.
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 <ms...@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
>
>
>
Re: testing uv3 with ...?
Posted by Marshall Schor <ms...@schor.com>.
Thanks, and it's nice to know we're getting to where we can see the light at the
end of the tunnel :-)
-Marshall
On 10/12/2017 4:23 PM, Richard Eckart de Castilho wrote:
> On 12.10.2017, at 15:08, Marshall Schor <ms...@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
>
>
>
Re: testing uv3 with ...?
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 12.10.2017, at 15:08, Marshall Schor <ms...@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
Re: testing uv3 with ...?
Posted by Marshall Schor <ms...@schor.com>.
Hi,
The code that throws the not-committed yet exception checks two type systems -
the one passed in (which has been committed), and the one associated with the CAS.
- This implies that the existing Type System in the CAS being deserialized
into is missing a committed type system.
Form 6 needs two type systems because it is designed to perform a kind of
mapping/filtering - the two type systems don't need to be the same, and form 6
will silently ignore types and features of types where they're missing.
There are variants of CasIOUtils which replace the CAS type system before
deserialization. The JavaDocs for CasIOUtils say:
For COMPRESSED_FILTERED_TS
* it uses the embedded TS for decoding
* it uses the external TSI to replace the CAS's existing type system and index
definition if CasLoadMode == REINIT.
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?
-Marshall
On 10/11/2017 6:20 PM, Richard Eckart de Castilho wrote:
> On 11.10.2017, at 16:01, Marshall Schor <ms...@schor.com> wrote:
>> fixed in trunk. Thanks for testing :-)
>>
>> On 10/11/2017 9:50 AM, Marshall Schor wrote:
>>> 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...
> Now I'm seeing a new exception in the units tests using the three-argument signature:
>
> org.apache.uima.cas.CASRuntimeException: Type Systems must be committed before calling this method.
> at org.apache.uima.cas.impl.CasTypeSystemMapper.<init>(CasTypeSystemMapper.java:101)
> at org.apache.uima.cas.impl.TypeSystemImpl.lambda$0(TypeSystemImpl.java:1853)
> at java.util.Map.computeIfAbsent(Map.java:957)
> at org.apache.uima.cas.impl.TypeSystemImpl.getTypeSystemMapperInner(TypeSystemImpl.java:1852)
> at org.apache.uima.cas.impl.TypeSystemImpl.getTypeSystemMapper(TypeSystemImpl.java:1841)
> at org.apache.uima.cas.impl.BinaryCasSerDes6.<init>(BinaryCasSerDes6.java:545)
> at org.apache.uima.cas.impl.BinaryCasSerDes6.<init>(BinaryCasSerDes6.java:639)
> at org.apache.uima.cas.impl.BinaryCasSerDes.reinit(BinaryCasSerDes.java:593)
> at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:382)
> at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:344)
> at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasReader.getNext(BinaryCasReader.java:194)
> at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasWriterReaderTest.read(BinaryCasWriterReaderTest.java:561)
> at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasWriterReaderTest.test6Lenient(BinaryCasWriterReaderTest.java:164)
> ...
>
> Mind, I actually do explicitly call typeSystem.commit() on the type system passed as the third argument before passing it.
>
> Any immediate ideas?
>
> Best,
>
> -- Richard
>
>
>
>
Re: testing uv3 with ...?
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 11.10.2017, at 16:01, Marshall Schor <ms...@schor.com> wrote:
>
> fixed in trunk. Thanks for testing :-)
>
> On 10/11/2017 9:50 AM, Marshall Schor wrote:
>> 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...
Now I'm seeing a new exception in the units tests using the three-argument signature:
org.apache.uima.cas.CASRuntimeException: Type Systems must be committed before calling this method.
at org.apache.uima.cas.impl.CasTypeSystemMapper.<init>(CasTypeSystemMapper.java:101)
at org.apache.uima.cas.impl.TypeSystemImpl.lambda$0(TypeSystemImpl.java:1853)
at java.util.Map.computeIfAbsent(Map.java:957)
at org.apache.uima.cas.impl.TypeSystemImpl.getTypeSystemMapperInner(TypeSystemImpl.java:1852)
at org.apache.uima.cas.impl.TypeSystemImpl.getTypeSystemMapper(TypeSystemImpl.java:1841)
at org.apache.uima.cas.impl.BinaryCasSerDes6.<init>(BinaryCasSerDes6.java:545)
at org.apache.uima.cas.impl.BinaryCasSerDes6.<init>(BinaryCasSerDes6.java:639)
at org.apache.uima.cas.impl.BinaryCasSerDes.reinit(BinaryCasSerDes.java:593)
at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:382)
at org.apache.uima.util.CasIOUtils.load(CasIOUtils.java:344)
at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasReader.getNext(BinaryCasReader.java:194)
at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasWriterReaderTest.read(BinaryCasWriterReaderTest.java:561)
at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasWriterReaderTest.test6Lenient(BinaryCasWriterReaderTest.java:164)
...
Mind, I actually do explicitly call typeSystem.commit() on the type system passed as the third argument before passing it.
Any immediate ideas?
Best,
-- Richard
Re: testing uv3 with ...?
Posted by Marshall Schor <ms...@schor.com>.
fixed in trunk. Thanks for testing :-)
-Marshall
On 10/11/2017 9:50 AM, Marshall Schor wrote:
> 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 <re...@apache.org> wrote:
>>> On 09.10.2017, at 16:35, Marshall Schor <ms...@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
>
Re: testing uv3 with ...?
Posted by Marshall Schor <ms...@schor.com>.
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 <re...@apache.org> wrote:
>> On 09.10.2017, at 16:35, Marshall Schor <ms...@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
Re: testing uv3 with ...?
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 10.10.2017, at 22:03, Richard Eckart de Castilho <re...@apache.org> wrote:
>
> On 09.10.2017, at 16:35, Marshall Schor <ms...@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
Re: testing uv3 with ...?
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 09.10.2017, at 16:35, Marshall Schor <ms...@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)
...
With the latest changes, some additional tests are failing with a new stack trace:
Caused by: java.util.NoSuchElementException
at org.apache.uima.internal.util.CopyOnWriteOrderedFsSet_array$1.next(CopyOnWriteOrderedFsSet_array.java:132)
at org.apache.uima.internal.util.CopyOnWriteOrderedFsSet_array$1.next(CopyOnWriteOrderedFsSet_array.java:120)
at org.apache.uima.cas.impl.FSIndexRepositoryImpl$1$1.next(FSIndexRepositoryImpl.java:1578)
at org.apache.uima.cas.impl.FSIndexRepositoryImpl$1$1.next(FSIndexRepositoryImpl.java:1563)
at org.apache.uima.cas.impl.AllFSs.getFSsForView(AllFSs.java:115)
at org.apache.uima.cas.impl.AllFSs.lambda$getAllFSsAllViews_sofas$1(AllFSs.java:89)
at org.apache.uima.cas.impl.CASImpl.forAllViews(CASImpl.java:4440)
at org.apache.uima.cas.impl.AllFSs.getAllFSsAllViews_sofas(AllFSs.java:89)
at org.apache.uima.cas.impl.AllFSs.getAllFSsAllViews_sofas_reachable(AllFSs.java:95)
at org.apache.uima.cas.impl.BinaryCasSerDes6.processIndexedFeatureStructures(BinaryCasSerDes6.java:2820)
at org.apache.uima.cas.impl.BinaryCasSerDes6.serialize(BinaryCasSerDes6.java:747)
at org.apache.uima.cas.impl.Serialization.serializeWithCompression(Serialization.java:247)
at org.apache.uima.util.CasIOUtils.save(CasIOUtils.java:483)
... 34 more
I'll also try to isolate this case.
Best,
-- Richard
Re: testing uv3 with ...?
Posted by Marshall Schor <ms...@schor.com>.
looking at this stack trace, NPE on line 1839 implies tgtType is null.
Looking up at previous lines, the initPrevIntValue(tgtType) would have thrown a
NPE if it was executed, so therefore "storeIt" must be false.
Which means srcType == null.
If lenient is being used, this probably means the src and target (the
deserialized form) type systems are different.
So, as far as I can tell, this means that there's a type code in the form being
deserialized which is a number not in the target type.
Because this is unlikely, it's more likely something else went amiss, and
there's some garbage being read for the type code.
I think this will need a test case - can you provide one?
-Marshall
On 10/3/2017 6:14 PM, Richard Eckart de Castilho wrote:
> On 02.10.2017, at 19:33, Marshall Schor <ms...@schor.com> wrote:
>> this should now be fixed. Can you update to head and retest? Thanks! -Marshall
> From DKPro Core: a considerable number of tests have been fixed. Several ones need to be updated again due to changes in FS.toString(). However, it seems there are still some issues. Before looking into these, I want to fix the more trivial things first though.
>
> That said, here is an example of one of the potentially remaining issues: a stacktrace (completely undiagnosed) that I still get when deserializing a form 6 binary CAS in lenient mode:
>
> java.lang.NullPointerException
> at org.apache.uima.cas.impl.BinaryCasSerDes6.deserializeAfterVersion(BinaryCasSerDes6.java:1839)
> 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)
> at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasReader.getNext(BinaryCasReader.java:194)
> at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasWriterReaderTest.read(BinaryCasWriterReaderTest.java:521)
> at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasWriterReaderTest.test6Lenient(BinaryCasWriterReaderTest.java:160)
>
> Cheers,
>
> -- Richard
Re: toString in v2 style
Posted by Marshall Schor <ms...@schor.com>.
Fs2String: there's a new global mode setting:
-Duima.v2_pretty_print_format
If you specify this, it should do toString() just like v2.
-M
On 10/3/2017 6:14 PM, Richard Eckart de Castilho wrote:
> On 02.10.2017, at 19:33, Marshall Schor <ms...@schor.com> wrote:
>> this should now be fixed. Can you update to head and retest? Thanks! -Marshall
> From DKPro Core: a considerable number of tests have been fixed. Several ones need to be updated again due to changes in FS.toString(). However, it seems there are still some issues. Before looking into these, I want to fix the more trivial things first though.
>
> That said, here is an example of one of the potentially remaining issues: a stacktrace (completely undiagnosed) that I still get when deserializing a form 6 binary CAS in lenient mode:
>
> java.lang.NullPointerException
> at org.apache.uima.cas.impl.BinaryCasSerDes6.deserializeAfterVersion(BinaryCasSerDes6.java:1839)
> 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)
> at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasReader.getNext(BinaryCasReader.java:194)
> at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasWriterReaderTest.read(BinaryCasWriterReaderTest.java:521)
> at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasWriterReaderTest.test6Lenient(BinaryCasWriterReaderTest.java:160)
>
> Cheers,
>
> -- Richard
Re: testing uv3 with ...?
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 02.10.2017, at 19:33, Marshall Schor <ms...@schor.com> wrote:
>
> this should now be fixed. Can you update to head and retest? Thanks! -Marshall
From DKPro Core: a considerable number of tests have been fixed. Several ones need to be updated again due to changes in FS.toString(). However, it seems there are still some issues. Before looking into these, I want to fix the more trivial things first though.
That said, here is an example of one of the potentially remaining issues: a stacktrace (completely undiagnosed) that I still get when deserializing a form 6 binary CAS in lenient mode:
java.lang.NullPointerException
at org.apache.uima.cas.impl.BinaryCasSerDes6.deserializeAfterVersion(BinaryCasSerDes6.java:1839)
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)
at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasReader.getNext(BinaryCasReader.java:194)
at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasWriterReaderTest.read(BinaryCasWriterReaderTest.java:521)
at de.tudarmstadt.ukp.dkpro.core.io.bincas.BinaryCasWriterReaderTest.test6Lenient(BinaryCasWriterReaderTest.java:160)
Cheers,
-- Richard
Re: testing uv3 with ...?
Posted by Marshall Schor <ms...@schor.com>.
this should now be fixed. Can you update to head and retest? Thanks! -Marshall
On 10/2/2017 5:03 AM, Peter Klügl wrote:
> Just reporting... all problems can be fixed on our side, I think.
>
>
> There are some problems deserializing a legacy XMI:
>
> org.apache.uima.cas.CASRuntimeException: Can''t use standard set methods
> with SofaFS features.
> at org.apache.uima.jcas.cas.Sofa.setFeatureValue(Sofa.java:272)
> at
> org.apache.uima.cas.impl.XmiCasDeserializer$XmiCasDeserializerHandler.finalizeRefValue(XmiCasDeserializer.java:1835)
> at
> org.apache.uima.cas.impl.XmiCasDeserializer$XmiCasDeserializerHandler.lambda$deserializeFsRef$182(XmiCasDeserializer.java:1120)
> at
> org.apache.uima.cas.impl.XmiCasDeserializer$XmiCasDeserializerHandler$$Lambda$166/1594873248.run(Unknown
> Source)
> at
> org.apache.uima.cas.impl.XmiCasDeserializer$XmiCasDeserializerHandler.endDocument(XmiCasDeserializer.java:1779)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endDocument(AbstractSAXParser.java:745)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:515)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
> at
> org.apache.uima.cas.impl.XmiCasDeserializer.deserialize(XmiCasDeserializer.java:2299)
> at
> org.apache.uima.cas.impl.XmiCasDeserializer.deserialize(XmiCasDeserializer.java:2216)
>
>
> Am 02.10.2017 um 10:18 schrieb Peter Klügl:
>> Hi,
>>
>>
>> I have also started testing some of our component repositories with uima v3.
>>
>> Here are some first observations:
>>
>> - Some new exceptions are thrown when a method is used in a wrong way,
>> e.g, annotation.setFeatureValueFromString() with a feature defined for a
>> different type. That's totally fine.
>>
>> - Many tests failed because mocking objects of JCas cover classes did
>> not work anymore, e.g., someting like "Token tokenMock =
>> Mockito.mock(Token.class);" This is now fixed with the latest changed in
>> SNAPSHOT
>>
>> - Some strange exceptions are thrown for tests including a specific type
>> system:
>>
>> org.apache.uima.UIMARuntimeException: An internal error occurred, please
>> report to the Apache UIMA project; nested exception if present: {0}
>> at org.apache.uima.internal.util.Misc.assertUie(Misc.java:585)
>> at org.apache.uima.internal.util.Misc.internalError(Misc.java:594)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCas(FSClassRegistry.java:499)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:370)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.loadJCasForTSandClassLoader(FSClassRegistry.java:325)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.getGeneratorsForClassLoader(FSClassRegistry.java:875)
>> at
>> org.apache.uima.cas.impl.TypeSystemImpl.getGeneratorsForClassLoader(TypeSystemImpl.java:2634)
>> at
>> org.apache.uima.cas.impl.TypeSystemImpl.commit(TypeSystemImpl.java:1382)
>> at org.apache.uima.cas.impl.CASImpl.commitTypeSystem(CASImpl.java:1529)
>> at
>> org.apache.uima.util.CasCreationUtils.doCreateCas(CasCreationUtils.java:613)
>> at
>> org.apache.uima.util.CasCreationUtils.createCas(CasCreationUtils.java:362)
>> at
>> org.apache.uima.util.CasCreationUtils.createCas(CasCreationUtils.java:313)
>> at
>> org.apache.uima.fit.factory.JCasFactory.createJCas(JCasFactory.java:118)
>> ...
>>
>> The line calling the JCasFactory looks like "jCas =
>> JCasFactory.createJCas("TestTypeSystem");" where TestTypeSystem.xml is a
>> valid description in src/test/resources, which could however be
>> incompatible with type systems found by uimaFIT's classpath scanning.
>> And it contains definitions incompatible to the generated JCas cover
>> classes on the classpath.
>>
>>
>> Best,
>>
>>
>> Peter
>>
>>
>>
>> Am 19.09.2017 um 15:53 schrieb Marshall Schor:
>>> Hi,
>>>
>>> Now that uimaFIT Jenkins build is back to normal, can anyone test uv3 with other
>>> things, like dk-pro?
>>>
>>> When you do this, please pay special attention to how logging is configured.
>>>
>>> If you see messages that no logging is being done because no target for the
>>> slf4j can be found, please try to fix this (possibly by adding a slf4j bridge
>>> jar to th target of your choice). The default binary distribution of uv3 has
>>> "runners" that include by default the bridge to the former logger
>>> (java.util.logger), for example.
>>>
>>> Cheers. -Marshall
>>>
>
Re: testing uv3 with ...?
Posted by Peter Klügl <pe...@averbis.com>.
Just reporting... all problems can be fixed on our side, I think.
There are some problems deserializing a legacy XMI:
org.apache.uima.cas.CASRuntimeException: Can''t use standard set methods
with SofaFS features.
at org.apache.uima.jcas.cas.Sofa.setFeatureValue(Sofa.java:272)
at
org.apache.uima.cas.impl.XmiCasDeserializer$XmiCasDeserializerHandler.finalizeRefValue(XmiCasDeserializer.java:1835)
at
org.apache.uima.cas.impl.XmiCasDeserializer$XmiCasDeserializerHandler.lambda$deserializeFsRef$182(XmiCasDeserializer.java:1120)
at
org.apache.uima.cas.impl.XmiCasDeserializer$XmiCasDeserializerHandler$$Lambda$166/1594873248.run(Unknown
Source)
at
org.apache.uima.cas.impl.XmiCasDeserializer$XmiCasDeserializerHandler.endDocument(XmiCasDeserializer.java:1779)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endDocument(AbstractSAXParser.java:745)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:515)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
at
org.apache.uima.cas.impl.XmiCasDeserializer.deserialize(XmiCasDeserializer.java:2299)
at
org.apache.uima.cas.impl.XmiCasDeserializer.deserialize(XmiCasDeserializer.java:2216)
Am 02.10.2017 um 10:18 schrieb Peter Klügl:
> Hi,
>
>
> I have also started testing some of our component repositories with uima v3.
>
> Here are some first observations:
>
> - Some new exceptions are thrown when a method is used in a wrong way,
> e.g, annotation.setFeatureValueFromString() with a feature defined for a
> different type. That's totally fine.
>
> - Many tests failed because mocking objects of JCas cover classes did
> not work anymore, e.g., someting like "Token tokenMock =
> Mockito.mock(Token.class);" This is now fixed with the latest changed in
> SNAPSHOT
>
> - Some strange exceptions are thrown for tests including a specific type
> system:
>
> org.apache.uima.UIMARuntimeException: An internal error occurred, please
> report to the Apache UIMA project; nested exception if present: {0}
> at org.apache.uima.internal.util.Misc.assertUie(Misc.java:585)
> at org.apache.uima.internal.util.Misc.internalError(Misc.java:594)
> at
> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCas(FSClassRegistry.java:499)
> at
> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:370)
> at
> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
> at
> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
> at
> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
> at
> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
> at
> org.apache.uima.cas.impl.FSClassRegistry.loadJCasForTSandClassLoader(FSClassRegistry.java:325)
> at
> org.apache.uima.cas.impl.FSClassRegistry.getGeneratorsForClassLoader(FSClassRegistry.java:875)
> at
> org.apache.uima.cas.impl.TypeSystemImpl.getGeneratorsForClassLoader(TypeSystemImpl.java:2634)
> at
> org.apache.uima.cas.impl.TypeSystemImpl.commit(TypeSystemImpl.java:1382)
> at org.apache.uima.cas.impl.CASImpl.commitTypeSystem(CASImpl.java:1529)
> at
> org.apache.uima.util.CasCreationUtils.doCreateCas(CasCreationUtils.java:613)
> at
> org.apache.uima.util.CasCreationUtils.createCas(CasCreationUtils.java:362)
> at
> org.apache.uima.util.CasCreationUtils.createCas(CasCreationUtils.java:313)
> at
> org.apache.uima.fit.factory.JCasFactory.createJCas(JCasFactory.java:118)
> ...
>
> The line calling the JCasFactory looks like "jCas =
> JCasFactory.createJCas("TestTypeSystem");" where TestTypeSystem.xml is a
> valid description in src/test/resources, which could however be
> incompatible with type systems found by uimaFIT's classpath scanning.
> And it contains definitions incompatible to the generated JCas cover
> classes on the classpath.
>
>
> Best,
>
>
> Peter
>
>
>
> Am 19.09.2017 um 15:53 schrieb Marshall Schor:
>> Hi,
>>
>> Now that uimaFIT Jenkins build is back to normal, can anyone test uv3 with other
>> things, like dk-pro?
>>
>> When you do this, please pay special attention to how logging is configured.
>>
>> If you see messages that no logging is being done because no target for the
>> slf4j can be found, please try to fix this (possibly by adding a slf4j bridge
>> jar to th target of your choice). The default binary distribution of uv3 has
>> "runners" that include by default the bridge to the former logger
>> (java.util.logger), for example.
>>
>> Cheers. -Marshall
>>
Re: testing uv3 with ...?
Posted by Peter Klügl <pe...@averbis.com>.
Sorry for this redudant mail. I am still catching up with the other mails...
Am 02.10.2017 um 10:47 schrieb Peter Klügl:
> Could it be that Annotation.toString() changed?
>
>
> There could be a porblem in uima/addons/trunk/RegularExpressionAnnotator
> concerning the
> uimaj-component-test-util/org.apache.uima.test.junit_extension.AnnotationWriter.class
>
>
> Best,
>
>
> Peter
>
>
> Am 02.10.2017 um 10:18 schrieb Peter Klügl:
>> Hi,
>>
>>
>> I have also started testing some of our component repositories with uima v3.
>>
>> Here are some first observations:
>>
>> - Some new exceptions are thrown when a method is used in a wrong way,
>> e.g, annotation.setFeatureValueFromString() with a feature defined for a
>> different type. That's totally fine.
>>
>> - Many tests failed because mocking objects of JCas cover classes did
>> not work anymore, e.g., someting like "Token tokenMock =
>> Mockito.mock(Token.class);" This is now fixed with the latest changed in
>> SNAPSHOT
>>
>> - Some strange exceptions are thrown for tests including a specific type
>> system:
>>
>> org.apache.uima.UIMARuntimeException: An internal error occurred, please
>> report to the Apache UIMA project; nested exception if present: {0}
>> at org.apache.uima.internal.util.Misc.assertUie(Misc.java:585)
>> at org.apache.uima.internal.util.Misc.internalError(Misc.java:594)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCas(FSClassRegistry.java:499)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:370)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.loadJCasForTSandClassLoader(FSClassRegistry.java:325)
>> at
>> org.apache.uima.cas.impl.FSClassRegistry.getGeneratorsForClassLoader(FSClassRegistry.java:875)
>> at
>> org.apache.uima.cas.impl.TypeSystemImpl.getGeneratorsForClassLoader(TypeSystemImpl.java:2634)
>> at
>> org.apache.uima.cas.impl.TypeSystemImpl.commit(TypeSystemImpl.java:1382)
>> at org.apache.uima.cas.impl.CASImpl.commitTypeSystem(CASImpl.java:1529)
>> at
>> org.apache.uima.util.CasCreationUtils.doCreateCas(CasCreationUtils.java:613)
>> at
>> org.apache.uima.util.CasCreationUtils.createCas(CasCreationUtils.java:362)
>> at
>> org.apache.uima.util.CasCreationUtils.createCas(CasCreationUtils.java:313)
>> at
>> org.apache.uima.fit.factory.JCasFactory.createJCas(JCasFactory.java:118)
>> ...
>>
>> The line calling the JCasFactory looks like "jCas =
>> JCasFactory.createJCas("TestTypeSystem");" where TestTypeSystem.xml is a
>> valid description in src/test/resources, which could however be
>> incompatible with type systems found by uimaFIT's classpath scanning.
>> And it contains definitions incompatible to the generated JCas cover
>> classes on the classpath.
>>
>>
>> Best,
>>
>>
>> Peter
>>
>>
>>
>> Am 19.09.2017 um 15:53 schrieb Marshall Schor:
>>> Hi,
>>>
>>> Now that uimaFIT Jenkins build is back to normal, can anyone test uv3 with other
>>> things, like dk-pro?
>>>
>>> When you do this, please pay special attention to how logging is configured.
>>>
>>> If you see messages that no logging is being done because no target for the
>>> slf4j can be found, please try to fix this (possibly by adding a slf4j bridge
>>> jar to th target of your choice). The default binary distribution of uv3 has
>>> "runners" that include by default the bridge to the former logger
>>> (java.util.logger), for example.
>>>
>>> Cheers. -Marshall
>>>
Re: testing uv3 with ...?
Posted by Peter Klügl <pe...@averbis.com>.
Could it be that Annotation.toString() changed?
There could be a porblem in uima/addons/trunk/RegularExpressionAnnotator
concerning the
uimaj-component-test-util/org.apache.uima.test.junit_extension.AnnotationWriter.class
Best,
Peter
Am 02.10.2017 um 10:18 schrieb Peter Klügl:
> Hi,
>
>
> I have also started testing some of our component repositories with uima v3.
>
> Here are some first observations:
>
> - Some new exceptions are thrown when a method is used in a wrong way,
> e.g, annotation.setFeatureValueFromString() with a feature defined for a
> different type. That's totally fine.
>
> - Many tests failed because mocking objects of JCas cover classes did
> not work anymore, e.g., someting like "Token tokenMock =
> Mockito.mock(Token.class);" This is now fixed with the latest changed in
> SNAPSHOT
>
> - Some strange exceptions are thrown for tests including a specific type
> system:
>
> org.apache.uima.UIMARuntimeException: An internal error occurred, please
> report to the Apache UIMA project; nested exception if present: {0}
> at org.apache.uima.internal.util.Misc.assertUie(Misc.java:585)
> at org.apache.uima.internal.util.Misc.internalError(Misc.java:594)
> at
> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCas(FSClassRegistry.java:499)
> at
> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:370)
> at
> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
> at
> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
> at
> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
> at
> org.apache.uima.cas.impl.FSClassRegistry.maybeLoadJCasAndSubtypes(FSClassRegistry.java:426)
> at
> org.apache.uima.cas.impl.FSClassRegistry.loadJCasForTSandClassLoader(FSClassRegistry.java:325)
> at
> org.apache.uima.cas.impl.FSClassRegistry.getGeneratorsForClassLoader(FSClassRegistry.java:875)
> at
> org.apache.uima.cas.impl.TypeSystemImpl.getGeneratorsForClassLoader(TypeSystemImpl.java:2634)
> at
> org.apache.uima.cas.impl.TypeSystemImpl.commit(TypeSystemImpl.java:1382)
> at org.apache.uima.cas.impl.CASImpl.commitTypeSystem(CASImpl.java:1529)
> at
> org.apache.uima.util.CasCreationUtils.doCreateCas(CasCreationUtils.java:613)
> at
> org.apache.uima.util.CasCreationUtils.createCas(CasCreationUtils.java:362)
> at
> org.apache.uima.util.CasCreationUtils.createCas(CasCreationUtils.java:313)
> at
> org.apache.uima.fit.factory.JCasFactory.createJCas(JCasFactory.java:118)
> ...
>
> The line calling the JCasFactory looks like "jCas =
> JCasFactory.createJCas("TestTypeSystem");" where TestTypeSystem.xml is a
> valid description in src/test/resources, which could however be
> incompatible with type systems found by uimaFIT's classpath scanning.
> And it contains definitions incompatible to the generated JCas cover
> classes on the classpath.
>
>
> Best,
>
>
> Peter
>
>
>
> Am 19.09.2017 um 15:53 schrieb Marshall Schor:
>> Hi,
>>
>> Now that uimaFIT Jenkins build is back to normal, can anyone test uv3 with other
>> things, like dk-pro?
>>
>> When you do this, please pay special attention to how logging is configured.
>>
>> If you see messages that no logging is being done because no target for the
>> slf4j can be found, please try to fix this (possibly by adding a slf4j bridge
>> jar to th target of your choice). The default binary distribution of uv3 has
>> "runners" that include by default the bridge to the former logger
>> (java.util.logger), for example.
>>
>> Cheers. -Marshall
>>