The ModeShape WebDAV server is deployed as a WAR and configured mostly through its web configuration file (web.xml). Here is an example web configuration that is used for integration testing of the ModeShape WebDAV server along with an explanation of its parts.

<?xml version="1.0"?>

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"

                         "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

    <display-name>ModeShape JCR RESTful Interface</display-name>

This first section is largely boilerplate and should look familiar to anyone who has deployed a servlet-based application before. The display-name can be customized, of course.

The next stanza configures the repository provider.

  <!--

    This parameter provides the fully-qualified name of a class that implements

    the o.m.web.jcr.spi.RepositoryProvider interface.  It is required

    by the ModeShapeJcrDeployer that controls the lifecycle for the ModeShape WebDAV server.

  -->

  <context-param>

    <param-name>org.modeshape.web.jcr.REPOSITORY_PROVIDER</param-name>

    <param-value>org.modeshape.web.jcr.spi.ModeShapeJcrRepositoryProvider</param-value>

  </context-param>

As noted above, this parameter informs the ModeShapeJcrDeployer of the specific repository provider in use. Unless you are using the ModeShape WebDAV server to connect to a different JCR implementation, this should never change. The ModeShape REST server also uses the ModeShapeJcrDeployer to get access to the JCR repository, so the two servlets can be deployed in the same WAR.

Next we configure the ModeShape JcrEngine itself.

  <!--

    This parameter, specific to the ModeShapeJcrRepositoryProvider implementation, specifies

    the name of the configuration file to initialize the repository or repositories.

    This configuration file must be on the classpath and is given as a classpath-relative

    directory.

  -->

  <context-param>

    <param-name>org.modeshape.web.jcr.CONFIG_FILE</param-name>

    <param-value>/configRepository.xml</param-value>

  </context-param>

If you are not familiar with the file format for a JcrEngine configuration file, you can build one programatically with the JcrConfiguration class and call save(...) instead of build() to output the configuration file that equates to the configuration.

This is followed by some additional WebDAV configuration that controls the mapping between JCR node types and WebDAV files and resources. You can omit this section entirely to use the default values.

<!--

    Nodes with any of the primary node types in this comma-delimited list will be treated by the 

    WebDAV implementation as content nodes.  The value below is the default value for this 

    parameter.  That is, if this init parameter is omitted, the value below will be used by default.

-->

<context-param>

    <param-name>org.modeshape.web.jcr.webdav.CONTENT_PRIMARY_TYPE_NAMES</param-name>

    <param-value>nt:resource, mode:resource</param-value>

</context-param>



<!--

    Nodes with any of the primary node types in this comma-delimited list will be treated by the 

    WebDAV implementation as resource (file) nodes.  The value below is the default value for this 

    parameter.  That is, if this init parameter is omitted, the value below will be used by default.

-->

<context-param>

    <param-name>org.modeshape.web.jcr.webdav.RESOURCE_PRIMARY_TYPE_NAMES</param-name>

    <param-value>nt:file</param-value>

</context-param>



<!--

    Each folder created through the WebDAV servlet will be created as a node with the primary node 

    type below.  The value below is the default value for this parameter.  That is, if this init 

    parameter is omitted, the value below will be used by default.

-->

<context-param>

    <param-name>org.modeshape.web.jcr.webdav.NEW_FOLDER_PRIMARY_TYPE_NAME</param-name>

    <param-value>nt:folder</param-value>

</context-param>



<!--

    Each resource (file created through the WebDAV servlet will be created as a node with the primary 

    node type below.  The value below is the default value for this parameter.  That is, if this init 

    parameter is omitted, the value below will be used by default.

-->

<context-param>

    <param-name>

        org.modeshape.web.jcr.webdav.NEW_RESOURCE_PRIMARY_TYPE_NAME

    </param-name>

    <param-value>nt:file</param-value>

</context-param>



<!--

    Content created through the WebDAV servlet will be created as a node with the primary node 

    type below.  The value below is the default value for this parameter.  That is, if this init 

    parameter is omitted, the value below will be used by default.

-->

<context-param>

    <param-name>

        org.modeshape.web.jcr.webdav.NEW_CONTENT_PRIMARY_TYPE_NAME

    </param-name>

    <param-value>mode:resource</param-value>

</context-param>

In general, this part of the web configuration file should not be modified.

Next, the RequestResolver must be configured. The RequestResolver converts the incoming URI into a repository name, workspace name, and path within the repository. It is possible (and easy) to develop a custom implementation of this interface, but a default resolver is provided that maps all URIs directly into a repository and workspace.

<!--

    This optional parameter provides the name of the o.m.w.j.webdav.RequestResolver

    implementation class.  The provided value must be the name of a class that 

    implements the RequestResolver interface and has a public, no-arg constructor.

    If no value is provided, o.m.w.j.webdav.DefaultRequestResolver will be used.

-->

<context-param>

    <param-name>org.modeshape.web.jcr.webdav.REQUEST_RESOLVER_CLASS_NAME</param-name>

    <param-value>org.modeshape.web.jcr.webdav.DefaultRequestResolver</param-value>

</context-param>



<!--

    This parameter is required if (and only if) the DefaultRequestResolver is used.

    It provides the name of the JCR repository that will be accessed.  An exception

    will be thrown if no value is provided for this parameter.

-->

<context-param>

    <param-name>

        org.modeshape.web.jcr.webdav.DEFAULT_RESOLVER_REPOSITORY_NAME

    </param-name>

    <param-value>mode:repository</param-value>

</context-param>



<!--

    This parameter is required if (and only if) the DefaultRequestResolver is used.

    It provides the name of the JCR workspace that will be accessed.  An exception

    will be thrown if no value is provided for this parameter.

-->

<context-param>

    <param-name>

        org.modeshape.web.jcr.webdav.DEFAULT_RESOLVER_WORKSPACE_NAME

    </param-name>

    <param-value>default</param-value>

</context-param>

Another brief section of boilerplate ensues.

<!-- Required parameter for ModeShape WebDAV - should not be modified -->

<listener>

    <listener-class>org.modeshape.web.jcr.ModeShapeJcrDeployer</listener-class>

</listener>



<!-- Required WebDAV servlet - should not be modified -->

<servlet>

    <servlet-name>WebDAV</servlet-name>

    <servlet-class>org.modeshape.web.jcr.webdav.ModeShapeWebdavServlet</servlet-class>

    

    <!--

        The webdav library requires this parameter to be present, but does not use it.

    -->

    <init-param>

        <param-name>rootpath</param-name>

        <param-value>.</param-value>

    </init-param>

</servlet>



<!-- Required parameter for ModeShape WebDAV - should not be modified -->

<servlet-mapping>

    <servlet-name>WebDAV</servlet-name>

    <url-pattern>/*</url-pattern>

</servlet-mapping>

Finally, security must be configured for the WebDAV server.

    <!-- 

        The ModeShape WebDAV implementation leverages the HTTP credentials to for authentication 

        and authorization within the JCR repository.  Unless the repository provides for anonymous 

        access, it makes no sense to try to log into the JCR repository without credentials, so 

        this constraint helps lock down the repository.

        

        This should generally not be modified. 

    -->

    <security-constraint>

        <display-name>ModeShape WebDAV</display-name>

        <web-resource-collection>

            <web-resource-name>WebDAV</web-resource-name>

            <url-pattern>/*</url-pattern>

        </web-resource-collection>

        <auth-constraint>

            <!--  

                A user must be assigned this role to connect to any JCR repository, in addition to 

                needing the READONLY or READWRITE roles to actually read or modify the data.  This 

                is not used internally, so another role could be substituted here.

            -->

            <role-name>connect</role-name>

        </auth-constraint>

    </security-constraint>



    <!--  

        Any auth-method will work for ModeShape.  BASIC is used this example for simplicity.

     -->

    <login-config>

        <auth-method>BASIC</auth-method>

    </login-config>



    <!-- 

        This must match the role-name in the auth-constraint above. 

     -->

    <security-role>

        <role-name>connect</role-name>

    </security-role>

</web-app>

As noted above, the WebDAV server will not function properly unless security is configured. All authorization methods supported by the Servlet specification are supported by ModeShape and can be used interchangeable, as long as authenticated users have the connect role listed above.

Deploying the ModeShape WebDAV server only requires three steps: preparing the web configuration, configuring the users and their roles in your web container (outside the scope of this document), and assembling the WAR. This section describes the requirements for assembling the WAR.

If you are using Maven to build your projects, the WAR can be built from a POM. Here is a portion of the POM used to build the ModeShape WebDAV Server integration subproject.

<project xmlns="http://maven.apache.org/POM/4.0.0" 

     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <parent>

        <artifactId>modeshape</artifactId>

        <groupId>org.modeshape</groupId>

        <version>1.1</version>

        <relativePath>../..</relativePath>

    </parent>

    <artifactId>modeshape-web-jcr-webdav-war</artifactId>

    <packaging>war</packaging>

    <name>ModeShape JCR WebDAV Servlet</name>

    <description>ModeShape servlet that provides WebDAV access to JCR items</description>

    <url>http://www.modeshape.org</url>

    <dependencies>

        <dependency>

            <groupId>org.modeshape</groupId>

            <artifactId>modeshape-web-jcr-webdav</artifactId>

            <version>${project.version}</version>

        </dependency>



        <dependency>

            <groupId>org.slf4j</groupId>

            <artifactId>slf4j-log4j12</artifactId>

            <version>1.5.8</version>

            <scope>runtime</scope>

        </dependency>

    </dependencies>

</project>

If you use this approach, make sure that web configuration file is in the /src/main/webapp/WEB-INF directory.

Of course, the JBoss WebDAV Server WAR can still be built if you are not using Maven. Simply construct a WAR with the following contents:

+ /WEB-INF
	+ /classes
	|	+ configRepository.xml
	|	+ log4j.properties (Optional)
	+ /lib
	|	+ activation-1.1.jar
	|	+ aperture-1.1.0.Beta1.jar
	|	+ google-collections-1.0.jar
	|	+ hamcrest-core-1.1.jar
	|	+ jakarta-regexp-1.4.jar
	|	+ jaxb-api-2.1.jar
	|	+ jaxb-impl-2.1.12.jar
	|	+ jcip-annotations-1.0.jar
	|	+ jcr-1.0.1.jar
	|	+ joda-time-1.6.jar
	|	+ junit-dep-4.4.jar
	|	+ lucene-analyzers-3.0.0.jar
	|	+ lucene-core-3.0.0.jar
	|	+ lucene-regex-3.0.0.jar
	|	+ lucene-snowball-3.0.0.jar
	|	+ modeshape-cnd-1.1.jar
	|	+ modeshape-common-1.1.jar
	|	+ modeshape-graph-1.1.jar
	|	+ modeshape-jcr-1.1.jar
	|	+ modeshape-mimetype-detector-aperture-1.1.jar
	|	+ modeshape-repository-1.1.jar
	|	+ modeshape-search-lucene-1.1.jar
	|	+ modeshape-web-jcr-1.1.jar
	|	+ modeshape-web-jcr-webdav-1.1.jar
	|	+ rdf2go.api-4.6.2.jar
	|	+ slf4j-api-1.5.8.jar
	|	+ slf4j-log4j12-1.5.8.jar
	|	+ stax-api-1.0-2.jar
	|	+ webdav-servlet-2.0.jar
	+ web.xml
			

If you are using sequencers or any connectors other than the in-memory or federated connector, you will also have to add the JARs for those dependencies into the WEB-INF/lib directory as well. You will also have to change the version numbers on the JARs to reflect the current version of ModeShape.

This WAR can be deployed into your servlet container.

The REST Server currently supports the URIs and HTTP methods described below. The URI patterns assume that the REST server is deployed at its conventional location of "/resources". These URI patterns would change if the REST server were deployed under a different web context and URI patterns below would change accordingly. Currently, only JSON-encoded responses are provided.

GET http://www.example.com/resources

{
	"modeshape%3arepository" : { 
		"repository" : {
			"name" : "modeshape%3arepository",
			"resources" : { "workspaces":"/resources/modeshape%3arepository" }
		}
	}
}

GET http://www.example.com/resources/modeshape%3arepository

This request (and all of the following requests) actually create a JCR Session to service the request and require that security be configured. This process is described in more detail in a later section. Assuming that security has been properly configured, the response would look something like this:

{
	"default" : {
		"workspace" : {
			"name" : "default",
			"resources" : { "items":"/resources/modeshape%3arepository/default/items" }
		}
	}
}

Like the first response, this response consists of a list of workspace names mapped to metadata about the workspaces. The example above only lists one workspace for simplicity, but there could be many different workspaces returned in a real deployment. Note that the "items" resource builds the full URI to the root of the items hierarchy, including the encoding of the repository name and the workspace name.

Now a request can be built to retrieve the root item of the repository.

GET http://www.example.com/resources/modeshape%3arepository/default/items

Any other item in the repository could be accessed by appending its path to the URI above. In a default repository with no content, this would return the following response:

{
	"properties": {
		"jcr:primaryType": "mode:root",
		"jcr:uuid": "97d7e2ef-996e-4d99-8ec2-dc623e6c2239"
	},
	"children": ["jcr:system"]

The response contains a mapping of property names to their values and an array of child names. Had one of the properties been multi-valued, the values for that property would have been provided as an array as well, as will shortly be shown.

The items resource also contains an option query parameter: mode:depth. This parameter, which defaults to 1, controls how deep the hierarchy of returned nodes should be. Had the request had the parameter:

GET http://www.example.com/resources/modeshape%3arepository/default/items?mode:depth=2

Then the response would have contained details for the children of the root node as well.

{
	"properties": {
		"jcr:primaryType": "mode:root",
		"jcr:uuid": "163bc5e5-3b57-4e63-b2ae-ededf43d3445"
	},
	"children": {
		"jcr:system": {
			"properties": {"jcr:primaryType": "mode:system"},
    		"children": ["mode:namespaces"]
		}
	}
}

It is also possible to use the RESTful API to add, modify and remove repository content. Removes are simple - a DELETE request with no body returns a response with no body.

DELETE http://www.example.com/resources/modeshape%3arepository/default/items/path/to/deletedNode

Adding content simply requires a POST to the name of the relative root node of the content that you wish to add and a request body in the same format as the response from a GET. Adding multiple nodes at once is supported, as shown below.

POST http://www.example.com/resources/modeshape%3arepository/default/items/newNode

{
	"properties": {
		"jcr:primaryType": "nt:unstructured",
		"jcr:mixinTypes": "mix:referenceable",
		"someProperty": "foo"
	},
	"children": {
		"newChildNode": {
			"properties": {"jcr:primaryType": "nt:unstructured"}
		}
	}
}

Note that protected properties like jcr:uuid are not provided but that the primary type and mixin types are provided as properties. The REST server will translate these into the appropriate calls behind the scenes. The response from the request will be empty by convention.

The PUT method allows for updates of nodes and properties. If the URI points to a property, the body of the request should be the new JSON-encoded value for the property, which includes the property name (allowing proper determination of whether the values are binary; see the next section"").

PUT http://www.example.com/resources/modeshape%3arepository/default/items/newNode/someProperty

{
	"someProperty" : "bar"
}

Setting multiple properties at once can be performed by providing a URI to a node instead of a property. The body of the request should then be a JSON object that maps property names to their new values.

PUT http://www.example.com/resources/modeshape%3arepository/default/items/newNode

{
	"someProperty": "foobar",
	"someOtherProperty": "newValue"
}

{
	"properties": {
		"jcr:primaryType": "nt:unstructured",
		"jcr:uuid": "163bc5e5-3b57-4e63-b2ae-ededf43d3445"
		"options": [ "1", "2" ]
		"content/base64/": 
	"TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz
IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg
dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu
dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo
ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4="
	},
}

The ModeShape REST server is deployed as a WAR and configured mostly through its web configuration file (web.xml). Here is an example web configuration that is used for integration testing of the ModeShape REST server along with an explanation of its parts.

<?xml version="1.0"?>

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"

                         "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

  <display-name>ModeShape JCR RESTful Interface</display-name>

This first section is largely boilerplate and should look familiar to anyone who has deployed a servlet-based application before. The display-name can be customized, of course.

The next stanza configures the repository provider.

  <!--

    This parameter provides the fully-qualified name of a class that implements

    the o.m.web.jcr.spi.RepositoryProvider interface.  It is required

    by the ModeShapeJcrDeployer that controls the lifecycle for the ModeShape REST server.

  -->

  <context-param>

    <param-name>org.modeshape.web.jcr.REPOSITORY_PROVIDER</param-name>

    <param-value>org.modeshape.web.jcr.spi.ModeShapeJcrRepositoryProvider</param-value>

  </context-param>

As noted above, this parameter informs the ModeShapeJcrDeployer of the specific repository provider in use. Unless you are using the ModeShape REST server to connect to a different JCR implementation, this should never change.

Next we configure the ModeShape JcrEngine itself.

  <!--

    This parameter, specific to the ModeShapeJcrRepositoryProvider implementation, specifies

    the name of the configuration file to initialize the repository or repositories.

    This configuration file must be on the classpath and is given as a classpath-relative

    directory.

  -->

  <context-param>

    <param-name>org.modeshape.web.jcr.CONFIG_FILE</param-name>

    <param-value>/configRepository.xml</param-value>

  </context-param>

If you are not familiar with the file format for a JcrEngine configuration file, you can build one programatically with the JcrConfiguration class and call save(...) instead of build() to output the configuration file that equates to the configuration.

This is followed by a bit of RESTEasy and JAX-RS boilerplate.

  <!--

    This parameter defines the JAX-RS application class, which is really just a metadata class

    that lets the JAX-RS engine (RESTEasy in this case) know which classes implement pieces

    of the JAX-RS specification like exception handling and resource serving.

        

    This should not be modified. 

  -->

  <context-param>

    <param-name>javax.ws.rs.Application</param-name>

    <param-value>org.modeshape.web.jcr.rest.JcrApplication</param-value>

  </context-param>



  <!-- Required parameter for RESTEasy - should not be modified -->

  <listener>

    <listener-class>org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap</listener-class>

  </listener>



  <!-- Required parameter for ModeShape REST - should not be modified -->

  <listener>

    <listener-class>org.modeshape.web.jcr.ModeShapeJcrDeployer</listener-class>

  </listener>



  <!-- Required parameter for RESTEasy - should not be modified -->

  <servlet>

    <servlet-name>Resteasy</servlet-name>

    <servlet-class>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher</servlet-class>

  </servlet>



  <!-- Required parameter for ModeShape REST - should not be modified -->

  <servlet-mapping>

    <servlet-name>Resteasy</servlet-name>

    <url-pattern>/*</url-pattern>

  </servlet-mapping>

In general, this part of the web configuration file should not be modified.

Finally, security must be configured for the REST server.

  <!-- 

    The ModeShape REST implementation leverages the HTTP credentials to for authentication and 

    authorization within the JCR repository.  It makes no sense to try to log into the JCR 

    repository without credentials, so this constraint helps lock down the repository.

        

    This should generally not be modified. 

  -->

  <security-constraint>

    <display-name>ModeShape REST</display-name>

    <web-resource-collection>

      <web-resource-name>RestEasy</web-resource-name>

      <url-pattern>/*</url-pattern>

    </web-resource-collection>

    <auth-constraint>

            <!--  

        A user must be assigned this role to connect to any JCR repository, in addition to needing the 

        READONLY or READWRITE roles to actually read or modify the data.  This is not used internally, 

        so another role could be substituted here.

      -->

      <role-name>connect</role-name>

    </auth-constraint>

  </security-constraint>



  <!--  

    Any auth-method will work for ModeShape.  BASIC is used this example for simplicity.

  -->

  <login-config>

    <auth-method>BASIC</auth-method>

  </login-config>



  <!-- 

    This must match the role-name in the auth-constraint above. 

  -->

  <security-role>

    <role-name>connect</role-name>

  </security-role>

</web-app>

As noted above, the REST server will not function properly unless security is configured. All authorization methods supported by the Servlet specification are supported by ModeShape and can be used interchangeable, as long as authenticated users have the connect role listed above.

Just as with the ModeShape WebDAV server, deploying the ModeShape REST server only requires three steps: preparing the web configuration, configuring the users and their roles in your web container (outside the scope of this document), and assembling the WAR. This section describes the requirements for assembling the WAR.

If you are using Maven to build your projects, the WAR can be built from a POM. Here is a portion of the POM used to build the ModeShape REST Server integration subproject.

<project xmlns="http://maven.apache.org/POM/4.0.0" 

     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <parent>

        <artifactId>modeshape</artifactId>

        <groupId>org.modeshape</groupId>

        <version>1.1</version>

        <relativePath>../..</relativePath>

    </parent>

    <artifactId>modeshape-web-jcr-rest-war</artifactId>

    <packaging>war</packaging>

    <name>ModeShape JCR REST Servlet</name>

    <description>ModeShape servlet that provides RESTful access to JCR items</description>

    <url>http://www.modeshape.org</url>

    <dependencies>

        <dependency>

            <groupId>org.modeshape</groupId>

            <artifactId>modeshape-web-jcr-rest</artifactId>

            <version>1.1</version>

        </dependency>



        <dependency>

            <groupId>org.slf4j</groupId>

            <artifactId>slf4j-log4j12</artifactId>

            <version>1.5.8</version>

            <scope>runtime</scope>

        </dependency>

        

        <dependency>

            <groupId>org.jboss.resteasy</groupId>

            <artifactId>resteasy-client</artifactId>

            <version>1.1.GA</version>

        </dependency>       

    </dependencies>

</project>

If you use this approach, make sure that web configuration file is in the /src/main/webapp/WEB-INF directory.

The JBoss REST Server WAR is still easy enough to build if you are not using Maven. Simply construct a WAR with the following contents:

+ /WEB-INF
	+ /classes
	|	+ configRepository.xml
	|	+ log4j.properties (Optional)
	+ /lib
	|	+ activation-1.1.jar
	|	+ commons-codec-1.2.jar
	|	+ commons-httpclient-3.1.jar
	|	+ google-collections-1.0.jar
	|	+ hamcrest-core-1.1.jar
	|	+ httpclient-4.0.jar
	|	+ httpcore-4.0.1.jar
	|	+ jakarta-regexp-1.4.jar
	|	+ javassist-3.6.0.GA.jar
	|	+ jaxb-api-2.1.jar
	|	+ jaxb-impl-2.1.12.jar
	|	+ jaxrs-api-1.2.1.GA.jar
	|	+ jcip-annotations-1.0.jar
	|	+ jcl-over-slf4j-1.5.8.jar
	|	+ jcr-1.0.1.jar
	|	+ jettison-1.1.jar
	|	+ joda-time-1.6.jar
	|	+ jsr250-api-1.0.jar
	|	+ junit-dep-4.4.jar
	|	+ lucene-analyzers-3.0.0.jar
	|	+ lucene-core-3.0.0.jar
	|	+ lucene-regex-3.0.0.jar
	|	+ lucene-snowball-3.0.0.jar
	|	+ modeshape-cnd-1.1.jar
	|	+ modeshape-common-1.1.jar
	|	+ modeshape-graph-1.1.jar
	|	+ modeshape-jcr-1.1.jar
	|	+ modeshape-repository-1.1.jar
	|	+ modeshape-search-lucene-1.1.jar
	|	+ modeshape-web-jcr-1.1.jar
	|	+ modeshape-web-jcr-rest-1.1.jar
	|	+ resteasy-jaxb-provider-1.2.1.GA.jar
	|	+ resteasy-jaxrs-1.2.1.GA.jar
	|	+ resteasy-jettison-provider-1.2.1.GA.jar
	|	+ scannotation-1.0.2.jar
	|	+ sjsxp-1.0.1.jar
	|	+ slf4j-api-1.5.8.jar
	|	+ slf4j-log4j12-1.5.8.jar
	|	+ slf4j-simple-1.5.8.jar
	|	+ stax-api-1.0-2.jar
	+ web.xml
			

If you are using sequencers or any connectors other than the in-memory or federated connector, you will also have to add the JARs for those dependencies into the WEB-INF/lib directory as well. You will also have to change the version numbers on the JARs to reflect the current version of ModeShape.

This WAR can be deployed into your servlet container.

The ModeShape REST Client API provides a POJO way of using the ModeShape REST web service to publish (upload) and unpublish (delete) files from ModeShape repositories. Java objects open the HTTP connection, create the HTTP request URLs, attach the payload associated with PUT and POST requests, parse the HTTP JSON response back into Java objects, and close the HTTP connection.

Here are the Java business objects you will need (all found in the org.modeshape.web.jcr.rest.client.domain package):

Along with the POJOs above, an org.modeshape.web.jcr.rest.client.IRestClient is needed. The IRestClient is responsible for executing the publishing and unpublishing operations. You can also use the IRestClient to find out what repositories and workspaces are available on a ModeShape server.

Here's a code snippet that publishes (uploads) a file:

// Setup POJOs
Server server = new Server("http://localhost:8080", "username", "password");
Repository repository = new Repository("repositoryName", server);
Workspace workspace = new Workspace("workspaceName", repository);

// Publish
File file = new File("/path/to/file");
IRestClient restClient = new JsonRestClient();
Status status = restClient.publish(workspace, "/workspace/path/", file);

if (status.isError() {
    // Handle error here
}
            

Successfully executing the above code results in the creation a JCR folder node (nt:folder) for each segment of the workspace path (if the folder didn't already exist). Also, a JCR file node (a node with primary type nt:file) is created or updated under the last folder node and the file contents are encoded and uploaded into a child node of that file node.