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] [Commented] (CMIS-959) CmisJS tests failing on getAllVersions, with cause analysis
Date Fri, 20 Nov 2015 11:10:11 GMT

    [ https://issues.apache.org/jira/browse/CMIS-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15015613#comment-15015613
] 

Steven Li commented on CMIS-959:
--------------------------------

Thanks for the quick response Florian. I am a confused by the CMIS 1.1 spec myself.

Section 5.4.3.32 specifies the 4 parameters needed by the binding itself (filter, includeAllowableActions,
succinct, token). But how does the server know which object to pull the versions from?

The same section then specifies the "service" the binding/selector is for, which is "getAllVersions".
It then points us to section 2.2.7.6. In that section it clearly says that "versionSeriesId"
is a REQUIRED parameter, in addition to the 2 optional parameters (filter, includeAllowableActions).

One way or another, there is no mention of using "objectId" as the parameter. The symptom
of the browser binding always returning versions for the root is definitely something that
needs to be fixed.

> 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)

Mime
View raw message