1
votes

Background: I've been thinking about adopting a service mix including Apache Sling, Jackrabbit, and Jetty, for purposes of content management within web site designs. At this point, I'd like to imagine that it would be possible to create a mobile content creation platform using DAV to access a JCR content repository. The matter of Versioning in JCR 2.0 (JSR-283) it leaves me wondering, how would one conduct JCR versioning operations via HTTP?

In more detail: I'm looking at what I presume would be section 15 of JSR-283, served up in HTML format from Adobe. In that section, JSR-283 presents a concept of versioning for JCR nodes.

I understand, then, that there's a VersionManager API in JSR-283 compatible releases of Jackrabbit. That serves to explain how one would conduct JCR (JSR-283) versioning operations via the API. So, but how can a user agent conduct a versioning operation via DAV?

I'd like to answer that one for myself, but I don't even know where to start.

Is there another part of JSR-283 explaining how the version checkin/checkout operations translate into HTTP requests? Is it a matter of simple DAV properties? Am I even close to the mark, at that?

/Peer review needed, lol

2
Like, how would the node 'checkin' and 'checkout' operations translate to DAV/HTTP requests? (and 'checkpoint' operations, likewise)Sean Champ
Reading more about WebDAV, I can see that RFC 3253 defines Versioning Extensions to WebDAV. [...]Sean Champ
I understand that the JCR versioning framework effectively pivots around the mix:versionable JCR mixin node type (Jackrabbit Wiki). So, if a node is created as being of type mix:versionable, then I presume that the conventional WebDAV checkin and checkout operations - as could be encapsulated with a WebDAV API - that those would probably be how one would conduct JCR checkin/checkout operations on versionable nodes. That, I presume, would answer that much of the question. [...]Sean Champ
I don't see any exact DAV compliment to the JCR <tt>checkpoint</tt> operation, but if that's just <tt>checkin</tt> followed with <tt>checkout</tt>, as the documentation explains, then it would be easy enough to emulate via DAV - thus making a compliment to that JCR operation. If there are not any other answers to the question, then I guess that I'll just go with this answer, in considering how a mobile content creation app could "check out" and then "check in" a versioned content item via JCR over WebDAV . Cheers.Sean Champ

2 Answers

1
votes

There is a document (JCR_Webdav_Protocol.doc - Apache Jackrabbit) describing the mapping between WebDAV method calls and Jackrabbit JCR API calls on the Jackrabbit website:

http://jackrabbit.apache.org/JCR_Webdav_Protocol.doc

Though this document is last updated 29.March 2006 I found it quite helpful to make my first steps.

I have traced a session with Microsoft Office 2010 against my Jackrabbit default repository using Word and Wireshark. The following shell script kind of executes the same actions using curl and libreoffice on *nix.


As you can see the DELETE, UPLOAD, VERSION-CONTROL Document WebDAV calls are executed upfront to the actions in Word.

The Browse Directory opens the URL in your Internet Explorer instance.

Microsoft Word retrieves Document Properties (PROPFIND) and then opens (GET) and LOCKs the Document. It also requests the Properties on %EE%B3%B0 for unknown reasons (UTF-8 (hex) 0xEE 0xB3 0xB0 (eeb3b0) or UTF-16 "\uECF0" a.k.a. "" from the Private Use Range of Unicode Character Set).

Once you Save the Document in Microsoft Word it will upload (PUT) and update the properties (PROPPATCH) of your Document node to include Win32CreationTime, Win32LastModifiedTime and Win32LastAccessTime stamps.

Closing the Document in Word will release the aquired lock using UNLOCK.

CHECKIN Document is again executed manually to make the Version lifecycle complete.

The Version-Tree REPORT can be gained from WebDAV too.

#!/bin/sh

# Delete document
curl -A Microsoft-WebDAV-MiniRedir/6.1.7601 -X DELETE -v http://localhost:7001/repository/default/test.docx

# Upload document
curl -A Microsoft-WebDAV-MiniRedir/6.1.7601 -X PUT -v http://localhost:7001/repository/default/test.docx --data-binary "@test.docx"

# Version-Control document
curl -A Microsoft-WebDAV-MiniRedir/6.1.7601 -X VERSION-CONTROL -v http://localhost:7001/repository/default/test.docx 

# Checkout document
curl -A Microsoft-WebDAV-MiniRedir/6.1.7601 -X CHECKOUT -v http://localhost:7001/repository/default/test.docx

# Browse directory
curl -A "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" -X GET -v http://localhost:7001/repository/default/ 

# Open document in Word
curl -A Microsoft-WebDAV-MiniRedir/6.1.7601 -X PROPFIND -v http://localhost:7001/repository/default/test.docx | xmllint --format -
curl -A Microsoft-WebDAV-MiniRedir/6.1.7601 -X GET -v http://localhost:7001/repository/default/test.docx -O
curl -A Microsoft-WebDAV-MiniRedir/6.1.7601 -X PROPFIND -v http://localhost:7001/repository/default/test.docx%EE%B3%B0
cat > LOCK_document.xml <<EOF
<?xml version="1.0" encoding="utf-8" ?>
<D:lockinfo xmlns:D="DAV:">
  <D:lockscope>
    <D:exclusive/>
  </D:lockscope>
  <D:locktype>
    <D:write/>
  </D:locktype>
  <D:owner>
    <D:href>WINDOWSDOMAIN\USER</D:href>
  </D:owner>
</D:lockinfo>
EOF
curl -A Microsoft-WebDAV-MiniRedir/6.1.7601 -X LOCK -v http://localhost:7001/repository/default/test.docx --data "@LOCK_document.xml" | xmllint --format - | tee LOCK_document.txt
export LOCK_token=$(grep opaquelocktoken LOCK_document.txt | sed 's/^.*opaquelocktoken:/<opaquelocktoken:/' | sed 's/<\/D:href>.*$/>/')

curl -A "Microsoft Office Existence Discovery" -X HEAD -v http://localhost:7001/repository/default/test.docx
curl -A Microsoft-WebDAV-MiniRedir/6.1.7601 -X OPTIONS -v http://localhost:7001/ -H "translate: f"

# Edit document in Word
libreoffice test.docx 

# Save document in Word
curl -A Microsoft-WebDAV-MiniRedir/6.1.7601 -X HEAD -v http://localhost:7001/repository/default/test.docx
curl -A Microsoft-WebDAV-MiniRedir/6.1.7601 -X PUT -v http://localhost:7001/repository/default/test.docx -H "If: (${LOCK_token})" --data-binary "@test.docx"
cat > PROPPATCH_document.xml <<EOF
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:" xmlns:Z="urn:schemas-microsoft-com:">
  <D:set>
    <D:prop>
      <Z:Win32CreationTime>Mon, 09 Mar 2015 15:24:36 GMT</Z:Win32CreationTime>
      <Z:Win32LastAccessTime>Mon, 16 Mar 2015 13:22:40 GMT</Z:Win32LastAccessTime>
      <Z:Win32LastModifiedTime>Mon, 16 Mar 2015 13:22:40 GMT</Z:Win32LastModifiedTime>
    </D:prop>
  </D:set>
</D:propertyupdate>
EOF
curl -A Microsoft-WebDAV-MiniRedir/6.1.7601 -X PROPPATCH -v http://localhost:7001/repository/default/test.docx -H "If: (${LOCK_token})" --data "@PROPPATCH_document.xml" | xmllint --format -

# Close document in Word
curl -A "Microsoft Office Existence Discovery" -X HEAD -v http://localhost:7001/repository/default/test.docx
curl -A Microsoft-WebDAV-MiniRedir/6.1.7601 -X UNLOCK -v http://localhost:7001/repository/default/test.docx -H "Lock-Token: ${LOCK_token}"

# Checkin document
curl -A Microsoft-WebDAV-MiniRedir/6.1.7601 -X CHECKIN -v http://localhost:7001/repository/default/test.docx

# Version tree report on document
cat > REPORT_version-tree.xml <<EOF
<?xml version="1.0" encoding="utf-8" ?>
<D:version-tree xmlns:D="DAV:">
 <D:prop>
   <D:version-name/>
 </D:prop>
</D:version-tree>
EOF
curl -A Microsoft-WebDAV-MiniRedir/6.1.7601 -X REPORT -v http://localhost:7001/repository/default/test.docx --data "@REPORT_version-tree.xml" | xmllint --format -

I only had problems with the auto-version capabilities of Jackrabbit, which are obviously not implemented yet.

https://issues.apache.org/jira/browse/JCR-1348

#<!--
# see http://www.webdav.org/specs/rfc3253.html#PROPERTY_auto-version
#      <D:auto-version>checkout-checkin</D:auto-version>
#      <D:auto-version>checkout-unlocked-checkin</D:auto-version>
#      <D:auto-version>checkout</D:auto-version>
#      <D:auto-version>locked-checkout</D:auto-version>
#-->
cat > PROPPATCH_auto-version.xml <<EOF
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:">
  <D:set>
    <D:prop>
      <D:auto-version>checkout-checkin</D:auto-version>
    </D:prop>
  </D:set>
</D:propertyupdate>
EOF
curl -A Microsoft-WebDAV-MiniRedir/6.1.7601 -X PROPPATCH -v http://localhost:7001/repository/default/test.docx -H "If: (${LOCK_token})" --data "@PROPPATCH_auto-version.xml" | xmllint --format -
0
votes

I understand that the JCR versioning framework effectively pivots around the mix:versionable JCR mixin node type (Jackrabbit Wiki). So, if a node is created as being of type mix:versionable, then I presume that the conventional WebDAV checkin and checkout operations - as could be encapsulated with a WebDAV API - that those would probably be how one would conduct JCR checkin/checkout operations on versionable nodes. That, I presume, would answer that much of the question

I don't see any exact DAV compliment to the JCR checkpoint operation, but if that's just checkin followed with checkout, as the documentation explains, then it would be easy enough to emulate via DAV - thus making a compliment to that JCR operation.