You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-user@jakarta.apache.org by Guido Casper <gc...@s-und-n.de> on 2004/03/08 18:11:59 UTC

WebDAV client lib question

I am using the WebDAV client lib with WebDAVResource and encountered the 
following problem:

I am unable to modify a resource that is locked by myself but by a 
different instance of WebDAVResource? Maybe I'm missing something?

To modify it I first have to unlock (and maybe re-lock) it, as 
WebDAVResource.unlockMethod(String path, String owner) seems to be the 
only method dynamically discovering the locks held by myself.

I can imagine cases where I don't want to let the user modify the 
resource locked by another instance of WebDAVResource, but shouldn't 
there be a refeshLocks or similar?

Thanks
Guido



---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org


Re: Patch to WebdavResource (was Re: WebDAV client lib question)

Posted by Guido Casper <gc...@s-und-n.de>.
Martin Holz wrote:
>>>Also I don't like the name since "refresh lock" usually means
>>
>>>"Change the expiration date of a lock".
>>
>>That's true. "discoverLocks" would probably be better. But it's
>>already in use by another protected method and I thought that might be
>>too much of an ambiguity. Anybody a better suggestion? :-)
> 
> 
> getOwnLocks() or discoverOwnLocks() ?

+1 for discoverOwnLocks()

Guido

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org


Re: Patch to WebdavResource (was Re: WebDAV client lib question)

Posted by Martin Holz <ho...@fiz-chemie.de>.

Guido Casper <gc...@s-und-n.de> writes:

> Martin Holz wrote:
> > So if two WebdavResource share the same client they share   the
> > locks. This is the case for all resources retrieved by
> > getChildResources().  Maybe a public constructor
> > WebdavResource(HttpClient,HttpURL)
> 
> > would be a  better solution, than the refreshLocks() method.
>
> That would only solve the issue for 2 instances of WebdavResource
> running within the same app. But there are other use cases such as:
> 
> -long duration locks
> -several apps (or instances of one app) running in parallel
> -a lock duration spanning multiple requests within a webapp

You are right. I was a little bit worried about two independent
applications run by the same user. The should usually not share 
locks. But I guess thats the way WebDAV works.

 
> > Also I don't like the name since "refresh lock" usually means
> 
> > "Change the expiration date of a lock".
> 
> That's true. "discoverLocks" would probably be better. But it's
> already in use by another protected method and I thought that might be
> too much of an ambiguity. Anybody a better suggestion? :-)

getOwnLocks() or discoverOwnLocks() ?



---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org


Re: Patch to WebdavResource (was Re: WebDAV client lib question)

Posted by Guido Casper <gc...@s-und-n.de>.
Martin Holz wrote:
> Hello Guido,
> 
> I do not know WebdavResource very well. Ingo Brunberg or
> Martin Dulisch know it better. 
> 
> Locks are administrated by the client in its WebdavState.
> So if two WebdavResource share the same client they share   
> the locks. This is the case for all resources retrieved 
> by getChildResources().  
> Maybe a public constructor WebdavResource(HttpClient,HttpURL)
> would be a  better solution, than the refreshLocks() method.

That would only solve the issue for 2 instances of WebdavResource 
running within the same app. But there are other use cases such as:
-long duration locks
-several apps (or instances of one app) running in parallel
-a lock duration spanning multiple requests within a webapp

> 
> Also I don't like the name since "refresh lock" usually means
> "Change the expiration date of a lock".

That's true. "discoverLocks" would probably be better. But it's already 
in use by another protected method and I thought that might be too much 
of an ambiguity. Anybody a better suggestion? :-)

> 
> I have applied the patch to main branch only for now.

Thanks a lot

Guido

> 
> 
> Martin
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org


Re: Patch to WebdavResource (was Re: WebDAV client lib question)

Posted by Martin Holz <ho...@fiz-chemie.de>.
Hello Guido,

I do not know WebdavResource very well. Ingo Brunberg or
Martin Dulisch know it better. 

Locks are administrated by the client in its WebdavState.
So if two WebdavResource share the same client they share   
the locks. This is the case for all resources retrieved 
by getChildResources().  
Maybe a public constructor WebdavResource(HttpClient,HttpURL)
would be a  better solution, than the refreshLocks() method.

Also I don't like the name since "refresh lock" usually means
"Change the expiration date of a lock".

I have applied the patch to main branch only for now.


Martin


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org


Patch to WebdavResource (was Re: WebDAV client lib question)

Posted by Guido Casper <gc...@s-und-n.de>.
Please find (and apply :-) the attached patch to the problem described 
below. I left all existing methods of WebdavResource untouched (to not 
break existing applications) and just added a refreshLocks method.

So if you want to write to a resource locked by another instance of 
WebdavResource (but the same owner) you just call:

resource.refreshLocks();
resource.proppatchMethod(properties);

If this patch is not acceptable please provide guidance on how to 
proceed with that.

Thanks
Guido


Guido Casper wrote:
> I am using the WebDAV client lib with WebDAVResource and encountered the 
> following problem:
> 
> I am unable to modify a resource that is locked by myself but by a 
> different instance of WebDAVResource? Maybe I'm missing something?
> 
> To modify it I first have to unlock (and maybe re-lock) it, as 
> WebDAVResource.unlockMethod(String path, String owner) seems to be the 
> only method dynamically discovering the locks held by myself.
> 
> I can imagine cases where I don't want to let the user modify the 
> resource locked by another instance of WebDAVResource, but shouldn't 
> there be a refeshLocks or similar?
> 
> Thanks
> Guido
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org
> 
>