chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <>
Subject Re: Connecting OpenCMIS to an ElasticSearch index on an object storage.
Date Fri, 06 Oct 2017 15:53:34 GMT
Hi Tycho,

This simplest code sample is propably this one:
It's a smaller and newer version of the Server Development Guide code. and and 
correspond to AbstractServiceFactory and AbstractCmisService. If you 
need a staring point, take the files from the link above.
If you are using Maven, use the archetype 
"chemistry-opencmis-server-archetype" to generate an OpenCMIS server 

Then follow the CMIS specification and don't use the source code from 
the link above. There are some bits and pieces that you may want to 
reuse, but I wouldn't try to refactor the code. Your own clean 
implementation is better to maintain in the long run.

Use the CMIS Workbench to test your server. After implementing a 
feature, run the TCK from the Workbench. It will lead you to bugs and 
compliance issues. It might be a bit frustrating in the beginning to see 
a lot of tests failing, but that will change over time. Writing a first, 
simple, read-only server should only take a few days.

- Florian

> Florian,
> Thanks for your reply. I see that I have misinterpreted the use of the
> OpenCMIS Server Development Guide. Based on your response, I think it
> is better for us to start from scratch. I have a some questions about
> the implementation if we do start from scratch:
>  - You say we need two classes, one derived from
> AbstractServiceFactory, and one from AbstractCmisService - where can I
> find the minimal required project code in which I can implement these
> two classes without having to remove all the code that does not work
> for us? I found this page
> (
> through [OpenCMIS Downloads] -> [Web Archives] -> [OpenCMIS Server
> War], but I can not see the contents of the war file because I am
> currently working on a PC that can not open it.
>  - Do the two classes that I need to implement correspond with the
> classes "" and
> "" in the OpenCMIS Server Development Guide
> project? If so, should I base my version of these two files on our
> needs combined with the CMIS specifications, or should they mimic the
> files from the OpenCMIS Server Development Guide project?
>  - Should I be able to test my new implementation using the CMIS
> workbench tool that the OpenCMIS Server Development Guide also uses?
> Thanks in advance,
> Tycho
> Florian Müller schreef op 2017-10-06 12:41:
>> Hi Tycho,
>> The OpenCMIS server framework has been used by several companies to
>> build CMIS servers. (Alfresco, Nuxeo, SAP, IBM, OpenText, to name a
>> few.) They all have different back-ends with different structures or
>> no structure at all. It's absolutely feasible to implement a CMIS
>> server with the OpenCMIS server framework on top of another data
>> source.
>> The OpenCMIS Server Development Guide has originally been written for
>> a hands-on training. The participants should implement a CMIS server
>> within 3 hours. Because of the short period of time, we required a
>> backend all participants were familiar with - the file system.
>> I don't know what is better option for you, taking the code and
>> changing it or starting from scratch. Both have pros and cons.
>> In the end, you need two classes. One derived from
>> AbstractServiceFactory and one derived from AbstractCmisService.
>> Implement the read-only operations first.
>> - Florian
>>> Hello,
>>> In the project I am currently working on, I am trying to implement an
>>> OpenCMIS Server to enable a CMIS connection to our repository.
>>> Following the OpenCMIS Server Development Guide from the 
>>> corresponding
>>> Github page (see addendum links), I managed to get the Java project
>>> running in Eclipse using Maven and a Tomcat server. In the default
>>> state, this project works with a repository based on a file system
>>> structure. In other words, it assumes a root and a directory/file
>>> structure and uses the Java File class to simulate this logic.
>>> However, the repository I am trying to connect to is an object 
>>> storage
>>> repository. This means that there is no mention of a file, or
>>> directory. On top of this object storage we have an ElasticSearch
>>> index in which some structure is defined (i.e. there is a file system
>>> like structure through parent/child relationships in the index). I am
>>> now wondering if it is possible to rewrite the provided code in such 
>>> a
>>> way that it can handle such an object instead of a Java File object.
>>> My attempts thus far have been unsuccessful, but I have not changed
>>> all the required parts of the project yet. After working mainly in 
>>> the
>>> "" file, I noticed that removing the File
>>> structure from that file raised errors in files higher up the chain,
>>> because they expect a File object to be returned.
>>> My question would then be: "Is it feasible to rewrite this project to
>>> a project that can handle different object types?". If the only way 
>>> to
>>> do that is to rewrite the entire framework, I am unsure if it is even
>>> worth it.
>>> I will be glad to explain more details about my project if more
>>> information is required.
>>> Kind regards,
>>> Tycho Nijon
>>> -----
>>> addendum:
>>> [OpenCMIS Server Development Guide PDF]
>>> [OpenCMIS Server Development Guide github]
> --
> Digitaal Archief Service
> mob      +31 6 43599147
> mail
> web
> adres:   Schieland 18, 1948RM, Beverwijk
> DiVault in beeld: VIDEO <>
> Deze e-mail inclusief inhoud is alleen voor de ontvanger van deze 
> e-mail.
> Elk gebruik anders dan gebruik door de ontvanger is verboden en 
> onrechtmatig.
> De verzender is niet verantwoordelijk voor de juiste en complete 
> verzending
> van de informatie noch voor enige vertraging.
> This email and any attachments thereto may contain private, 
> confidential,
> and privileged material for the sole use of the intended recipient.
> Any review, copying, or distribution of this email (or any attachments 
> thereto)
> by others is strictly prohibited. If you are not the intended 
> recipient,
> please contact the sender immediately and permanently delete the 
> original and
>  any copies of this email and any attachments thereto.
>                               © DiVault 2015

View raw message