title: RestAPI logging practice issue
body: <p>I have this issue while working on logging application events.
  Below is the requirement.</p>
  
  <ul>
  <li>Log basic application events that are being taken place, method calls, their parameters, returns, process timings, etc..</li>
  <li>But only log file must contain 3 log lines for each request.
  
  <ul>
  <li>First line: to log request details, when a request comes in.</li>
  <li>Second line: to log all application events (this was the problem)</li>
  <li>Third line: to log request destroying event, when a request completes it lifecycle.</li>
  </ul></li>
  </ul>
  
  <p>Those three requests are identified by a transaction ID created when a request is hit, this ID puts to <code>MDC</code> of <code>slf4j</code>.</p>
  
  <p>Now I was told to use a <code>StringBuilder</code> to append logging details, which is supposed to initialized in a controller method, pass reference of it to every method getting called, log content of <code>StringBuilder</code> in <code>finally</code> block of controller method.</p>
  
  <p>This implementation makes the entire code base ugly.
  So I tried to use a <code>ThreadLocal</code> var with a <code>StringBuilder</code> to store logging details and clean it up when request is destroyed to avoid memory leaks. Instead of that I tried to use an implementation like below (pseudo).</p>
  
  <p><em>initialize <code>ThreadLocal</code> with an init value.</em></p>
  
  <pre><code>public static ThreadLocal&lt;StringBuilder&gt; log = new ThreadLocal&lt;StringBuilder&gt;() {
      @Override protected StringBuilder initialValue() {
          return new StringBuilder("|Internal");
      }
  };
  </code></pre>
  
  <p><em>append details to this <code>ThreadLocal</code>ed <code>StringBuilder</code></em></p>
  
  <pre><code>SomeClass.log.get().append("|").append(whatever);
  </code></pre>
  
  <p>After all processing, in finally block of controller method will write content of this to log file as second line of log, then clean it up.
  However my teammates are very doubtful about this.</p>
  
  <ul>
  <li>Could you please let me know is there anything wrong with the implementation in this case (is this a good approach)?</li>
  <li>is there any concerns such as memory leaks?</li>
  </ul>
  
  <p>Any comment on this is highly appreciated.</p>