Bug 37509 - ClassLoaderLogManager remove '\n' at the end of logging.properties values
Summary: ClassLoaderLogManager remove '\n' at the end of logging.properties values
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Unknown (show other bugs)
Version: 5.5.12
Hardware: Other other
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-15 18:22 UTC by Franck Hamelin
Modified: 2006-11-08 19:05 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Franck Hamelin 2005-11-15 18:22:38 UTC
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;
    }
Comment 1 Yoav Shapira 2006-04-13 19:45:04 UTC
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.
Comment 2 Franck Hamelin 2006-04-13 23:27:02 UTC
(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.
Comment 3 Remy Maucherat 2006-04-13 23:31:22 UTC
Ok, you have your fix and you can use it, rejoice :) Tomcat will not integrate
your fix, however.
Comment 4 Franck Hamelin 2006-04-14 21:05:52 UTC
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.
Comment 5 Mark Thomas 2006-11-08 19:05:58 UTC
Fixed in SVN (not with the above patch) and will be included in 5.5.21 onwards.