well, when I was testing some of the CMIS sevices, I got the error as attached in the file repeatedly for some of the OOTB services. When I started digging into its genesis, I found the following. I think EMC should address such issues at the earliest.
Core issue for services such as getObject(id) or getObjectByPath(string)
---------------------------------------------------------------------------------------------------------
[E_CANT_INIT_TYPE_INFO_CACHE] Cant initialize TypeInfoCache: {0}.
[DM_QUERY_E_SYNTAX] [DM_QUERY_E_SYNTAX]error: "A Parser Error (yacc stack overflow) has occurred in the vicinity of: ','dm_cache_config','dm_job_sequence','dm_locator','dm_job_request','dm_qual_comp','dm_component','dm_application','dm_app_ref','dm_retainer','dm_sysprocess_config','dm_jms_config','dm_migrate_rule','dmc_wfsd_element_parent','dmc_wfsd_element','dmc_wfsd_element_integer','dmc_wfsd_element_string','dmc_wfsd_element_double','dmc_wfsd_element_boolean','dmc_wfsd_element_date','dmc_process_parameter','dmc_wf_package_type_info','dm_ftengine_config','dm_ftindex_agent_config','dm_ssa_policy','dm_docset',"
org.apache.chemistry.opencmis.commons.exceptions.CmisRuntimeException: Failed to get types from repository: lexecmtrain
[E_CANT_INIT_TYPE_INFO_CACHE] Cant initialize TypeInfoCache: {0}.
[DM_QUERY_E_SYNTAX] [DM_QUERY_E_SYNTAX]error: "A Parser Error (yacc stack overflow) has occurred in the vicinity of: ','dm_cache_config','dm_job_sequence','dm_locator','dm_job_request','dm_qual_comp','dm_component','dm_application','dm_app_ref','dm_retainer','dm_sysprocess_config','dm_jms_config','dm_migrate_rule','dmc_wfsd_element_parent','dmc_wfsd_element','dmc_wfsd_element_integer','dmc_wfsd_element_string','dmc_wfsd_element_double','dmc_wfsd_element_boolean','dmc_wfsd_element_date','dmc_process_parameter','dmc_wf_package_type_info','dm_ftengine_config','dm_ftindex_agent_config','dm_ssa_policy','dm_docset',"
at org.apache.chemistry.opencmis.client.bindings.spi.webservices.AbstractWebServicesService.convertException(AbstractWebServicesService.java:93)
at org.apache.chemistry.opencmis.client.bindings.spi.webservices.ObjectServiceImpl.getObjectByPath(ObjectServiceImpl.java:402)
at org.apache.chemistry.opencmis.client.runtime.PersistentSessionImpl.getObjectByPath(PersistentSessionImpl.java:449)
at org.apache.chemistry.opencmis.client.runtime.PersistentSessionImpl.getObjectByPath(PersistentSessionImpl.java:420)
at com.lexmark.poc.cmis.GenericTestClass.fetchObjectSOAP(GenericTestClass.java:76)
at com.lexmark.poc.cmis.GenericTestClass.testSOAPBinding(GenericTestClass.java:46)
at com.lexmark.poc.cmis.GenericTestClass.main(GenericTestClass.java:28)
My Observation
----------------------
1. The DFS services implementation have been tweaked for the CMIS implementation. That is, if you open up the DFS impl classes for a non CMIS package and compare with the same classses from a CMIS package, you will see some difference. For example, for the above service call, the DFS side flow for the CMIS package was SchemaService-->SchemaInfoFacade--->SchemaServiceLoader--->SchemaInfoLoader---->TypeInfoFacade whereas for a non-CMIS package, the DFS flow would be SchemaService-->SchemaInfoFacade---->SchemaServiceCache---->SchemaInfoCache----->TypeInfoFacade-->TypeInfoCache. We are using the DFS 6.5, I am not sure if the subsequent versions of DFS changed the underlying implementation and the CMIS is using the latest impl. However, if that is not the case, then I think we should have a problem of version mismatch b/w the CMIS DFS and non-CMIS DFS just incase one should want to use the same installation for both (ie CMIS and DFS) purposes
2. In the CMIS DFS implementation, the above error is caused by a faulty implementation as explained below.
com.emc.documentum.fs.services.core.impl.schema.TypeInfoFacade
------------------------------------------------------------------------------------------------------
private String toSQLString(List items)
{
StringBuilder builder = new StringBuilder();
String item;
for(Iterator iterator = items.iterator(); iterator.hasNext(); builder.append((new StringBuilder("'")).append(item).append("',").toString()))
item = (String)iterator.next();
return builder.substring(0, builder.length() - 1);
}
The above method actually helps build a query for fetching some DD info as part of the schema services implementation. As you would note, it comma separates the passed in params and then returns a string while attempting to dropthe last comma. But the use of "builder.length() - 1" dos not drop the comma and hence you would see the following error on the server side. NB: Spot a comma(,) at the very end of the string. Well, the worrying point about this is that it is a DFS implementation bug and hence will impact the actual DFS schema services whether we use CMIS or not.
Caused by: DfException:: THREAD: http-7080-Processor24; MSG: [DM_QUERY_E_SYNTAX]error: "A Parser Error (yacc stack overflow) has occurred in the vicinity of: ','dm_cache_config','dm_job_sequence','dm_locator','dm_job_request','dm_qual_comp','dm_component','dm_application','dm_app_ref','dm_retainer','dm_sysprocess_config','dm_jms_config','dm_migrate_rule','dmc_wfsd_element_parent','dmc_wfsd_element','dmc_wfsd_element_integer','dmc_wfsd_element_string','dmc_wfsd_element_double','dmc_wfsd_element_boolean','dmc_wfsd_element_date','dmc_process_parameter','dmc_wf_package_type_info','dm_ftengine_config','dm_ftindex_agent_config','dm_ssa_policy','dm_docset',"; ERRORCODE: 100; NEXT: null
