[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    [jira] [Resolved] (OGNL-261) Avoid collecting stacktrace when building an OgnlException
From:       "Lukasz Lenart (Jira)" <jira () apache ! org>
Date:       2021-12-31 16:48:00
Message-ID: JIRA.13411664.1636895687000.84647.1640969280219 () Atlassian ! JIRA
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/OGNL-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Lukasz Lenart resolved OGNL-261.
--------------------------------
    Fix Version/s: 3.3.1
       Resolution: Fixed

> Avoid collecting stacktrace when building an OgnlException
> ----------------------------------------------------------
> 
> 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
> Fix For: 3.3.1
> 
> 
> 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)


[prev in list] [next in list] [prev in thread] [next in thread]