users@jersey.java.net

Re: [Jersey] Fighting with Regex

From: Daniel Manzke <daniel.manzke_at_googlemail.com>
Date: Tue, 23 Dec 2008 17:19:37 +0100

Hi Marc,
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.
Nether the less now the GET method with the shorter path doesn't work
anymore. ;)

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?!

Any idea? If your are interested I could send you a whole copy of the webdav
project.


Daniel

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