Some SWORD updates

February 19, 2009

Being an aggregate of bits and pieces associated with the SWORD protocol: –

  • A quick note to clear up a common confusion I encountered last week at the JISC developer days: The JISC-funded project “SWORD2” led to the 1.3 version of the spec. There is no “SWORD 2.0” spec.
  • I’ve put my mercurial repository of the SWORD spec on bitbucket. This is mainly in the interests of transparency, rather than because I think anyone will be interested.
  • Mark Nottingham’s recent blog post on the evil of experimental HTTP headers points out that the headers we used in SWORD should be changed. We hadn’t read enough RFCs, clearly! I’m in the process of working out what needs to be done to register headers and change the spec in a back-compatible manner. As a result of this, I’ll probably create proposal to run the package type registry along the same lines as the IETF’s provisional header repositories.

Another SWORD draft

September 19, 2008

Another draft of the SWORD 1.3 spec. Mainly small revisions, and added explanation where needed. I think this is likely to be the working revision for the SWORD2 project.

Stuart Lewis on using the stackable authentication in DSpace to use Shibboleth to protect a SWORD interface.

Java Resource Listing

November 30, 2007

I’ve been working on a SWORD client for SPECTRa for the last day or so, and an got a little sidetracked into mavenizing the SWORD Java code, and further sidetracked into refactoring some of it as I went. Part of the SWORD code is jar including a CLI and a Swing GUI. Far maximum convenience the code and dependencies are assembled into a single jar (run using “java -jar …”).

The original author of the code, Neil Taylor (Aberystwyth) has been careful throughout the code to access all resources through the ClassLoader.getResource[AsStream] methods, through the InputStream and URL abstractions. So far so froody. There’s a wrinkle, though – the help system launches the user’s browser with the location of the help index file as an argument, and this is a limitation to the “everything in the jar file” approach – the code needs to executed from the correct pwd (or passed a parameter) for the help to display correctly.

Most (all?) web browsers are unable to understand the “jar:file:” protocol to get hold of the help pages directly from the jar. Well, I thought, that’s not a problem, I’ll copy the resources out of the jar into a tmp directory and point the browser there. Well, this would work fine, but I hit a snag – there’s no way to list, search for or glob resources through the ClassLoader. I’d have to have an explicit list of all the help resources, which would suck. Sam Adams suggested a solution he used for JNI-InChI: pull the jar file location out of the “jar:file:” URL, then use the java.util.jar.JarFile class to find the relevant entries.

It’s verbose and hacky (in a bad way), but it does allow you to have filesystem-like handling of resources and still distribute as a single executable jar, which is a good thing. Here’s the code, in all it’s filthy glory: –

ClassLoader cl = getClass().getClassLoader();
URL help = cl.getResource("help");
if ("file".equals(help.getProtocol())) {
File from = new File(help.toURI());
FileUtils.copyDirectory(from, helpDir);
} else if ("jar".equals(help.getProtocol())) {
// Strip between 'jar:file:'
String jarLoc = help.toString().substring(9,
File f = new File(jarLoc);
JarFile jarFile = new JarFile(jarLoc);
for (Enumeration entries = jarFile.entries();
entries.hasMoreElements();) {
JarEntry je = entries.nextElement();
if (je.getName().startsWith("help/")) {
// Trim the 'help/' off and fix up the file separators
String filename = je.getName().substring(5).replaceAll(
"/", File.separator);
File destination = new File(helpDir, filename);
File directory = je.isDirectory() ? destination
: destination.getParentFile();
log.debug("Creating " + directory
+ " and copying resource to " + destination);
if (!(directory.exists() || directory.mkdirs())) {
throw new IOException(
"Problem creating temp help directory, couldn't "
+"create:"+ directory);
if (!je.isDirectory()) {