[
https://issues.apache.org/jira/browse/CMIS-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346795#comment-17346795
]
Andrea Ligios commented on CMIS-1117:
-------------------------------------
Hi [~fmui],
I've checked [the
code|https://github.com/apache/chemistry-opencmis/blob/trunk/chemistry-opencmis-server/chemistry-opencmis-server-fileshare/src/main/java/org/apache/chemistry/opencmis/fileshare/FileShareRepository.java#L418-L425]
you linked and it suffers the same problem:
!image-2021-05-18-12-19-22-907.png|width=984,height=536!
As you can see, if you call _*FoldersImpl.createDocument()*_ passing
_*"cmis:folder"*_ as ObjectTypeId, _*FileShareRepository.create()*_ will
actually create a Folder, then _*FolderImpl.createDocument()*_ will complain
about the object created not being a Document, and throw an Exception.
But the object would have been created at that point, and not deleted.
!image-2021-05-18-12-27-45-903.png|width=984,height=470!
The opposite is also true (if you call _*FoldersImpl.createFolder()*_ with
_*"cmis:document"*_ you will actually create a Document).
Inside _*FileShareRepository.create()*_ you're using the ObjectTypeId to evince
the method to call - but you've already lost the knowledge of the calling
method at that point, there's nothing you can do with that ObjectTypeId alone.
Since the whole call didn't start from a _*create()*_ method but from a
_*createDocument()*_ or _*createFolder()*_ method, I think this is just a small
"workflow bug", with a very simple fix:
* check that the ObjectTypeId is _*"cmis:document"*_ in the first row of
_*FoldersImpl.createDocument()*_ and _*FoldersImpl.createDocumentFromSource()*_
* check that the ObjectTypeId is _*"cmis:folder"*_ in the first row of
_*FoldersImpl.createFolder()*_
Only this one check, which is needed to ensure the call will be steered
correctly inside the server's _*create()*_ method.
All the rest of the validation (nullity, consistency, etc.) will still happen
where it belongs, but this is the proper (and only possible) bugfix IMHO, it is
needed due to the agnostic nature of the AtomPub's _*create()*_ method.
The FolderImpl methods are even performing the check *after* the creation
(leaving unwanted objects behind),
let's check it also *before* the creation, and prevent the wrong calls in the
first place:
!image-2021-05-18-12-52-29-841.png|width=984,height=486!
Do you agree?
> 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,
> image-2021-05-18-12-52-29-841.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)
