On 4/13/2014 1:18 PM, Boogie Shafer wrote: > as you discovered, the double logging problem is because additivity is > default enabled and you have solr event defined specifically AND in the root > logger
My config has the root logger at WARN, the specific category is at INFO. All of the doubly logged messages are at INFO, so they should not be logged by the root logger. I would call that a bug in log4j. I have the issue under control by turning additivity off. When I have a moment, I will check the log4j bug tracker to see if it's already been reported. > on your log4jv2 v logback investigation > > logback IS "log4j done right" and the way to go. its here today and works. > http://logback.qos.ch/reasonsToSwitch.html > > I've never understood the point of the log4j2 project. or why folks still > want to use log4j given its deficiencies relative to logback. ;) I was just noting what's supported by slf4j and what isn't. I can't say which is better between logback and log4j2, because I have not looked into the capabilities or documentation on either project. It's not high enough on my priority list. > is this a good place to ask about a few logging related items re: solr > support for them? > > -more up to date slf4j included in the distribution (e.g 1.7.7) . slf4j has > gotten more than a few updates in the 8 release since 1.6.6 (which is what is > currently packaged with solr) > http://www.slf4j.org/news.html Solr is part of the Lucene project. Because Lucene is a programming API, one very important guideline in the project can be stated as "Don't break compatibility unless it's necessary." This conservative approach extends to Solr. This means that we don't upgrade our dependencies just because a new version has come out. There needs to be a specific reason to upgrade. It mostly happens when there's a bug to be fixed or a new feature cannot be implemented properly without the upgrade. Sometimes we do upgrade if there's a distinct advantage. See SOLR-5765 -- version 4.8.0 will release with slf4j 1.7.6. When we upgrade our dependencies, users that have been using Solr or SolrJ with other software projects may run into a compatibility problem that did not exist before they upgraded. When someone asks why we broke their setup, we better have a good reason. > -if not switching to logback, a more up to date log4j included in the > distribution (e.g. 1.2.17) (since that seems to be the logger of choice for > the solr devs) > > -if sticking with log4j, switching to the log4j.xml version of the config > file which allows some more configuration options and is apparently the > current preferred format > > -if sticking with log4j, consider also packaging the log4j extras jar to > extend the capabilities of regular log4j and get it closer to logback (e.g. > log rotation with compression) The Solr example is only one release back - 1.2.16. Anyone is free to use the XML config format, upgrade slf4j, upgrade log4j, include additional jars for additional features, or switch to an entirely new logging framework. This is why we removed the logging jars from the .war file in version 4.3.0. In my own Solr install, I have upgraded all these components to more recent versions. I am in a position to make that decision for myself. > -fixing the solr logging UI display so it can work even if the solr events > are NOT sent to the root logger. (maybe this UI interface should allow > picking a specific log file defined in the logging configuration for max > flexibility?) If you have an idea and there's not already an issue for it in Jira, feel free to open one. If you can write a patch to implement your idea, even better. Thanks, Shawn
