jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Proposal for managing JCR resources in webapps
Date Mon, 04 Jun 2007 08:45:32 GMT

On 6/4/07, Felix Meschberger <Felix.Meschberger@day.com> wrote:
>    - The org.apache.jackrabbit.commons.repository.ProxyRepository class
>    does not only access the repository lazily but "re-acquires" the repository
>    on each call. This seems somewhat too expensive. I suggest to add an
>    accessor method, which accesses the repository realy lazily.

I considered that but then we'd need explicit invalidation of the
memorized repository reference. I want to be able to for example
restart the repository accessed through JNDI or across servlet
contexts without having to redeploy also all the applications that use
the repository. Re-acquiring the reference for each method call
achieves this in a clean and simple way.

Most often the repository is also used just for a login() call, which
in any case is more expensive than the typical repository lookup. The
only time I think the lookup time will dominate access time is when a
client reads the repository descriptors. This would typically be an
administration operation so I don't think optimizing that is very

Typically the repository lookup is also very fast for example when
using local JNDI or a servlet context. The only case where the lookup
would be more expensive is when accessing a remote repository, but
such cases would typically not be performance-critical in any case and
even there the typical performance hit would be a few extra
milliseconds per login() call.

>    - I tend to not like the inclusion of Serlvet API specific methods in
>    the commons and rmi libraries. IMHO using JCR in a Servlet Context is a very
>    valid and probably most often used use case but it is not the sole and
>    primary and most important use case. So adding dependencies to the Servlet
>    API to these two libraries seems unfit. Rather I suggest to have a separate
>    library supporting the important Servlet Context use case which combines the
>    servlet support packages from the commons and rmi libraries.

We already have quite a few components to manage, so I'd prefer to
avoid creating a yet another component. The servlet-api dependency
scope is provided, so an application that doesn't use classes in the
o.a.j.*.servlet packages would not be affected by the dependency.

I could of course create such an extra component, but then it becomes
a question of whether we should have separate components for the
generic classes and ones specific to jackrabbit-jcr-rmi or
jackrabbit-core or if we should just have a single jackrabbit-servlet
component that depends on all these pieces. Following the former
option (that doesn't impose extra dependencies to clients) would give
us (at least):

    jackrabbit-jcr-servlet (depends on jackrabbit-jcr-commons)
    jackrabbit-jcr-rmi-servlet (depends on jackrabbit-jcr-rmi,
    jackrabbit-core-servlet (depends on jackrabbit-core, jackrabbit-jcr-servlet)

This simply duplicates the existing jcr-commons/jcr-rmi/core triple,
so in my opinion we would be better of just accepting the (provided)
servlet-api dependency in existing components.


Jukka Zitting

View raw message