Chris M. Hostetter created SOLR-15630:
-----------------------------------------

             Summary: MDC "prefix labels" should be handled by Layout - not 
hardcoded in solr code
                 Key: SOLR-15630
                 URL: https://issues.apache.org/jira/browse/SOLR-15630
             Project: Solr
          Issue Type: Improvement
      Security Level: Public (Default Security Level. Issues are Public)
            Reporter: Chris M. Hostetter
            Assignee: Chris M. Hostetter


Currently, when Solr puts values in the MDC for logging, it always prepends 
them with a "CHAR" + "COLON" prefix that uniquely identifies what the value is 
– even though the MDC is a map and every value has a "key" associated with it 
that identifies what it is, ex...
{code:java}
  public static void setCollection(String collection) {
    if (collection != null) {
      MDC.put(COLLECTION_PROP, "c:" + collection);
    } else {
      MDC.remove(COLLECTION_PROP);
    }
  }
{code}
This choice evidently traces back to when MDC values where initially added 
SOLR-6673/SOLR-7590 (when Solr was still using slf4j->JUL IIUC) because that 
was best (only?) way folks found to ensure that log messages that did _not_ 
have values for specific MDC keys weren't cluttered with valueless prefixes  
even when a log message didn't correspond to a specific collection (or replica, 
or shard, etc...)

But with modern log4j, we can use use things like the {{%notEmpty}} syntax to 
prevent excessive verbosity when MDC values aren't set – allowing us to move 
the prefixes out of the Solr code and into Solr default log4j configuration – 
so that users who customize their log4j configuration with things like {{%mdc}} 
(or JSON logging) can get the "bare" values w/o hardcoded prefixes. (while 
keeping the exact same default log format ... or even improving it by removing 
some of the wasted whitespace)

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to