Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 92066 invoked from network); 2 Sep 2009 15:03:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Sep 2009 15:03:57 -0000 Received: (qmail 94338 invoked by uid 500); 2 Sep 2009 15:03:56 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 94250 invoked by uid 500); 2 Sep 2009 15:03:56 -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 94242 invoked by uid 99); 2 Sep 2009 15:03:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Sep 2009 15:03:56 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Sep 2009 15:03:53 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id A7C53234C004 for ; Wed, 2 Sep 2009 08:03:32 -0700 (PDT) Message-ID: <1646708558.1251903812682.JavaMail.jira@brutus> Date: Wed, 2 Sep 2009 08:03:32 -0700 (PDT) From: "Thomas Mueller (JIRA)" To: dev@jackrabbit.apache.org Subject: [jira] Commented: (JCR-1865) Add the Data Store to the Jackrabbit API In-Reply-To: <289230505.1227092384220.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/JCR-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750464#action_12750464 ] Thomas Mueller commented on JCR-1865: ------------------------------------- > Why do we need to modify JackrabbitSession for this To ensure the session is authorized. Otherwise how do you ensure only authorized users use the facility? > I'd just put all the management interfaces in o.a.j.api.management Ok, I don't care. > I'd drop the DataStore part of the interface and method names It's for the data store, so I think it makes sense to keep the name. But I don't care that much. > Do we really need the MarkEventListener mechanism Yes, we do, it's important. However I could document that it may return null if not supported by the given implementation. > The sleepBetweenNodes property seems really implementation specific You are right, it's not that important. I will remove it. > do we then need to expose a close() method on the garbage collector? Yes. The current implementation can add an observation listener, and this needs to be removed. > Add the Data Store to the Jackrabbit API > ---------------------------------------- > > Key: JCR-1865 > URL: https://issues.apache.org/jira/browse/JCR-1865 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core > Reporter: Thomas Mueller > Assignee: Thomas Mueller > Priority: Minor > Attachments: api.patch, api_2.patch, core.patch, core_2.patch > > > Currently, the garbage collection is not part of the Jackrabbit API. However, the data store garbage collection must be used once in a while if the data store is enabled. I propose to add the required interfaces to the Jackrabbit API. This will also allow to call garbage collection using RMI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.