id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
579	Unexisting paths not handled in getObjectByPath method	car031		"My colleague encountered a nasty little bug in LogicalDOC's CMIS 
support. He ported the Apache VFS CMIS provider to the latest version of 
Apache VFS (check it out here: 
https://github.com/topicusfinan/commons-vfs-cmis)

The bug is in the ""getObjectByPath"" method, when calling it with a 
non-existing path. A little funny, but this is the way the VFS provider 
works. It then catches the CmisObjectNotFoundException and goes on its 
merry way (generating an imaginary VFS file, which will be created for 
real later).

The bug is that the ""getObjectByPath"" method does not throw a 
CmisObjectNotFoundException, but rather just returns NULL. The OpenCMIS 
framework specifies that that is illegal in the Javadoc above the 
method: ""Object infos should contain the returned object."" (See here for 
the class: 
https://svn.apache.org/repos/asf/chemistry/opencmis/trunk/chemistry-opencmis-commons/chemistry-opencmis-commons-impl/src/main/java/org/apache/chemistry/opencmis/commons/impl/server/AbstractCmisService.java)

The fix for the bug would be in function 
com.logicaldoc.cmis.LDRepository.getObjectByPath(CallContext, String, 
String, Boolean, IncludeRelationships, String, Boolean, Boolean, 
ExtensionsData). Just append the lines to LDRepository.java around line 
992 (replacing ""return out;""):

if (out == null) {
     throw new CmisObjectNotFoundException(""Object not found!"");
} else {
     return out;
}

This prevents 
org.apache.chemistry.opencmis.server.impl.atompub.ObjectService$GetObjectByPath.serve 
throwing a stacktrace, and instead returns a correct 404 HTTP response.

With kind regards,

Jurrie Overgoor"	bug	closed	minor	7.3	CMIS	7.2.1	fixed		oliver.pehnke@… jurrie@…