Bug 50226 - Problem with placeholders and PropertyConfigurator
Summary: Problem with placeholders and PropertyConfigurator
Status: NEW
Alias: None
Product: Log4j - Now in Jira
Classification: Unclassified
Component: Configurator (show other bugs)
Version: 1.2
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: log4j-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-06 20:14 UTC by Pedro J. Martos
Modified: 2010-11-06 20:14 UTC (History)
0 users



Attachments
Code snippet for PropertyConfigurator (946 bytes, text/plain)
2010-11-06 20:14 UTC, Pedro J. Martos
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pedro J. Martos 2010-11-06 20:14:00 UTC
Created attachment 26264 [details]
Code snippet for PropertyConfigurator

Hello and well met. I'm having problems while trying PropertyConfigurator to find configuration files with system placeholders in their names. I'll ellaborate on this issue:

I'm trying to set up the logging engine for a Web App. In order to give more flexibility in the configuration and deployment process, I have a properties file where the administrator can set the location of the main log4j configuration file. In my application code, I load the first file as a java.util.Properties instance, get the location of the log4j.properties file via Properties.getProperty, and then call PropertyConfigurator.configure with that value as the String parameter. The problem comes when I set the location as a file name with filesystem placeholders, e.g. ${some.folder}/webapps/appname/WEB-INF/log4j.properties, even when the "some.folder" folder is declared as an environment variable.

After checking the PropertyConfigurator class code, I found the problem inside the doConfigure(String, LoggerRepository) method. It tries to open a FileInputStream without considering any placeholders in the filename, and then an Exception is raised if the file couldn't be found (that is, if the file is not literally accesible in the filesystem as is, or exists but is archived inside a .jar file). The Exception is catched and silenced, and logging engine fails over and turns off. There's a snippet attached to this bugfile with a possible solution to this issue; the code provides a means for retrieving configuration files with absolute paths or relative to the classpath (even those inside .jar files), with or without placeholders. Obviously, the placeholders must contain keys known to the JVM (i.e. System properties). The fix requires the addition of the java.io.File class in the imports section. I'd love to share any thougths about this subject; critics and advices are the way to mastery :D

I apologize for the inconvenience if this issue was already tracked down and planned to fix in a future release. 

Thank you for your time. Farewell.