jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Müller <thomas.muel...@day.com>
Subject Re: Jackrabbit management API
Date Thu, 03 Sep 2009 14:19:43 GMT
Hi,

The solution should be compliant with the JCR 2.0 API (specially
regarding creating Repository objects).

We should use interfaces and no 'hard coded' classes. There are two reasons:

1) with interfaces, we can add 'wrappers' or 'proxies' around an
implementation such as a logging layer, a virtual repository that can
combine multiple repositories into one, or a remoting layer.

2) with interfaces, applications can be written in an
implementation-independent way, so that the exact same code (without
having to recompile) can run against many implementations. One example
is a generic JCR browser tool.

I don't think that we should _rely_ on a specific mechanism such as
JMX, JNDI, OSGi, Spring and so on. Any such mechanism should be
orthogonal to the Jackrabbit API.

Regards,
Thomas



On Thu, Sep 3, 2009 at 4:00 PM, Jukka Zitting<jukka.zitting@gmail.com> wrote:
> Hi,
>
> Let's branch some of the more general discussion from JCR-1865 to here on dev@.
>
> The issue is about repository management operations like starting and
> stopping the repository, changing repository configuration, etc. that
> are typically only available to administrators. It would be nice if
> these operations could be accessed through mechanisms like JMX for
> easy integration with various network and server management and
> monitoring tools.
>
> The question is, should such an API be implemented by extending the
> existing JCR Repository and Session interfaces for easy access over
> layers like JCR-RMI and SPI, or should it be a separate interface that
> is only exposed to selected clients? The former approach requires some
> extra administrator-level access controls and might be more difficult
> to integrate with JMX, while the latter approach requires extra
> configuration and won't benefit from our existing remoting mechanisms.
> It might also be possible to merge these approaches somehow, for
> example with a method like
> JackrabbitRepository.getRepositoryManager(Credentials).
>
> A related consideration is what we are going to do with OSGi. The OSGi
> bundle lifecycle and configuration mechanisms offer much of the same
> functionality as proposed above, and there are already things like JMX
> integration for OSGi.
>
> BR,
>
> Jukka Zitting
>

Mime
View raw message