Return-Path: 
 <oak-dev-return-3537-apmail-jackrabbit-oak-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org>
X-Original-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org
Delivered-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 6281AE781
	for <apmail-jackrabbit-oak-dev-archive@minotaur.apache.org>;
 Tue, 19 Feb 2013 15:52:29 +0000 (UTC)
Received: (qmail 3343 invoked by uid 500); 19 Feb 2013 15:52:29 -0000
Delivered-To: apmail-jackrabbit-oak-dev-archive@jackrabbit.apache.org
Received: (qmail 3217 invoked by uid 500); 19 Feb 2013 15:52:28 -0000
Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:oak-dev-help@jackrabbit.apache.org>
List-Unsubscribe: <mailto:oak-dev-unsubscribe@jackrabbit.apache.org>
List-Post: <mailto:oak-dev@jackrabbit.apache.org>
List-Id: <oak-dev.jackrabbit.apache.org>
Reply-To: oak-dev@jackrabbit.apache.org
Delivered-To: mailing list oak-dev@jackrabbit.apache.org
Received: (qmail 3180 invoked by uid 99); 19 Feb 2013 15:52:27 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Feb 2013 15:52:27 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of jukka.zitting@gmail.com
 designates 209.85.219.45 as permitted sender)
Received: from [209.85.219.45] (HELO mail-oa0-f45.google.com) (209.85.219.45)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Feb 2013 15:52:20 +0000
Received: by mail-oa0-f45.google.com with SMTP id o6so7106746oag.18
        for <oak-dev@jackrabbit.apache.org>;
 Tue, 19 Feb 2013 07:51:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=x-received:mime-version:from:date:message-id:subject:to
         :content-type;
        bh=jKhIwNgu5o26j5Hckxai2TRsLx+s8YNnpu8mZPGWB1c=;
        b=puaOC658+IEkhVgGXsbtFsPcRG5erEdTv9wq6Jp0Y9bUaQlCVYHjGPB5YoIPt9vvDJ
         2mQ3WIlmAMvGh+/9Fpk1eexWwYMp1HzmF0nOxwAUzxs9Fqx4XD5ijbRzyIWw9hyaRduc
         cY2LOZmXNsl+RZBntmUA7PuAfkGGZrburvalDFa0kZVdNZ6MQSZShNet9SsI7Ohv8NFi
         XiY7DxN3yH3SiHrXfDlFSFIl3vYgZJO3Aw8pddqW65gGTzjoT6yfqbpb1f4sAd82YhDy
         kbQ8KBavgLFcE9QWi7EEltm6z5E2MS0X9mAjMMv922r+uyM7ZkiHYKvXme968gOX1Rh/
         vPIg==
X-Received: by 10.60.27.228 with SMTP id w4mr7641817oeg.104.1361289118850;
 Tue, 19 Feb 2013 07:51:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.47.35 with HTTP; Tue, 19 Feb 2013 07:51:38 -0800 (PST)
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Tue, 19 Feb 2013 17:51:38 +0200
Message-ID: 
 <CAOFYJNY50JfEecBHDefERa9RNet_tMD4Kdsy9LooHKhwfJrr3A@mail.gmail.com>
Subject: enter() method for JCR implementation classes
To: Oak devs <oak-dev@jackrabbit.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Virus-Checked: Checked by ClamAV on apache.org

Hi,

The current boilerplate for most of the methods in our JCR
implementation classes looks something like this:

    public Something getSomething() {
        checkStatus();
        return sessionDelegate.perform(
            new SessionOperation<PropertyImpl>() {
                @Override
                public Something perform() throws RepositoryException {
                    return ...;
                }
            });
    }

That's quite verbose and also troublesome from a performance
perspective as even basic operations require multiple method calls and
the instantiation of at least one extra object.

The purpose of the above boilerplate is first to check the state of
the current object (and the session responsible for it) and to take
care of the auto-refresh logic. Later on we might want to attach more
functionality to this pattern.

Originally the perform() pattern comes from JCR-890, where we had to
add it to prevent concurrent clients from messing up with repository
internals. In Oak I believe we could do with a lot lighter-weight
approach since we have better decoupling between the different layers
of the system.

So, to simplify things I propose that we refactor the above code to
something like this:

    public Something getSomething() {
        enter("doSomething");
        return ...;
    }

The enter() method should take care of all the tasks outlined above,
and with the given argument constant could also emit a debug log of
all JCR method calls. Variants like enterOrThrowSomeException() could
be used in cases where special exceptions are required for specific
states.

WDYT?

PS. I wonder if we could use some aspect-tool to automatically inject
such enter() calls to our code as a part of the compilation process...

BR,

Jukka Zitting