You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Peter Ertl (JIRA)" <ji...@apache.org> on 2010/12/08 21:17:02 UTC
[jira] Resolved: (WICKET-3219) programmatical add or remove of
request filters to intercept requests prior to wicket
[ https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Ertl resolved WICKET-3219.
--------------------------------
Resolution: Won't Fix
> 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
> Fix For: 1.5.1
>
> 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();
> MyCustomFilter filter = new MyCustomFilter();
> 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 MyCustomFilter#doFilter() ->
> MyCustomFilter processing ->
> chain.doFilter(request,response) ->
> invoke wicket request processing ->
> end MyCustomFilter#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 can add additional filters to an application by extending from a BaseWebApplication (especially useful if want to support a base library for a number of sub-projects in your company)
> - You don't have to touch web.xml ever
> - the filter class can not be invalid (<filter-class> in web.xml) since it's type-safe and checked by the compiler instead of read from xml
> - You can use the large stock of existing servlet filters from other frameworks without modification (e.g. from spring framework)
> - Migration from non-wicket applications might be easier
> - You can specify mock filter configs or alternate filter configs using (WicketFilter#addInterceptor(filter, alternateFilterConfig)) and have programmatic control over the filter configuration, again not needing to touch web.xml
> - 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 to the application without requiring any manual intervention by the developer, this will make them more powerful
> - Filters can be removed thread-safely at runtime
> - Low-level request processing is really simple and requests or responses can be wrapped using HttpServletRequestWrapper and HttpServletResponseWrapper
> IMHO there are plenty of useful use cases.
> 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.