[
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 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 :-)
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, 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 :-)
> 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 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.
