There is also a JCA implementation available for jackrabbit under
contrib. The example configuration targets JBoss but the rar should run
on any application server (afaik).
regards
marcel
Jukka Zitting wrote:
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
