Local binding for CMIS repository

[Jakub Liska, modifié il y a 13 années.]

Hey,

it could be relatively easy to add Local JCR binding for CMIS repository, where the "server side" would run in the same JVM.

see the third paragraph

So that in CMISRpository.getSession( ) would be also a condition like :

		if (isLocal()) {
			        parameter.put(SessionParameter.BINDING_TYPE, BindingType.LOCAL.value());
                                parameter.put(SessionParameter.LOCAL_FACTORY, "my.local.factory");

Where implementation of the ServiceFactory would be JcrServiceFactory from chemistry-opencmis-server-jcr

see apache-chemistry svn

the advantage would be that if you had an existing repository on the same machine where LR is running, you could plug it in via CMIS interface, but you wouldn't have to run CMIS server and communicate via tcp/ip / atomPub

It would be for cases, when the repository already contain data + it is accessed externally. Which couldn't be done easily via JCRHook due to the versionning & database synchronization issue.

[Jakub Liska, modifié il y a 13 années.]

So that it would need this dependency

<dependency>
<groupId>org.apache.chemistry.opencmis</groupId>
<artifactId>chemistry-opencmis-server-jcr</artifactId>
<version>0.3.0-incubating-SNAPSHOT</version>
<classifier>classes</classifier>
</dependency>

This artifact depends on chemistry-opencmis-server-bindings and chemistry-opencmis-server-support...

So that all opencmis libs in liferay would have to be upgraded from 0.2.0 to 0.3.0 and 3 jars added :

chemistry-opencmis-server-jcr
chemistry-opencmis-server-bindings
chemistry-opencmis-server-support

Otherwise only this block of code needs to be added:

	if (isLocal()) {
			parameters.put(SessionParameter.BINDING_TYPE, BindingType.LOCAL.value());
			parameters.put(SessionParameter.LOCAL_FACTORY, JcrServiceFactory.class.getName());
			parameters.put("jcr." + RepositoryFactoryImpl.REPOSITORY_HOME, PropsUtil.get(PropsKeys.JCR_JACKRABBIT_REPOSITORY_HOME));
		}

and a simple class that extends CmisRepository and a few changes in properties and RepositoryTest passes even for this local binding....

Because otherwise everything is hidden behind the session :

parameter.put(SessionParameter.BINDING_TYPE, BindingType.LOCAL.value());
parameters.put(SessionParameter.LOCAL_FACTORY, JcrServiceFactory.class.getName());  // + information about the local JCR repository

SessionFactory factory = SessionFactoryImpl.newInstance();
Session session = factory.createSession(parameter);   // creates session with reference to [b]JcrServiceFactory[/b]

CmisBindingFactory factory = CmisBindingFactory.newInstance(); // [b]this is an alternative[/b] (it's under the hood)
CmisBinding binding = factory.createCmisLocalBinding(parameters);  

The CmisBinding then serves JcrService (CmisService) with all cmis operations to be executed on the jcr repository

That should be theoretically everything ... Otherwise it behaves like if it was talking to cmis repo via atomPub / webService

I attached two patches, one for CmisRepository, the second one for RepositoryTest to see if it works. You also need to add following properties into portal-impl/test/portal-test.properties.

liferay.home=.
dl.hook.file.system.root.dir=${liferay.home}/data/document_library // for some other tests to pass successfully

jcr.workspace.name=liferay
jcr.node.documentlibrary=documentlibrary

jcr.jackrabbit.repository.root=${liferay.home}/data/jackrabbit
jcr.jackrabbit.config.file.path=${jcr.jackrabbit.repository.root}/repository.xml
jcr.jackrabbit.repository.home=${jcr.jackrabbit.repository.root}/home
jcr.jackrabbit.credentials.username=none
jcr.jackrabbit.credentials.password=none

dl.repository.impl=com.liferay.portal.repository.cmis.CMISAtomPubRepository,com.liferay.portal.repository.cmis.CMISWebServicesRepository,com.liferay.portal.repository.cmis.CMISLocalJcrRepository

I was gonna implement a LocalCMISHook, that would extend BaseHook. It's a shame that org.apache.chemistry.opencmis.client.api.Session doesn't implement javax.jcr.session. It's due to the fact that CMIS spec doesn't cover JCR spec in some points.

But I couldn't because for it to work LR would have to use current JackRabbit revision, which doesn't deppend on Lucene 2.x anymore, when jackRabbit is initialized by opencmis.

[Jakub Liska, modifié il y a 13 années.]

Ok,

To summarize it, for this feature LR would have to use JackRabbit 3.x because JackRabbit 2.x depends on Lucene 2.x the way opencmis uses it.

It is mostly due to the fact that opencmis support for server-jcr bindings is brand new ....

I tried to run LR 's RepositoryTest with the trunk version of JackRabbit and it breaks even other tests, so that my opinion is, that this feature should wait ... It isn't worth it. A lot of dirty work would have to be done...

see JCR-2415

[Alexander Chow, modifié il y a 13 années.]

Hi Jakub,

You are talking about Jackrabbit 2.3, not 3.x, right? We would need to upgrade to 2.3, right?

I haven't had a chance to test this out yet.. party because OpenCMIS 0.3.0 has yet to be released (though should be soon).

We can fairly easily add this in but I am not entirely clear what the use case would be for this, especially for a local JCR and specifically Jackrabbit. You said in your earlier post:

It would be for cases, when the repository already contain data + it is accessed externally. Which couldn't be done easily via JCRHook due to the versionning & database synchronization issue.

However, how often do you have a Jackrabbit-JCR repository on the same VM as Liferay, that is not already from Liferay?

[Jakub Liska, modifié il y a 13 années.]

Hi Alex,

The JR versions 2.2.x are not fully compatible with Lucene 3.x ( for some use cases). Only the trunk (future 2.3.x) currently supports Lucene 3.x ... for a few months now.

I suppose it would be useful mainly for cases when one needs to work with jackrabbit directly and have the content accessible via document library ... Mostly performance reasons (no abdera, no parsing, etc.)

Look, it just seemed to be easy to get it done, but as I said, the server-jcr bindings is a brand new project, tested on Jackrabbit trunk version only apparently... so currently I'd let it go ....