Marc we getting closer to the problem. ;)
There is no cut-and-paste error. I checked multiple times. (this time too :)
Why I need the regex:
Due the fact that we are trying to develop a webdav based solution on the
jersey stack and we need some examples, I decided to develop a
filesystem-based example.
Due the fact that I don't want a hard-coded filesystem structure I use the
regex. So I get the folder structure as one parameter.
Where does jersey decides which method it should take? Maybe I can debug on
my machine.
Daniel
2008/12/23 Marc Hadley <Marc.Hadley_at_sun.com>
> 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.
>
>
>
> ---------------------------------------------------------------------
> 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