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
