You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jean-Baptiste Quenot <jb...@apache.org> on 2007/01/27 11:22:25 UTC
Getting rid of filterPath?
Hi all,
I followed the latest refactoring on the WicketFilter and
WebRequestCodingStrategy with interest because on our application
we have problems setting in production with a root filter mapping
and non-root context path, see WICKET-205.
I made a few tests on wicket-examples, and it seems that the
relative URLs fix the problem. Thanks for that!
However there's still one thing that bugs me: this cryptic
filterPath init parameter.
It's cryptic because:
* you repeat yourself and often forget to keep in sync with filter
mapping
* it's not exactly the same as filter mapping (slashes removed,
wildcard removed)
* it is not properly documented
* it doesn't make sense
The last point is especially true now that you did a great work
working around the nightmare of rewriting URIs by using relative
ones: why don't you go further and apply the relative URL theory
one step forward to get rid of filterPath?
For example when using a filter-mapping such as /abc/* and
accessing /abc/somePage, you will notice that the generated URLs
for a bookmarkable page look like: ../abc/anotherPage
Why not generate URLs like "./anotherPage" directly? This would
allow to say goodbye to filterPath maybe.
I tracked down using the debugger every call to
WicketFilter.getRootPath() and here are the places where it gets
called:
* WicketFilter.isWicketRequest() do we really need to check that?
Under which conditions does this method returns false? The code
for this method is really ugly and completely lacks Javadoc and
comments. I know it's not easy but I'm sure we can do something
much more simple and much less error-prone.
* WicketFilter.getLastModified() I'm sure we can workaround using
getRootPath() for that
* WebRequestCodingStrategy.decode() Why do we rely on
getRootPath() to compute the request path, whereas it's
available through the Filter API?
* WebRequestCodingStrategy.encode() when issuing a redirect: I
guess it is the only one where it's a bit more tricky: but I'm
sure we can arrange something as well
WDYT?
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Getting rid of filterPath?
Posted by Johan Compagner <jc...@gmail.com>.
>
> > maybe we should just parse web.xml and rip out the mapping. we already
> have
> > an xml parser :P
>
> Yeah, I've just thought about doing that, and it certainly works,
> although it's a bit ugly. However, I've thought a bit harder, and I'm
> not convinced it's actually necessary. I think we can resolve it from
> the inbound request. I'll post more on this later, when I've played with
> it a bit more.
Please post it how you do that.
I haven't found a method on the Servlet spec that gives you that back.
And if the (first) request is a mount how do you know it then what the
filter path it and what the mount is?
johan
Re: Getting rid of filterPath?
Posted by Al Maw <wi...@almaw.com>.
Igor Vaynberg wrote:
> On 1/27/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
>> * you repeat yourself and often forget to keep in sync with filter
>> mapping
>
> maybe we should just parse web.xml and rip out the mapping. we already have
> an xml parser :P
Yeah, I've just thought about doing that, and it certainly works,
although it's a bit ugly. However, I've thought a bit harder, and I'm
not convinced it's actually necessary. I think we can resolve it from
the inbound request. I'll post more on this later, when I've played with
it a bit more.
I'll be putting various other fixes in today for all this.
Al
Re: Getting rid of filterPath?
Posted by Igor Vaynberg <ig...@gmail.com>.
On 1/27/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
>
>
> * you repeat yourself and often forget to keep in sync with filter
> mapping
maybe we should just parse web.xml and rip out the mapping. we already have
an xml parser :P
* it's not exactly the same as filter mapping (slashes removed,
> wildcard removed)
it doesnt mean the exact same thing :)
* it is not properly documented
true dat, but it hasnt seen its release yet. im sure before releasing we
will add the necessary javadoc/wiki. you are using a pre-beta/beta so you
cant really complain about documentation yet :)
* it doesn't make sense
this i dont know about :)
> For example when using a filter-mapping such as /abc/* and
> accessing /abc/somePage, you will notice that the generated URLs
> for a bookmarkable page look like: ../abc/anotherPage
>
> Why not generate URLs like "./anotherPage" directly? This would
> allow to say goodbye to filterPath maybe.
lets take a case where i have two different wicket apps (user and admin)
deployed under the same context.
i take my user app filter and map it to /user/*, my admin filter to /admin/*
in the user app i have a status page mounted under /status
a request comes in for /context/user/status
the userfilter tries to process it, sees a url /user/status - checks for any
mounts for /user/status, falls through
404
now if my user filter has a filterpath of "/user" the processing looks
different
request comes in for /context/user/status
filter sees /user/status, filter strips its filterpath off the url ->
/status
looks for mounts for /status
serves the status page
on irc you mentioned to use getPathInfo() to get the url minus the filter
path, but the javadoc for that reads...
* Returns any extra path information associated with
* the URL the client sent when it made this request.
* The extra path information follows the servlet path
* but precedes the query string.
* This method returns <code>null</code> if there
* was no extra path information.
the difference between a filter and a servlet is that a filter is an
interceptor, but a servlet is a handler. once the url hits a servlet thats
it, it is owned by that servlet. so for a servlet the spec provides
pathinfo, too bad it doesnt do the same for filters.
-igor
Re: Getting rid of filterPath?
Posted by Eelco Hillenius <ee...@gmail.com>.
On 1/27/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
> unacceptable how? what if you could configure the name under which wicket
> stores its resources in application settings? default could be wicket but
> you
> could change it.
We've had a lot of complaints of people wanting to map their Wicket
apps to /* (the root), but couldn't really do that in older versions/
before the filter. Introducing a separate namespace would get those
same complaints back again.
Eelco
Re: Getting rid of filterPath?
Posted by Jonathan Locke <jo...@gmail.com>.
unacceptable how? what if you could configure the name under which wicket
stores its resources in application settings? default could be wicket but
you
could change it.
Eelco Hillenius wrote:
>
> On 1/27/07, Jonathan Locke <jo...@gmail.com> wrote:
>>
>>
>> a long time ago, i was wondering if we shouldn't put all wicket framework
>> resources under wicket. so you'd have <app>/wicket/* for framework
>> reserved
>> stuff. besides being a nice orgnization, this would allow us to mount
>> stuff
>> on the root without so much potential for conflicts.
>
> That would be easier from the perspective of developers maybe, but I'm
> sure unacceptable for most production systems.
>
> I'm think we're getting close; if we can find a way to get rid of that
> parameter, I think we're done and don't have to worry about it again
> ever.
>
> Eelco
>
>
--
View this message in context: http://www.nabble.com/Getting-rid-of-filterPath--tf3127196.html#a8668372
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Getting rid of filterPath?
Posted by Eelco Hillenius <ee...@gmail.com>.
On 1/27/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
> a long time ago, i was wondering if we shouldn't put all wicket framework
> resources under wicket. so you'd have <app>/wicket/* for framework reserved
> stuff. besides being a nice orgnization, this would allow us to mount stuff
> on the root without so much potential for conflicts.
That would be easier from the perspective of developers maybe, but I'm
sure unacceptable for most production systems.
I'm think we're getting close; if we can find a way to get rid of that
parameter, I think we're done and don't have to worry about it again
ever.
Eelco
Re: Getting rid of filterPath?
Posted by Jonathan Locke <jo...@gmail.com>.
a long time ago, i was wondering if we shouldn't put all wicket framework
resources under wicket. so you'd have <app>/wicket/* for framework reserved
stuff. besides being a nice orgnization, this would allow us to mount stuff
on the root without so much potential for conflicts.
Johan Compagner wrote:
>
>>
>> What I don't understand is why we need to know the filterPath to
>> decide whether Wicket can serve the requested URL or not. If
>> WicketFilter is called, then you know for sure that you are within
>> the configured filter mapping, no need to double check with
>> filterPath.
>
>
> Not if you don't use any filter path!
> Then everything falls through
> I agree that when you use a filter path then pretty much everything that
> goes
> through is a wicket request. (doesn't have to be ofcourse but it 99% i
> guess
> it is the case)
>
> But we are using a filter because then you can use it just for everything
> and don't have
> that context path. Then it is ofcourse not the case that everything is a
> wicket request.
>
>
>> What we could do there is making: /resources/ a bit different so
>> > that it really says wicket or something so something like
>> > /wcktresources/
>>
>> Or maybe using a query string like other request targets:
>> ?wicket:resource=something
>
>
> yuk.
> no.. that would be horrible.
>
>> > * WebRequestCodingStrategy.decode() Why do we rely on
>> > > getRootPath() to compute the request path, whereas it's
>> > > available through the Filter API?
>> >
>> > What method do you think you can call then?
>>
>> Maybe we don't need to know the request path at all. Why would we
>> care?
>
>
> thats because we need to construct the right rootpath.
>
>
> I'd love to hear AlMaw's opinion about all that.
>
>
>
> yes i also haven't looked at the code yet so need to dig into it a bit
> more.
>
> johan
>
>
--
View this message in context: http://www.nabble.com/Getting-rid-of-filterPath--tf3127196.html#a8667394
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Getting rid of filterPath?
Posted by Johan Compagner <jc...@gmail.com>.
>
> What I don't understand is why we need to know the filterPath to
> decide whether Wicket can serve the requested URL or not. If
> WicketFilter is called, then you know for sure that you are within
> the configured filter mapping, no need to double check with
> filterPath.
Not if you don't use any filter path!
Then everything falls through
I agree that when you use a filter path then pretty much everything that
goes
through is a wicket request. (doesn't have to be ofcourse but it 99% i guess
it is the case)
But we are using a filter because then you can use it just for everything
and don't have
that context path. Then it is ofcourse not the case that everything is a
wicket request.
> What we could do there is making: /resources/ a bit different so
> > that it really says wicket or something so something like
> > /wcktresources/
>
> Or maybe using a query string like other request targets:
> ?wicket:resource=something
yuk.
no.. that would be horrible.
> > * WebRequestCodingStrategy.decode() Why do we rely on
> > > getRootPath() to compute the request path, whereas it's
> > > available through the Filter API?
> >
> > What method do you think you can call then?
>
> Maybe we don't need to know the request path at all. Why would we
> care?
thats because we need to construct the right rootpath.
I'd love to hear AlMaw's opinion about all that.
yes i also haven't looked at the code yet so need to dig into it a bit more.
johan
Re: Getting rid of filterPath?
Posted by Eelco Hillenius <ee...@gmail.com>.
> Or maybe using a query string like other request targets:
> ?wicket:resource=something
That would be going back to Wicket 0.something. We introduced using
the path - after much debate and testing - so that we would have
shared resources that would still potentially be cached by all
browsers.
Eelco
Re: Getting rid of filterPath?
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Johan Compagner:
> > * WicketFilter.isWicketRequest() do we really need to check
> > that? Under which conditions does this method returns false?
> > The code for this method is really ugly and completely lacks
> > Javadoc and comments. I know it's not easy but I'm sure we
> > can do something much more simple and much less error-prone.
>
> Yes we need to check. We need to know if the filter can handle
> this request or not. Else it needs to fall through, thats the
> whole point of using a filter.
What I don't understand is why we need to know the filterPath to
decide whether Wicket can serve the requested URL or not. If
WicketFilter is called, then you know for sure that you are within
the configured filter mapping, no need to double check with
filterPath.
> What we could do there is making: /resources/ a bit different so
> that it really says wicket or something so something like
> /wcktresources/
Or maybe using a query string like other request targets:
?wicket:resource=something
> > * WebRequestCodingStrategy.decode() Why do we rely on
> > getRootPath() to compute the request path, whereas it's
> > available through the Filter API?
>
> What method do you think you can call then?
Maybe we don't need to know the request path at all. Why would we
care?
I'd love to hear AlMaw's opinion about all that.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Getting rid of filterPath?
Posted by Johan Compagner <jc...@gmail.com>.
I dont know where we now exactly stand with the relative paths.
So maybe it can be removed now but:
* WicketFilter.isWicketRequest() do we really need to check that?
> Under which conditions does this method returns false? The code
> for this method is really ugly and completely lacks Javadoc and
> comments. I know it's not easy but I'm sure we can do something
> much more simple and much less error-prone.
Yes we need to check. We need to know if the filter can handle this request
or not. Else it needs to fall through, thats the whole point of using a
filter.
* WicketFilter.getLastModified() I'm sure we can workaround using
> getRootPath() for that
huh? you checked what uses getRootPath() and you say that here
we can use the workaround using getRootPath()?
What we could do there is making: /resources/
a bit different so that it really says wicket or something so something like
/wcktresources/
Then we just can do a index of for that.
* WebRequestCodingStrategy.decode() Why do we rely on
> getRootPath() to compute the request path, whereas it's
> available through the Filter API?
What method do you think you can call then?
Eelco already did remove that filter path once and then everything broke
done.
Because you don't have the getContextPath() call in a wicket filter
as you have on a servlet. You can't get the filter mapping from a filter.
thats
impossible though the api. Thats why we need it
But as i said. Maybe we can now completely remove the rootpath or what ever
all together
now we use
johan