[
https://issues.apache.org/jira/browse/SOLR-12008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386512#comment-16386512
]
Erick Erickson commented on SOLR-12008:
---------------------------------------
bq: If we're going to use the same config for all of them, I think there should
only be one config file in the binary distribution
I couldn't agree more. OTOH, multiple files weren't created just for fun and
we're about to cut Solr 7.3 so I'm reluctant to do anything this week.
I'm thinking that after the branch for 7.3 is cut and SOLR-7887 gets committed
(also after the 7.3 branch is set) we can work on this seriously.
Here's a list of all of them as of SOLR-7887:
./core/src/test-files/log4j2.xml
./example/resources/log4j2.xml
./solrj/src/test-files/log4j2.xml
./server/resources/log4j2.xml
./server/scripts/cloud-scripts/log4j2.xml
./contrib/dataimporthandler/src/test-files/log4j2.xml
./contrib/clustering/src/test-files/log4j2.xml
./contrib/ltr/src/test-files/log4j2.xml
./test-framework/src/test-files/log4j2.xml
I think anything with an ancestor directory of test-files actually seems OK;
it's clear to anyone
looking that they're for, well, tests. It might be aesthetically pleasing to
point them at the "one true source".
These three _do_ bother me....
./example/resources/log4j2.xml
./server/resources/log4j2.xml
./server/scripts/cloud-scripts/log4j2.xml
When we look at this seriously we'll have to trace back what the JIRA they were
originally added was about and insure that whatever it was still works.
> Settle a location for the "correct" log4j2.xml file.
> ----------------------------------------------------
>
> Key: SOLR-12008
> URL: https://issues.apache.org/jira/browse/SOLR-12008
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: logging
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Major
>
> As part of SOLR-11934 I started looking at log4j.properties files. Waaay back
> in 2015, the %C in "/solr/server/resources/log4j.properties" was changed to
> use %c, but the file in "solr/example/resources/log4j.properties" was not
> changed. That got me to looking around and there are a bunch of
> log4j.properties files:
> ./solr/core/src/test-files/log4j.properties
> ./solr/example/resources/log4j.properties
> ./solr/solrj/src/test-files/log4j.properties
> ./solr/server/resources/log4j.properties
> ./solr/server/scripts/cloud-scripts/log4j.properties
> ./solr/contrib/dataimporthandler/src/test-files/log4j.properties
> ./solr/contrib/clustering/src/test-files/log4j.properties
> ./solr/contrib/ltr/src/test-files/log4j.properties
> ./solr/test-framework/src/test-files/log4j.properties
> 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.
> [[email protected]] 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
