Jersey WebDAV Support

Skip to end of metadata
Go to start of metadata

This page assembles information about Jersey's WebDAV Support.

Abstract

Besides being the reference implementation (RI) of JAX-RS, Jersey also comes with several additional features not covered by this standard. One of these features is core support for the WebDAV protocol.

What is it good for?

Using Jersey's WebDAV support, it is pretty easy to implement a WebDAV based RESTful WebService (instead of "just" a HTTP based RESTful WebService). There are two main aspects: (1) Using WebDAV instead of HTTP allows to provide a lot of cool features, like using a RESTful WebService like a File System (e. g. using WebDAV based file systems), or like using pessimistic locking where HTTP only provides proprietary client applications or web browsers to access the service and provides "only" optimistic locking. See the WebDAV specification at ietf.org to learn more about WebDAV's features above HTTP's. (2) Writing a WebDAV service is hard work, since WebDAV is complex. Jersey's supporting code makes it easier, since it provides a lot of prebuild WebDAV building Blocks, e. g. JAXB classes that make it easy to read and write all of WebDAV's special HTTP bodies. It's not a complete WebDAV server, but it is a collection of useful bricks to build one – just like Jersey is not a WebServer but a collection of bricks to build one.

Who did it?

The initial WebDAV contribution (the core code) was provided by Markus KARG (karg@users.java.net, see http://www.headcrashing.eu/projects.html) in December 2008. He currently is in charge of coordinating this contribution project, which can be found on http://webdav.java.net.

Many thanks to Daniel MANZKE for providing a lot of useful patches and input and contributing samples and the interop filters (http://java.net/projects/webdav-interop). Also thanks to Julian RESCHKE, Marc HADLEY and last but not least Paul SANDOZ for answering all of my silly questions and discussing lots of implementation and conceptional details with me. Also thanks for Craig McCLANAHAN for being part of this team.

How does it work?

The solution contains the following parts:

  • JAXB classes for all the XML elements and properties defined in RFC 4918 (see http://www.ietf.org/rfc/rfc4918.txt). These can be used directly as parameters or return types with Jersey methods, so implementing e. g. PROPFIND becomes rather simple. No need to deal with String concatenation, SAX or DOM.
  • WebDAV specific response codes as predefined constants. These provide clearly to read names instead of ambiguous numbers.
  • WebDAV specific HTTP headers as predefined constants. Using those prevents typos.
  • An interoperability filter providing compatibility to Microsoft's WebDAV clients.
Does it support WebDAV's extensibility?

Yes, even the first draft of the initial contribution already comes with full support for custom properties. There is a sample included that shows how custom properties can be used together with and inexactly in the same way as standard properties.

Are there any samples?

Yes, you can find two samples on http://java.net/projects/webdav-addressbook and http://java.net/projects/webdav-fileserver showing different types of services: The first one uses JPA to look into a database, the second one turns any local folder into a WebDAV file server.

Where are the unit tests?

There are no unit tests yet. If somebody wants to volunteer on that, please write to Markus KARG (mkarg@users.java.net). We really appreciate your help.

Where to get it? / Current Status and Development Schedule / Where to get more information?
Is this used in the real world?

Yes, there are several companies using this in the real world. For example EADS.

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.