Level configuration such as the following log4j.logger.org.apache=info is recognized as DEBUG rather than INFO in Turkish locale This is caused by the "Turkish-i problem" that's explained on the following sites http://java.sys-con.com/read/46241.htm http://www.i18nguy.com/unicode/turkish-i18n.html In summary the following assumptions fail, and produces "false" value in Turkish locale "i".toUpperCase().equals("I"); "I".toLowerCase().equals("i"); Solution is to compare the config level to "INFO" with explicit English locale To reproduce, change the regional settings of Windows to be Turkish (via Control Panel -> Regional)
See this: http://pmd.sourceforge.net/rules/design.html In general, we should avoid case conversions where possible, and if not possible with a particular locale.
Changes for this checked into SVN trunk
Elias committed changes against log4j trunk in rev 500441. The changes would appear to result in several changed behaviors that may not be desirable, for example, Level.toLevel("\u0131NFO") (lowercase undotted I + NFO) would appear to return Level.INFO and now would return Level.DEBUG.
Changes in rev 500441 were reverted in rev 502388 to fix unit test breakage in o.a.l.helpers.DateLayoutTest.testSetOptionDateFormat. The scope of rev 500441 was way too broad and lacked unit tests to establish the pre-patch behavior that would be needed for changes to be applied in log4j 1.2. I'll review this bug and see if I can come up with smaller patches that address the individual issues raised.
Committed rev 510707 that addresses Level.getLevel("info") while still letting Level.getLevel("\u0131nfo") also work. Only other places in 1.2 branch that I saw toLower/toUpper used was in LogFactor5 and TTCCLayout and since those are deprecated I did not want to open that up. JoranConfig stuff in trunk uses it pretty heavily, but less need to support existing behavior there. I'm considering this fixed in log4j 1.2 and open in 1.3.
Closing bug. Fixed in log4j 1.2, walking away from 1.3.