Folder is not a folder???

[aweber1nj]

I'm getting the following exception (snippet) when I'm trying to create a new folder and add it to an existing folder.  This existing folder, the "prospective parent" is a custom folder type.

I was able to use the same code to add a folder to a cmis:folder parent, so I'm wondering if there's something special I need to do to tell cmis that the parent I'm trying to add this child-folder to is a cmis:folder subtype…but it should be able to check that very easily using the BaseTypeId.

Code snippet:

   String typePlusAspects = "F:" + curTypeName + ",P:sys:hidden";
            props.put(PropertyIds.NAME, nameTemplate);
            props.put(PropertyIds.OBJECT_TYPE_ID, typePlusAspects);
            fldrObj = destFolder.createFolder(props);
‍‍‍‍‍

Exception thrown:

org.apache.chemistry.opencmis.commons.exceptions.CmisInvalidArgumentException: Folder is not a folder!
   at org.alfresco.opencmis.CMISNodeInfoImpl.checkIfFolder(CMISNodeInfoImpl.java:756)
   at org.alfresco.opencmis.AlfrescoCmisServiceImpl.getOrCreateFolderInfo(AlfrescoCmisServiceImpl.java:292)
   at org.alfresco.opencmis.AlfrescoCmisServiceImpl.createFolder(AlfrescoCmisServiceImpl.java:1055)
   at org.alfresco.opencmis.AlfrescoCmisServiceImpl.create(AlfrescoCmisServiceImpl.java:1019)
   at sun.reflect.GeneratedMethodAccessor770.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)‍‍‍‍‍‍‍‍

Any ideas?

Thanks again,
AJ

[afaust]

Hello,

if "curTypeName" is "Folder", than this won't work as "Folder" is not a valid type(name). As far as I see it, this probably has nothing to do with the type of the target folder, just with the proposed type of the child folder.  "curTypeName" should be the qualified name (namespace/prefix + localName) of a content type in Alfresco (see Alfresco Data Dictionary guide in the wiki) which extends from "cm:folder" built-in type that maps to "cmis:folder".

Regards
Axel

[aweber1nj]

The folder type I am trying to create is efr:legal_folder. As you can see, it gets prefixed with F: as well.

I have already created one using this code successfully (in many tests),  the error occurs when I create one and try to link it to the first one (to make a child of the first one I created).

The first one creates perfectly, and I verify that with Share, Explorer, and cmis workbench.  And stepping through the debugger, the original is absolutely instantiated as alfrescofolderimpl (and the properties are correct).

That's why I think it is the CMIS service checking the parent during create, and not correctly identify it as a folder subtype.

[aweber1nj]

I verified this further with another test.  I changed the type of the "parent folder" to be a regular folder (cmis:folder).  I created it (with Apache Chemistry/Alfresco OpenCMIS Extension), then tried linking 4 subfolders to that parent. All 4 subfolders are of a custom folder type.  All 4 created and linked perfectly.

However, in this test, I did not change the folder name of the parent (rename it) between creating it and trying to create and link the "children".  Again, this worked.  I try to re-fetch the parent before linking the newly created children, using getObject and a OperationContext with setCacheEnabled = FALSE – always.

But I think something might be getting screwed-up in the cache, because if I let the code rename the parent, then re-fetch it (using getObject with cache disabled), then use that in my destFldr.createFolder( ), it fails with the aforementioned exception.

So my hypothesis changed.

Going to continue testing and "playing with" OperationContexts to see if I can sort it out.  The mystery remains!

Happy to provide further details if needed.
-AJ

[aweber1nj]

OK, maybe someone can explain the "best practices" for this, because I think I found my problem, and it has to do with an inconsistency, but may or may-not be an Alfresco bug…

In my code, I create a folder (any folder, I do them all with the same method) :

Folder fldrObj = destFolder.createFolder(props);

This returns a new Folder (yes, of course…bear with me ).  Getting the objectId of this new folder via fldrObj.getId() gives me this long string, ending with a UUID.  Fine.

Next, if I have to update the properties of the "new" folder, I change-up my property-map and use:

ObjectId retID = fldrObj.updateProperties(props, true);

This ObjectId, when I do a .getId() on it has the identical string as before, except a ";1.0" appended.  Interesting, I say.  I guess Alfresco auto-versioned the folder or something when I updated the properties.  Fine.  The updated ID works fine if I go re-fetch the folder object:
fldrObj = session.getObject(retID);

BUT, if I use that ID with the suffix in a getObject() and then use that folder like this:
Folder nextFldr = fldrObj.createFolder(props);
That is when it fails with the "Folder is not a folder!" exception.

Now, if I take off that suffix – if I keep the original objectId from the first time I saved the folder – the next folder can be created and linked as a child just fine.  Furthermore, if I perform a getObjectByPath() on the path of the first folder, it too does not return the suffix.

So the bottom-line is that there seems to be an inconsistency in the ObjectId's returned from a CmisObject versus what gets returned in a CmisObject.updateProperties() method…and Alfresco (or CMIS) does not like it if you use the "extended version".

With all that said, maybe someone knows the root-reason for all this, and which .getId() methods we should trust to always work, and which ones to stay away from?

Thanks for hearing me out…
-AJ

[pankajt]

I am facing exactly the same problem.

A cmis:folder after creation is fetching a guid say 'xxx'. After updating the same folder, the guid returned is 'xxx;1.0'. On the other hand, documents are returning the same guid before and after update.

I think this is an alfresco issue.

Can somebody help us out on what is going wrong in here.