On Tue, Jan 5, 2016 at 12:50 AM, Alexey Panchenko
<alex.panche...@gmail.com> wrote:
> 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.
I'm not suggesting any auto(matic/magic) setting of the TCCL, just to
make sure that applications that need it can control it a little more
conveniently.
>
>
>>
>> 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.
If an application needs disparate TCCL values for disparate callbacks,
I completely agree that the application will be coding
ClassLoader oldTccl = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(myClassLoader);
DO_WHATEVER();
} finally {
Thread.currentThread().setContextClassLoader(oldTccl);
}
in the callbacks; there's nothing to be done to make their life easier.
>
>
>>
>> 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?
Here's the advantage of this for some situations. Imagine a
pre-existing executor service that does not give you a way to
influence the thread factory. If Async Http was an example of an API
that took an ExecutorService, this would allow TCCL management for
someone who could not influence the executor service's choice of
thread factory. At least, that's what I think that the CXF people were
thinking. If HttpAsync already accepts a ThreadFactory rather than an
Executor, I see agree that there's little advantage of this over #2.
>
>
>>
>> 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
