If I understand the following, which is retrieved from a propfind
correctly, the Repository does not support transactions but only
exclusive/write and shared/write?
<D:supportedlock>
<D:lockentry>
<D:lockscope>
<D:exclusive />
</D:lockscope>
<D:locktype>
<D:write />
</D:locktype>
</D:lockentry>
<D:lockentry>
<D:lockscope>
<D:shared />
</D:lockscope>
<D:locktype>
<D:write />
</D:locktype>
</D:lockentry>
</D:supportedlock>
With regards,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Thu, Nov 13, 2008 at 8:25 PM, Nick Stolwijk <[EMAIL PROTECTED]> wrote:
> I am busy implementing, but have a question: Does the Hippo Repository
> support transaction locking / unlocking?
>
> With regards,
>
> Nick Stolwijk
> ~Java Developer~
>
> Iprofs BV.
> Claus Sluterweg 125
> 2012 WS Haarlem
> www.iprofs.nl
>
>
>
> On Mon, Nov 10, 2008 at 3:46 PM, Wander Grevink <[EMAIL PROTECTED]> wrote:
>> Correct on both points, forget my previous remarks, I already mentioned they
>> were silly :-)
>>
>> Go Nick!
>>
>> Wander
>>
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] on behalf of Nick Stolwijk
>> Sent: Mon 11/10/2008 3:06 PM
>> To: Hippo CMS development public mailinglist
>> Subject: Re: [HippoCMS-dev] Locking documents from the WebdavService
>> interface.
>>
>> Hi Wander,
>>
>>> * Is it necessary to add a new Lock class? isn't it possible to reuse the
>>> existing org.apache.webdav.lib.Lock?
>>
>> At this moment the WebdavService interface has no external
>> dependencies. To keep it this way I proposed to add the Lock class. It
>> external dependencies on the interface are no problem, we could use
>> the org.apache.webdav.lib.Lock. This means that all clients of the
>> WebdavRepository must have the webdav package on its compile time
>> classpath and thus adding a dependency.
>>
>>
>>> * I guess that the proposed new executePut with lock is meant as a
>>> convenience? is it correct that the same can be done by letting the
>>> application code call lockDocument first? If that is the case I would
>>> propose not adding them, you would need a 'locked' variant of all write
>>> methods (proppatch, put, copy etc.) leading to many more methods. I would
>>> prefer to keep the interface as clean and orthogonal as possible.
>>
>> At this moment the WebdavService is implemented as a service and does
>> not have any state. If multiple threads are talking to the same
>> service there is no way of knowing which thread has which lock, so the
>> lockToken would be necessary on the locked documents and locking state
>> should be guarded by the clients of the WebdavService.
>>
>>> For the rest: patches for more complete webdav support are more than welcome
>>
>> I am looking forward to add Maven 2 support and Generics support with
>> support for a backwards compitable Java 1.4 build. But that is for the
>> next time. First locking. :)
>>
>>> I'm looking forward to reviewing your patch, keep up the good work!
>>
>> With regards,
>>
>> Nick Stolwijk
>> ~Java Developer~
>>
>> Iprofs BV.
>> Claus Sluterweg 125
>> 2012 WS Haarlem
>> www.iprofs.nl
>>
>>
>>
>> On Mon, Nov 10, 2008 at 2:53 PM, Wander Grevink <[EMAIL PROTECTED]> wrote:
>>> Hi Nick,
>>>
>>> looks good, just a few (silly) questions:
>>
>>
>>
>>>
>>> Wander
>>>
>>>
>>> Nick Stolwijk wrote:
>>>>
>>>> Hi, I was looking for a way to get locking on documents in the
>>>> repository and found that these methods weren't available on the
>>>> interface yet. I have found the WebdavHelper which has the logic for
>>>> this code, so I can implement the methods, but I first need to know
>>>> which methods.
>>>>
>>>> I was thinking along the lines of
>>>>
>>>> public String lockDocument(Document doc, Lock lock) throws
>>>> ClientException;
>>>>
>>>> public void unlockDocument(Document doc, String lockToken) throws
>>>> ClientException;
>>>>
>>>> And a new value class Lock which contains the properties Scope, Depth
>>>> and Owner, just like org.apache.webdav.lib.Lock.
>>>>
>>>> There also must be additional methods for the other webdav methods, to
>>>> provide the lockToken.
>>>>
>>>> ie.
>>>>
>>>> public int executePut(DocumentPath targetPath, InputStream putObject)
>>>> throws ClientException;
>>>> public int executePut(DocumentPath targetPath, InputStream putObject,
>>>> String lockToken) throws ClientException;
>>>>
>>>> Any input appreciated, so I can provide a patch that implements this.
>>>>
>>>> With regards,
>>>>
>>>> Nick Stolwijk
>>>> ~Java Developer~
>>>>
>>>> Iprofs BV.
>>>> Claus Sluterweg 125
>>>> 2012 WS Haarlem
>>>> www.iprofs.nl
>>>> ********************************************
>>>> Hippocms-dev: Hippo CMS development public mailinglist
>>>>
>>>> Searchable archives can be found at:
>>>> MarkMail: http://hippocms-dev.markmail.org
>>>> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html
>>>>
>>>>
>>>
>>> ********************************************
>>> Hippocms-dev: Hippo CMS development public mailinglist
>>>
>>> Searchable archives can be found at:
>>> MarkMail: http://hippocms-dev.markmail.org
>>> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html
>>>
>>>
>> ********************************************
>> Hippocms-dev: Hippo CMS development public mailinglist
>>
>> Searchable archives can be found at:
>> MarkMail: http://hippocms-dev.markmail.org
>> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html
>>
>>
>>
>> ********************************************
>> Hippocms-dev: Hippo CMS development public mailinglist
>>
>> Searchable archives can be found at:
>> MarkMail: http://hippocms-dev.markmail.org
>> Nabble: http://www.nabble.com/Hippo-CMS-f26633.html
>>
>>
>>
>
********************************************
Hippocms-dev: Hippo CMS development public mailinglist
Searchable archives can be found at:
MarkMail: http://hippocms-dev.markmail.org
Nabble: http://www.nabble.com/Hippo-CMS-f26633.html
