We have a webapp that must be able to start logging during production.

Our solution is to start a timer thread from its ContextListener that regularly 
re-initializes the configuration from a log4j.properties file:

   LogManager.resetConfiguration();
      ClassLoader cl = this.getClass().getClassLoader();
      URL log4jPropsUrl = cl.getResource("log4j.properties");
      if (log4jPropsUrl != null)
         PropertyConfigurator.configure(log4jPropsUrl);
      else
         log.warn("log4j properties not found");

However, this locks the log4j.properties file, located in the webapp directory, 
so that a hot redeploy fails; Tomcat can't delete log4j.properties since it is 
locked. That is a show-stopper for us.

I have checked the source code of PropertyConfigurator, and think I have found 
the bug. The method doConfigure calls

   props.load(configUrl.openStream());

but it does not call close() on the resulting InputStream. It must be closed, 
or the file will be locked, at least on Windows. A fix may look like:

  InputStream is = configUrl.openStream();
  props.load(is);
  is.close();

We have encountered serveral other problems with files locked by log4j, but 
they are harder to track down. Searching the web also turns up several 
frustrations with files unnecessarily locked by log4j. It would therefore 
probably be a very good idea to search the log4j source code for similar 
constructs elsewhere and add close() wherever necessary.