You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2017/09/19 13:53:48 UTC
testing uv3 with dk-pro?
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 dk-pro?
Posted by Marshall Schor <ms...@schor.com>.
ok, taking a look.
-Marshall
On 9/26/2017 6:33 AM, Richard Eckart de Castilho wrote:
> The fix in UIMA-5586 resolves various unit test failures in DKPro Core
> when building against UIMAv3.
>
> However, I still get the an NPE during deserialization in some cases when JCas
> is used and when a custom document annotation class is used. I
> have moved this to a separate issue:
>
> https://issues.apache.org/jira/browse/UIMA-5588
>
> Best,
>
> -- Richard
>
>> On 25.09.2017, at 19:18, Marshall Schor <ms...@schor.com> wrote:
>>
>> this is now fixed; additional testing much appreciated! -Marshall
>
Re: testing uv3 with dk-pro - toString compares now possible
Posted by Marshall Schor <ms...@schor.com>.
Re: the toString compares in test cases
The toString problems are fixed (I think :-) ), and I added a
migration/compatibility flag,
-Duima.v2_pretty_print_format
which when provided, makes the pretty print format identical to v2 (subject to
some "fixes" in v3 that have never been put into v2); this ought to make test
cases which are comparing toString() results work.
As usual, any testing appreciated !
-Marshall
On 9/29/2017 4:25 PM, Richard Eckart de Castilho wrote:
>> On 28.09.2017, at 04:34, Marshall Schor <ms...@schor.com> wrote:
>>
>> I reproduced this with more test case varieties - I added tests for all the
>> varieties of serialization in CasIOUtils.
>>
>> While investigating this, I found another issue; both are now fixed.
>>
>> Richard, would be great if you could try again :-)
> 6 down, 73 failures to go ;)
>
> Some of them are related to the change in the toString() format of feature structures.
> I'll fix these soon.
>
> However, some are still likely related to be issues in UIMAv3. For example, I still get
> an NPE when deserializing format 6 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)
> ...
>
> Be invited to directly check the Jenkins logs [1] and/or trying to run the respective DKPro Core
> tests yourself. If not, I'll try to open new Jira's after I have fixed the trivial failures and
> once I have found the time to do some diagnosis on the non-trivial ones.
>
> Cheers,
>
> -- Richard
>
> P.S.: it's "DKPro Core" ;)
>
> [1] https://zoidberg.ukp.informatik.tu-darmstadt.de/jenkins/job/DKPro%20Core%20(GitHub)%20-%20UIMAv3/lastBuild/testReport/
>
>
Re: testing uv3 with dk-pro?
Posted by Marshall Schor <ms...@schor.com>.
added a Jira https://issues.apache.org/jira/browse/UIMA-5595
On 9/29/2017 5:21 PM, Richard Eckart de Castilho wrote:
> On 29.09.2017, at 22:57, Marshall Schor <ms...@schor.com> wrote:
>> Thanks Richard!
>>
>> Re: the change in format for toString() for Feature Structures, I'm wondering if
>> I should see about making that more or less like v2. In your case(s), would it
>> have to be identical to avoid failure?
> uimaFIT and DKPro Core provide a component called CasDumpWriter which is
> intended for use in tests to write the CAS contents to a "human readable"
> format. To this end, it uses the toString() method. DKPro Core has various
> tests which contain "reference" files created by the CasDumpWriter and as
> part of unit tests, these files are compared to the actual output created
> during the test.
>
> Mind, this is not the best design - but it is quite convenient.
> I just have to update the reference files for the new toString() format.
> A bit tedious, but IMHO no reason to reconsider the format of toString().
>
> However, there seems to be room for improvement in the toString() method
> when dealing with nested annotations and multi-valued features. E.g.
> the array contents in the following output do not seem to be properly
> indented. Maybe one-element-per-line would also look better.
>
> ------
> [Save]
> #23 Token:3
> sofa: sofa id: _InitialView
> begin: 0 end: 4 parent: #22 Constituent:141
> sofa: sofa id: _InitialView
> begin: 0 end: 29 constituentType: "VP"
> parent: #1 ROOT:100
> sofa: sofa id: _InitialView
> begin: 0 end: 169 constituentType: "S"
> children: #26 FSArray:147
> Array length: 3
> Array elements: ["#27 Token:21
> sofa: sofa id: _InitialView
> beg...", "#2 Constituent:101
> sofa: sofa id: _InitialView
> ...", "#22 "]
>
>
> children: #125 FSArray:146
> Array length: 2
> Array elements: ["#23 ", "#24 Constituent:142
> sofa: sofa id: _InitialView..."]
>
>
> lemma: #143 Lemma:4
> sofa: sofa id: _InitialView
> begin: 0 end: 4 value: "save"
>
> pos: #144 POS_VERB:5
> sofa: sofa id: _InitialView
> begin: 0 end: 4 PosValue: "VB"
> coarseValue: "VERB"
>
> id: "s115_0"
> ------
>
> Cheers,
>
> -- Richard
Re: testing uv3 with dk-pro?
Posted by Marshall Schor <ms...@schor.com>.
Re: the toString method needs improvement/fixes.
Yes, I agree. I in fact broke something that used to work; it's not handling
the circular references quite right.
I worked on this once before, IIRC, when some earlier tests of UV3 ran into a
similar issue where the test was depending on the format. Somewhere along the
line of subsequent development, this got forgotten, and messed up.
Working on it...
-Marshall
On 9/29/2017 5:21 PM, Richard Eckart de Castilho wrote:
> On 29.09.2017, at 22:57, Marshall Schor <ms...@schor.com> wrote:
>> Thanks Richard!
>>
>> Re: the change in format for toString() for Feature Structures, I'm wondering if
>> I should see about making that more or less like v2. In your case(s), would it
>> have to be identical to avoid failure?
> uimaFIT and DKPro Core provide a component called CasDumpWriter which is
> intended for use in tests to write the CAS contents to a "human readable"
> format. To this end, it uses the toString() method. DKPro Core has various
> tests which contain "reference" files created by the CasDumpWriter and as
> part of unit tests, these files are compared to the actual output created
> during the test.
>
> Mind, this is not the best design - but it is quite convenient.
> I just have to update the reference files for the new toString() format.
> A bit tedious, but IMHO no reason to reconsider the format of toString().
>
> However, there seems to be room for improvement in the toString() method
> when dealing with nested annotations and multi-valued features. E.g.
> the array contents in the following output do not seem to be properly
> indented. Maybe one-element-per-line would also look better.
>
> ------
> [Save]
> #23 Token:3
> sofa: sofa id: _InitialView
> begin: 0 end: 4 parent: #22 Constituent:141
> sofa: sofa id: _InitialView
> begin: 0 end: 29 constituentType: "VP"
> parent: #1 ROOT:100
> sofa: sofa id: _InitialView
> begin: 0 end: 169 constituentType: "S"
> children: #26 FSArray:147
> Array length: 3
> Array elements: ["#27 Token:21
> sofa: sofa id: _InitialView
> beg...", "#2 Constituent:101
> sofa: sofa id: _InitialView
> ...", "#22 "]
>
>
> children: #125 FSArray:146
> Array length: 2
> Array elements: ["#23 ", "#24 Constituent:142
> sofa: sofa id: _InitialView..."]
>
>
> lemma: #143 Lemma:4
> sofa: sofa id: _InitialView
> begin: 0 end: 4 value: "save"
>
> pos: #144 POS_VERB:5
> sofa: sofa id: _InitialView
> begin: 0 end: 4 PosValue: "VB"
> coarseValue: "VERB"
>
> id: "s115_0"
> ------
>
> Cheers,
>
> -- Richard
Re: testing uv3 with dk-pro?
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 29.09.2017, at 22:57, Marshall Schor <ms...@schor.com> wrote:
>
> Thanks Richard!
>
> Re: the change in format for toString() for Feature Structures, I'm wondering if
> I should see about making that more or less like v2. In your case(s), would it
> have to be identical to avoid failure?
uimaFIT and DKPro Core provide a component called CasDumpWriter which is
intended for use in tests to write the CAS contents to a "human readable"
format. To this end, it uses the toString() method. DKPro Core has various
tests which contain "reference" files created by the CasDumpWriter and as
part of unit tests, these files are compared to the actual output created
during the test.
Mind, this is not the best design - but it is quite convenient.
I just have to update the reference files for the new toString() format.
A bit tedious, but IMHO no reason to reconsider the format of toString().
However, there seems to be room for improvement in the toString() method
when dealing with nested annotations and multi-valued features. E.g.
the array contents in the following output do not seem to be properly
indented. Maybe one-element-per-line would also look better.
------
[Save]
#23 Token:3
sofa: sofa id: _InitialView
begin: 0 end: 4 parent: #22 Constituent:141
sofa: sofa id: _InitialView
begin: 0 end: 29 constituentType: "VP"
parent: #1 ROOT:100
sofa: sofa id: _InitialView
begin: 0 end: 169 constituentType: "S"
children: #26 FSArray:147
Array length: 3
Array elements: ["#27 Token:21
sofa: sofa id: _InitialView
beg...", "#2 Constituent:101
sofa: sofa id: _InitialView
...", "#22 "]
children: #125 FSArray:146
Array length: 2
Array elements: ["#23 ", "#24 Constituent:142
sofa: sofa id: _InitialView..."]
lemma: #143 Lemma:4
sofa: sofa id: _InitialView
begin: 0 end: 4 value: "save"
pos: #144 POS_VERB:5
sofa: sofa id: _InitialView
begin: 0 end: 4 PosValue: "VB"
coarseValue: "VERB"
id: "s115_0"
------
Cheers,
-- Richard
Re: testing uv3 with dk-pro?
Posted by Marshall Schor <ms...@schor.com>.
Thanks Richard!
Re: the change in format for toString() for Feature Structures, I'm wondering if
I should see about making that more or less like v2. In your case(s), would it
have to be identical to avoid failure?
-Marshall
On 9/29/2017 4:25 PM, Richard Eckart de Castilho wrote:
>> On 28.09.2017, at 04:34, Marshall Schor <ms...@schor.com> wrote:
>>
>> I reproduced this with more test case varieties - I added tests for all the
>> varieties of serialization in CasIOUtils.
>>
>> While investigating this, I found another issue; both are now fixed.
>>
>> Richard, would be great if you could try again :-)
> 6 down, 73 failures to go ;)
>
> Some of them are related to the change in the toString() format of feature structures.
> I'll fix these soon.
>
> However, some are still likely related to be issues in UIMAv3. For example, I still get
> an NPE when deserializing format 6 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)
> ...
>
> Be invited to directly check the Jenkins logs [1] and/or trying to run the respective DKPro Core
> tests yourself. If not, I'll try to open new Jira's after I have fixed the trivial failures and
> once I have found the time to do some diagnosis on the non-trivial ones.
>
> Cheers,
>
> -- Richard
>
> P.S.: it's "DKPro Core" ;)
>
> [1] https://zoidberg.ukp.informatik.tu-darmstadt.de/jenkins/job/DKPro%20Core%20(GitHub)%20-%20UIMAv3/lastBuild/testReport/
>
>
Re: testing uv3 with dk-pro?
Posted by Richard Eckart de Castilho <re...@apache.org>.
> On 28.09.2017, at 04:34, Marshall Schor <ms...@schor.com> wrote:
>
> I reproduced this with more test case varieties - I added tests for all the
> varieties of serialization in CasIOUtils.
>
> While investigating this, I found another issue; both are now fixed.
>
> Richard, would be great if you could try again :-)
6 down, 73 failures to go ;)
Some of them are related to the change in the toString() format of feature structures.
I'll fix these soon.
However, some are still likely related to be issues in UIMAv3. For example, I still get
an NPE when deserializing format 6 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)
...
Be invited to directly check the Jenkins logs [1] and/or trying to run the respective DKPro Core
tests yourself. If not, I'll try to open new Jira's after I have fixed the trivial failures and
once I have found the time to do some diagnosis on the non-trivial ones.
Cheers,
-- Richard
P.S.: it's "DKPro Core" ;)
[1] https://zoidberg.ukp.informatik.tu-darmstadt.de/jenkins/job/DKPro%20Core%20(GitHub)%20-%20UIMAv3/lastBuild/testReport/
Re: testing uv3 with dk-pro?
Posted by Marshall Schor <ms...@schor.com>.
I reproduced this with more test case varieties - I added tests for all the
varieties of serialization in CasIOUtils.
While investigating this, I found another issue; both are now fixed.
Richard, would be great if you could try again :-)
-Marshall
On 9/26/2017 6:33 AM, Richard Eckart de Castilho wrote:
> The fix in UIMA-5586 resolves various unit test failures in DKPro Core
> when building against UIMAv3.
>
> However, I still get the an NPE during deserialization in some cases when JCas
> is used and when a custom document annotation class is used. I
> have moved this to a separate issue:
>
> https://issues.apache.org/jira/browse/UIMA-5588
>
> Best,
>
> -- Richard
>
>> On 25.09.2017, at 19:18, Marshall Schor <ms...@schor.com> wrote:
>>
>> this is now fixed; additional testing much appreciated! -Marshall
>
Re: testing uv3 with dk-pro?
Posted by Richard Eckart de Castilho <re...@apache.org>.
The fix in UIMA-5586 resolves various unit test failures in DKPro Core
when building against UIMAv3.
However, I still get the an NPE during deserialization in some cases when JCas
is used and when a custom document annotation class is used. I
have moved this to a separate issue:
https://issues.apache.org/jira/browse/UIMA-5588
Best,
-- Richard
> On 25.09.2017, at 19:18, Marshall Schor <ms...@schor.com> wrote:
>
> this is now fixed; additional testing much appreciated! -Marshall
Re: testing uv3 with dk-pro?
Posted by Marshall Schor <ms...@schor.com>.
this is now fixed; additional testing much appreciated! -Marshall
On 9/25/2017 4:55 AM, Richard Eckart de Castilho wrote:
> I expect that most problems building DKPro Core against UIMA v3 can be resolved by addressing https://issues.apache.org/jira/browse/UIMA-5586 .
>
> Of course other things may crop up once that is done.
>
> Best,
>
> -- Richard
>
>> On 20.09.2017, at 19:05, Marshall Schor <ms...@schor.com> wrote:
>>
>> thanks! :-) -Marshall
>>
>>
>> On 9/20/2017 10:13 AM, Richard Eckart de Castilho wrote:
>>> I have adjusted DKPro Core for the removal of the ExtendedLogger in uimaFIT v3
>>> and try a new build now. I'll report back with comments once that is completed
>>> and diagnosed.
>>>
>>> Best,
>>>
>>> -- Richard
>
Re: testing uv3 with dk-pro?
Posted by Richard Eckart de Castilho <re...@apache.org>.
I expect that most problems building DKPro Core against UIMA v3 can be resolved by addressing https://issues.apache.org/jira/browse/UIMA-5586 .
Of course other things may crop up once that is done.
Best,
-- Richard
> On 20.09.2017, at 19:05, Marshall Schor <ms...@schor.com> wrote:
>
> thanks! :-) -Marshall
>
>
> On 9/20/2017 10:13 AM, Richard Eckart de Castilho wrote:
>> I have adjusted DKPro Core for the removal of the ExtendedLogger in uimaFIT v3
>> and try a new build now. I'll report back with comments once that is completed
>> and diagnosed.
>>
>> Best,
>>
>> -- Richard
Re: testing uv3 with dk-pro?
Posted by Marshall Schor <ms...@schor.com>.
thanks! :-) -Marshall
On 9/20/2017 10:13 AM, Richard Eckart de Castilho wrote:
> I have adjusted DKPro Core for the removal of the ExtendedLogger in uimaFIT v3
> and try a new build now. I'll report back with comments once that is completed
> and diagnosed.
>
> Best,
>
> -- Richard
>
>> On 19.09.2017, at 15:53, Marshall Schor <ms...@schor.com> wrote:
>>
>> 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 dk-pro?
Posted by Richard Eckart de Castilho <re...@apache.org>.
I have adjusted DKPro Core for the removal of the ExtendedLogger in uimaFIT v3
and try a new build now. I'll report back with comments once that is completed
and diagnosed.
Best,
-- Richard
> On 19.09.2017, at 15:53, Marshall Schor <ms...@schor.com> wrote:
>
> 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
>>
Re: testing uv3 with ...?
Posted by Peter Klügl <pe...@averbis.com>.
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
>