Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of anchela@adobe.com designates
 64.18.1.21 as permitted sender)
Message-ID: <4FD0B2B7.9000202@adobe.com>
Date: Thu, 7 Jun 2012 15:55:03 +0200
From: Angela Schreiber <anchela@adobe.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: NodeDelegate leakage from NodeImpl
References: <4FD08B5E.7020508@gmail.com> <4FD096BD.5050206@gmx.de>
In-Reply-To: <4FD096BD.5050206@gmx.de>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit

On 6/7/12 1:55 PM, Julian Reschke wrote:
> On 2012-06-07 13:07, Michael D�rig wrote:
>>
>> Hi,
>>
>> I noticed that since revision 1344662 NodeImpl has an (package private)
>> accessor for NodeDelegate. This defeats the original intent of the
>> separation of NodeImpl and NodeDelegate (OAK-84): users should not be
>> able to gain access to internals by hacking NodeImpl. But precisely this
>> is now possible when a user put his code into the
>> org.apache.jackrabbit.oak.jcr package.
>>
>> Michael
>
> Apparently because UserManagerImpl deals with nodes, but does want to
> set properties directly using the delegates. (Performance? Skipping checks?)

being able to set protected properties (currently this check
is missing but we will need to add it once the node type stuff
is implemented)... feel free to change the implementation of
SessionDelegate#getDelegate(Node jcrNode)... i didn't want to
use the method taking a path since i have the node at hand
already.... that looked really bad to me.

after all i am not convinced that the separation between delegate
and impl is really the right approach... to much duplicate
methods with no actual benefit IMO.

regards
angela