Lapis Server 1.2.7 connection to JCR repository

Posted: 16 June 2014 in Teamsite

I am looking at connecting the web application to JCR repositories at the moment so that I can “attach” JCR nodes to workflows (and also possibly watch nodes that are created/modified/deleted as trigger points for instantiating workflows). I’ve had a few issues along the way but the base logic is there to be able to instantiate JCR sessions from the details located in the Lapis Server.


Make sure those jars are on the classpath. they were downloaded from the Maven repository or copied from within the jackrabbit standalone jar file

commons-codec-1.5.jar commons-collections-3.2.1.jar commons-httpclient-3.1.jar jackrabbit-jcr-commons-2.8.0.jar jackrabbit-jcr-rmi-2.8.0.jar jackrabbit-jcr2dav-2.8.0.jar jackrabbit-jcr2spi-2.8.0.jar jackrabbit-spi-2.8.0.jar jackrabbit-spi-commons-2.8.0.jar jackrabbit-spi2dav-2.8.0.jar jackrabbit-spi2jcr-2.8.0.jar jackrabbit-webdav-2.8.0.jar jcl-over-slf4j-1.7.4.jar jcr-2.0.jar slf4j-api-1.6.6.jar

Storing repository details

A file containing the repositories can be created and be referenced by the server property lapis.repositories.config (we set ours to etc/repositories.xml). Below is an example repositories file “mounting” 2 JCR repositories of a standard CQ5 installation. note that the passwords are encrypted.

<repositories> <repository name="" path="//jackrabbit/cq5/dev/author" type="jsr170" url="http://localhost:4502/crx/server" username="admin" password="SrAxtm8ihY+hBPYklrYYJQ==" /> <repository name="" path="//jackrabbit/cq5/dev/publish" type="jsr170" url="http://localhost:4503/crx/server" username="admin" password="SrAxtm8ihY+hBPYklrYYJQ==" /> </repositories>

Getting connected to the repositories via the Lapis Server

 List<String> repositories = client.getRepositories(); for (String repository : repositories) { Repository jcrRepository = JcrUtils.getRepository(client.getJCRRepositoryURL(repository)); Credentials credentials = client.getJCRCryptedCredentials(repository); Session jcrSession = jcrRepository.login(credentials); dump(jcrSession.getRootNode()); } 

The code above first retrieves the Lapis “mount points” of the JCR repositories (in our case, we have 2 “//jackrabbit/cq5/dev/author” and “//jackrabbit/cq5/dev/publish”) which is than passed the JackRabbit utility class to retrieve the repository. In order to get a session to the repository, we must get the username and password, which is provided by the client calls to getJCRCryptedCredentials. The method gets given a path (it can be anything below a mount point, so //jackrabbit/cq5/dev/author/var/audit/ works just as well as //jackrabbit/cq5/dev/author) to resolve the credentials for us from the encrypted details in the repositories file.

All we need to do then is call the login method of the repository object and get connected. I have in mind that the username/password combination would be for a read-only user and that another method would be available to pass your own username/password (This is yet to be implemented). Below is a screenshot of the development environment in the process of dumping data from the JCR repository (something I will have to replicate when I implement the changes for the web application).

Attaching JCR nodes to the workflows

In the very near future, it will be possible to attach a reference to a JCR node to workflows. The paths would be the Lapis “mounted” paths but I will be providing a path modulator/demodulator to translate between the path as the Lapis server would know it across multiple repositories and the path within the repository.
For example, the path //jackrabbit/cq5/dev/author/var/audit/ of an attached node in a lapis workflow could be translated into /var/audit/ so that a call can be made using the standard JCR API from the workflow. Once I have this developed, I’ll post so that this is documented.

Why is that a good thing?

Well, when I get this implementation completed, it would start to open the workflow engine to a log of “enterprise” level systems (and the companies that use them!). Anything that uses Apache JackRabbit, JBoss modeShape, Adobe CQ, IBM WCM, to name but a few could now gain a workflow engine with very little effort. I believe this would definitely help put the Lapis Engine on the map.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s