Mailing-List: contact dev-help@chemistry.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@chemistry.apache.org
Date: Thu, 20 Nov 2014 18:10:33 +0000 (UTC)
From: =?utf-8?Q?Florian_M=C3=BCller_=28JIRA=29?= <jira@apache.org>
To: dev@chemistry.apache.org
Message-ID: <JIRA.12756740.1416504065000.545872.1416507033894@Atlassian.JIRA>
In-Reply-To: <JIRA.12756740.1416504065000@Atlassian.JIRA>
References: <JIRA.12756740.1416504065000@Atlassian.JIRA>
 <JIRA.12756740.1416504065096@arcas>
Subject: [jira] [Commented] (CMIS-871) Client API Atompub binding -
 getContentChanges still sends change log token even though I specify null
 for the changeLogToken parameter
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CMIS-871?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D142196=
88#comment-14219688 ]=20

Florian M=C3=BCller commented on CMIS-871:
-------------------------------------

Re 1. The AtomPub binding doesn't send a changeLogToken. Where should it co=
me from?
This is a generated URL: {{http://localhost:8080/inmemory/atom11/A1/changes=
?includeProperties=3Dfalse&includePolicyIds=3Dfalse&includeACL=3Dfalse&maxI=
tems=3D2147483647}}
The session.getContentChanges(null, false) method emulates paging. That is,=
 if the first page contained a next link (with a changeLogToken), it will c=
all this link to get the second page. This second call must have a changeLo=
gToken, otherwise paging wouldn't work. But that's the same for the Web Ser=
vices and the Browser binding.=20

Re 2. maxItems only defines number of items that must not be exceeded by th=
e server. It doesn't force the server to send that many items. It's totally=
 fine to only return, let's say, 1000 items and indicate that there is a ne=
xt page that the client can fetch.
The whole point of this getContentChanges() method is to eventually read th=
e complete change log. Using large pages minimizes the number of calls.
The session interface provides other getContentChanges() methods to only ge=
t the tip or an excerpt of the change log.=20


> Client API Atompub binding - getContentChanges still sends change log tok=
en even though I specify null for the changeLogToken parameter
> -------------------------------------------------------------------------=
--------------------------------------------------------------
>
>                 Key: CMIS-871
>                 URL: https://issues.apache.org/jira/browse/CMIS-871
>             Project: Chemistry
>          Issue Type: Bug
>          Components: opencmis-client
>    Affects Versions: OpenCMIS 0.12.0
>         Environment: Windows 64 bits
>            Reporter: Vincent Tang
>              Labels: getContentChanges
>
> I found 2 OpenCMIS Client API problems in my test to use OpenCMIS Client =
API Session.getContentChanges(String changeLogToken, boolean includePropert=
ies).=20
> The test is calling it like session.getContentChanges(null, false); You s=
ee I set null to changeLogToken. Based on my understanding of CMIS specific=
ation, I assume that the API would not include a change log token in the re=
quest.
> The problems I found are
> 1. OpenCMIS API send a changeLogToken anyway in Atompub binding but null =
in Web services binding. The latter is compliant with CMIS specification bu=
t the former is not. I think the OpenCMIS API in Atompub binding has a bug.
> 2. This API sends a default maxItems in request because our test doesn't =
specify one. However OpenCMIS API sends an unreasonable maxItem 2147483647.=
 I think it is the maximum value of a java integer. It causes different eff=
ect in Atompub and web services bindings.
>     In Atompub binding, because of the bug (a change log token is passed =
in), CMIS passed the change log token and the maxItems in the query, the qu=
ery returns the change events after the change log token. Therefore the tes=
t cases passed.
>     In web services binding, the null value change log token and the maxI=
tems will effectively return the entire change log from the repository. It =
causes the query hang and eventually timed out after 300 seconds.
> This JIRA is reporting the first problem. I am not sure if the second pro=
blem (maxItems =3D 2147483647 by default) is a problem. Because CMIS specif=
ication doesn't say anything about the default maxItems. We will do somethi=
ng at server side to prevent such a unreasonable maxItems to be used in que=
ry.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)