You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Erick Erickson (Jira)" <ji...@apache.org> on 2020/05/27 15:15:00 UTC

[jira] [Comment Edited] (SOLR-14280) SolrConfig logging not helpful

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org