You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@taverna.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2018/01/05 16:06:00 UTC
[jira] [Commented] (TAVERNA-1027) COMBINE parsing fails with
updated Jena - app URI scheme not supported
[ https://issues.apache.org/jira/browse/TAVERNA-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16313354#comment-16313354 ]
ASF GitHub Bot commented on TAVERNA-1027:
-----------------------------------------
GitHub user stain opened a pull request:
https://github.com/apache/incubator-taverna-language/pull/37
TAVERNA-1027: Use file:/// instead of app://{uuid}/ as base
This fixes [TAVERNA-1027](https://issues.apache.org/jira/browse/TAVERNA-1027) for COMBINE archive.
It does not seem like JSON-LD parsing of the .ro/manifest.json fails similarly although that also uses the app://{uuid}/ base.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/incubator-taverna-language TAVERNA-1027
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-taverna-language/pull/37.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #37
----
commit d9552b6e1fcdddf08fb3e99f6dda980d7fe95feb
Author: Stian Soiland-Reyes <st...@...>
Date: 2018-01-05T15:17:10Z
Json-LD test fix
commit cb45105e7be1ca53eae3818bdaf9c82968d3a0e4
Author: Stian Soiland-Reyes <st...@...>
Date: 2018-01-05T15:59:32Z
TAVERNA-1027: Avoid app:// for Jena
.. by making a fake file:/// URI instead without the UUID
As Jena would fail with ERR_RESOLVING_AGAINST_MALFORMED_BASE
not recognising app:// from https://www.w3.org/TR/app-uri/
as a valid URL scheme
----
> COMBINE parsing fails with updated Jena - app URI scheme not supported
> ----------------------------------------------------------------------
>
> Key: TAVERNA-1027
> URL: https://issues.apache.org/jira/browse/TAVERNA-1027
> Project: Apache Taverna
> Issue Type: Bug
> Components: Taverna Language
> Affects Versions: language 0.16.0
> Reporter: Stian Soiland-Reyes
> Assignee: Stian Soiland-Reyes
>
> I'm trying to update taverna-language to use Jena 3.6.0 (already updated in taverna-maven-parent 3-incubating-SNAPSHOT), but then taverna-robundle fails a test:
> "Resolving against bad URI <app:://4a8a0ff8-eab0-3930-8257-017dec3a8356/manifest0.xml>"
> This seems to be because Jena's IRI support now fails for non-IANA URI schemes like "app" when parsing RDF/XML - as within the COMBINE archive's metadata.
> In RO Bundle we use UUID-based [app: URL scheme|https://www.w3.org/TR/app-uri/] as specified by W3C to represent files within a Research Object zip archive.
> That means naturally when parsing RDF files within that archive that we'll use URIs like app://4a8a0ff8-eab0-3930-8257-017dec3a8356/manifest0.xml as a base URI, so that a reference "fred.doc" becomes "app://4a8a0ff8-eab0-3930-8257-017dec3a8356/fred.xml"
> A workaround would be to replace "app" with "file", pretending the UUID is a hostname, but somehow this also fails with Jena as it mangles "file://4a8a0ff8-eab0-3930-8257-017dec3a8356/fred.xml" into file:///4a8a0ff8-eab0-3930-8257-017dec3a8356/fred.xml after parsing - so it becomes tricky tyo ask the RDF model about fred.xml afterwards.
> A workaround to the workaround would be to use host-less file:/// URIs -- another to drop the UUID and pretend file:/// is the root of the local file system rather than the root of the zip archive. (This would also then correctly support relative URIs like /fred.xml although those don't occur in COMBINE archive)
> Stack trace:
> {code}
> Jan 05, 2018 3:45:58 PM org.apache.taverna.robundle.manifest.combine.CombineManifest findAnnotations
> WARNING: Can't parse /manifest0.xml
> org.apache.jena.riot.RiotException: [line: 3, col: 48] {E214} Resolving against bad URI <app://4a8a0ff8-eab0-3930-8257-017dec3a8356/manifest0.xml>: <./BorisEJB.xml>
> at org.apache.jena.riot.system.ErrorHandlerFactory$ErrorHandlerStd.error(ErrorHandlerFactory.java:140)
> at org.apache.jena.riot.lang.ReaderRIOTRDFXML$ErrorHandlerBridge.error(ReaderRIOTRDFXML.java:254)
> at org.apache.jena.rdfxml.xmlinput.impl.ARPSaxErrorHandler.error(ARPSaxErrorHandler.java:37)
> at org.apache.jena.rdfxml.xmlinput.impl.XMLHandler.warning(XMLHandler.java:196)
> at org.apache.jena.rdfxml.xmlinput.impl.XMLHandler.warning(XMLHandler.java:173)
> at org.apache.jena.rdfxml.xmlinput.impl.XMLHandler.warning(XMLHandler.java:168)
> at org.apache.jena.rdfxml.xmlinput.impl.XMLBaselessContext.checkBaseUse(XMLBaselessContext.java:108)
> at org.apache.jena.rdfxml.xmlinput.impl.AbsXMLContext.resolveAsURI(AbsXMLContext.java:131)
> at org.apache.jena.rdfxml.xmlinput.impl.AbsXMLContext.resolveAsURI(AbsXMLContext.java:123)
> at org.apache.jena.rdfxml.xmlinput.impl.URIReference.resolve(URIReference.java:166)
> at org.apache.jena.rdfxml.xmlinput.states.WantDescription.startElement(WantDescription.java:63)
> at org.apache.jena.rdfxml.xmlinput.impl.XMLHandler.startElement(XMLHandler.java:111)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
> at org.apache.xerces.impl.XMLNamespaceBinder.handleStartElement(Unknown Source)
> at org.apache.xerces.impl.XMLNamespaceBinder.startElement(Unknown Source)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
> at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
> at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
> at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at org.apache.jena.rdfxml.xmlinput.impl.RDFXMLParser.parse(RDFXMLParser.java:150)
> at org.apache.jena.rdfxml.xmlinput.ARP.load(ARP.java:118)
> at org.apache.jena.riot.lang.ReaderRIOTRDFXML.parse(ReaderRIOTRDFXML.java:135)
> at org.apache.jena.riot.lang.ReaderRIOTRDFXML.read(ReaderRIOTRDFXML.java:79)
> at org.apache.jena.riot.RDFParser.read(RDFParser.java:334)
> at org.apache.jena.riot.RDFParser.parseNotUri(RDFParser.java:324)
> at org.apache.jena.riot.RDFParser.parse(RDFParser.java:273)
> at org.apache.jena.riot.RDFParserBuilder.parse(RDFParserBuilder.java:498)
> at org.apache.jena.riot.RDFDataMgr.parseFromInputStream(RDFDataMgr.java:870)
> at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:268)
> at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:254)
> at org.apache.taverna.robundle.manifest.combine.CombineManifest.parseRDF(CombineManifest.java:240)
> at org.apache.taverna.robundle.manifest.combine.CombineManifest.findAnnotations(CombineManifest.java:332)
> at org.apache.taverna.robundle.manifest.combine.CombineManifest.readCombineArchive(CombineManifest.java:465)
> at org.apache.taverna.robundle.Bundle.readOrPopulateManifest(Bundle.java:121)
> at org.apache.taverna.robundle.Bundle.getManifest(Bundle.java:87)
> at org.apache.taverna.robundle.Bundle.close(Bundle.java:61)
> at org.apache.taverna.robundle.Bundle.close(Bundle.java:52)
> at org.apache.taverna.robundle.manifest.combine.TestCombineManifest.convertDirectoryMadnessZipped(TestCombineManifest.java:152)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)