Hi Florian, if my implementation returns all properties in case of an empty filter I got no errors. If I change this there are many errors like this one:
FAILURE: Root folder children check (RootFolderTest.java:91) FAILURE: Child and object fetched by path don't match! Id: 4e548ef9c64904db9097cc01 (AbstractSessionTest.java:1414) FAILURE: Number of properties don't match (AbstractSessionTest.java:2036) INFO: expected: 14 / actual: 13 Best Regards, Achim -----Original Message----- From: Florian Müller [mailto:[email protected]] Sent: Donnerstag, 25. August 2011 13:00 To: Weigel, Achim Cc: [email protected] Subject: Re: Not set properties Hi Achim, The TCK should always set a "*" filter. If that's not the case, then it's a bug. Please let me know if you find one of those. The Workbench sets different filters based on the data it requires and based on the Workbench configuration. - Florian On 25/08/2011 11:50, Weigel, Achim wrote: > Hi Florian, > > the problem is gone with the new version of the workbench but might it be, > that the TCK of the workbench has the same problem, i.e. that it expects all > properties if the filter is not set? > > Best Regards, > Achim > > > -----Original Message----- > From: Florian Müller [mailto:[email protected]] > Sent: Dienstag, 23. August 2011 10:19 > To: Weigel, Achim > Cc: [email protected] > Subject: Re: Not set properties > > Hi Achim, > > Please get the latest Workbench code. The problem with the compliance button > has been fixed. > > getObjectInfo() only requires a small set of standard CMIS properties. But > the implementation provided by OpenCMIS is only there for convenience. > In order to improve the performance you should override getObjectInfo() or > getObjectInfoIntern() with your own implementation. > > > - Florian > > > On 23/08/2011 07:53, Weigel, Achim wrote: >> Hi Florian, >> >> thank you for the clarification. >> >> >> Now I have the following problem. When I'm using "Check specification >> compliance" button of the CMIS Workbench I get errors that some properties >> are not returned. I have debugged and found out that the filter is always >> set to "". I thought that in this case the repository could determine the >> properties it wants to return. >> If I handle this case as if the filter is set to "*" the errors are gone. >> >> Another point is the method getObjectInfo which is called several times, >> which has no filter parameter. Does this method pose any demands on the set >> of properties to return or is this also repository specific. >> >> Best Regards, >> Achim >> >> -----Original Message----- >> From: Florian Müller [mailto:[email protected]] >> Sent: Montag, 22. August 2011 15:58 >> To: [email protected]; Weigel, Achim >> Subject: Re: Not set properties >> >> Hi Achim, >> >> Not-set properties have to be returned (see CMIS spec). There must be a >> PropertyData object for each property. The value can be either null or an >> empty list. OpenCMIS understands both. >> getProperties() and getPropertyList() have to return the same objects for a >> property. The easiest way to assure that is to use the PropertiesImpl class. >> >> >> - Florian >> >> >> On 22/08/2011 14:47, Weigel, Achim wrote: >>> Hello, >>> >>> I'm not sure what is expected if no value is set at an object for some >>> property X and this property is requested e.g. via a '*' filter. >>> >>> a) ObjectService.getProperties(...) >>> For the resulting Properties object should getProperties() contain an >>> entry for X with a null value or a not null value PropertyData object? >>> For the resulting Properties object should getPropertyList() contain an >>> element for X? >>> >>> b) If in the case before getProperties() and getPropertyList() contain a >>> PropertyData entry for X what is expected for the method >>> 'PropertyData<T>.getValues()': null or an empty list? >>> >>> Thank you very much in advance and best regards, >>> Achim >> >
