[
https://issues.apache.org/jira/browse/JCR-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Satya Deep Maheshwari updated JCR-3895:
---------------------------------------
Attachment: JCR-3895.patch
Attaching a patch containing proposed implementation for this.
Implementation synopsis:
* Introduced a new LockHandler interface which is responsible for checking
whether a resource is lockable or not. If it is lockable, it would return a
LockManager to take care of the webdav locking operations. LockManager [1] is a
pre-existing interface in Jackrabbit for taking care of webdav lock operations.
* Introduced a new LockHandlerManager interface. This provides api to register
lockhandlers. It also provides api to get the appropriate LockManager for a
resource on the basis of its registered LockHandlers and the specified resource
on which the webdav lock operation is to be performed.
* org.apache.jackrabbit.webdav.simple.ResourceFactoryImpl which is responsible
for DavResource creation, determines a suitable LockManager for a resource if
available. If none is found, it falls back to the default lockmanager that it
already has. Thus ensuring that there is no impact on the current functionality
unless a LockHandlerManager is available and it is able to return a LockManager
for a resource.
[1]-http://jackrabbit.apache.org/api/2.10/org/apache/jackrabbit/webdav/lock/LockManager.html
> Add handler to handle webdav LOCK requests
> ------------------------------------------
>
> Key: JCR-3895
> URL: https://issues.apache.org/jira/browse/JCR-3895
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-jcr-server
> Reporter: Tobias Bocanegra
> Attachments: JCR-3895.patch
>
>
> similar to JCR-3884, an application should be able to control how LOCK
> requests are handled.
> the concrete use case: WebDAV on OSX does not respect failing PUT requests,
> if the prior LOCK request succeeded.
> in the case where a user does not have write access to a node, and the node
> does not have mix:lockable, the webdav server creates a in-memory lock token
> for that node, hence allowing the LOCK.
> We don't want to change this behavior in general, as it might have unexpected
> results in other places, but to be able to control the LOCK behavior in more
> detail in a handler than can be controlled by the application.
> workaround: create servlet filter
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
