Hi Stuart,

Thank you for your response. We have a filter class at the top level currently which authenticates and tracks requests and may decide to delay a request using AsyncContext's timeout. When implemented at the top level before being delegated to a servlet, the asynccontext.dispatch will cause the request (after the delay) to come back through the same filter class. If it is done after being delegated, the dispatch will directly access the resource requested. The class will mostly work in the same way if added as an outer handler to the servlet context, except that dispatch will directly go to the  underlying resource.

Thanks,
Jack

On Sun, Jul 10, 2016 at 8:03 PM, Stuart Douglas <sdouglas@redhat.com> wrote:
No, in Undertow these are not created until the request has actually
been delegated to a Servlet context (as it is possible for requests to
not be using Servlet at all).

What are you trying to do? There is probably a way to do it using
native Undertow handlers.

Stuart

On Sat, Jul 9, 2016 at 1:59 AM, Jack Ding <z29ding@uwaterloo.ca> wrote:
> Hi,
>
> Is there a method or workaround that would allow the the initial level
> Handler (e.g., PathHandler) for an undertow server access HttpServletRequest
> and HttpServletResponse? I am trying to switch our server from Embedded
> Jetty, in which the initial handler does some processing using the
> HttpServletRequest and Response before matching and delegating to the
> appropriate ServletContextHandler, however in Undertow it seems these are
> not created (via ServletRequestContext) until after the matching.
>
>
> Thank you,
>
>
> Jack
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev