[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling
[
https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-3219:
---
Attachment: filter-extension.patch
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.
[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling
[
https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-3219:
---
Affects Version/s: 1.5-M3
Fix Version/s: (was: 1.5-M4)
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
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.
[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling
[
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
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 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
[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling
[
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
[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling
[
https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-3219:
---
Attachment: (was: filter-extension.patch)
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
[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.
[jira] Updated: (WICKET-3219) programmatical addition or removal of filters prior to wicket filter request handling
[
https://issues.apache.org/jira/browse/WICKET-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ertl updated WICKET-3219:
---
Attachment: interceptors.patch
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: 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 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.
