Pascal Davoust created OGNL-261:
-----------------------------------

             Summary: 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


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

Reply via email to