hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Resolving an HttpAsyncRequestHandler from an HttpRequest
Date Tue, 07 Aug 2012 11:58:18 GMT
On Mon, 2012-08-06 at 14:56 -0400, Bill Speirs wrote:
> What we'd truly like to do is resolve a request based upon host first,
> then based upon URI. Certainly rolling-out a handler for /*, then
> having that handler call the other handlers based upon host/URI would
> work, but it feels ugly.
> Do you want me to open a JIRA ticket with patch to make
> HttpAsyncService.getRequestHandler() protected?
> I'd be willing to put some work into making these interfaces more
> generic, should I open a JIRA for that discussion, or keep it here?

I think you should raise a JIRA for this change and put a short summary
of what has been discussed on the dev list there.

> Such changes would have to be released with 5.0 as they would probably
> be API breaking, correct. I realize we're only on 4.2.X for core, but
> is it worth starting a 5.0 branch for these types of things? We could
> also probably delete a lot of deprecated code.

There is no need to wait till 5.0. We can deprecate the old interfaces,
add new ones and provide compatibility adaptors for the deprecated API.
This should keep HttpCore 4.3 fully compatible with the older versions
and allow for a gradual migration path. There are plenty of examples of
this approach in core and client. See this adaptor class [1] that
provides compatibility mappings between newer RedirectStrategy and
deprecated RedirectHandler APIs.

> Let me know and I could probably start on that effort if you think
> it's worth it now.




To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message