Tag Archives: Java

Java WebDAV Clients

I have been looking into using WebDAV as the core of a new solution I am working on. I needed centralized, content management style, read and write access to documents from multiple servers. WebDAV interested me because users could easily access these documents using external tools.

The application I am working on is written in Java so I went searching for an open-source WebDAV server and client library. There were a number of options for WebDAV servers:

1) Slide – http://jakarta.apache.org/slide/
This project was one of the primary WebDAV implementations in Java but has been retired as of Nov 3, 2007.
2) JackRabbit – http://jackrabbit.apache.org/
JackRabbit is a JSR170 Java Content Repository. It also provides access to its content through WebDAV.
3) Tomcat – http://tomcat.apache.org/
Tomcat has a WebDAV servlet that can be used to read and write web application content.

Options for a WebDAV client were a little bit more limited. Jakarta Slide had been the primary WebDAV client which was used in may other open source projects. Since it had been retired, I was looking for alternatives. Here is a message posted on the slide mailing list that mentions JackRabbit as the most suitable alternative.

The Apache Jakarta PMC is sorry to announce the retirementof the
Jakarta Slide subproject. After it's last release inDecember 2004,
development activity was significantly reducedand came to a total
standstill this year. Without a minimumdeveloper community that
can release security fixes, we haveno choice but to retire Slide.
We'll keep at least one ofthe mailing lists open for a transition
period, so users candiscuss alternatives and migration away from
Slide. Furtheruse of the Slide codebase is discouraged.

One alternative to Slide is provided by the Apache Jackrabbit
project. Jackrabbit has a healthy, active developer communityand
provides, among others things:- a server-side content repository-
a WebDAV server component for access to the repository- a WebDAV
client componentPlease visit http://jackrabbit.apache.org/ for
more information.

We apologize for the inconveniences.

Roland Weber

The problem is that JackRabbit does not currently have a WebDAV client component. JackRabbit focuses on the Java Content Repository specification and provides WebDAV as a server option. The following post from the mailing list explains.

Re: Webdav Client Examples?


by Angela Schreiber Nov 20, 2007; 04:45am

Jukka Zitting wrote:
> Hi,
> On Nov 14, 2007 11:26 AM, ossi petz <ossipetz@…> wrote:
>> Has anyone made some examples on how to use HttpClient with the
>> Jackrabbit Webdav Client?

there is an example in the sandbox/spi/spi2dav project.

> Not really. The WebDAV support in Jackrabbit is more focused on
> server-side implementations than clients.

> The best there is for clients is a collection of WebDAV method classes
> in the jackrabbitwebdav component.

… which are only waiting for somebody having time to put them
together to a complete dav client :).



When Apache retired the Slide project, they unknowingly retired the primary Java WebDAV client implementation. The folks in Apache must not have communicated with the JackRabbit team to ensure that it would be able to fill the hole that slide left. I continued my quest to find alternative WebDAV clients in Java.

Eclipse used to have a WebDAV client that was used for Team support. This was an extension available for Eclipse 3.2 and earlier called “WebDAV and FTP Support“. This project is no longer being maintained since 3.3 because of the new Eclipse FileSystem. The EFS (Eclipse FileSystem) was a new API for interacting with different file systems. The EFS implementation for WebDAV has not yet been completed. I stumbled upon a new project with Google’s Summer of Code to create an WebDAV EFS implementation. This is a note from that page.

Eclipse’s webdav client hasn’t been worked on for 2 years and has many shortcomings. The Jakarta Slide Webdav client (http://jakarta.apache.org/slide/webdav-client.html) is an actively maintained project.

I found it quite entertaining how Eclipse chose to use Slide as the client implementation because it was “actively maintained”. In reality the slide project had not been updated in years. It may be better than the old eclipse implementation, but it was far from actively maintained. I wonder what will happen with this project once they find out that Slide is no longer being developed.

I also found a few other projects that provide WebDAV access. These also use the slide client to provide their WebDAV functionality.

Maven Wagon – http://maven.apache.org/wagon/wagon-providers/wagon-webdav/
Apache Commons VFS – http://commons.apache.org/vfs/filesystems.html

After all of my investigation, it seems that Slide is still the best (or only) option for open source WebDAV clients even though the project is no longer being maintained.

I hope that the old slide client will eventually become an Apache Commons WebDAV client or maybe be incorporated into the HTTPClient project.

Agile Dynamic Languages for Java

There has been a lot of buzz about Ruby in recent days, particularly around Ruby on Rails. I love these Ruby on Rails vs. X commercials that www.railsenvy.com has created. Rails provides a much better framework for the “web backed by a database” problem than anything I have seen in the pure Java world. Java has become a very bloated language and even the so-called “lightweight” frameworks are large and clunky. Rails is a great alternative for most people.

But not for everyone. I work mostly with Java based server applications that do not fit the “web backed by a database” type of project. These applications could benefit from the Ruby language itself, but not much from Rails. I have looked into using JRuby as a way to leverage the strengths of the Ruby language on the Java platform.

JRuby is a Ruby interpreter written 100% in Java and therefore runs on the JVM. It allows you to have the benefits of Ruby but still be able to use existing Java code. My main issue with this implementation is that it does not inter operate well with Java. Code written for JRuby typically use the Ruby libraries which work distinctly different from their Java counterparts. This makes it difficult to create a hybrid application where both Ruby and Java is used.

This is about the time I found the Groovy project. Groovy is “an agile dynamic language for the Java Platform” (http://groovy.codehaus.org). It is a powerful dynamic language that has many of the sought after features of other languages like Ruby and Python. The key difference here is that Java is a first class citizen in Groovy. The Groovy libraries are built on top of Java, extending and modifying the core API. Groovy makes creating a hybrid Groovy/Java application possible and easy.

For those coming from a Java background, Groovy is very easy to learn. The syntax is very similar to Java with a twist. Semicolons are not required, getters and setters are not required for properties, code closures are available and metaprogramming is possible. If you are looking for Rails, there is Grails which is a web framework for Groovy.

So if you long to wet your feet in an agile dynamic language like Ruby but are stuck with supporting legacy Java applications, I would recommend giving Groovy a try.

URL Based HTTP Authentication

I ran into a situation the other day where I needed to connect to a remote Web server from a server side application. This web server requires HTTP authentication. The user sets the Web Server location from a configuration file.

What I wanted to be able to do was have the user enter the URL in the following format:

The plan was to use Java’s URL connection library to make my connection to the website. I figured that the default implementation of the URL authentication would allow the user name and password to be supplied as part of the URL. To my surprise, I was greeted with a “401 Unauthorized” message.

The way to provide HTTP based authentication in Java is using the java.net.Authenticator mechanism. Java 5 provides a new method on the Authenticator called getRequestingURL(). This allows access to the URL that requested the authentication. By using this method, an Authenticator can get access to the user name and password embedded in the URL.

So, I created a simple Authenticator that uses the Apache Commons HTTPClient to parse the URL and pull out the authentication information.

Here is the code:

public class HTTPAuthenticator extends Authenticator {
    protected PasswordAuthentication getPasswordAuthentication() {
       if (!getRequestingProtocol().equals("http") &&
               !getRequestingProtocol().equals("https")) {
           return null;
       }       URL url = getRequestingURL();
       try {
           // Get the Username and password from the URL
           HttpURL httpUrl = new HttpURL(url.toString());
           String username = httpUrl.getUser();
           char[] password = httpUrl.getRawPassword();
           if (username == null || password == null) {
               return null;
           return new PasswordAuthentication(username, password);
       catch (Exception e) {
           return null;
    public void init() {