On Dec 23, 2008, at 10:52 AM, Daniel Manzke wrote:
> you are my lonely hero. ;)
>
:-D
> The hint with the multiple declared folders helped.
>
>
> But...
> @PROPFIND
> @Path("/filesystem/{folder:.+}")
> public javax.ws.rs.core.Response propfind(..)
>
> was overriden by...
> @GET
> @Produces("application/octet-stream")
> @Path("/filesystem/{folder}/{filename}")
> public InputStream get(..)
>
>
> I read in the chapter that you mentioned, that first the uri is
> parsed and then the method will be identified. So is it my fault or
> is it a bug? :)
>
I think your problem might be due to the way that methods (@GET,
@PROPFIND etc) aren't considered until the final stage of the matching
algorithm. If the two methods above are in different classes then its
possible that the propfind method is ignored because the algorithm has
already chosen the class containing the get method. IOW, the algorithm
first tries to find the class that best matches the path and only then
looks to see if the chosen class supports the request method.
Marc.
>
>
> 2008/12/23 Marc Hadley <Marc.Hadley_at_sun.com>
> On Dec 23, 2008, at 9:28 AM, Daniel Manzke wrote:
>
> I have some little fights with the regex and jersey. I followed the
> example and used "@Path("/filesystem/{folder:.+}"). In the hope that
> I would get all folders.
>
> /filesystem/folder1 - works
> /filesystem/folder1/folder2 - doesn't work
>
> With the help of wireshark I get a "Method not allowed" returned.
> Any ideas? Is Regex supported or experimental?
>
> Its supported. My guess is that the second path is matching another
> resource that doesn't support the method you are using. All matching
> resources are sorted according to the following keys (most to least
> significant):
>
> (i) Number of literal chars in the template (descending order)
> (ii) Number of template vars (descending order)
> (iii) Number of template vars with non-default regex (descending
> order)
>
> So, if you have @Path("/filesystem/{folder:.+}") and @Path("/
> filesystem/{folder1}/{folder2}") then the latter will be matched
> since it has more literal characters (the extra literal '/').
>
> You can find the full matching algorithm in section 3.7 of the JAX-
> RS spec:
>
> https://jsr311.dev.java.net/nonav/releases/1.0/spec/
> spec3.html#x3-340003.7
>
> Marc.
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
>
> --
> Mit freundlichen Grüßen
>
> Daniel Manzke
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.