Re: [Wicket-develop] use filter instead of servlet for 2.0

[Riyad Kalla]

Good points Igor. Igor Vaynberg wrote: this is prob something we can optimize by splitting the path and creating some datastructure to hold the pieces (like a map of maps or something) lets say we mount A/B/C/D and A/B/E/F the request comes in for A/B/G we check if we have anything for A, we do, anything for B, we do, anything for G no, fallthrough i think most of the time requests will comein where not even the first part will match and so they will be eliminated immediately. -Igor On 3/9/06, Johan Compagner <[EMAIL PROTECTED]> wrote: if we don't prefix mountable pages then we have to check all urls if the map or not Maybe not a big problem but. johan On 3/9/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: another neat thing about the filter is that since it allows /* mapping easily the bookmarkable page mounts can live directly under context root. so http://foo.com/context/view can be a mounted page as opposed to http://foo.com/context/app/view. -Igor On 3/9/06, Riyad Kalla < [EMAIL PROTECTED]> wrote: Roger that, thanks Johan. Johan Compagner wrote: /resources is now under the wicket application so if you bind the servlet to /app/* then it is /app/resources If we are going to use a filter then we have to prefix it to /wicket/resources johan On 3/9/06, Riyad Kalla <[EMAIL PROTECTED]> wrote: Igor, What did you mean here: ------------ 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. ------------ What is the /resources or /wicket/resources path, are those going to be new reserved paths in 1.2 or something? (I tend to use /resources for my images, css, etc. so this made my ears perk up) -R Igor Vaynberg wrote: > 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 > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop