programmatical addition or removal of filters prior to wicket filter request 
handling
-------------------------------------------------------------------------------------

                 Key: WICKET-3219
                 URL: https://issues.apache.org/jira/browse/WICKET-3219
             Project: Wicket
          Issue Type: New Feature
            Reporter: Peter Ertl
            Assignee: Peter Ertl
             Fix For: 1.5-M4
         Attachments: filter-extension.patch

[full-working patch included]

I would like to extend WicketFilter so you can add (or remove) standard servlet 
filters programatically to it. These will filter the request  prior to wicket 
using Filter#doChain(). At the end of the filter chain wicket itself will 
process the request.

Usually the wicket request handling looks like this:

 incoming browser request -> 
   begin WicketFilter#doFilter ->
     wicket request processing ->
   end WicketFilter#doFilter ->
 send response to browser

Now when adding standard java.servlet.Filter instances to the WicketFilter 
using something like

--- sample code ---

public class MyApplication extends WebApplication
{
        @Override
        protected void init()
        {
                super.init();

                XForwardFilter filter = new XForwardFilter(); // transparent 
proxy handling behind front-end proxies

                try
                {
                        getWicketFilter().addInterceptor(filter);
                        ////////// getWicketFilter().addInterceptor(filter, 
config); // alternate config (e.g. mock filter config since FilterConfig is 
just an interface)
                }
                catch (ServletException e)
                {
                  // standard exception which can be thrown from 
javax.servlet.Filter#init(FilterConfig)
                        log.error(e.getMessage(), e);
                }
}

--- EOF sample code ---

the processing will change like that:

  incoming browser request -> 
    begin WicketFilter#doFilter ->
      begin XForwardFilter#doFilter() ->
        XForwardFilter processing ->
        chain.doFilter(request,response) ->
          invoke wicket request processing ->
          end XForwardFilter#doFilter() ->
    end WicketFilter#doFilter ->
        send response to browser

- The filter (= interceptor) will be invoked for the same filter path 
WicketFilter is configured

Being able to add filters like this will have the following advantages:

- The filter can be added or removed anytime during the wicket application 
lifecycle
- You don't have to touch web.xml ever
- You can specify mock filter configs or alternate filter configs using 
(WicketFilter#addInterceptor(filter, alternateFilterConfig))
- Tigher integration of the filter with wicket since the application and 
session is already attached to the current thread context (similar to 
WicketSessionFilter, but without web.xml fiddling)
- Plugins can add filters without requiring any manual intervention by the 
developer, this will make them more powerful
- Filters can be removed thread-safe at runtime
- Low-level request processing is really simple and requests or responses can 
be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
- the filter class can not be invalid (<filter-class> in web.xml) since it's 
checked by the compiler
- Eventually migration from pre-wicket application might be easier

Please check the patch to get the whole idea.

Votes and comments are greatly appreciated :-)


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to