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? 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. Let me know and I could probably start on that effort if you think it's worth it now. Thanks! Bill- On Fri, Aug 3, 2012 at 5:56 PM, Oleg Kalnichevski <[email protected]> wrote: > On Fri, 2012-08-03 at 16:31 -0400, William Speirs wrote: >> The HttpAsyncRequestHandlerResolver interface only allows for >> resolving an HttpAsyncRequestHandler via URI, and >> HttpAsyncService.getRequestHandler() is marked as private, so >> extending that class to change functionality it's possible. What would >> be the easiest way to change HttpCore-NIO to resolve an >> HttpAsyncRequestHandler from an HttpRequest? >> >> I am looking to resolve based upon the Host header... essentially, >> providing virtual host support to HttpCore-NIO. >> >> Thoughts? >> >> Thanks! >> >> Bill- >> > > Hi Bill > > Making HttpAsyncService#getRequestHandler() protected would probably be > the easiest. However, we could consider deprecating > HttpRequestHandlerResolver and HttpAsyncRequestHandlerResolver in favor > of more generic interfaces. > > Please note that as an interim solution you can always make > HttpAsyncRequestHandlerResolver resolve the request URI to a > HttpAsyncRequestHandler that delegates request processing to custom > handlers based on some other properties of the request. > > 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]
