[
https://issues.apache.org/jira/browse/SLING-12478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897652#comment-17897652
]
Robert Munteanu commented on SLING-12478:
-----------------------------------------
[~rliechti] - right, we had some 1-1 discussions which are not captured in this
Jira issue. The Jira should reflect the full conversation, otherwise it gets
confusing for anyone else.
Here's my recollection:
- analysing warnings triggered by SLING-12454 we sometimes get inactionable
warnings
-- DefaultGetServlet tried to change the content type
-- 8321 tried to change the content type
- one idea was to print the include chain, which you implemented based on the
request dispatcher data
- another idea was to print the full context
-- first idea was the stack trace, but that is a) too verbose (IMO) and b) can
reach a size where various logging platforms (Loki, Splunk, Elastic, etc )
start truncating it
-- so the idea of printing the RequestProgressTracker came up
{quote}Yes, as we discussed before... This is first of all done because a java
exception message should not contain multi line, and second to support logging
tools better that may have issues with multi line parsing.{quote}
a. With regards to multiline exception messages I don't have a big concern with
that. I think it helps with readability. If your concern is about the message
being displayed as-is, you can create a nested exception and add the
RequestProgressTracker information in the message of the cause.
b. One thing I want to point out is that logging platforms usually operate on
total message size, not number of lines. So if your concern about 'one big
string' vs 'multiple lines' is truncation, I think we should prefer more
readable output. These tools need to support reading stack traces anyway.
> Add potential origins of violations to the RequestDispatcher include API
> ------------------------------------------------------------------------
>
> Key: SLING-12478
> URL: https://issues.apache.org/jira/browse/SLING-12478
> Project: Sling
> Issue Type: Improvement
> Components: Engine
> Reporter: Remo Liechti
> Assignee: Remo Liechti
> Priority: Minor
> Fix For: Engine 2.16.0
>
>
> Add more information to the log about potential origins of the violation
> message added in SLING-12454.
> Use the RequestProgressTracker API to get the messages to find START_TIMER's
> that do not have an END_TIMER yet, which means a violation is most likely
> caused by that origin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
