Hi Florian, thx for quick response. This makes much more sense now.
According to 2): I simply forgot to set the value of the Holder with the latest token on server side. Now all my unit tests shine green ;) Thx for the hint. Cheers Sascha > Am 06.03.2015 um 17:17 schrieb Florian Müller <f...@apache.org>: > > Hi Sascha, > > The maxItems parameter defines how many entries should be returned (at most). > If the client does not specify the maxItems parameter, the server can decide. > > I agree the spec wording could be better. It should be: > > "If not specified, then the repository MUST return the first change event > recorded in the change log [as the first result in the output]." > > A client can receive all change events from the beginning of time with one > call (if the repository supports this) by providing no change log token. > > > Re 2) > The latestChangeLogToken is not the one that is passed in. It's a holder > variable that is updated in the getContentChanges() method of the respective > binding implementation. Whatever the server returned as "changeLogToken" is > used here. > > > - Florian > > >> 2) >> I am a bit irritated about client library behaviour when getting >> latestChangeLogToken from ChangeEvent: >> It seems to always return the token which is passed as argument of >> method ‚getContentChanges‘. >> A look inside SessionImpl class confirmed that the token parameter is >> passed through to create ChangeEventsImpl. >> Shouldn’t the latestChangeLogToken be the one at the end of the >> changeEvents List retrieved from server? >> Due to spec the token which is passed as parameter should be the FIRST >> result in the output. So the first change event in list should >> correspond to this token. >> And the latestChangeLogToken should be „The change log token >> corresponding to the LAST change event in changeEvents.“ >> Do I miss sth. here? >> (Don’t want to immediately create a bug ticket because I think its >> more probably that I misunderstood sth.) >> tia >> Cheers >> Sascha >> Am 06.03.2015 um 12:23 schrieb Sascha Homeier >> <shome...@apollon.de<mailto:shome...@apollon.de>>: >> Hello together, >> I am currently implementing the ChangeLog functionality on server side >> and have a question concerning the spec conformant behavior of >> Discovery Service „getContentChanges“: >> Due to get the very first change event the CMIS spec 1.1 says I need >> to pass a null changeLogToken parameter: >> * String changeLogToken: If specified, then the repository MUST >> return the change event corresponding to the value of the specified >> change log token as the first result in the output. >> If not specified, then the repository MUST return the first change event >> recorded in the change log. >> So did I understand it correctly that at server side I should only >> pass ONE change event which must be the very first event (either from >> beginning if ChangeLog capability provides complete log or otherwise >> from the point in time when changes were recorded)? >> So if I am on the right track I think to get ALL change events from >> beginning of the ChangeLog on client-side I should first ask for the >> first change event with token parameter null and then ask for the >> events since that token. >> So client-code should look like that imho: >> // get very first change event >> ItemIterable<ChangeEvent> contentChanges = >> cmisSession.getContentChanges(null, includeProperties); >> ChangeEvent veryFirstChangeEvent = contentChanges.iterator().next(); >> // get change log token of very first event and ask for the first page >> of change events on going-forward basis >> CmisObject veryFirstCmisObject = >> cmisSession.getObject(veryFirstChangeEvent.getObjectId()); >> ChangeEvents allContentChangesFirstPage = >> cmisSession.getContentChanges(veryFirstCmisObject.getChangeToken(), >> includeProperties, maxItems); >> It would be nice if someone could just confirm if this is the intended >> and spec compliant repository behaviour. >> I am not fully sure if the server reply for a null token parameter >> should really only be ONE change event (the very first) or ALL change >> events beginning with the very first. >> thx in advance. >> Cheers >> Sascha >
