[
https://issues.apache.org/jira/browse/CMIS-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118959#comment-15118959
]
Florian Müller commented on CMIS-968:
-------------------------------------
It makes absolute sense to set this secondary type. The client deliberately
indicates that this objects should now be put under retention management, which
in some repositories cannot be undone. The client also chooses a retention type
with that. CMIS defines two types (client managed retention and destruction
retention) and a repository could define many more. Without the secondary type
the repository would have to guess, which is pretty bad if the decision was
wrong and cannot be undone.
Apart from that, it would be more confusing if retention management secondary
types would be treated differently from other secondary types. Once a developer
has understood how to work with secondary types, setting this one is pretty
obvious.
Those rules are also not binding specific. They are valid for the Browser
binding, the AtomPub binding, and Web Services binding. It's just a (necessary)
OpenCMIS implementation detail that the types and properties are checked early
when the Browser binding is used.
> Broswer binding failed to check the property list for secondary type when
> update/create properties for secondary type
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: CMIS-968
> URL: https://issues.apache.org/jira/browse/CMIS-968
> Project: Chemistry
> Issue Type: Bug
> Components: opencmis-server
> Affects Versions: OpenCMIS 0.13.0
> Environment: Windows2008R2
> Reporter: Xian Zou
>
> I am developing retention management in CMIS1.1 which
> cmis:secondaryObjectTypeIds is cmis:rm_destructionRetention. After complete
> the server code for CM repository, I tried to develop a JUNIT case to
> create/update a document with the cmis:rm_expirationDate and
> cmis:rm_destructionDate property. All create/update operations works as
> design for atompub binding, but failed in browser binding with the following
> error.
> org.apache.chemistry.opencmis.commons.exceptions.CmisInvalidArgumentException:
> cmis:rm_expirationDate is unknown!
> at
> org.apache.chemistry.opencmis.client.bindings.spi.browser.AbstractBrowserBindingService.convertStatusCode(AbstractBrowserBindingService.java:249)
> at
> org.apache.chemistry.opencmis.client.bindings.spi.browser.AbstractBrowserBindingService.post(AbstractBrowserBindingService.java:377)
> at
> org.apache.chemistry.opencmis.client.bindings.spi.browser.ObjectServiceImpl.updateProperties(ObjectServiceImpl.java:400)
> at
> org.apache.chemistry.opencmis.client.runtime.AbstractCmisObject.updateProperties(AbstractCmisObject.java:349)
> at
> org.apache.chemistry.opencmis.client.runtime.AbstractCmisObject.updateProperties(AbstractCmisObject.java:313)
> at
> com.ibm.ecm.cmis.test.opencmis.util.TestUtils.updateDocument(TestUtils.java:2568)
> at
> com.ibm.ecm.cmis.test.opencmis.object.common.DocumentCRUD.createDocument(DocumentCRUD.java:172)
> Here is my sample code for the update logic as the example.
> Map<String, Object> updateProperties = new HashMap<String, Object>();
> String newName = "updatedname" + TestUtils.getRandomInt(10000);
> updateProperties.put("cmis:name", newName);
> updateProperties.put("clbNonGroup.CMISString", newName);
> Calendar c = getTestCalendar(2);
> Calendar c2 = getTestCalendar(3);
> updateProperties.put(PropertyIds.SECONDARY_OBJECT_TYPE_IDS,
> secondObjTypeIds);
> updateProperties.put(PropertyIds.EXPIRATION_DATE, c);
> updateProperties.put(PropertyIds.DESTRUCTION_DATE, c2);
> Document updatedDoc = TestUtils.updateDocument(session,
> doc.getId(), updateProperties);
> I checked the chemistry code and found the following logic may cause the
> "cmis:rm_expirationDate is unknown!" error" in createNewProperties and
> createUpdateProperties methods in AbstractBrowserServiceCall.java.
> PropertiesImpl result = new PropertiesImpl();
> for (Map.Entry<String, List<String>> property :
> properties.entrySet()) {
> PropertyDefinition<?> propDef =
> typeCache.getPropertyDefinition(property.getKey());
> if (propDef == null && objectIds != null) {
> for (String objectId : objectIds) {
> typeCache.getTypeDefinitionForObject(objectId);
> propDef =
> typeCache.getPropertyDefinition(property.getKey());
> if (propDef != null) {
> break;
> }
> }
> }
> if (propDef == null) {
> throw new CmisInvalidArgumentException(property.getKey() + "
> is unknown!");
> }
> result.addProperty(createPropertyData(propDef,
> property.getValue()));
> }
> Actually, when we create/update an document, the type definition in the code
> above will be gotten from the primary object type. The properties for
> secondary object types will not be gotten in the type definitions , so I
> think it should be a bug for browser binding. Here are some possible
> solutions for the issue.
> Possible solution 1: Don't check the properties and throw the
> CmisInvalidArgumentException(property.getKey() + " is unknown!"); exception
> for browser binding like other bindings.
> Possible solution 2: Check the properties in type definitions in both primary
> object type and all possible/passed secondary types. If we find the property
> in either of them. We will not throw the exception.
> If I develop the code in wrong way, please tell me how to write it correctly.
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
