Mailing-List: contact dev-help@chemistry.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@chemistry.apache.org
Received-SPF: pass (athena.apache.org: domain of florian.mueller@alfresco.com
 designates 207.126.144.141 as permitted sender)
Message-ID: <4DF243C7.6040109@alfresco.com>
Date: Fri, 10 Jun 2011 17:18:15 +0100
From: =?ISO-8859-1?Q?Florian_M=FCller?= <florian.mueller@alfresco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "dev@chemistry.apache.org" <dev@chemistry.apache.org>,
 nathan.degroff@fmr.com
Subject: Re: VersioningService.cancelCheckOut() and working-copy vs self rel
 link
References: 
 <2A1D0A84B520BE4D84231A6156F934C05CC2C28E5A@MSGDALCCRC2WIN.DMN1.FMR.COM>
In-Reply-To: 
 <2A1D0A84B520BE4D84231A6156F934C05CC2C28E5A@MSGDALCCRC2WIN.DMN1.FMR.COM>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.