[ 
https://issues.apache.org/jira/browse/CMIS-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Ligios updated CMIS-1117:
--------------------------------
    Attachment: image-2021-05-18-12-27-45-903.png

> Using AtomPub binding I can create Folders calling createDocument
> -----------------------------------------------------------------
>
>                 Key: CMIS-1117
>                 URL: https://issues.apache.org/jira/browse/CMIS-1117
>             Project: Chemistry
>          Issue Type: Bug
>          Components: opencmis-server
>    Affects Versions: OpenCMIS 1.1.0
>            Reporter: Andrea Ligios
>            Priority: Minor
>         Attachments: image-2021-05-18-00-03-11-323.png, 
> image-2021-05-18-00-06-14-967.png, image-2021-05-18-00-20-40-800.png, 
> image-2021-05-18-12-19-22-907.png, image-2021-05-18-12-27-45-903.png
>
>
> I've met CMIS a couple of days ago, please forgive me in case the question is 
> naive.
> I have a test case that is trying to create a document by passing the 
> _*"cmis:folder"*_ ObjectTypeId (instead of _*"cmis:document"*_), and expects 
> the test to fail.
>  * With *Browser binding*, {color:#00875a}it fails with a 
> CmisConstraintException{color}
>  * With *WebService binding*, {color:#00875a}it fails with a 
> CmisConstraintException{color}
>  * With *AtomPub binding*,{color:#de350b} it creates a Folder, and then fails 
> later with a CmisRuntimeException{color}
> While debugging the code, I've seen that *Browser binding* (along with 
> *WebService binding*) has a *_createDocument()_* method in its [ObjectService 
> implementation|https://github.com/apache/chemistry-opencmis/blob/trunk/chemistry-opencmis-server/chemistry-opencmis-server-bindings/src/main/java/org/apache/chemistry/opencmis/server/impl/browser/ObjectService.java#L88-L137]:
> !image-2021-05-18-00-03-11-323.png|width=984,height=914!
> The *AtomPub Binding*, instead, has a _*create()*_ method in itsĀ 
> [ObjectService 
> implementation|https://github.com/apache/chemistry-opencmis/blob/trunk/chemistry-opencmis-server/chemistry-opencmis-server-bindings/src/main/java/org/apache/chemistry/opencmis/server/impl/atompub/ObjectService.java#L79-L158]:
> !image-2021-05-18-00-06-14-967.png|width=984,height=1609!
> While the _*createDocument()*_ method allows us to check if the ObjectTypeId 
> passed is the proper one (*_"cmis:document"_*), and to raise an error if an 
> unexpected ObjectTypeId is passed, the _*create()*_ method is agnostic about 
> the object to create, and forces us to perform a Switch on the ObjectTypeId 
> to detect the proper action to call.
> Hence, calling _*createDocument()*_ with *AtomPub binding* and 
> _*"cmis:folder"*_ ObjectTypeId will result in calling the _*create()*_ 
> method, and then in the switch reading _*"cmis:folder"*_ and calling the 
> underlying _*createFolder()*_ method, instead of the underlying 
> _*createDocument()*_ one.
> The folder will be created, then somewhere up in the chain[*] the error will 
> be detected and will trigger a *CmisRuntimeException*, but that implies that,
>  * for the same call, two different exceptions could be returned depending on 
> the binding used
>  * for the same call, the AtomPub binding will create an unwanted object 
> before returning an error 
> Could you please confirm me this is intended, and maybe shed some light on 
> why the *AtomPub binding* is working with a different set of creational 
> methods than the other bindings?
> Should we simply add a check in front of the calls to cover cases like this?
> [*] It's the [FolderImpl 
> class|https://github.com/apache/chemistry-opencmis/blob/trunk/chemistry-opencmis-client/chemistry-opencmis-client-impl/src/main/java/org/apache/chemistry/opencmis/client/runtime/FolderImpl.java#L83-L103]
>  that checks that the object created is of the expected type, and this seems 
> an attempt to cope with the problem... but one that leaves debris behind, 
> though (the folder created):
> !image-2021-05-18-00-20-40-800.png|width=985,height=472!
> Thank you in advance



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to