title: Configuring Java FileHandler Logging to create directories if they do not exist
body: <p>I'm trying to configure the <a href="http://java.sun.com/j2se/1.4.2/docs/guide/util/logging/overview.html" rel="noreferrer">Java Logging</a> API's <a href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/FileHandler.html" rel="noreferrer">FileHandler</a> to log my server to a file within a folder in my home directory, but I don't want to have to create those directories on every machine it's running.</p>
  
  <p>For example in the logging.properties file I specify:</p>
  
  <pre><code>java.util.logging.FileHandler
  java.util.logging.FileHandler.pattern=%h/app-logs/MyApplication/MyApplication_%u-%g.log
  </code></pre>
  
  <p>This would allow me to collect logs in my home directory (%h) for MyApplication and would rotate them (using the %u, and %g variables).</p>
  
  <p>Log4j supports this when I specify in my log4j.properties:</p>
  
  <pre><code>log4j.appender.rolling.File=${user.home}/app-logs/MyApplication-log4j/MyApplication.log
  </code></pre>
  
  <p>It looks like there is a bug against the Logging FileHandler:
  <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6244047" rel="noreferrer">Bug 6244047: impossible to specify driectorys to logging FileHandler unless they exist</a></p>
  
  <p>It sounds like they don't plan on fixing it or exposing any properties to work around the issue (beyond having your application parse the logging.properties or hard code the path needed):</p>
  
  <blockquote>
    <p>It looks like the
    java.util.logging.FileHandler does not
    expect that the specified directory
    may not exist. Normally, it has to
    check this condition anyway. Also, it
    has to check the directory writing
    permissions as well. Another question
    is what to do if one of these check
    does not pass.</p>
    
    <p>One possibility is to create the
    missing directories in the path if the
    user has proper permissions. Another
    is to throw an IOException with a
    clear message what is wrong. The
    latter approach looks more consistent.</p>
  </blockquote>