Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

SWORD 2.0 Server

This server library is an implementation of the SWORD 2.0 standard defined here

Use Maven Central Version

Include this dependency into your pom.xml to obtain the 1.0 release version of this software



To build this library use maven 2:

mvn clean package

In the root directory will build the software


This library provides a layer between the implementer's software and the web API provided by SWORDv2. There are two distinct tasks for the implementer when using this library:

Implementing functionality through interfaces

The library converts web API requests into objects, and passes them to implementations of interfaces which it provides. The interfaces that must be implemented are:

  • CollectionDepositManager - this contains the method signatures required to create a new item on the server
  • CollectionListMnager - this contains the method signatures required to list the contents of a collection
  • ContainerManager - this contains the method signatures for retrieving and updating an existing object on the server
  • MediaResourceManager - this contains the method signatures for retrieving and updating the content within a Container on the server
  • ServiceDocumentManager - this contains the method signatures for retrieving service documents from the server
  • StatementManager - this contains the method signatures for retrieving Statement objects from the server

In addition, the library takes its configuration from the interface:


If no implementation of the configuration is provided, implementers can use the default, which provides a basic set of config options:


Binding the server library's API to your servlet container

In order to have the server respond to web requests, and call the appropriate implementations, it is necessary to either use the standard servlets which come bundled with the library, or to write your own.

Most of the work of the library is done in classes which end with API, such as ServiceDocumentAPI. Requests are routed to the relevant API handler by servlets whose only task is to respond to HTTP requests by loading the relevant server implementation of the *Manager interfaces, and routing the HTTP request to the relevant method of the *API object. This means that implementers are free to write their UI/URL space as they choose, by overriding the standard servlets as necessary.

Standard servlets

These can be found in org.swordapp.server.servlets


Each of these implements the relevant doGet, doPost, doPut or doDelete HTTP methods, loads the relevant *Manager implementations (see above), and routes requests into the web API handlers in the library. For example:

GET on ServiceDocument-IRI -> ServiceDocumentServletDefault.doGet() 
    -> ServiceDocumentAPI.get() 
    -> ServiceDocumentManagerImpl.getServiceDocument()

Custom servlets

If the standard servlets do not fit your requirements for your URL space or the way in which you want to present SWORD to your users, they can be replaced. Their only job is to load your *Manager implementations and pass the requests to the *API objects. The *API objects reflect exactly the requirements of the SWORD specification so failure to call them correctly will result in incompatibility with the specification. Implementers should therefore be sure to invoke the correct API calls when routing from custom servlets. It is recommended to use the dfault servlets as a reference.

web.xml for deploying servlets

The library includes an example web.xml for your webapp in


It shows how to configure your implementations of the *Manager interfaces for use in the default servlets (if you have implemented your own servlets, this may differ):

        The ServiceDocumentManager server implementation class name

We load the implementation as a context parameter in the webapp, which the default servlets then load from the context environment.

We can then bind the servlet implementations by declaring them:


And then mapping them to the URL space:


Once this has been done, the the *Manager interfaces implemented, you are good to go with using SWORDv2!


Java server library for supporting integration with SWORDv2







No packages published