DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=22894>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=22894 ------- Additional Comments From [EMAIL PROTECTED] 2005-07-21 22:37 ------- After reviewing the 1.3 fix, I've concluded that I don't particularly like the way that I approached it and will likely redo it and any fix is not going to be perfect enough for the 1.2 branch. I expect that the ultimate solution will be to preserve the existing backslash behavior for XML files with a "http:// jakarta.apache.org/log4j/" namespace and perform no backslash expansion when using an "http:// logging.apache.org/" namespace. The problem is that the undesired backslash expansion occurs in the generic XML processing. By the time the value gets to the FileAppender, it has lost too much information to be able to recreate the expected file name. However, if the backslash expansion is removed from the generic processing, then any configuration parameter that expected or compensated for the backslash expansion would have a different value. This most likely parameter that would be tripped up is the PatternLayout.pattern where the tests (and possibly other external users) used patterns like value="%m\n". However, since the processing affects all parameters, including those in custom appenders and layouts, there is no way of always doing the "right" thing. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
