Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com
 designates 209.85.198.234 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:mime-version:content-type
         :x-google-sender-auth;
        b=PHqUiCj1B/sw1SxWq0MuY1O2/XCIeVyPd/Oc0qwOu686AgX8pE5vPi7beB7/eTD0RV
         ttpGT7LMD9bKozRgy5/8RdeDAxfk/3sY8oaTgmbdM46Cm1PmpBtmv/EengnPv32uwCmE
         JaCWjai5YoHGHM0jZa7f1k70DNhIR8idC5Eu0=
Message-ID: <a32f6b020806181842q5ab5f73bnaad3f415c4189bde@mail.gmail.com>
Date: Wed, 18 Jun 2008 21:42:18 -0400
From: "Alex Karasulu" <akarasulu@apache.org>
Sender: akarasulu@gmail.com
To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: [ApacheDS] [Interceptors] Added new entry property to
 OperationContext
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_5697_12594545.1213839738128"

------=_Part_5697_12594545.1213839738128
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Emmanuel,

I just added a new entry property to the OperationContext implementation in
the BB.  So now we can cache the target entry of any operation instead of
performing lookups all the time in various interceptors.  The property
allows getting and setting a ClonedServerEntry.  This is useful because we
can perform alterations on this entry and use getOriginalEntry() to get the
original state of the entry before any modifications are made to that entry.

The only tedious part to this is that we have to populate it at some point
(some barrier or interceptor) or else all the code accessing this entry will
need to check if it's null then do the lookup and call the setter.  Rather
than do this I was thinking we can eagerly load this in an interceptor or
have it eagerly loaded right as the OperationContext enters the
InterceptorChain via the chain itself.  Perhaps there are other options like
doing it in the constructors.

Wondering what your thoughts are on the best place for this if we should at
all leverage eager loading of this target entry.

Thanks,
Alex

------=_Part_5697_12594545.1213839738128
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Emmanuel,<br><br>I just added a new entry property to the OperationContext implementation in the BB.&nbsp; So now we can cache the target entry of any operation instead of performing lookups all the time in various interceptors.&nbsp; The property allows getting and setting a ClonedServerEntry.&nbsp; This is useful because we can perform alterations on this entry and use getOriginalEntry() to get the original state of the entry before any modifications are made to that entry.<br>
<br>The only tedious part to this is that we have to populate it at some point (some barrier or interceptor) or else all the code accessing this entry will need to check if it&#39;s null then do the lookup and call the setter.&nbsp; Rather than do this I was thinking we can eagerly load this in an interceptor or have it eagerly loaded right as the OperationContext enters the InterceptorChain via the chain itself.&nbsp; Perhaps there are other options like doing it in the constructors.<br>
<br>Wondering what your thoughts are on the best place for this if we should at all leverage eager loading of this target entry.&nbsp; <br><br>Thanks,<br>Alex<br><br>

------=_Part_5697_12594545.1213839738128--