chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Li (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CMIS-959) CmisJS tests failing on getAllVersions, with cause analysis
Date Fri, 20 Nov 2015 10:48:10 GMT
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)

Mime
View raw message