On Dec 23, 2008, at 11:19 AM, Daniel Manzke wrote:
>
> the methods are all in one class. But it seems that jersey is
> ignoring the methods "completely", because after I commented out the
> GET method the other one started working.
Hmm, that is strange. I could see the problem I suggested occurring
with sub-resource locators or with multiple root resource classes but
it looks like all your Java methods have HTTP method annotations. I
can't see how commenting out a @GET method will make your @PROPFIND
method start working.
I would check the value of the @HttpMethod annotation on each of your
WebDAV method annotations, maybe you have a cut-and-paste-o that has
@PROPFIND as a pseudonym for @GET ?
>
> Nether the less now the GET method with the shorter path doesn't
> work anymore. ;)
>
Do you need to adjust the regex for the remaining get to be .+ instead
of the default which will only match a single path segment ?
> In all the discussion with Stefan (Tilkov) and some other REST guys,
> they told me that the HTTP is the interface for my resources. But in
> this case it seems that the interface is ignored. ;) Is there a way
> to force jersey to search first for the methods and than the right
> resource path?!
>
No, AFAIK, Jersey follows the JAX-RS spec and first identifies the
resource by matching the path and then looks for a method to call. I
don't think that is counter to HTTP being the interface for your
resources but it does looks like you might have stumbled on a bug.
Marc.
>
> 2008/12/23 Marc Hadley <Marc.Hadley_at_sun.com>
> 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.
>
>
>
> ---------------------------------------------------------------------
> 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
> <
> FileSystem
> .java
> >---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.