[jira] [Commented] (OGNL-261) OgnlException with "source is null for getProperty" thrown when using compound expression

2021-11-16 Thread Lukasz Lenart (Jira)


[ 
https://issues.apache.org/jira/browse/OGNL-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17444359#comment-17444359
 ] 

Lukasz Lenart commented on OGNL-261:


All configuration options are passed by OgnlContext, basically a constant key 
with a value [1]which is then controlled here [2].

Anyway, I wouldn't add a configure options to control that, just change the 
behaviour.

 

[1] 
[https://github.com/jkuhnert/ognl/blob/master/src/main/java/ognl/OgnlContext.java#L56]

[2] 
https://github.com/jkuhnert/ognl/blob/master/src/main/java/ognl/OgnlContext.java#L555-L581

> OgnlException with "source is null for getProperty" thrown when using 
> compound expression
> -
>
> Key: OGNL-261
> URL: https://issues.apache.org/jira/browse/OGNL-261
> Project: Commons OGNL
>  Issue Type: Improvement
>  Components: Core Runtime
>Reporter: Pascal Davoust
>Priority: Major
>
> Spin-off discussion from WW-5147 and related 
> [https://github.com/apache/struts/pull/504] pull request.
> Whenever an OGNL expression compiles into an AST with compound node 
> statements, the evaluation can result into a {{{}OgnlException("source is 
> null for getProperty(null, "propertyName")"){}}}.
> This stems from the logic in method {{ognl.ASTChain.getValueBody(OgnlContext, 
> Object)}} which uses the result of the current node as the source for the 
> next node in the chain.
> If the result of the current node evaluation results into {{{}null{}}}, then 
> the next node throws the exception.
> As mentioned in [https://github.com/apache/struts/pull/504], there is a 
> question about whether this logic is by design or if there is something to 
> investigate (I definitely lack background and OGNL knowledge to even guess).
> If this behavior is legitimate, it also turns out that this situation occurs 
> a lot and the cost of building the exceptions with the stack traces is fairly 
> noticeable: profiling the code while under load shows a significant amount of 
> time spent building the stack traces.
> Depending on the outcome of the discussion above, would it make sense to 
> envision to allow OGNL to throw these exceptions without the stack traces if 
> configured so (which can be easily done from JDK 7 using the constructor 
> taking the {{enableSuppression}} and {{writableStackTrace}} arguments - can 
> also be achieved from older JDKs by overriding method {{fillInStackTrace()}} 
> )?
> Note that a preliminary attempt showed that the cost of building these 
> exceptions without the stack traces is virtually zero, making the exceptions 
> totally painless and invisible (they appear no more while profiling).



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (OGNL-261) OgnlException with "source is null for getProperty" thrown when using compound expression

2021-11-15 Thread Pascal Davoust (Jira)


[ 
https://issues.apache.org/jira/browse/OGNL-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17443869#comment-17443869
 ] 

Pascal Davoust commented on OGNL-261:
-

[~lukaszlenart]
{quote} I would expect a null-friendly behaviour in {{ASTChain}} - I mean if 
source is null return null instead of throwing an exception.
{quote}
I would as well, I usually don't rely on exceptions to deal with nominal code 
logic.
But that's how the code just works here, so unless someone has got the 
knowledge to tell us whether this is a bug or a choice at design-time, we can 
only assume that this is the way it works, I guess
{quote}If we want to empower users to choose whether the stacktraces are 
suppressed or not, what configuration mechanism would you recommend?
{quote}
Any suggestion?

> OgnlException with "source is null for getProperty" thrown when using 
> compound expression
> -
>
> Key: OGNL-261
> URL: https://issues.apache.org/jira/browse/OGNL-261
> Project: Commons OGNL
>  Issue Type: Improvement
>  Components: Core Runtime
>Reporter: Pascal Davoust
>Priority: Major
>
> Spin-off discussion from WW-5147 and related 
> [https://github.com/apache/struts/pull/504] pull request.
> Whenever an OGNL expression compiles into an AST with compound node 
> statements, the evaluation can result into a {{{}OgnlException("source is 
> null for getProperty(null, "propertyName")"){}}}.
> This stems from the logic in method {{ognl.ASTChain.getValueBody(OgnlContext, 
> Object)}} which uses the result of the current node as the source for the 
> next node in the chain.
> If the result of the current node evaluation results into {{{}null{}}}, then 
> the next node throws the exception.
> As mentioned in [https://github.com/apache/struts/pull/504], there is a 
> question about whether this logic is by design or if there is something to 
> investigate (I definitely lack background and OGNL knowledge to even guess).
> If this behavior is legitimate, it also turns out that this situation occurs 
> a lot and the cost of building the exceptions with the stack traces is fairly 
> noticeable: profiling the code while under load shows a significant amount of 
> time spent building the stack traces.
> Depending on the outcome of the discussion above, would it make sense to 
> envision to allow OGNL to throw these exceptions without the stack traces if 
> configured so (which can be easily done from JDK 7 using the constructor 
> taking the {{enableSuppression}} and {{writableStackTrace}} arguments - can 
> also be achieved from older JDKs by overriding method {{fillInStackTrace()}} 
> )?
> Note that a preliminary attempt showed that the cost of building these 
> exceptions without the stack traces is virtually zero, making the exceptions 
> totally painless and invisible (they appear no more while profiling).



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (OGNL-261) OgnlException with "source is null for getProperty" thrown when using compound expression

2021-11-15 Thread Lukasz Lenart (Jira)


[ 
https://issues.apache.org/jira/browse/OGNL-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17443625#comment-17443625
 ] 

Lukasz Lenart commented on OGNL-261:


I have no idea if the logic is correct. I would expect a null-friendly 
behaviour in {{ASTChain}} - I mean if source is null return null instead of 
throwing an exception.

> OgnlException with "source is null for getProperty" thrown when using 
> compound expression
> -
>
> Key: OGNL-261
> URL: https://issues.apache.org/jira/browse/OGNL-261
> Project: Commons OGNL
>  Issue Type: Improvement
>  Components: Core Runtime
>Reporter: Pascal Davoust
>Priority: Major
>
> Spin-off discussion from WW-5147 and related 
> [https://github.com/apache/struts/pull/504] pull request.
> Whenever an OGNL expression compiles into an AST with compound node 
> statements, the evaluation can result into a {{{}OgnlException("source is 
> null for getProperty(null, "propertyName")"){}}}.
> This stems from the logic in method {{ognl.ASTChain.getValueBody(OgnlContext, 
> Object)}} which uses the result of the current node as the source for the 
> next node in the chain.
> If the result of the current node evaluation results into {{{}null{}}}, then 
> the next node throws the exception.
> As mentioned in [https://github.com/apache/struts/pull/504], there is a 
> question about whether this logic is by design or if there is something to 
> investigate (I definitely lack background and OGNL knowledge to even guess).
> If this behavior is legitimate, it also turns out that this situation occurs 
> a lot and the cost of building the exceptions with the stack traces is fairly 
> noticeable: profiling the code while under load shows a significant amount of 
> time spent building the stack traces.
> Depending on the outcome of the discussion above, would it make sense to 
> envision to allow OGNL to throw these exceptions without the stack traces if 
> configured so (which can be easily done from JDK 7 using the constructor 
> taking the {{enableSuppression}} and {{writableStackTrace}} arguments - can 
> also be achieved from older JDKs by overriding method {{fillInStackTrace()}} 
> )?
> Note that a preliminary attempt showed that the cost of building these 
> exceptions without the stack traces is virtually zero, making the exceptions 
> totally painless and invisible (they appear no more while profiling).



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (OGNL-261) OgnlException with "source is null for getProperty" thrown when using compound expression

2021-11-14 Thread Pascal Davoust (Jira)


[ 
https://issues.apache.org/jira/browse/OGNL-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17443611#comment-17443611
 ] 

Pascal Davoust commented on OGNL-261:
-

Hi [~lukaszlenart] ,

Could you please confirm that the logic in {{ASTChain}} is correct and that the 
exception must be thrown in this situation?

Of course, I can definitely provide a PR for this.
If we want to empower users to choose whether the stacktraces are suppressed or 
not, what configuration mechanism would you recommend?

 

 

> OgnlException with "source is null for getProperty" thrown when using 
> compound expression
> -
>
> Key: OGNL-261
> URL: https://issues.apache.org/jira/browse/OGNL-261
> Project: Commons OGNL
>  Issue Type: Improvement
>  Components: Core Runtime
>Reporter: Pascal Davoust
>Priority: Major
>
> Spin-off discussion from WW-5147 and related 
> [https://github.com/apache/struts/pull/504] pull request.
> Whenever an OGNL expression compiles into an AST with compound node 
> statements, the evaluation can result into a {{{}OgnlException("source is 
> null for getProperty(null, "propertyName")"){}}}.
> This stems from the logic in method {{ognl.ASTChain.getValueBody(OgnlContext, 
> Object)}} which uses the result of the current node as the source for the 
> next node in the chain.
> If the result of the current node evaluation results into {{{}null{}}}, then 
> the next node throws the exception.
> As mentioned in [https://github.com/apache/struts/pull/504], there is a 
> question about whether this logic is by design or if there is something to 
> investigate (I definitely lack background and OGNL knowledge to even guess).
> If this behavior is legitimate, it also turns out that this situation occurs 
> a lot and the cost of building the exceptions with the stack traces is fairly 
> noticeable: profiling the code while under load shows a significant amount of 
> time spent building the stack traces.
> Depending on the outcome of the discussion above, would it make sense to 
> envision to allow OGNL to throw these exceptions without the stack traces if 
> configured so (which can be easily done from JDK 7 using the constructor 
> taking the {{enableSuppression}} and {{writableStackTrace}} arguments - can 
> also be achieved from older JDKs by overriding method {{fillInStackTrace()}} 
> )?
> Note that a preliminary attempt showed that the cost of building these 
> exceptions without the stack traces is virtually zero, making the exceptions 
> totally painless and invisible (they appear no more while profiling).



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (OGNL-261) OgnlException with "source is null for getProperty" thrown when using compound expression

2021-11-14 Thread Lukasz Lenart (Jira)


[ 
https://issues.apache.org/jira/browse/OGNL-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17443598#comment-17443598
 ] 

Lukasz Lenart commented on OGNL-261:


Also you can post the same or open PR here [https://github.com/jkuhnert/ognl] - 
thanks in advance!

> OgnlException with "source is null for getProperty" thrown when using 
> compound expression
> -
>
> Key: OGNL-261
> URL: https://issues.apache.org/jira/browse/OGNL-261
> Project: Commons OGNL
>  Issue Type: Improvement
>  Components: Core Runtime
>Reporter: Pascal Davoust
>Priority: Major
>
> Spin-off discussion from WW-5147 and related 
> [https://github.com/apache/struts/pull/504] pull request.
> Whenever an OGNL expression compiles into an AST with compound node 
> statements, the evaluation can result into a {{{}OgnlException("source is 
> null for getProperty(null, "propertyName")"){}}}.
> This stems from the logic in method {{ognl.ASTChain.getValueBody(OgnlContext, 
> Object)}} which uses the result of the current node as the source for the 
> next node in the chain.
> If the result of the current node evaluation results into {{{}null{}}}, then 
> the next node throws the exception.
> As mentioned in [https://github.com/apache/struts/pull/504], there is a 
> question about whether this logic is by design or if there is something to 
> investigate (I definitely lack background and OGNL knowledge to even guess).
> If this behavior is legitimate, it also turns out that this situation occurs 
> a lot and the cost of building the exceptions with the stack traces is fairly 
> noticeable: profiling the code while under load shows a significant amount of 
> time spent building the stack traces.
> Depending on the outcome of the discussion above, would it make sense to 
> envision to allow OGNL to throw these exceptions without the stack traces if 
> configured so (which can be easily done from JDK 7 using the constructor 
> taking the {{enableSuppression}} and {{writableStackTrace}} arguments - can 
> also be achieved from older JDKs by overriding method {{fillInStackTrace()}} 
> )?
> Note that a preliminary attempt showed that the cost of building these 
> exceptions without the stack traces is virtually zero, making the exceptions 
> totally painless and invisible (they appear no more while profiling).



--
This message was sent by Atlassian Jira
(v8.20.1#820001)


[jira] [Commented] (OGNL-261) OgnlException with "source is null for getProperty" thrown when using compound expression

2021-11-14 Thread Lukasz Lenart (Jira)


[ 
https://issues.apache.org/jira/browse/OGNL-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17443590#comment-17443590
 ] 

Lukasz Lenart commented on OGNL-261:


So the whole problem is to suppress the stack trace? I think when OGNL was 
developed there were no way to do this or noone thought about the consequences. 
If this is the whole change I opt for it!

[~davoustp] thanks a lot for your support!

> OgnlException with "source is null for getProperty" thrown when using 
> compound expression
> -
>
> Key: OGNL-261
> URL: https://issues.apache.org/jira/browse/OGNL-261
> Project: Commons OGNL
>  Issue Type: Improvement
>  Components: Core Runtime
>Reporter: Pascal Davoust
>Priority: Major
>
> Spin-off discussion from WW-5147 and related 
> [https://github.com/apache/struts/pull/504] pull request.
> Whenever an OGNL expression compiles into an AST with compound node 
> statements, the evaluation can result into a {{{}OgnlException("source is 
> null for getProperty(null, "propertyName")"){}}}.
> This stems from the logic in method {{ognl.ASTChain.getValueBody(OgnlContext, 
> Object)}} which uses the result of the current node as the source for the 
> next node in the chain.
> If the result of the current node evaluation results into {{{}null{}}}, then 
> the next node throws the exception.
> As mentioned in [https://github.com/apache/struts/pull/504], there is a 
> question about whether this logic is by design or if there is something to 
> investigate (I definitely lack background and OGNL knowledge to even guess).
> If this behavior is legitimate, it also turns out that this situation occurs 
> a lot and the cost of building the exceptions with the stack traces is fairly 
> noticeable: profiling the code while under load shows a significant amount of 
> time spent building the stack traces.
> Depending on the outcome of the discussion above, would it make sense to 
> envision to allow OGNL to throw these exceptions without the stack traces if 
> configured so (which can be easily done from JDK 7 using the constructor 
> taking the {{enableSuppression}} and {{writableStackTrace}} arguments - can 
> also be achieved from older JDKs by overriding method {{fillInStackTrace()}} 
> )?
> Note that a preliminary attempt showed that the cost of building these 
> exceptions without the stack traces is virtually zero, making the exceptions 
> totally painless and invisible (they appear no more while profiling).



--
This message was sent by Atlassian Jira
(v8.20.1#820001)