Steven Li created CMIS-959:
------------------------------
Summary: 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
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)
