<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 5/14/15 12:13 AM, Daniel Fisher
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAFC6YwRLiVjf2p3bDwQVBjNKX2UVU-r+nXErSofcFrjeb+VPdA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote"><br>
            <div><br>
            </div>
            <div>I was forced to use ThreadLocal for LDAPS connections
              in JNDI. This is due to the fact that JNDI does not
              provide anyway to configure an SSLSocketFactory except by
              providing a string that is the class name. Which is used
              to load the class and invoke a static method. </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Ah, ok, I misremembered the details.<br>
    <br>
    <blockquote
cite="mid:CAFC6YwRLiVjf2p3bDwQVBjNKX2UVU-r+nXErSofcFrjeb+VPdA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>I would avoid this strategy if at all possible. Besides
              the code being hard to read,</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Yeah, that's why it's distasteful.  ThreadLocal always is.  But
    sometimes probably a necessary evil.<br>
    <br>
    <br>
    <blockquote
cite="mid:CAFC6YwRLiVjf2p3bDwQVBjNKX2UVU-r+nXErSofcFrjeb+VPdA@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> all sorts of interesting bugs can arise when
              connections need to be reopened by a different thread.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    <br>
    I actually don't think there's any dangers of that sort with this
    specific use case, esp even compared to say the servlet
    request/response ThreadLocal proxy stuff we did.  I think it's
    pretty much guaranteed that the HttpClient request/response will
    always be synchronous and happen in a single thread, period (they
    have an async httpclient, but that's a whole 'nother library and
    programming model). So as long as the ThreadLocal is cleaned up
    properly on each call, I'm not terribly concerned about that aspect
    of this proposal.<br>
    <br>
  </body>
</html>