lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <>
Subject [jira] [Commented] (SOLR-12008) Settle a location for the "correct" log4j2.xml file.
Date Fri, 06 Jul 2018 19:26:00 GMT


Erick Erickson commented on SOLR-12008:

I think this is ready, unless I made some silly error. Places that I could use some help testing:

- windows solr.bat files.
- solr-exporter

The thing to watch out for is if any log file is created in something very funky like {{ ${sys:solr.log.dir}/solr.log

The problem here is what I described above and it just means that the script should point
to server/resources/log4j2-console.xml

I messed up the Windows commands earlier and they all pointed to log4j2.xml, which would have
put files, well, somewhere wrong.

Since this isn't pushed yet, it is not responsible for SOLR-12538. However, since I'm in here
anyway, I'll incorporate all the /// in the specs for Windows command files and maybe kill
two birds with one stone.

The first patch today is without any attempt to fix SOLR-12538, the second _does_ try to fix

[~varunthacker] I couldn't reproduce your issue with IntelliJ.

I'd really like to push this early next week, so if someone who has Windows readily available
could give it a whirl I'd appreciate.

I haven't precommitted or tested this since these latest changes, will be doing that momentarily.

> Settle a location for the "correct" log4j2.xml file.
> ----------------------------------------------------
>                 Key: SOLR-12008
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: logging
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>            Priority: Major
>         Attachments: SOLR-12008.patch, SOLR-12008.patch, SOLR-12008.patch
> As part of SOLR-11934 I started looking at files. Waaay back in 2015,
the %C in "/solr/server/resources/" was changed to use %c, but the file in
"solr/example/resources/" was not changed. That got me to looking around and
there are a bunch of files:
> ./solr/core/src/test-files/
> ./solr/example/resources/
> ./solr/solrj/src/test-files/
> ./solr/server/resources/
> ./solr/server/scripts/cloud-scripts/
> ./solr/contrib/dataimporthandler/src/test-files/
> ./solr/contrib/clustering/src/test-files/
> ./solr/contrib/ltr/src/test-files/
> ./solr/test-framework/src/test-files/
> Why do we have so many? After the log4j2 ticket gets checked in (SOLR-7887) I propose
the logging configuration files get consolidated. The question is "how far"? 
> I at least want to get rid of the one in solr/example, users should use the one in server/resources.
Having to maintain these two separately is asking for trouble.
> [] Do you have any wisdom on the properties file in server/scripts/cloud-scripts?
> Anyone else who has a clue about why the other properties files were created, especially
the ones in contrib?
> And what about all the ones in various test-files directories? People didn't create them
for no reason, and I don't want to rediscover that it's a real pain to try to re-use the one
in server/resources for instance.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message