Hi,
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
repository:
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
descriptor:
<resource-env-ref>
<description>Content Repository</description>
<resource-env-ref-name>jcr/repository</resource-env-ref-name>
<resource-env-ref-type>javax.jcr.Repository</resource-env-ref-type>
</resource-env-ref>
This will give maximum installation and maintenance flexibility as the
deployer
is free to select and configure the content repository component the way that
best matches the deployment environment.
BR,
Jukka Zitting
