[
https://issues.apache.org/jira/browse/OAK-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810824#comment-13810824
]
angela commented on OAK-1135:
-----------------------------
if we can't reproduce an issue we most probably didn't understand what went
wrong and where the bug is... so i would argue that any fix that relies on that
kind of analysis is most probably not correct. IMHO it is indispensable to
write tests for odd behavior or whenever a failure arises with the permission
evaluation. if we get NPE, we must have a test that covers the setup that
caused that error because this was apparently something we didn't expect to
happen. having tests for things like that is IMO required irrespective on
whether we change the code or not... but having them makes it easier to change
the code later on.
if it's not a simple setup i would suggst to use the jcr-logger present with
jackrabbit-commons to determine the set of JCR calls that lead to the problem
> NPE in CompiledPermissionImpl.getTreePermission()
> -------------------------------------------------
>
> Key: OAK-1135
> URL: https://issues.apache.org/jira/browse/OAK-1135
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Reporter: Tobias Bocanegra
> Fix For: 0.11
>
>
> I don't know exactly why and when, but accessing an property in the version
> store can yield to an NPE in CompiledPermissionImpl.getTreePermission() if
> the TreeLocation is a PropertyLocation. then TreeLocation.getTree() returbs
> NULL and subsequently causes a NPE.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
