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:32:34 GMT
Hi again,

Regarding access control: I think we should use the JCR access control
mechanism, meaning that only authorized sessions can do certain
operations. Relying on other mechanisms doesn't make sense for me,
because it restricts what kind of applications can use such methods.
For example: A standalone tool should be able to trigger garbage
collection. The tools should be able to use the JCR 2.0 API to get the
repository, no matter if the repository is installed locally or on a
remote server.

The JCR API already provides a number of 'management' features, such
as creating workspaces, node type management, namespace registry, and
so forth. Whatever API we invent, it should be similar to the existing
API. For two reasons: it's more consistent with the Jackrabbit API,
and it can later be included in the next JCR API.

Regards,
Thomas


On Thu, Sep 3, 2009 at 4:19 PM, Thomas Müller<thomas.mueller@day.com> wrote:
> 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