[
https://issues.apache.org/jira/browse/CMIS-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Li reopened CMIS-959:
----------------------------
I'm sorry, but see my previous comment, I think we have a problem that need to
be fixed. The VersioningService always returns stuff about the root node today.
> 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)
