[ 
https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966273#action_12966273
 ] 

Juergen Donnerstag commented on WICKET-3219:
--------------------------------------------

That was my first idea as well. I reverted it because in my opinion we don't 
need it. WebApplication.newWebRequest(HttpServletRequest) is the place where 
you can do all that already. To register a "filter" simply replace 
newWebRequest with you own implementation. Wrap the servletrequest with your 
"filter", create a new WebRequest with that and your done. Have a look at the 
testcase.

> programmatical add or remove of request filters to intercept requests prior 
> to wicket
> -------------------------------------------------------------------------------------
>
>                 Key: WICKET-3219
>                 URL: https://issues.apache.org/jira/browse/WICKET-3219
>             Project: Wicket
>          Issue Type: New Feature
>    Affects Versions: 1.5-M3
>            Reporter: Peter Ertl
>            Assignee: Peter Ertl
>         Attachments: interceptors.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, implements javax.servlet.Filter
>     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 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 use the large stock of existing servlet filters from other 
> frameworks without modification (e.g. from spring framework)
> - 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