Vincent Tang created CMIS-871:
---------------------------------
Summary: Client API Atompub binding - getContentChanges still
sends change log token 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
I found 2 OpenCMIS Client API problems in my test to use OpenCMIS Client API
Session.getContentChanges(String changeLogToken, boolean includeProperties).
The test is calling it like session.getContentChanges(null, false); You see I
set null to changeLogToken. Based on my understanding of CMIS specification, I
assume that the API would not include a change log token in the request.
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 but 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 effect 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 query
returns the change events after the change log token. Therefore the test cases
passed.
In web services binding, the null value change log token and the maxItems
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 problem
(maxItems = 2147483647 by default) is a problem. Because CMIS specification
doesn't say anything about the default maxItems. We will do something at server
side to prevent such a unreasonable maxItems to be used in query.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
