jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <ju...@zitting.name>
Subject Re: Making JSR-170 implementation transparent in a J2EE app
Date Thu, 29 Sep 2005 22:54:08 GMT

Emmanouil Batsis wrote:
> * Come up with an interface (JSRRegistryHelper) or abstract class to hide
> implementation specific calls to initially obtain a repo and put it under
> JNDI, something like what jackrabbit.core.jndi.RegistryHelper does. In the
> case of jackrabbit this would boil down to something like the following:
> [...]
> Any advice welcome, i am especially interested in solutions that would make
> this topology-independent as well (clustering of the webapp comes in mind,
> plus jackrabbit will also become clusterable at some point).

A similar issue was briefly discussed a short while ago [1], and I'd like to
repeat my view that this need is probably better met by JNDI or some general
component framework than a specialized Registry factory or helper class.

[1] http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/3404

For your use case I propose that (unless you need the implementation-specific
features) you include *no* Jackrabbit dependencies in your application. Use
only the JCR API and a code snippet like the following to access the

    InitialContext context = new InitialContext();
    Context environment = (Context) context.lookup("java:comp/env");
    Repository repository = (Repository) environment.lookup("jcr/repository");

You should also declare this component reference in your J2EE deployment

      <description>Content Repository</description>

This will give maximum installation and maintenance flexibility as the 
is free to select and configure the content repository component the way that
best matches the deployment environment.


Jukka Zitting

View raw message