Bug 51249 - JULI ClassLoaderLogManager doesn't properly handle ${} when replacing property values
Summary: JULI ClassLoaderLogManager doesn't properly handle ${} when replacing propert...
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 6.0.32
Hardware: PC All
: P2 minor (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-23 21:54 UTC by Richard Lavoie
Modified: 2011-06-15 12:22 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Lavoie 2011-05-23 21:54:38 UTC
when the LogManager does it's replace of ${property} it doesn't handle properly the fact that a } could exist before ${.

The indexOf for the char } should be relative to the start position of ${

Example of string : %{custom.property.matching} ${system.property.tomcat}

This would throw an exception about the index } being before ${

This is valid for all the 7.* versions as well as all the 6.* versions (validated from 6.0.27 and above).

There is not even a way to "escape" the ${} chars if we'd like to output them.
Comment 1 Konstantin Kolinko 2011-05-23 22:43:20 UTC
I see. Please be more specific next time: you are referring to the source code of method replace(String) of class org.apache.juli.ClassLoaderLogManager.

I acknowledge the issue with indexOf.


> There is not even a way to "escape" the ${} chars if we'd like to output them.

You can define a system property that expands to ${} or to ${ or whatever. As you might see from the code, the replacement text is used "as is" and is not searched further for replacement characters.
Comment 2 Mark Thomas 2011-06-02 16:13:36 UTC
Fixed in 7.0.x and will be included in 7.0.15 onwards.

Proposed for 6.0.x
Comment 3 Konstantin Kolinko 2011-06-09 13:49:34 UTC
I reimplemented the property substitution code in r1133857 with several improvements. See commit message and test cases.

It will be in 7.0.16. Proposed for 6.0.x
Comment 4 Konstantin Kolinko 2011-06-15 12:22:23 UTC
The fix applied 6.0 in r1136010. Will be in 6.0.33.