[
https://issues.apache.org/jira/browse/CMIS-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15015636#comment-15015636
]
Florian Müller commented on CMIS-959:
-------------------------------------
The AtomPub and the Browser Binding work slightly different than defined in the
domain model in this regard. The URL points to an object and defines which
information about the object should be returned. (The terminology in the spec
is "Object URL").
A version series is not an object and therefore cannot be addressed. Instead
you have address an object that is part of the version series and ask it for
all versions.
Your URL is addressing the root folder because you neither defined a path nor
included an objectId parameter. With the parameter cmisselector you are asking
the root folder for its versions.
> CmisJS tests failing on getAllVersions, with cause analysis
> -----------------------------------------------------------
>
> Key: CMIS-959
> URL: https://issues.apache.org/jira/browse/CMIS-959
> Project: Chemistry
> Issue Type: Bug
> Components: opencmis-server
> Affects Versions: OpenCMIS 0.14.0
> Environment: CentOS 7.1
> Reporter: Steven Li
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> So I'm debugging another failed test cases from CmisJS
> (https://github.com/agea/CmisJS), where the Chemistry CMIS binding for
> "browser" apparently has some problems.
> *Symptom*
> The client would send in a "getAllVersions" request, with a URL like below:
> {code}
> GET
> /browser/default/root?succinct=true&token=token%2Cadmin&versionSeriesId=94279486-06a1-4c3f-a80d-ea13367fabcb&cmisselector=versions
> {code}
> The server (both InMemory, and Jcr) would return NOT the versions for the
> specified node, but the "root" node instead.
> *Cause*
> In CmisBrowserBindingServlet::dispatch(), an objectId would be prepared (on
> line 343) before invoking the actual services (such as VersioningService) in
> this case:
> {code}
> String objectId = HttpUtils.getStringParameter(request, PARAM_OBJECT_ID);
> {code}
> This is correct for most other services which expect an "objectId" parameter
> from the CMIS client. This is however not the case for the Versioning
> service, which would instead be expecting a "versionSeriesId" parameter. In
> the implementation of the VersioningService class though, it somehow forgets
> that fact, and takes the incoming "objectId" prepared for it. Since there is
> no incoming objectId, the CmisBrowserBindingServlet would fill in the "root"
> node instead (I think). The relevant code is below:
> {code}
> public static class GetAllVersions extends AbstractBrowserServiceCall {
> @Override
> public void serve(CallContext context, CmisService service, String
> repositoryId, HttpServletRequest request,
> HttpServletResponse response) throws Exception {
> assert context != null;
> assert service != null;
> assert repositoryId != null;
> assert request != null;
> assert response != null;
> // get parameters
> String objectId = ((BrowserCallContextImpl)
> context).getObjectId();
> String filter = getStringParameter(request, PARAM_FILTER);
> Boolean includeAllowableActions = getBooleanParameter(request,
> PARAM_ALLOWABLE_ACTIONS);
> boolean succinct = getBooleanParameter(request,
> Constants.PARAM_SUCCINCT, false);
> DateTimeFormat dateTimeFormat =
> getDateTimeFormatParameter(request);
> // execute
> if (stopBeforeService(service)) {
> return;
> }
> List<ObjectData> versions = service.getAllVersions(repositoryId,
> objectId, null, filter,
> includeAllowableActions, null);
> {code}
> As you can see the VersioningService is taking the object ID from the
> "context", and forgetting how the "context" would figure out such object ID.
> While not trivial, I believe there should be a straightforward fix. I'm happy
> to write the code too, but I never contributed to Apache before, and don't
> know what the best way is (patch file? merge request?).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
