[ https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Ertl updated WICKET-3219: ------------------------------- Description: [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 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 :-) was: [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 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 :-) > 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 > Affects Versions: 1.5-M3 > Reporter: Peter Ertl > Assignee: Peter Ertl > 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, 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 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.