[
https://issues.apache.org/jira/browse/SOLR-14280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17117796#comment-17117796
]
Erick Erickson edited comment on SOLR-14280 at 5/27/20, 3:14 PM:
-----------------------------------------------------------------
[~asalamon74] Please open up a new JIRA. @-mention me and/or Jason so we can
track. What IDE do you use? 'cause I can give you a hack of the
validateLoggingCalls gradle build file that makes finding all these easy, at
least in IntelliJ. Actually, it wouldn't be a hack, if you clean all of these
up it'll be permanent. I just glanced at the text file I pasted on this JIRA
and don't quite know why it reported the message that's commented out....
What's unclear to me is if any of them should remain just getMessage() or
should print out the entire stack trace. If some of them should _stay_
getMessage/Cause(), add //logok to the line and the validation will not report
the issue.
I suppose we need two JIRAs, one for Lucene and one for Solr. Do note that the
Lucene ones are in Luke (except the one that's commented out) . Other than
Luke, Lucene doesn't use logging.
was (Author: erickerickson):
[~asalamon74] Please open up a new JIRA. @-mention me and/or Jason so we know
now to track. What IDE do you use? 'cause I can give you a hack of the
validateLoggingCalls gradle build file that makes finding all these easy, at
least in IntelliJ. Let me know.
What's unclear to me is if any of them should remain just getMessage() or
should print out the entire stack trace.
> SolrConfig logging not helpful
> ------------------------------
>
> Key: SOLR-14280
> URL: https://issues.apache.org/jira/browse/SOLR-14280
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Andras Salamon
> Assignee: Jason Gerlowski
> Priority: Minor
> Fix For: master (9.0), 8.6
>
> Attachments: SOLR-14280-01.patch, SOLR-14280-02.patch, getmessages.txt
>
>
> SolrConfig prints out a warning message if it's not able to add files to the
> classpath, but this message is not too helpful:
> {noformat}
> o.a.s.c.SolrConfig Couldn't add files from
> /opt/cloudera/parcels/CDH-7.1.1-1.cdh7.1.1.p0.1850855/lib/solr/dist filtered
> by solr-langid-\d.*\.jar to classpath:
> /opt/cloudera/parcels/CDH-7.1.1-1.cdh7.1.1.p0.1850855/lib/solr/
> dist {noformat}
> The reason should be at the end of the log message but it's just repeats the
> problematic file name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
