You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by bu...@apache.org on 2010/11/07 01:14:06 UTC

DO NOT REPLY [Bug 50226] New: Problem with placeholders and PropertyConfigurator

https://issues.apache.org/bugzilla/show_bug.cgi?id=50226

           Summary: Problem with placeholders and PropertyConfigurator
           Product: Log4j
           Version: 1.2
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Configurator
        AssignedTo: log4j-dev@logging.apache.org
        ReportedBy: pjmv1986@gmail.com


Created an attachment (id=26264)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26264)
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.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org