Making JSR-170 implementation transparent in a J2EE app

[Emmanouil Batsis <ma...@geekologue.com>]

Hi all,

I'm trying to figure out the best way to abstract JSR-170 implementations for 
my J2EE apps (and maybe provide a patch for lenya ;-). My knowledge of the 
JSR-170 API is rather basic on this and i was hoping someone could comment on 
the approach below.

My understanding is that JSR-170 does not specify how a Repository should be 
obtained and thus related classes are implementation specific. My target 
deployment environment is J2EE appservers and Servlet Containers like Tomcat 
and Jetty, so the obvious tasks seem to be:

* During application/web context initialisation, obtain a repo in an 
implementation specific way
* put it under the JNDI tree for the rest of application to use

The solution i have in mind is:

* 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:

 class JackRabbitRegistryHelper implements JSRRegistryHelper{
   // use jackrabbit.core.jndi.RegistryHelper to put a 
   // bindable repo under JNDI
 }

* Use a ServletContextListener to call the implementation based on some 
config, for example the implementation classname (JackRabbitRegistryHelper) 
could be in web.xml. 


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).

Manos

Re: Making JSR-170 implementation transparent in a J2EE app

[Marcel Reutegger <ma...@gmx.net>]

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
> 
> 

Re: Making JSR-170 implementation transparent in a J2EE app

[Jukka Zitting <ju...@zitting.name>]

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