First steps with Jackrabbit: Java app -> JNDI -> Dav -> Remote

[Graham Leggett <mi...@sharp.fm.INVALID>]

Hi all,

I am trying to integrate JCR into an existing java application deployed within Tomcat, and I am struggling to find docs that describe how to do this.

We want to follow the JCR architecture and not hardcode the implementation into the app, and so we try pick up a JCR implementation from JNDI, like so (snip error handling):

			InitialContext context = new InitialContext();
			Object obj = context.lookup("java:comp/env");
			javax.naming.Context environment = javax.naming.Context.class.cast(obj);
			obj = environment.lookup("jcr/repository");
			Repository repository = Repository.class.cast(obj);

Now we go to tomcat, and we set up a resourcelink:

          <ResourceLink global="jcr/GlobalRepository" name=“jcr/AppRepository" type="javax.jcr.Repository"/>

which points to a resource:

    <Resource 
        name="jcr/GlobalRepository"
        auth="Container"
        type="javax.jcr.Repository" 
        factory=“[Something undocumented goes here]" 
        url="[The RMI URL of the repository]"

I am stuck at "Something undocumented goes here”.

Most specifically, I need a factory that will allow me to set an URL, pointing at the WebDav interface of the repository, but I'm hitting a wall. A local repository is available for testing purposes which is nice, but that doesn’t help for an actual implementation.

This question was raised a long time ago, which led to this ticket https://issues.apache.org/jira/browse/JCR-1877 marked fixed, but it’s not clear what the fix was, or where the fix was documented.

This factory comes close: https://jackrabbit.apache.org/api/trunk/index.html?org/apache/jackrabbit/jcr2dav/package-summary.html - but it documents three possible different URLs to be provided, which doesn't map to the resource element, which only has the option to provide one url.

Are there any complete examples of a JCR implementation using JNDI and Jackrabbit as a client?

All I can find are references to people hard coding Jackrabbit into their app, which breaks the architecture: org.apache.jackrabbit.commons.JcrUtils

Regards,
Graham
—

Re: First steps with Jackrabbit: Java app -> JNDI -> Dav -> Remote

[Robert Munteanu <ro...@apache.org>]

Hi Graham,

On Wed, 2022-06-08 at 22:35 +0200, Graham Leggett wrote:
> On 07 Jun 2022, at 20:20, Graham Leggett <mi...@sharp.fm.INVALID>
> wrote:
> 
> > Am I on the right track, or does no one use the JCR API and instead
> > just hard codes Jackrabbit directly into apps?
> 
> I am assuming hardcoding seems to be the way.
> 

Speaking as a Jackrabbit (Oak) user, we do have mechanisms to
externalise the definition of the JCR repository to connect to, it just
happens that we don't use JNDI.

We're using a web framework called Apache Sling [1] and that framework
uses the Feature Model [2] to configure applications.

I don't have extensive experience with running Jackrabbit outside of
Sling, but I always see Oak embedded with the application, whether the
persistence is tied to the individual instance, using the
SegmentNodeStore, or clusterable, using the DocumentNodeStore [4].

Hope this helps,
Robert

[1]: https://sling.apache.org/
[2]:
https://sling.apache.org/documentation/feature-model/feature-model-howto.html
[3]:
https://jackrabbit.apache.org/oak/docs/nodestore/segment/overview.html
[4]: https://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html

Re: First steps with Jackrabbit: Java app -> JNDI -> Dav -> Remote

[Graham Leggett <mi...@sharp.fm.INVALID>]

On 07 Jun 2022, at 20:20, Graham Leggett <mi...@sharp.fm.INVALID> wrote:

> Am I on the right track, or does no one use the JCR API and instead just hard codes Jackrabbit directly into apps?

I am assuming hardcoding seems to be the way.

I have raised https://issues.apache.org/jira/browse/JCR-4797 to keep track so this can be fixed (if I have time).

Regards,
Graham
—

Re: First steps with Jackrabbit: Java app -> JNDI -> Dav -> Remote

[Graham Leggett <mi...@sharp.fm.INVALID>]

On 07 Jun 2022, at 14:22, Graham Leggett <mi...@sharp.fm.INVALID> wrote:

>    <Resource 
>        name="jcr/GlobalRepository"
>        auth="Container"
>        type="javax.jcr.Repository" 
>        factory=“[Something undocumented goes here]" 
>        url="[The RMI URL of the repository]"
> 
> I am stuck at "Something undocumented goes here”.

Trying factories at random and following the exceptions I have worked out that a factory that is visible through JNDI has to implement the following interface:

javax.naming.spi.ObjectFactory

A search for implementations show up three options:

jackrabbit-core/src/main/java/org/apache/jackrabbit/core/jndi/BindableRepositoryFactory.java <https://github.com/apache/jackrabbit/blob/ed3124e5fe223dada33ce6ddf53bc666063c3f2f/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/jndi/BindableRepositoryFactory.java> - useful for testing, not useful in my case.
jackrabbit-jcr-rmi/src/main/java/org/apache/jackrabbit/rmi/client/ClientRepositoryFactory.java <https://github.com/apache/jackrabbit/blob/ed3124e5fe223dada33ce6ddf53bc666063c3f2f/jackrabbit-jcr-rmi/src/main/java/org/apache/jackrabbit/rmi/client/ClientRepositoryFactory.java> - I understand RMI is obsolete.
jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit/jcr2spi/RepositoryImpl.java <https://github.com/apache/jackrabbit/blob/ed3124e5fe223dada33ce6ddf53bc666063c3f2f/jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit/jcr2spi/RepositoryImpl.java> - looks promising, but exposes weird internals that seems wrong (impl?)

Google is giving me endless copies of javadocs (the whole idea of factories is impossible to google) or copies of sources, so any docs if they exist are lost.

Am I on the right track, or does no one use the JCR API and instead just hard codes Jackrabbit directly into apps?

Regards,
Graham
—