On Wed, 2014-12-17 at 11:55 +0530, srihari na wrote: > Thank You for the quick response. Can we get a confirmation that this issue > is resolved in later versions or a probable solution can be designed for > the described scenario? The reason we ask is our product bundled > v4.2.5(upgraded from 3.1) of the library in April 2013 and moving to > 4.3/4.4 would mean a lot of API/design changes that can significantly > impact the product stability. It is therefore desirable for us to move to a > stable version which is covered under under Long Term Suppor (LTS). Is > there a plan to support 4.3/4.4 for longer term or can you let us know the > current outlook for ending support for those streams? Also we will be > interested to know if any support will be provided on 4.2 stream on buying > support for annual fee. >
Apache HC is a non-commercial project. We do not have LTS releases. We are able to maintain two concurrent branches only only: dev (unstable) and ga (stable). Current stable branch is 4.3. 4.4 GA can be expected in Q1 2015. Oleg > Thank you hoping for a quick response. > > On Mon, Dec 15, 2014 at 7:48 PM, Oleg Kalnichevski <[email protected]> wrote: > > > > On Mon, 2014-12-15 at 17:46 +0530, srihari na wrote: > > > Hello Folks, > > > > > > We are using HttpClient 4.2.5 and Our scenario is that there is only 1 > > > instance of HTTP client throughout the JVM and only one connection pool > > > linked to client. The same client using the single connection pool > > > interacts with various http/https endpoints by creating a new method > > > instance for every request. For https based connections we have our own > > > implementation for socket connection factory, when we try to register a > > new > > > custom scheme using custom socket factory via local context, it is not > > > being picked by the client. It always tries to get the list of scheme > > > registries from connection manager even though we try to override at > > local > > > context level. We use local context to pass authentication information > > > which works perfectly fine however schemeregistry is not picked up. > > > > > > AbstractHttpClient > > > protected HttpRoutePlanner createHttpRoutePlanner() { > > > return new DefaultHttpRoutePlanner(*getConnectionManager* > > > *().getSchemeRegistry()*); > > > } > > > > > > > > > Now that local context scheme registry is not picked up we tried > > > registering all the schemes at connection manager level with unique > > scheme > > > names and pass the respective scheme name in the HttpHost of the execute > > > method. > > > In the first pass route planner has the proper scheme name we set in the > > > HttpHost so it pickedup the proper socket factory > > > DefaultHttpRoutePlanner.determineRoute(HttpHost, HttpRequest, > > HttpContext) > > > line: 113 > > > DefaultRequestDirector.determineRoute(HttpHost, HttpRequest, HttpContext) > > > line: 791 > > > DefaultRequestDirector.execute(HttpHost, HttpRequest, HttpContext) line: > > 414 > > > DefaultHttpClient(AbstractHttpClient).execute(HttpHost, HttpRequest, > > > HttpContext) line: 906 > > > > > > In the second pass the target it reconstructed using the URI so the > > custom > > > scheme name is lost and our custom socket factory is not picked up > > > DefaultRequestDirector.handleResponse(RoutedRequest, HttpResponse, > > > HttpContext) line: 1110 > > > *HttpHost newTarget = URIUtils.extractHost(uri);* > > > > > > DefaultHttpRoutePlanner.determineRoute(HttpHost, HttpRequest, > > HttpContext) > > > line: 113 > > > DefaultRequestDirector.determineRoute(HttpHost, HttpRequest, HttpContext) > > > line: 791 > > > DefaultRequestDirector.handleResponse(RoutedRequest, HttpResponse, > > > HttpContext) line: 1129 > > > DefaultRequestDirector.execute(HttpHost, HttpRequest, HttpContext) line: > > 548 > > > > > > Request the forum to help solve our scenario. You help is much > > appreciated, > > > awaiting a quick response. > > > > > > Thank you > > > > > > > Please consider upgrading to 4.3.x. Even if it is a bug in HttpClient > > there will be no more releases from the 4.2.x branch. > > > > Oleg > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
