On Mon, 2016-01-04 at 15:41 -0500, Benson Margulies wrote: > Oleg, let me start with a more coherent explanation, and that might > lead to an idea about what sort of PR would be tasteful. > > The Async http client is an example of a thing that creates threads, > accepts objects, and calls those objects from those threads. > > Meanwhile, there are things in the world that call > Thread#getContextClassLoader, and use the class loader that they > receive in return to search. Some of the built-in Java 'SPI' > interfaces are examples. > > The combination of the two of these things can lead to unpleasant > surprises, when a callback object is called on some thread whose > context class loader is not what it needs/expects. > > 1. One possible response to this is 'doctor, doctor'. It's the job of > the person coding the callback to capture the desired classloader, and > try/finally it into the current thread's context class loader. > > 2. Another possibility is for the thread-making component to accept a > ThreadFactory, and the coder can provide a thread factory that does > the right thing. >
This should be pretty trivial to do as HttpAsyncClientBuilder already accepts ThreadFactory as input. > 3. A third is for the thread-making component to have an explicit API > to specify the desired context class loader when calling callbacks. > Apache CXF does this. > > If you want to stick to #1, I'm not going to armtwist. For all I know, > Http Async already does #2. If not, I would be happy to JIRA/PR > whichever of 2 or 3 you dislike least. > I can do a few little tweaks to make #2 work right away and I am happy to add #3 if everyone agrees. Cheers Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
