[TAVERNA-971] jarcache not working through OSGi

• Type: Bug
• Status: Done
• Priority: Major
• Resolution: Done
• Affects Version/s: language 0.15.1, command-line 3.1.0
• Fix Version/s: command-line 3.1.0, language 0.16.0
• Component/s: Taverna Language
• Assignee: Stian Soiland-Reyes
• Reporter: Stian Soiland-Reyes
• Created: 26/May/16 15:32
• Updated: 26/May/16 15:55
• Resolved: 26/May/16 15:55

Description

taverna-robundle includes a jarcache.json which specifies contexts/bundle.jsonld to be loaded from the taverna-robundle JAR instead of from https://w3id.org/bundle/context.json

This uses JSONLD-Java's JAR cache - in order to avoiding network access when parsing the manifest JSON-LD of the robundle.

This does however not work well under OSGi with the Taverna Command Line, as the jarcache within the jsonld-java OSGi bundle can't access /jarcache.json in the taverna-robundle OSGi bundle - at least not without setting Thread.currentThread.setContextClassLoader().

This caused running of the workflow to fail with a large stack trace at the point of closing the data bundle (this happen with or without -bundle)

Note that using Jena 3.1.0 and OpenJDK on Ubuntu, access to https://w3id.org/bundle/context.json fails with an "internal error" SSL error, so even with network access it can fail.

Note that in Taverna Language 0.15.1 there was also a bug that when adding the Apache header to the bundle.json an extra } was added - this worked with earlier versions of Jackson/JSONLD-Java but now after TAVERNA-970 upgrades this fails - thus for the Command Line 3.1.0 I propose a workaround to add a fixed bundle.json on its own classpath, and then set the thread context loader to its own classloader while running the workflow.

The fix for robundle 0.16.0 would be to set the thread class loader before parsing the manifest.json.

(Thus we can fix it properly for next Taverna Language, but can ship Command Line 3.1.0 with existing Language 0.15.1)