Am 20:59, schrieb Ivan Habunek: > On 27 January 2012 21:55, Marcelo Gornstein <marce...@gmail.com> wrote: > >> <snip> >> >> Is this change irreversible? Is there anything that can be done to >> restore this behaviour? It seems to me that it is a benefit to expect >> the log4php ini files behave exactly as the php ini files (or it >> should be documented otherwise if they ARE NOT php ini files from >> 2.2.0 and up). >> >> I'm willing to work on a patch but I wanted to ask first if there is >> any consensus about this that I should be aware of. >> >> > Hi Marcelo, > > Frankly, I did not consider this use case when writing the new parser. You > have a valid point, and I'll consider bringing this back as it was. I will > first have to consider what else this action might break... > > Originally, this is where the idea came from: > https://issues.apache.org/jira/browse/LOG4PHP-114 > > To avoid the whole parsing issue, have you considered using the PHP config > format? Since 2.2. it is possible to provide it inline as well as in a > file. > http://logging.apache.org/log4php/docs/configuration.html > > We're trying to push the PHP and XML formats instead of INI since they're > more versatile and easier for us to parse and to document (working on an > XSD for next release).
I really hate to say it, but the third optional parameter to parse_ini_file() is a PHP 5.3-only feature. See changenotes section of the docs page: http://de.php.net/manual/en/function.parse-ini-file.php I assume you created duplicate behaviour for installations with 5.2 vs. 5.3, one behaving as tested and advertised, and one not. I'd suggest going back to INI_SCANNER_NORMAL, as this is the unchangable default for PHP 5.2. Regards, Sven Rautenberg
