Hi guys, On Tue, Jan 5, 2016 at 2:41 AM, Benson Margulies <bimargul...@gmail.com> 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. > The threads created initially have TCCL inherited from their parent thread. In simple cases it might work already. Overall, it would be better if libraries stay away of it, as some frameworks use it, some don't, and library have no idea if user would benefit from that or not. > > 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. > That should work. > > 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. > There is DefaultConnectingIOReactor constructor accepting ThreadFactory, however that won't always help if callbacks with different TCCL expectations are called from the same thread. > > 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. > It seems like a variation of #1, if implemented as a delegate, isn't it? > > 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. > > Regards, Alex > > > > > 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 > >
