[
https://issues.apache.org/jira/browse/JCR-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pedro Teixeira updated JCR-3882:
Description:
Current GlobalPattern's equals() implementation is throwing NPE under specific
circumstances:
https://github.com/apache/jackrabbit/blob/2.10.0/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/security/authorization/GlobPattern.java#L160-L161
Looks like the *intended* predicate logic was something on the lines of "return
X && Y" , where Y is a ternary IF clause: "return X && ( outcome of Y ternary
IF clause )"
This is not the *actual* case; current implementation, *because is lacking
parenthesis around the second statement*, causes a behaviour of "return ( X &&
Y ) ? outcome1 : outcome2";
Under a scenario of:
nodePath = "mycompany/tenant0"
other.nodePath = "mycompany"
restriction = null;
other.restriction = null;
then
{code:java}
nodePath.equals(other.nodePath) && (restriction == null) ? (...)
{code}
is false, and the return value is the outcome of the ternary IF's else clause
{code:java}
(...) ? other.restriction == null : restriction.equals(other.restriction)
{code}
is the outcome of
{code:java}
restriction.equals(other.restriction)
{code}
when restriction is null, an NPE gets thrown
\\
\\
\\
*Possible solution*
wrapping the second statement in parenthesis would fix the behaviour
{code:java}
return nodePath.equals(other.nodePath) &&
( (restriction == null) ? other.restriction == null :
restriction.equals(other.restriction) );
{code}
was:
Current GlobalPattern's equals() implementation is throwing NPE under specific
circumstances:
https://github.com/apache/jackrabbit/blob/2.10.0/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/security/authorization/GlobPattern.java#L160-L161
Looks like the *intended* predicate logic was something on the lines of "return
X && Y" , where Y is a ternary IF clause: "return X && ( outcome of Y predicate
)
This is not the *actual* case; current implementation, *because is lacking
parenthesis around the second predicate*, causes a behaviour of "return ( X &&
Y ) ? outcome1 : outcome2";
Under a scenario of:
nodePath = "mycompany/tenant0"
other.nodePath = "mycompany"
restriction = null;
other.restriction = null;
then
{code:java}
nodePath.equals(other.nodePath) && (restriction == null) ? (...)
{code}
is false, and the return value is the outcome of the ternary IF's else clause
{code:java}
(...) ? other.restriction == null : restriction.equals(other.restriction)
{code}
is the outcome of
{code:java}
restriction.equals(other.restriction)
{code}
when restriction is null, an NPE gets thrown
\\
\\
\\
*Possible solution*
wrapping the second statement in parenthesis would fix the behaviour
{code:java}
return nodePath.equals(other.nodePath) &&
( (restriction == null) ? other.restriction == null :
restriction.equals(other.restriction) );
{code}
> GlobalPattern's equals() implementation throws NullPointerException
> ---
>
> Key: JCR-3882
> URL: https://issues.apache.org/jira/browse/JCR-3882
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 2.10
>Reporter: Pedro Teixeira
>Priority: Critical
>
> Current GlobalPattern's equals() implementation is throwing NPE under
> specific circumstances:
> https://github.com/apache/jackrabbit/blob/2.10.0/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/security/authorization/GlobPattern.java#L160-L161
> Looks like the *intended* predicate logic was something on the lines of
> "return X && Y" , where Y is a ternary IF clause: "return X && ( outcome of Y
> ternary IF clause )"
> This is not the *actual* case; current implementation, *because is lacking
> parenthesis around the second statement*, causes a behaviour of "return ( X
> && Y ) ? outcome1 : outcome2";
> Under a scenario of:
> nodePath = "mycompany/tenant0"
> other.nodePath = "mycompany"
> restriction = null;
> other.restriction = null;
> then
> {code:java}
> nodePath.equals(other.nodePath) && (restriction == null) ? (...)
> {code}
> is false, and the return value is the outcome of the ternary IF's else clause
> {code:java}
> (...) ? other.restriction == null : restriction.equals(other.restriction)
> {code}
> is the outcome of
> {code:java}
> restriction.equals(other.restriction)
> {code}
> when restriction is null, an NPE gets thrown
> \\
> \\
> \\
> *Possible solution*
> wrapping the second statement in parenthesis would fix the behaviour
> {code:java}
> return nodePath.equals(other.nodePath) &&
> ( (restriction == null) ? other.restriction == null :
> restriction.equals(other.restriction) );
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)