From dev-return-25248-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Thu Sep 03 14:20:17 2009 Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 8760 invoked from network); 3 Sep 2009 14:20:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Sep 2009 14:20:16 -0000 Received: (qmail 40525 invoked by uid 500); 3 Sep 2009 14:20:15 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 40483 invoked by uid 500); 3 Sep 2009 14:20:15 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 40426 invoked by uid 99); 3 Sep 2009 14:20:14 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Sep 2009 14:20:14 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of tmueller@day.com designates 207.126.148.183 as permitted sender) Received: from [207.126.148.183] (HELO eu3sys201aog003.obsmtp.com) (207.126.148.183) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 03 Sep 2009 14:20:04 +0000 Received: from source ([209.85.219.219]) by eu3sys201aob003.postini.com ([207.126.154.11]) with SMTP ID DSNKSp/Qf2niQBaHYfNo1Nx8DLZZ3qGzoSzQ@postini.com; Thu, 03 Sep 2009 14:19:44 UTC Received: by ewy19 with SMTP id 19so1930851ewy.20 for ; Thu, 03 Sep 2009 07:19:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.210.19.7 with SMTP id 7mr9669192ebs.81.1251987583157; Thu, 03 Sep 2009 07:19:43 -0700 (PDT) In-Reply-To: <510143ac0909030700m23f34bfdi8b31dbf3b3326fdc@mail.gmail.com> References: <510143ac0909030700m23f34bfdi8b31dbf3b3326fdc@mail.gmail.com> Date: Thu, 3 Sep 2009 16:19:43 +0200 Message-ID: <91f3b2650909030719wd57de7fpcd12db9fe3a5d8f4@mail.gmail.com> Subject: Re: Jackrabbit management API From: =?ISO-8859-1?Q?Thomas_M=FCller?= To: dev@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org 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 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 >