Hi Tycho,
This simplest code sample is propably this one:
https://svn.apache.org/viewvc/chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-fileshare/
It's a smaller and newer version of the Server Development Guide code.
FileBridgeCmisServiceFactory.java and FileBridgeCmisService.java 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
stub.
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
(https://www.apache.org/dyn/closer.lua/chemistry/opencmis/1.1.0/chemistry-opencmis-server-bindings-war-1.1.0.war)
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 "FileBridgeCmisServiceFactory.java" and
"FileBridgeCmisService.java" 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
"FilebridgeRepository.java" 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]
https://github.com/cmisdocs/ServerDevelopmentGuide/blob/master/doc/OpenCMIS%20Server%20Development%20Guide.pdf?raw=true
[OpenCMIS Server Development Guide github]
https://github.com/cmisdocs/ServerDevelopmentGuide
--
Digitaal Archief Service
mob +31 6 43599147
mail ty...@divault.nl
web www.divault.com
adres: Schieland 18, 1948RM, Beverwijk
DiVault in beeld: VIDEO <http://youtu.be/Yse1JvmhJ64>
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
