Announcement Announcement Module
No announcement yet.
Why doesn't Log4jConfigListener resolve system properties in URL-style locations? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Why doesn't Log4jConfigListener resolve system properties in URL-style locations?


    Log4jWebConfigurer can be used to load different Log4J config files depending on a system property (Log4jConfigListener just passes it through):

    I would like to use this mechanism for URL locations, like "classpath:log4j-${com.example.env}.properties", which is currently not supported.

    Is there a reason why this shouldn't be possible? Otherwise I'd raise a feature request in Jira.


  • #2
    The (current) support is only (and I believe it is more container specific then spring specific!) for full paths and not parts of a path. But as I stated in the beginning I think this depends on the container and not on Spring.

    Well I was wrong . Just checked the code and Spring replaces any ${..} with the system-property associated with that, however it does that, indeed, only for urls not starting with file: or classpath:. However is you check the initLogging method of the Log4JConfigurer that should replace any placeholders left in the string.

    So which makes me believe that it should already be possible to replace those Strings in classpath: or file: urls.
    Last edited by Marten Deinum; Jul 16th, 2007, 08:32 AM.


    • #3
      Sorry Marten, I don't think I understand.

      From what I see, Log4jConfigListener just passes the context param string to Log4jWebConfigurer as is.

      Log4jWebConfigurer expands placeholders for non-URL locations, and passes the result on to Log4jConfigurer.initLogging(location).

      And according to the javadoc, Log4jConfigurer does support "classpath:"-style locations:

      location - the location of the config file: either a "classpath:" location (e.g. "") ...
      Therefore, it looks to me as if everything should work just fine if Log4jWebConfigurer expanded placeholders for URL locations as well. I admit I haven't tested this in code as of yet.


      • #4
        Check the source code of the method I mentioned. Log4jConfigurer initLogging ALSO tries to replace any remaining ${..}.

        	public static void initLogging(String location, long refreshInterval) throws FileNotFoundException {
        		String resolvedLocation = SystemPropertyUtils.resolvePlaceholders(location);
        		File file = ResourceUtils.getFile(resolvedLocation);
        		if (!file.exists()) {
        			throw new FileNotFoundException("Log4J config file [" + resolvedLocation + "] not found");
        		if (resolvedLocation.toLowerCase().endsWith(XML_FILE_EXTENSION)) {
        			DOMConfigurator.configureAndWatch(file.getAbsolutePath(), refreshInterval);
        		else {
        			PropertyConfigurator.configureAndWatch(file.getAbsolutePath(), refreshInterval);
        So the classpath: and file: are skipped by the Log4jWebConfigurer but are afterwards being processed by the Log4JConfigurer.


        • #5
          Nice catch, Marten. What actually threw me off track was this log message from Log4jWebConfigurer:

          Initializing Log4J from [classpath:log4j-${com.example.env}.properties]