The method ClassLoaderLogManager.replace(String) that is in charge of replacing system properties at the begining of the property also modify the end of the property due to a call to trim. This implies that Logger/Handler/Formatter that relies on properties endding with some spases (including '\n') will have a different behaviour with JDK LogManger and tomcat ClassLoaderLogManager a modified verstion of this method could be: protected String replace(String str) { // start modification // String result = str.trim(); // commented out int len = str.length(); int st = 0; while ((st < len) && (str.charAt(st) <= ' ')) { st++; } String result = (st > 0) ? str.substring(st) : str; // end modification if (result.startsWith("${")) { int pos = result.indexOf('}'); if (pos != -1) { String propName = result.substring(2, pos); String replacement = System.getProperty(propName); if (replacement != null) { result = replacement + result.substring(pos + 1); } } } return result; }
I'm not sure our goal is to provide identical behavior to Sun's log manager. Relying on whitespace is fragile anyways. I won't close this item, in case other people have different opinions, but it doesn't seem worthwhile to me.
(In reply to comment #1) ...Relying on whitespace is fragile anyways... Even if whitespace are "fragile", tomcat shall handle properties values according to properties file specification or not use a properties file. The goal is to addapt LogManager to the container environnement and to offer some new facilities. But, in my opinion, logging utilities (Handler, Formatter) devlopped for J2SE shall usable in a webapp environment without re-writting their properties handling code.
Ok, you have your fix and you can use it, rejoice :) Tomcat will not integrate your fix, however.
The current behavior does not follow the file properties specification see http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html#load(java.io.InputStream) but claims it does. in org.apache.juli.ClassLoaderLogManager ... /** * Get the value of the specified property in the classloader local * configuration. * * @param name The property name */ public String getProperty(String name) { ... This requires a correction either in the documentation, to explain the specific behavior, or in the code to follow file properties specification. I fully agree that this is neither critical nor urgent. Priority or resource might impose to postpone the fix. Or compatibility with the buggy behavior might be preferred to a code fix. That's no trouble, but transition to "Resolved won't fix" when the specification contract is broken cannot be a good practice.
Fixed in SVN (not with the above patch) and will be included in 5.5.21 onwards.