OK, so here is how I propose to implement the
ServletDispatchingFilter's mapping:
1) A basic mapping must adhere to the servlet spec exactly (i.e.,
/test* would require the url passed from the browser to literally be
'/test*') servletPath and pathInfo are split according to the spec.
2) A mapping prepended with 'regex:' is treated as a regular
expression but the servletPath and pathInfo are more complex:
a) The servletPath will always include everything that is within
the mapping url with the following exception
b) If the regex ends with a '/' it is included, along with any
other characters to the end of the request url as part of the pathInfo
c) No groupings (parentheses) are allowed unless escaped to be
treated as literals
I'd be happy to throw in an ant mapping ability as well, but I'm not
as familiar with the subtleties of it beyond the '**' vs. '*'
characters to suggest a sensible division between the servletPath and
pathInfo.
Thoughts?
Tom
> -----Original Message-----
> From: [email protected] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 10, 2008 5:50 AM
> To: [email protected]
> Subject: [magnolia-dev] Fwd: [magnolia-user] problem with
> Servlet filter
>
> Hey Tom, let's take this here.
> I'll to reply soon, if i get a chance.. but basically, we
> realized some time ago that using SimpleUrlPattern in
> ServletDispatchingFilter wasn't such a bright idea if we
> wanted to respect the spec completely...
>
> -g
>
> Begin forwarded message:
> > From: "Tom Jensen" <[EMAIL PROTECTED]>
> > Date: April 9, 2008 9:18:34 PM GMT+02:00
> > To: <[EMAIL PROTECTED]>
> > Subject: Re: [magnolia-user] problem with Servlet filter
> > Reply-To: <[EMAIL PROTECTED]>
> >
> > Hey Greg,
> >
> > I have been messing around with this code and the cleanest
> solution in
> > my mind would be to make better use of regexps to get the
> servletPath
> > and the pathInfo. There are some problems that I came across in
> > trying to work out a solution, two related to the
> > ServletDispatchingFilter and two related to the
> SimpleUrlPattern and
> > its related tests. One of the issues on SimpleUrlPattern
> has nothing
> > to do with fixing the ServletDispatchingFilter but would be
> helpful to
> > nail down.
> >
> > First, the issues related to SimpleUrlPattern:
> >
> > 1) I don't understand what the opening and closing
> parentheses are for
> > on lines 105, 107, 112, and 114 If I take them out the tests still
> > run successfully. Is there a test that should be written to verify
> > those are in there or can they be removed?
> > 2) The tests imply an ant type of syntax for directory
> matching (using
> > the /**/ chars) However, the following test fails:
> >
> > assertFalse(new
> > SimpleUrlPattern("/*/url.html").match("/test/dir/dir/url.html"));
> >
> > Should the tests with the '**' in them be removed as they imply an
> > incorrect functionality? My understanding of the double asterisk
> > functionality is that it will match multiple directories,
> but then a
> > single asterisk will only allow a single directory to be matched.
> >
> > The issues with ServletDispatchingFilter:
> >
> > 1) The parentheses I mentioned above being put into the
> regexp string
> > would make it difficult to use regular expressions to consistently
> > extract the servletPath and pathInfo. I understand that using the
> > SimpleUrlPattern.getEncodedString() method helps to remove invalid
> > characters from the url, but I'm still not clear on the parentheses.
> > 2) One of the tests,
> testShouldNotBypassWhenPathMappingMatches() gives
> > an invalid mapping according to the servlet spec. How would the
> > servletPath and pathInfo variables be expected to be
> divided in that
> > situation? If there are more complex regexps embedded within the
> > mapping I can see how it would be logical to take the
> resulting string
> > and parse it up, but when it is open ended like that without a '/'
> > where is the dividing line?
> >
> > Thanks,
> >
> > Tom
> >
> >
> >> -----Original Message-----
> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> >> Sent: Wednesday, April 09, 2008 5:04 AM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: [magnolia-user] problem with Servlet filter
> >>
> >> Hi Tom,
> >>
> >> You're completely right - and this is probably a
> misinterpretation of
> >> the spec from our part at some point.
> >>
> >> As far as I can see, there's no critical usage of this
> method in the
> >> Magnolia code base, so it should cause any issue fixing
> it. If you're
> >> willing to provide a patch, that'd be awesome. You might
> want to have
> >> a look at ServletDispatchingFilterTest and fix/add tests in there
> >> (particularly, there's a nasty one which is commented out
> because we
> >> couldn't get it to pass - or let's be honest: we couldn't
> be bothered
> >> fixing the code be compliant with this part of the spec)
> >>
> >> If you just patched the test case, i'd be willing to help
> and get the
> >> green bar for fixing the real code ;)
> >>
> >> Cheers,
> >>
> >> -greg
> >>
> >> On Apr 9, 2008, at 00:20 , Tom Jensen wrote:
> >>> I'm trying to hookup DWR 1.1.4 within Magnolia 3.5.4. I have it
> >>> mapped in the /config/server/filters/servlet section
> >> configured to use
> >>> the mapping /dwr/*. The problem is that DWR depends on the
> >>> request.getServletPath() to return back the value as
> >> specified in the
> >>> servlet spec (at least 2.2-2.4, I didn't check other
> >> versions of the
> >>> spec). In the above mapping it should return back /dwr, but in
> >>> Magnolia it returns back /dwr/interface/MappingName.js
> or whatever
> >>> the url is requested under /dwr/.
> >>>
> >>> The question I have is: is this a bug or does Magnolia not
> >> intend to
> >>> fully support the servlet spec in that regard? I really like the
> >>> configuration capabilities of Magnolia for servlets but if
> >> it doesn't
> >>> fully support the spec I don't feel comfortable using it
> to deploy
> >>> servlets.
> >>>
> >>> Thanks,
> >>>
> >>> Tom
> >>>
> >>> ----------------------------------------------------------------
> >>> for list details see
> >>> http://documentation.magnolia.info/
> >>> ----------------------------------------------------------------
> >>
> >>
> >> ----------------------------------------------------------------
> >> for list details see
> >> http://documentation.magnolia.info/
> >> ----------------------------------------------------------------
> >>
> >
> > ----------------------------------------------------------------
> > for list details see
> > http://documentation.magnolia.info/
> > ----------------------------------------------------------------
>
>
> ----------------------------------------------------------------
> for list details see
> http://documentation.magnolia.info/
> ----------------------------------------------------------------
>
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/
----------------------------------------------------------------
