Hi Oleg, > There are several ways this could be done: > > * dumbly copy those attributes from the default context that are not > explicitly defined in the custom one (will have performance costs)
* Clone the default context as a shallow copy and modify it. > * 'link' contexts similarly to the way we link HttpParams in HttpCore > (considered error-prone) But that is available currently. The HttpRequestExecutionContext supports a parent context, or at least it did last year when I was still struggling with HttpDispatch. > * 'stack' the custom context on top of the default one using a decorator > class of a kind (needs work) I'd call that 'wrap'. The 'stack' idea I mentioned during the params discussions is closer to the 'link' approach. > The latter approach goes hand in hand with the problem of building > parameter hierarchies I and Roland have been wrestling with for quite > some time. > > Do we want to invest more time into this issue in an attempt to get it > right from the start or do we rather get HttpClient 4.0a1 out the door > sooner and come up with the fix for 4.0a2 already having some > preliminary feedback about the new API? The HttpClient interface makes the default context available, and both HttpClientContext and HttpExecutionContext support a 'parent' argument to the constructor. That is good enough for everything except the override-with-null problem. IMHO certainly good enough for an alpha1. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
