You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by "Degroff, Nathan" <na...@fmr.com> on 2011/06/10 17:22:12 UTC
VersioningService.cancelCheckOut() and working-copy vs self rel link
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.
RE: VersioningService.cancelCheckOut() and working-copy vs self rel
link
Posted by "Degroff, Nathan" <na...@fmr.com>.
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:florian.mueller@alfresco.com]
Sent: Saturday, June 11, 2011 5:31 PM
To: Degroff, Nathan
Cc: dev@chemistry.apache.org
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:florian.mueller@alfresco.com]
> Sent: Friday, June 10, 2011 12:18 PM
> To: dev@chemistry.apache.org; 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.
>
Re: VersioningService.cancelCheckOut() and working-copy vs self rel
link
Posted by Florian Müller <fl...@alfresco.com>.
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:florian.mueller@alfresco.com]
> Sent: Friday, June 10, 2011 12:18 PM
> To: dev@chemistry.apache.org; 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.
>
Re: VersioningService.cancelCheckOut() and working-copy vs self rel
link
Posted by Florian Müller <fl...@alfresco.com>.
Ok, here is something wrong.
document.cancelCheckOut() should throw an exception. checkIn() and cancelCheckOut() should only work on PWCs:
ObjectId pwcId = document.checkOut();
Document pwc = (Document) session.getObject(pwcId);
pwc.cancelCheckOut();
Based on what you told me, my guess is that EMC Documentum uses the same object id for the document and for the (faked) PWC.
That would not be spec compliant. Section "2.1.9.4.1 Checkout" says:
"The effects of invoking the checkout service MUST be as follows:
A _new_ Document object, referred to herein as the Private Working Copy (PWC), is created."
And a new document must have a new object id because object ids are unique within a repository.
You may want to contact the EMC Documentum support. I'll check if the working-copy relation can mitigate the problem.
- 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:florian.mueller@alfresco.com]
> Sent: Friday, June 10, 2011 12:18 PM
> To: dev@chemistry.apache.org; 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.
>
RE: VersioningService.cancelCheckOut() and working-copy vs self rel
link
Posted by "Degroff, Nathan" <na...@fmr.com>.
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:florian.mueller@alfresco.com]
Sent: Friday, June 10, 2011 12:18 PM
To: dev@chemistry.apache.org; 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.
Re: VersioningService.cancelCheckOut() and working-copy vs self rel
link
Posted by Florian Müller <fl...@alfresco.com>.
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.