WebDAV Construction Kit

(work in progress)

The WebDAV Construction Kit (WCK) was created by Oliver Zeigermann in response to Slide being too difficult to use. It is perfect for giving a generic application basic WebDAV functionality with both ease of use and some flexibility. This tutorial should give any developer the knowledge to create a dynamic file system that users access through WebDAV.

For a little more background information:



Feel free to make additions or corrections



Currently, WCK is only available from CVS. For more information on accessing Slide from CVS, check http://jakarta.apache.org/site/cvsindex.html The easiest way to get everything done on any platform (downloading from CVS, buidling from ant, etc...) is to use Eclipse IDE. (Tutorials for Eclipse can be found within Eclipse itself, inside its help menu.)

WCK works for Slide 2.1 and above. However since WCK is only available through CVS, it would be safer to assume that WCK is only compatible with the latest from CVS Head. (Hopefully for the 2.2 release, WCK will be included with the binaries to avoid this problem.)

Servlet Container and App Server Setup

Depending on your familiarity with the application server, this section can either be easy or very difficult. Hopefully, this information will ease some of the pain.

WckTomcat - This has information on setting up Tomcat 5 with WCK.

WckJetty - This has information on setting up Jetty 5 with WCK.

If you have successfully used Slide with JBoss, any other servlet container, or application server, please post some information it does not have to be formal and neat - anything is better than nothing.

WebDAV Client Issues

Mac OS X

The standard Mac OS X client will by default create meta files that start with "._". It will also try to create a '/Content' or '/Content/PkgInfo' directory.


Goliath will display ghost directories.

Windows XP


WCK essentially allows easy creation of a custom Slide Store class. In general a store class is responsible for displaying and storing files. Given this flexibility, you can store files in a variety of ways (database, regular file system, and so on) and have a consistent interface for which users to access these files.

Essential Interface to Implement

Any concrete store must implement the org.apache.slide.simple.store.BasicWebdavStore interface.

The following functions are basically all Slide and WCK need to make basic WebDAV operations work (you need to implement them).

* Important Note: Remember that Slide itself will be using your store to create its own system files (/roles, /users, and other folders and files). Therefore it would be wise to implement all of BasicWebdavStore's functions unless otherwise noted - even if your users will not be allowed to perform certain functions - such as creating new folders or deleting. Hint: when the system is using your store to create the files and directories it needs - the Principal parameter object is null.

As of Slide 2.1 these functions on Mac OS X, regardless of whether your store implements these functions correctly Slide will still return incorrect values regarding these file properties. However, do not be tempted to return a static value. While text files will be unaffected, other files like images may become corrupted when you retrieve the file.

This extension interface org.apache.slide.simple.authentication.SessionAuthenticationManager lets your system handle security (full property access and locking) and bypass Slide's built-in system.

You need to implement the following functions.

Here is a very simple example:

    public Object getAuthenticationSession(String loginId, String password)
         * make calls to your user database with your custom Data Access Object class and return the userid
        UserDAO userDAO = new UserDAO();
        UserBean userBean = userDAO.getUser(loginId);

        /* ensures that the given password matches what is stored in the database */
        if (userBean == null || password.trim() != userBean.getPassword().trim())
            /*failed authentication*/
            return null;
            /*ex brian:123456*/
            return userBean.getUserId() + StringUtil.COLON + userBean.getPassword();

org.apache.slide.simple.authentication.AbstractPoolingConnectionManager is a connection pool framework. You do not need to create an implementation of this class. You can easily use your app server's connection pool features and simply put the calls in other classes called by your custom store class.

However, if you do decide to implement a connection manager based on Slide code, you need to implement the following functions.

Domain.xml Configuration

There are some changes you have to make to the domain.xml file. For more information on this file see DomainConfig

<store name="simple">
    <parameter name="cache-mode">cluster</parameter>
    <nodestore classname="org.apache.slide.simple.store.WebdavStoreAdapter">
        <parameter name="callback-store">org.apache.slide.simple.reference.WebdavFileStore</parameter>
        <parameter name="rootpath">c:/tmp</parameter>

<nodestore classname="org.apache.slide.store.simple.WebdavStoreAdapter">

First the nodestore class reference must be changed to the above WebdavStoreAdapter class. This class will deal with most of Slide's extra calls that deal with locking, and so on.

<parameter name="callback-store">org.apache.slide.store.simple.WebdavFileStore</parameter>

The "callback-store" parameter value must point to your WebdavFileStore implementation (remember your class must implement the BasicWebdavStore interface - as shown above). Here the given WebdavFileStore reference store implementation. It is recommended that you analyze it.

Overring the slide.properties file

Depending on what you want to do, you may need to override the slide.properties file. For more details check the SlidePropertiesFile documentation.

Correct way to interoperate with Slide locks

Posted by Alessandro Apostoli to the Slide user list

I have a static Map to hold the lockids to be returned by getLockInfo(). Every call to lockObject() generates an exclusive lock on my proprietary system and stores the pair (uri,lockId) in the map for later retrieval, this for webdav locks only. Each call to getLockInfo() first checks if there is a lock in the proprietary system and if not it returns a SimpleLock[0] If the resource is locked it has to determine if it was locked via webdav or via proprietary interface so it checks if there's an entry in the map for that lock. If so it returns it, if there's no entry in the map and the resource is locked it has to generate a valid lockId, store it in the map for subsequent calls to getLockInfo() and return it. My system supports only one lock per resource so the key in my map is the uri, I also used the uri to generate the lockId string with a call to DigestUtils.md5Hex(uri). As one might expect a call to unlockObject() removes the entry from the map and unlocks the resource.

WebDavConstructionKit (last edited 2009-09-20 22:02:46 by localhost)