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 Elodie Tasia <e....@ever-team.com> on 2002/04/19 12:28:02 UTC
UNLOCK big problem
Hi,
I'm afraid by something grave in the Slide client API : imagine you lock a resource for a long time or even infinite time.
You get the resource and work it.
It can take just a few minutes, or many hours... but you need anyway that the resource is locked because you're modifying it.
And then, you want to put the new resource on the server and unlock them. And what happens : the server returns that the resource is already locked, but doesn't want to recognize you !
That's what happens when you call lockMethod and unlockMethod, but not with the same instance resource.
That phenomen seems to me illogical and dangerous (and to my boss, too !). So, what must I do ? Where is the bug ?
thanx for help
RE: UNLOCK big problem
Posted by Tim Anderson <ti...@intalio.com>.
Try adding:
client.setState(new WebdavState());
prior to the call client.startSession();
-Tim
> -----Original Message-----
> From: Elodie Tasia [mailto:e.tasia@ever-team.com]
> Sent: Tuesday, April 23, 2002 2:06 AM
> To: Slide Users Mailing List; tima@intalio.com
> Subject: Re: UNLOCK big problem
>
>
> Ok, I succeed in getting the token when I lock a resource.
> But when I want to unlock it, I get this error message :
>
> java.lang.ClassCastException: org.apache.commons.httpclient.State
> at
> org.apache.webdav.lib.methods.UnlockMethod.parseResponse(UnlockMet
> hod.java:1
> 75)
> at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.
> java:669)
>
> My code is :
>
>
> Http Client client = new HttpClient();
> client.setDebug(10);
> client.startSession(this.host, this.port, new Credentials(this.user,
> this.passwd));
>
> um = new UnlockMethod(this.path);
> um.setDebug(10);
> um.setLockToken(this.token);
>
> client.executeMethod(um);
>
> What does it doesn't work ? What did I miss ?
>
> Thanx
>
>
> ----- Original Message -----
> From: "Tim Anderson" <ti...@intalio.com>
> To: "Slide Users Mailing List" <sl...@jakarta.apache.org>
> Sent: Friday, April 19, 2002 12:50 PM
> Subject: RE: UNLOCK big problem
>
>
> > I'm guessing, but try using the LockMethod and UnlockMethod classes
> > (located in the org.apache.webdav.lib.methods package)
> > directly, rather than using WebdavResource.
> >
> > WebdavResource caches lock tokens within the http session -
> > if you try and do an unlockMethod() using another instance,
> > the lock token associated with the path you're trying to
> > unlock won't be found, and so no UNLOCK request will
> > be issued to the server.
> >
> > -Tim
> >
> >
> >
> > > -----Original Message-----
> > > From: Elodie Tasia [mailto:e.tasia@ever-team.com]
> > > Sent: Friday, April 19, 2002 8:28 PM
> > > To: Slide Group
> > > Subject: UNLOCK big problem
> > >
> > >
> > > Hi,
> > >
> > > I'm afraid by something grave in the Slide client API : imagine
> > > you lock a resource for a long time or even infinite time.
> > > You get the resource and work it.
> > > It can take just a few minutes, or many hours... but you need
> > > anyway that the resource is locked because you're modifying it.
> > > And then, you want to put the new resource on the server and
> > > unlock them. And what happens : the server returns that the
> > > resource is already locked, but doesn't want to recognize you !
> > >
> > > That's what happens when you call lockMethod and unlockMethod,
> > > but not with the same instance resource.
> > > That phenomen seems to me illogical and dangerous (and to my
> > > boss, too !). So, what must I do ? Where is the bug ?
> > >
> > > thanx for help
> > >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: UNLOCK big problem
Posted by Elodie Tasia <e....@ever-team.com>.
Ok, I succeed in getting the token when I lock a resource.
But when I want to unlock it, I get this error message :
java.lang.ClassCastException: org.apache.commons.httpclient.State
at
org.apache.webdav.lib.methods.UnlockMethod.parseResponse(UnlockMethod.java:1
75)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:669)
My code is :
Http Client client = new HttpClient();
client.setDebug(10);
client.startSession(this.host, this.port, new Credentials(this.user,
this.passwd));
um = new UnlockMethod(this.path);
um.setDebug(10);
um.setLockToken(this.token);
client.executeMethod(um);
What does it doesn't work ? What did I miss ?
Thanx
----- Original Message -----
From: "Tim Anderson" <ti...@intalio.com>
To: "Slide Users Mailing List" <sl...@jakarta.apache.org>
Sent: Friday, April 19, 2002 12:50 PM
Subject: RE: UNLOCK big problem
> I'm guessing, but try using the LockMethod and UnlockMethod classes
> (located in the org.apache.webdav.lib.methods package)
> directly, rather than using WebdavResource.
>
> WebdavResource caches lock tokens within the http session -
> if you try and do an unlockMethod() using another instance,
> the lock token associated with the path you're trying to
> unlock won't be found, and so no UNLOCK request will
> be issued to the server.
>
> -Tim
>
>
>
> > -----Original Message-----
> > From: Elodie Tasia [mailto:e.tasia@ever-team.com]
> > Sent: Friday, April 19, 2002 8:28 PM
> > To: Slide Group
> > Subject: UNLOCK big problem
> >
> >
> > Hi,
> >
> > I'm afraid by something grave in the Slide client API : imagine
> > you lock a resource for a long time or even infinite time.
> > You get the resource and work it.
> > It can take just a few minutes, or many hours... but you need
> > anyway that the resource is locked because you're modifying it.
> > And then, you want to put the new resource on the server and
> > unlock them. And what happens : the server returns that the
> > resource is already locked, but doesn't want to recognize you !
> >
> > That's what happens when you call lockMethod and unlockMethod,
> > but not with the same instance resource.
> > That phenomen seems to me illogical and dangerous (and to my
> > boss, too !). So, what must I do ? Where is the bug ?
> >
> > thanx for help
> >
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: UNLOCK big problem
Posted by Tim Anderson <ti...@intalio.com>.
I'm guessing, but try using the LockMethod and UnlockMethod classes
(located in the org.apache.webdav.lib.methods package)
directly, rather than using WebdavResource.
WebdavResource caches lock tokens within the http session -
if you try and do an unlockMethod() using another instance,
the lock token associated with the path you're trying to
unlock won't be found, and so no UNLOCK request will
be issued to the server.
-Tim
> -----Original Message-----
> From: Elodie Tasia [mailto:e.tasia@ever-team.com]
> Sent: Friday, April 19, 2002 8:28 PM
> To: Slide Group
> Subject: UNLOCK big problem
>
>
> Hi,
>
> I'm afraid by something grave in the Slide client API : imagine
> you lock a resource for a long time or even infinite time.
> You get the resource and work it.
> It can take just a few minutes, or many hours... but you need
> anyway that the resource is locked because you're modifying it.
> And then, you want to put the new resource on the server and
> unlock them. And what happens : the server returns that the
> resource is already locked, but doesn't want to recognize you !
>
> That's what happens when you call lockMethod and unlockMethod,
> but not with the same instance resource.
> That phenomen seems to me illogical and dangerous (and to my
> boss, too !). So, what must I do ? Where is the bug ?
>
> thanx for help
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>