You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Pedro Teixeira (JIRA)" <ji...@apache.org> on 2015/05/14 17:39:00 UTC

[jira] [Updated] (JCR-3882) GlobalPattern's equals() implementation throws NullPointerException

     [ 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)