jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: NodeDelegate leakage from NodeImpl
Date Thu, 07 Jun 2012 14:43:39 GMT


On 7.6.12 14:55, Angela Schreiber wrote:
> 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.

Implementations which need access to internals should be done against 
the delegates. The delegatee can always be retrieved from the respective 
delegate when necessary but not vice versa. See OAK-81. The delegates 
are this strictly more general.

>
> 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.

Ok we should then open an issue for that and reconsider that. The 
current implementation however breaks the intention of OAK-81.

Michael

>
> regards
> angela
>

Mime
View raw message