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
>>>
>
