Florian,

I know this is a little late from your notification back on June 11th, but I 
just was able to validate the 0.4.0 build involving using 
Constants.REL_WORKINGCOPY for the VersioningServiceImpl.cancelCheckOut() method 
and it worked perfectly.  The object pulled back the appropriate URL and 
cancelled the checkout without using the Delete object URL.

Nathan

-----Original Message-----
From: Florian Müller [mailto:[email protected]] 
Sent: Saturday, June 11, 2011 5:31 PM
To: Degroff, Nathan
Cc: [email protected]
Subject: Re: VersioningService.cancelCheckOut() and working-copy vs self rel 
link

I have added a workaround. If you have the chance to test a 0.4.0 
snapshot, please let us know if it works.

Thanks,

Florian


On 10/06/2011 19:42, Degroff, Nathan wrote:
> According to the EMC Documentum CMIS Reference Guide (ver 6.7), the two 
> Repository Capabilities are false:
>
>      capabilityPWCUpdatable - This capability cannot be implemented because 
> Documentum does not have a PWC feature.
>      capabilityPWCSearchable - This capability cannot be implemented because 
> Documentum does not have a PWC feature.
>
>
> The ID of the original doc is passed back when:
>
>      ObjectId pwcId = document.checkOut();
>
> However, if in the same session you call:
>
>       document.cancelCheckOut()
>
> the LinkCache for "self" is the actual checkedout link which works.
>
> The issue comes in if you are opening a new session for a docuemnt that is 
> already checked out and you want to cancel out an item you checked out in a 
> previous session or in some other application.  If you retrieve the document 
> using:
>
>       session.getCheckedOutDocs()
>
> The LinkCache result for "self" when calling cancelCheckOut() gives you the 
> working-copy link.  However, you have to iterate over the collection of 
> checked out docs to get the right document.
>
> -----Original Message-----
> From: Florian Müller [mailto:[email protected]]
> Sent: Friday, June 10, 2011 12:18 PM
> To: [email protected]; Degroff, Nathan
> Subject: Re: VersioningService.cancelCheckOut() and working-copy vs self rel 
> link
>
> Hi Nathan,
>
> Thanks for your report!
>
> I can't really comment on the EMC Documentum CMIS implementation because I 
> haven't had a chance to test it extensively.
>
>
> Could you describe how you get the PWC id in the first place?
> Did you do something like this:   ObjectId pwcId = document.checkOut();
>
> If so, EMC does not return the PWC entry but the document entry, which would 
> be a bug on their end.
>
>
> Using the working-copy relation would be a valid workaround. Let me play with 
> that a bit and if it works with other repositories, I'll open an issue and 
> change it.
>
>
> Thanks,
>
> Florian
>
>
>
> On 10/06/2011 16:22, Degroff, Nathan wrote:
>> To whom it may concern,
>>
>> Topic:      VersioningService.cancelCheckOut()
>> Binding:    AtomPub
>> Issue:      Deletion of object rather than cancelling checkout
>> Repository: EMC Documentum
>>
>> We encountered an issue with utilizing the OpenCMIS client where depending 
>> on how you retrieve the Document, the system would send a DELETE for the 
>> actual object:
>>
>> DELETE 
>> http://<host>:<port>/<app>/resources/repositories/<repository>/objects/<roid>
>>
>> instead of the working copy:
>>
>> DELETE 
>> http://<host>:<port>/<app>/resources/repositories/<repository>/checkedout/<roid>
>>
>> There are many ways around it by retrieving the doc using the 
>> Session.getCheckedOutDocs() and then calling cancelCheckOut() from that 
>> object or just calling the SOAP version (which calls the checkout operation 
>> directly), but I was wondering if this is a culmination of:
>>
>>       -) CMIS 1.0 Spec specifying the "self" relationship while calling 
>> cancelCheckOut() instead of using the "working-copy" relationship link
>>       -) EMC CMIS implementation not supporting a PWC
>>
>>
>> After tracing and inspecting to the LinkCache, I can see that if (atompub 
>> package) VersioningServiceImpl used Constants.REL_WORKINGCOPY it would work 
>> in all instances whether you checked the doc out in the same "OpenCMIS" 
>> session or if you are pulling it back from a new session.
>>
>>       public void cancelCheckOut(String repositoryId, String objectId, 
>> ExtensionsData extension) {
>>           // find the link
>>           String link = loadLink(repositoryId, objectId, 
>> Constants.REL_WORKINGCOPY, Constants.MEDIATYPE_ENTRY);
>>
>>           if (link == null) {
>>               throwLinkException(repositoryId, objectId, 
>> Constants.REL_WORKINGCOPY, Constants.MEDIATYPE_ENTRY);
>>           }
>>
>>           delete(new UrlBuilder(link));
>>       }
>>
>> We were able to pull back many different ways to deal with it especially 
>> pulling back the "checkedOutDocs" collection, but any thoughts would be 
>> appreciated.  Pulling the doc directly without having to iterate through a 
>> collection to find the doc one needs.
>

Reply via email to