i just noticed that RIFE is implemented as a filter not a servlet. eelco and i tried to figure out what the advantage is, and what we came up with was that it is much easier to allow the servlet container to handle urls you are not interested in. we asked bevin, and he confirmed that this was indeed the reason why he chose to use a filter.

if we switch to a filter we can get rid of the part of wicket where we have to stream a static resource if the user used a /* mapping and wicket cannot handle the url.

in fact it should be pretty easy (and quick) to figure out if we want to handle the url or not:

if it starts with /resources ( soon to be /wicket/resources? ) or /?wicket:interface= then it is a wicket url, otherwise we just let it fall through and be handled by the container.

as far as i can tell a filter has the same lifecycle as a servlet so the change over should be pretty minimal.

the only area i can see being hurt a little is OSGI. i dont know how hard it is to deploy a filter instead of a servlet. maybe we might write a shell servlet that wraps the filter if that becomes an issue.



thoughts? ideas?

-Igor

Reply via email to