jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Layering the Jackrabbit JCR interface classes
Date Fri, 09 Feb 2007 16:12:17 GMT

Jackrabbit currently implements the JCR interfaces directly in the
various Impl classes that directly access the underlying repository
state. This approach has a few drawbacks:

    a) The Impl classes are huge, partly because the JCR interfaces
       typically declare such a large number of methods. For example:
       NodeImpl = 4.2kLOC, SessionImpl = 1.4kLOC, PropertyImpl = 1.2kLOC.

    b) Related to the above, the Impl classes have a large number of
       separate responsibilities, but as of now the fixed nature of the
       JCR interfaces prevent easy refactoring of those responsibilities
       to separate classes.

    c) Many Impl classes expose extra public or protected methods in
       addition to the ones declared in the JCR interfaces. This introduces
       potential security issues, especially when in some cases exposing
       some internal features to other internal classes would in fact be
       beneficial (for example access to the system session).

    d) The JCR interfaces contain many utility methods that can be
       implemented in terms of other JCR methods. Such default methods
       could easily be shared across JCR implementations but the nature
       of the current Impl classes prevents such sharing.

    e) Name parsing and formatting is normally only performed just when
       entering or leaving a JCR method. This mapping activity is currently
       duplicated in almost all method implementations.

I would like to suggest that we introduce a new layer just beneath the
JCR API for getting rid of or reducing the above drawbacks. This layer
would consist of the following three parts:

    1) Set of abstract AbstractSession, AbstractItem, etc. classes that
       implement as much of the respective JCR interfaces using nothing
       else but calls to other JCR methods. These would be just like the
       AbstractMap, etc. classes in java.util.

    2) Set of QSession, QItem, etc. (or with some better naming) interfaces
       that declare QName and Path versions of those JCR methods that can't
       reasonably be implemented by the above abstract classess. Potentially
       we could also break strict one-to-one correspondence with the JCR
       interfaces to allow for better separation of concerns.

    3) Set of adapter (or facade) classes that extend the above abstract
       classes and implement the remaining methods using name mapping and
       implementations of the above interfaces. These classes could also
       take care of backreferences like Session.getRepository() and

All these parts could be implemented within jackrabbit-jcr-commons so
that they can be reused in other JCR implementations, for example in
the client part of the SPI project.

The current Impl classes in jackrabbit-core would be refactored to
implement the above interfaces instead of the standard JCR interfaces.

What do you think? At least the first part of the proposal should be
easy to implement incrementally without destabilizing anything. The
granularity of implementing the other parts is a bit bigger, but could
still be performed just one interface at a time.


Jukka Zitting

View raw message