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