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. 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. On Mon, Jan 4, 2016 at 2:09 PM, Oleg Kalnichevski <ol...@apache.org> wrote: > On Sat, 2016-01-02 at 19:35 -0500, Benson Margulies wrote: >> It would be convenient if there was some way to tell the HTTP client >> what class loader to use as the Thread Context Classloader when >> calling the FutureCallback. Otherwise, it's prone (in OSGi) to be for >> the the http component OSGI component. >> > > Hi Benson > > My knowledge and understanding of OSGi is rudimentary at best. Would you > suggest a solution to this issue by submitting a patch or raising a PR? > > Oleg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
