jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: JSOP/davex and transactions not working (compared to "simple webdav")
Date Wed, 07 Mar 2012 14:36:20 GMT
hallo chregu

ok. looking forward to your comments.

ps: 'simple webdav' is not referring to version 1 of the jcr-remoting
     that purely relied on (extended) webdav functionality but to a
     regular file-folder-based webdav view to a JCR repository...
     yet something completely different.

to clarify a quick non-alphabetic glossary:


remote JCR calls over http.

version 1: webdav based. described in the corresponding protocol on
            the jackrabbit website [1].
            expectations at that time: thin jcr client that does not
            take care of the transient space.

            -> see also: jcr-server

version 2: extended version that supports JCR 2.0 and in addition
            batch-read and batch-write using JSOP in order to address
            the reality that 'our' jcr client in fact does take care
            of the transient space (introduction of the SPI).

            in particular this version uses a single
            request with a defined 'diff' parameter to transport a set
            of transient modifications between 2 calls to Session.save().
            the client-side spi implementation is called 'spi2davex'
            that's probably were the term davex is coming from.

            -> see also: davex
            -> see also: JSOP

Simple Webdav

WebDAV (conformance levels 1, 2, and 3) and DeltaV compliant WebDAV 
server implementation to access a JSR170 repository + WebDAV BIND.

so, this is what people are usally looking for when they are talking
about WebDAV support in jackrabbit: files, folders and nothing
JCR specific views.

the corresponding source is located in the jackrabbit-jcr-server

-> see also jcr-server


shortcut for spi2davex which is an extension of the initial
SPI implementation that was talking to the jcr-remoting server and
not only made use of WebDAV but some custom read/write that was
later called JSOP.

-> see also: JCR Remoting version 2.
-> see also: JSOP


a) the original name of the remoting-server implementation (version 1).

b) the jackrabbit module that (unfortunately) contains both server
    - the simple webdav server (webdavwebdav) and
    - the server(s) used for jcr-remoting.

bref, a bad name and a lot of confusion.


protocol to read/write fine grained information such as JCR items.
the initial draft was developed along with version 2 of the jcr-remoting
in order to address the need for batch read and batch write.

see [2] for in overview.

-> see also: JCR Remoting


[1] http://jackrabbit.apache.org/JCR_Webdav_Protocol.doc
[2] http://www.slideshare.net/uncled/jsop

On 3/7/12 1:12 PM, Christian Stocker wrote:
> Hi
> Thanks. I will read the JCR specs again about that part, but your
> explanations helped a lot already. I think we might find a way for our
> needs with this
> greetings
> chregu
> On 07.03.12 13:05, Angela Schreiber wrote:
>> hi chregu
>> if you mean 'a bunch of transient modifications' when speaking
>> about transactions that everything works as expected:
>> you have 2 possibilities to transport a set of transient JCR
>> modifications to the server:
>> a) LOCK (special lockscope)
>>     your requests that reflect your transient modifications
>>     valid methods are PUT, POST, MKCOL, ORDERPATCH, PROPPATCH
>>     as far as i remember those cover the complete set of transient
>>     modifications in jcr lingo.
>>     UNLOCK
>> b) keep the transient jcr-modifications on the client-side
>>     until there is a save() call on the JCR API and upon that
>>     one send a single POST (later PATCH) request to the server
>>     that lists the changes in the jsop diff format.
>> the usage of 'commit' however sound rather like real transaction
>> handling... so i am a bit confused....
>>> I guess all the operations which are not covered by jsop-diff (like
>>> checkin and copy) are anyway never part of a transaction, since they are
>>> on the workspace level and not on the session level
>> real transactions in JCR include all operations irrespective of
>> session or workspace level. the specification has a section that
>> explains this in detail. but as i said before those are not
>> supported by the jcr-remoting (neither client nor server) so far.
>> not sure, what exactly you are referring to.
>> kind regards
>> angela
>>> Greetings
>>> chregu
>>> On 07.03.12 12:44, Angela Schreiber wrote:
>>>> hi chregu
>>>> the transaction type you are referring to aren't transactions s.str. but
>>>> were the first version of my jcr-remoting to indentify a set of
>>>> transient modifications that are transported to the server and are
>>>> 'saved' at the end (or reverted with Session.refresh(false)).
>>>> at that time we thought the jcr-client was really thin and would not
>>>> keep transient modifications but instead immediately send them to the
>>>> server (keeping as Session across multiple requests until the final
>>>> save/revert is sent with the corresponding unlock request).
>>>> with the creation of jcr2spi that in fact keeps track of transient
>>>> modifications and the invention of the jsop diff format that concept
>>>> became obsolete. in this new setup the complete set of transient
>>>> changes between 2 save calls are sent to the server in a single
>>>> 'batch-write' POST/PATCH request. therefore refresh(false) must not
>>>> be implemented on the server-side as this is taken care off by
>>>> jcr2spi (or any other jcr-client).
>>>> there was an initial attempt to support transactions as defined
>>>> by JSR 170 in the jcr-remoting setup but we never completed that
>>>> for various reasons.
>>>> there are fragments left in the jcr-server code (and for those we
>>>> initially wanted to use a lock-type<jcr:global />).
>>>> hope that helps
>>>> angela
>>>>> One thing I still get not working with using JSOP. Transactions.
>>>>> It works, when I eg. create a new Node with LOCK/MKCOL/UNLOCK, put it
>>>>> doesn't with the diff format in a POST:
>>>>> In details how it worked before (the important parts)
>>>>> ***
>>>>> LOCK /server/default/jcr:root HTTP/1.1
>>>>> <D:lockinfo xmlns:D="DAV:"
>>>>> xmlns:jcr="http://www.day.com/jcr/webdav/1.0">
>>>>>       <D:lockscope>
>>>>>           <jcr:local />
>>>>>       </D:lockscope>
>>>>>       <D:locktype>
>>>>>           <jcr:transaction />
>>>>>       </D:locktype>
>>>>> </D:lockinfo>
>>>>> **
>>>>> MKCOL /server/default/jcr:root/foo HTTP/1.1
>>>>> TransactionId:<opaquelocktoken:6b78a37a-1513-4673-bd43-6a254538bd40>
>>>>> <sv:node xmlns:sv="http://www.jcp.org/jcr/sv/1.0"
>>>>> xmlns:nt="http://www.jcp.org/jcr/nt/1.0" sv:name="foo">
>>>>>       <sv:property sv:name="jcr:primaryType" sv:type="Name">
>>>>>           <sv:value>nt:unstructured</sv:value>
>>>>>       </sv:property>
>>>>> </sv:node>
>>>>> **
>>>>> UNLOCK /server/default/jcr:root HTTP/1.1
>>>>> Lock-Token:<opaquelocktoken:1a252718-18bf-40a3-ab7f-b5559c887143>
>>>>> <jcr:transactioninfo xmlns:jcr="http://www.day.com/jcr/webdav/1.0">
>>>>>       <jcr:transactionstatus>
>>>>>           <jcr:rollback />
>>>>>       </jcr:transactionstatus>
>>>>> </jcr:transactioninfo>
>>>>> ***
>>>>> With the<jcr:rollback/>    at the end, that node never gets finally
>>>>> created.
>>>>> But if I do exactly the same, just with a POST and :diff instead of the
>>>>> MKCOL (and the LOCK/UNLOCK before/after)
>>>>> ***
>>>>> POST /server/default/jcr:root/ HTTP/1.1
>>>>> TransactionId:<opaquelocktoken:69125aba-3117-4a45-baf2-44e958364dc3>
>>>>> :diff=+/foo : {"jcr:primaryType":"nt:unstructured",}
>>>>> ***
>>>>> That node gets created even with a rollback afterwards.
>>>>> Is this a bug? Or a missing feature? Or do transactions work
>>>>> differently
>>>>> here? I tried to find the problem by myself in jackrabbit-jcr-server,
>>>>> but was not really successful, therefor any help would be appreciated.
>>>>> greetings
>>>>> chregu

View raw message