[jira] [Commented] (CMIS-871) Client API Atompub binding - getContentChanges still sends change log token even though I specify null for the changeLogToken parameter
[
https://issues.apache.org/jira/browse/CMIS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14220169#comment-14220169
]
Florian Müller commented on CMIS-871:
-
Re #3: Use {{null}} as the change log token.
> 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
> Labels: getContentChanges
>
> 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)
[jira] [Commented] (CMIS-871) Client API Atompub binding - getContentChanges still sends change log token even though I specify null for the changeLogToken parameter
[ https://issues.apache.org/jira/browse/CMIS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14220118#comment-14220118 ] Vincent Tang commented on CMIS-871: --- Thank you Florian. I removed the changeLogToken from the changes link in RepositoryInfo. Now my tests passed. I think the only not answered question is #3. I cannot find a way in OpenCMIS API. Therefore I wrote a test case that directly sends HTTP requests. > 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 > Labels: getContentChanges > > 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)
[jira] [Commented] (CMIS-871) Client API Atompub binding - getContentChanges still sends change log token even though I specify null for the changeLogToken parameter
[ https://issues.apache.org/jira/browse/CMIS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219912#comment-14219912 ] Florian Müller commented on CMIS-871: - The link in the service document must not contain a change log token. Otherwise clients cannot generate a URL without a change log token and if the clients adds a change log token, the URL contains two, which might confuse the server. If you remove the change log token from the link, the AtomPub binding should behave like the other bindings. > 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 > Labels: getContentChanges > > 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)
[jira] [Commented] (CMIS-871) Client API Atompub binding - getContentChanges still sends change log token even though I specify null for the changeLogToken parameter
[ https://issues.apache.org/jira/browse/CMIS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219788#comment-14219788 ] Vincent Tang commented on CMIS-871: --- I found the change link in GetRepositoryInfo response is http://localhost:8080/fncmis/resources/ICNAutomation/changes?changeLogToken=1017991.0"; rel="http://docs.oasis-open.org/ns/cmis/link/200908/changes"; type="application/atom+xml;type=feed" title="Content changes of repository" cmisra:id="ICNAutomation"/> I think OpenCMIS Client API using this as the base for the first getContentChanges call. Do you think so? However if so, I have a couple of questions 1. Should I not include the changeLogToken in the changes link in RepositoryInfo, like the example in CMIS specification? 2. Why does web service binding behave differently? In my settings, the SOAP message from the same method doesn't include a change log token. 3. How do I make a call deliberately without a change log token so that I can get change events from the beginning of the change logs any time? Our implementation has a first link. How does OpenCMIS Client API support it? > 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 > Labels: getContentChanges > > 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)
[jira] [Commented] (CMIS-871) Client API Atompub binding - getContentChanges still sends change log token even though I specify null for the changeLogToken parameter
[
https://issues.apache.org/jira/browse/CMIS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219752#comment-14219752
]
Vincent Tang commented on CMIS-871:
---
My test code is very simple.
1. Create session
2. Get repository info which will get the latest change log token, cache the
change log token
3. Create a bunch of documents, delete some, update some so that the change
events will be created after we retrieve the latest change log token in step 2.
4. Call getContentChanges with null for changeLogToken
5. Delete these documets
The junit code of step 4 is below
@Test
public void testGetContentChangesWithoutChangeLogToken() throws Exception {
logger.info("**
testGetContentChangesWithoutChangeLogToken *");
ItemIterable changeEvents =
session.getContentChanges(null, false);
assertNotNull(changeEvents);
logger.info("Number of Change events: " +
changeEvents.getTotalNumItems());
}
I captured HTTP messages using TCPMON. I posted the complete trace below. The
only getContentChanges is the 3rd last one. It has a change log token.
GET /fncmis/resources/Service?repositoryId=ICNAutomation HTTP/1.1
GET
/fncmis/resources/ICNAutomation/Content?path=%2F&filter=&includeAllowableActions=true&includeACL=false
HTTP/1.1
GET /fncmis/resources/ICNAutomation/Type/cmis%3Afolder HTTP/1.1
GET
/fncmis/resources/ICNAutomation/ContentFlat/idf_0F1E2D3C-4B5A-6978-8796-A5B4C3D2E1F0?includeAllowableActions=true&includeRelationships=none&renditionFilter=cmis%3Anone&includePathSegment=true&maxItems=100&skipCount=0
HTTP/1.1
GET
/fncmis/resources/ICNAutomation/Content/idf_6FEB6A26-7438-4B7C-BA7C-82A3FD4D93FB?filter=&includeAllowableActions=true&includeACL=false
HTTP/1.1
GET
/fncmis/resources/ICNAutomation/Content/idf_6FEB6A26-7438-4B7C-BA7C-82A3FD4D93FB?filter=&includeAllowableActions=true&includeACL=false
HTTP/1.1
POST
/fncmis/resources/ICNAutomation/ContentFlat/idf_6FEB6A26-7438-4B7C-BA7C-82A3FD4D93FB
HTTP/1.1
GET
/fncmis/resources/ICNAutomation/Content/idf_BD4A8268-71EF-45B0-8C13-C57F8A302000?filter=&includeAllowableActions=true&includeACL=false
HTTP/1.1
GET /fncmis/resources/ICNAutomation/Type/cmis%3Adocument HTTP/1.1
POST
/fncmis/resources/ICNAutomation/ContentFlat/idf_BD4A8268-71EF-45B0-8C13-C57F8A302000?versioningState=major
HTTP/1.1
GET
/fncmis/resources/ICNAutomation/Content/idd_29ACEDB9-D075-4FA2-B062-2733ED5FB329?filter=&includeAllowableActions=true&includeACL=false
HTTP/1.1
POST
/fncmis/resources/ICNAutomation/ContentFlat/idf_BD4A8268-71EF-45B0-8C13-C57F8A302000?versioningState=major
HTTP/1.1
GET
/fncmis/resources/ICNAutomation/Content/idd_79F812B4-0AC8-4461-BC00-ECB9DF5A13C4?filter=&includeAllowableActions=true&includeACL=false
HTTP/1.1
POST
/fncmis/resources/ICNAutomation/ContentFlat/idf_BD4A8268-71EF-45B0-8C13-C57F8A302000?versioningState=major
HTTP/1.1
GET
/fncmis/resources/ICNAutomation/Content/idd_D270A01F-6712-40ED-8A78-D36645FE8CB6?filter=&includeAllowableActions=true&includeACL=false
HTTP/1.1
POST
/fncmis/resources/ICNAutomation/ContentFlat/idf_BD4A8268-71EF-45B0-8C13-C57F8A302000?versioningState=major
HTTP/1.1
GET
/fncmis/resources/ICNAutomation/Content/idd_D079C925-9998-4E56-A9DF-B57B62D7BDE7?filter=&includeAllowableActions=true&includeACL=false
HTTP/1.1
POST
/fncmis/resources/ICNAutomation/ContentFlat/idf_BD4A8268-71EF-45B0-8C13-C57F8A302000?versioningState=major
HTTP/1.1
GET
/fncmis/resources/ICNAutomation/Content/idd_4967AC5A-AEC1-4E6B-BB2A-3CFE79915CD7?filter=&includeAllowableActions=true&includeACL=false
HTTP/1.1
POST
/fncmis/resources/ICNAutomation/ContentFlat/idf_BD4A8268-71EF-45B0-8C13-C57F8A302000?versioningState=major
HTTP/1.1
GET
/fncmis/resources/ICNAutomation/Content/idd_F2C8A180-83E4-48C1-B508-9F12F5DC3B2B?filter=&includeAllowableActions=true&includeACL=false
HTTP/1.1
POST
/fncmis/resources/ICNAutomation/ContentFlat/idf_BD4A8268-71EF-45B0-8C13-C57F8A302000?versioningState=major
HTTP/1.1
GET
/fncmis/resources/ICNAutomation/Content/idd_02CFFB5F-49E1-4AB1-8E50-469ADF655695?filter=&includeAllowableActions=true&includeACL=false
HTTP/1.1
POST
/fncmis/resources/ICNAutomation/ContentFlat/idf_BD4A8268-71EF-45B0-8C13-C57F8A302000?versioningState=major
HTTP/1.1
GET
/fncmis/resources/ICNAutomation/Content/idd_4E4E53DB-C735-49F3-8823-236E903BB6C2?filter=&includeAllowableActions=true&includeACL=false
HTTP/1.1
POST
/fncmis/resources/ICNAutomation/ContentFlat/idf_BD4A8268-71EF-45B0-8C13-C57F8A302000?versioningState=major
HTTP/1.1
GET
/fncmis/resources/ICNAutomation/Content/idd_A92B1782-9DC1-486C-80C3-86F0846AF78D?filter=&includeAllowableActions=true&includeACL=false
HTTP/1.1
POST
/fncmis/resources/ICNAutomation/ContentFlat/idf_BD4A8268-71EF-45B0-8C13-C57F8A302000?versioningState=major
HTTP/1.1
GET
/fncmis/resources/ICNAutomation/Content/idd_97365CF7-3E18-4156-8BFC-FA96D574D18A?filter=&i
[jira] [Commented] (CMIS-871) Client API Atompub binding - getContentChanges still sends change log token even though I specify null for the changeLogToken parameter
[
https://issues.apache.org/jira/browse/CMIS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219688#comment-14219688
]
Florian Müller commented on CMIS-871:
-
Re 1. The AtomPub binding doesn't send a changeLogToken. Where should it come
from?
This is a generated URL:
{{http://localhost:8080/inmemory/atom11/A1/changes?includeProperties=false&includePolicyIds=false&includeACL=false&maxItems=2147483647}}
The session.getContentChanges(null, false) method emulates paging. That is, if
the first page contained a next link (with a changeLogToken), it will call this
link to get the second page. This second call must have a changeLogToken,
otherwise paging wouldn't work. But that's the same for the Web Services and
the Browser binding.
Re 2. maxItems only defines number of items that must not be exceeded by the
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 next page
that the client can fetch.
The whole point of this getContentChanges() method is to eventually read the
complete change log. Using large pages minimizes the number of calls.
The session interface provides other getContentChanges() methods to only get
the tip or an excerpt of the change log.
> 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
> Labels: getContentChanges
>
> 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)
