Fwiw, we've had a solution using Chemistry to talk to SP 2010 for about two years. We also ran into some limitations in the SP 2010 CMIS implementation - as I recall, it was a bit constrained in what meta-data you could specify as a predicate in a query and that caused us some issues in implementing some code to check if our client code had the latest version of an object cached locally. We also had some problems getting NTLM authentication to work and encountered some performance issues. All of our access was to document libraries so we didn't try to look at Calendars. But it eventually worked out ok for us and our customer (who had lots of stuff in SP, so switching to a different CMS wasn't an option for them).
thx, g George Florentine VP Engineering Office: 303.542.2173 | Mobile: 303.669.8628 | Fax: 303.542.0522 [email protected] | http://www.flatironssolutions.com/ Tw: @FlatironsSols | Fb: https://www.facebook.com/FlatironsSolutions -----Original Message----- From: Prahalad Deshpande [mailto:[email protected]] Sent: Wednesday, April 09, 2014 9:46 AM To: [email protected] Subject: Re: Exception while obtaining the root folder of a Sharepoint 2010 Calendar list Ok.. thanks for this information :). This query saved me a lot of time from debugging some exceptions only to find out later that MS Sharepoint does not support all of the CMIS specification On Wed, Apr 9, 2014 at 6:24 PM, Mark Streit <[email protected]> wrote: > I'm only offering an opinion here so please keep that in mind. We > worked for a number of months trying to make Sharepoint 2010 work with > a CMIS client application that we were building. > > We were using AtomPub and OpenCMIS 0.8.0. It was an uphill battle on > numerous fronts as far as SP 2010 went in terms of CMIS spec compliance. > We were able to get only a handful of basic operations to work. When > we began to try certain CMIS-SQL cases, it was worse. Admittedly, and > supposedly, SP 2013 was to address some of the CMIS issues. However, > We could not wait and switched to Alfresco 4.x > > Every use case we had worked OOTB once we got our custom content model > in place with XML files deployed on the server side with Alfresco. > Granted, this entire project we built was on Java (both client and server > sides). > > You may also wish to check out this book which is great. > > http://www.manning.com/mueller/ > > For the record, I don't work for Alfresco or Manning publishing. What > I can say is Alfresco is clearly ahead in CMIS compliance and was the > solution after we could not make SP 2010 work and could not wait on SP > 2013 due to time constraints. Your constraints and requirements will > obviously be different. > > > > Mark > > > On Wednesday, April 9, 2014, Prahalad Deshpande <[email protected]> > wrote: > > > Hello All, > > > > I am currently evaluating Apache Chemistry to retrieve information > > from a Sharepoint 2010 server. > > > > I have a simple CLI-based java application which uses the Apache > Chemistry > > client libraries. > > > > I am using the web service endpoints in my application; however the > > error also occurs for ATOMPUB URL. > > > > Apache Chemistry will enumerate a Sharepoint 2010 Calendar as a > repository. > > I set the repository ID within the session parameter and then make a > > call to *getRootFolder() *as shown below: > > > > *Folder rootFolder = session.getRootFolder();* > > > > The above call for a calendar item yields the following exception > > stack > > trace: > > > > Exception in thread "main" > > > > > org.apache.chemistry.opencmis.commons.exceptions.CmisInvalidArgumentException: > > typeId > > at > > > > > org.apache.chemistry.opencmis.client.bindings.spi.webservices.Abstract > WebServicesService.convertException(AbstractWebServicesService.java:10 > 9) > > at > > > > > org.apache.chemistry.opencmis.client.bindings.spi.webservices.Reposito > ryServiceImpl.getTypeDefinition(RepositoryServiceImpl.java:133) > > at > > > > > org.apache.chemistry.opencmis.client.bindings.impl.RepositoryServiceIm > pl.getTypeDefinition(RepositoryServiceImpl.java:137) > > at > > > > > org.apache.chemistry.opencmis.client.runtime.SessionImpl.getTypeDefini > tion(SessionImpl.java:525) > > at > > > > > org.apache.chemistry.opencmis.client.runtime.repository.ObjectFactoryI > mpl.getTypeFromObjectData(ObjectFactoryImpl.java:258) > > at > > > > > org.apache.chemistry.opencmis.client.runtime.repository.ObjectFactoryI > mpl.convertObject(ObjectFactoryImpl.java:565) > > at > > > > > org.apache.chemistry.opencmis.client.runtime.SessionImpl.getObject(Ses > sionImpl.java:414) > > at > > > > > org.apache.chemistry.opencmis.client.runtime.SessionImpl.getRootFolder > (SessionImpl.java:489) > > at > > > > > org.apache.chemistry.opencmis.client.runtime.SessionImpl.getRootFolder > (SessionImpl.java:483) > > at CMISConnectorDriver.main(CMISConnectorDriver.java:95) > > > > I am however able to retrieve the root folder of a Document Library > without > > any problems. is this a known issue or bug with Chemistry? > > > > > > > > > > -- > > With warm regards > > > > Prahalad > > > > > -- > Regards, > > Mark > > Sent from Gmail Mobile on iPhone > -- With warm regards Prahalad
