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/
----------------------------------------------------------------
