currently the spec says in 6.2.1 - 4
*The filter may invoke the next entity in the filter chain. The next entity
may be
another filter, or if the filter making the invocation is the last filter
configured in the
deployment descriptor for this chain, the next entity is the target Web
resource. The
invocation of the next entity is effected by calling the doFilter method on
the
FilterChain object, and passing in the request and response with which it
was
called or passing in wrapped versions it may have created.
The filter chain’s implementation of the doFilter method, provided by the
container, must locate the next entity in the filter chain and invoke its
doFilter
method, passing in the appropriate request and response objects.
*
This strongly indicates that it is the thread calling doFilter that invokes
the next element of the chain, be that a filter or servlet. Also it is
a very common pattern to use try{}finally{} in filters to allocate and free
resources, so it is essential to keep the invocation chain intact.
Thus if we clarify this, is must be to say:
The service method is required to run in the same thread as all filters
that apply to the servlet.
regards
On 31 January 2012 08:08, Shing Wai Chan <shing.wai.chan_at_oracle.com> wrote:
> In an internal platform discussion, there is a question of whether all
> filters need to be run in the same thread as in servlets.
> In Section 6.2 of Servlet 3.0, there is a description on how filters work.
> There is "no" explicit requirement that the filters need to be run in the
> same thread.
> Is it a tacit assumption?
>
> We propose that the spec ought to say either:
>
> - The service method is required to run in the same thread as all filters
> that apply to the servlet.
>
> or
>
> - The service method is **not** required to run in the same thread as
> filters
> that apply to the servlet, and filters should not depend on sharing
> thread local data with the servlet.
>
>
> Shing Wai Chan
>