[
https://issues.apache.org/jira/browse/SOLR-11701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16295411#comment-16295411
]
Tim Allison commented on SOLR-11701:
------------------------------------
Back to keyboard. You're right in all of the above. When we bump slf4j from
1.7.7 to 1.7.24, its behavior changes to print out the full stacktrace instead
of just the message.
In org.slf4j.helpers.MessageFormatter in 1.7.7, the exception is counted as one
of the members of {{argArray}}, and because of the following snippet, the
{{throwableCandidate}} is nulled out in the returned {{FormattingTuple}}
{noformat}
if (L < argArray.length - 1) {
return new FormattingTuple(sbuf.toString(), argArray,
throwableCandidate);
} else {
return new FormattingTuple(sbuf.toString(), argArray,
(Throwable)null);
}
{noformat}
In 1.7.24, there's an added bit of logic before we get to that location that
removes the exception from {{argArray}} so that it can't get swept into the
message.
{noformat}
Object[] args = argArray;
if (throwableCandidate != null) {
args = trimmedCopy(argArray);
}
{noformat}
I have in the back of my mind that there was a reason we upgraded slf4j in
Tika. I'll look through our git history to see when/why and if we need to do
it for the Solr integration.
> Upgrade to Tika 1.17 when available
> -----------------------------------
>
> Key: SOLR-11701
> URL: https://issues.apache.org/jira/browse/SOLR-11701
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Tim Allison
> Assignee: Erick Erickson
> Attachments: SOLR-11701.patch
>
>
> Kicking off release process for Tika 1.17 in the next few days. Please let
> us know if you have any requests.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
