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<[email protected]> wrote: > Hi, > > Let's branch some of the more general discussion from JCR-1865 to here on > d...@. > > 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 >
