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