Hey Marc,
it would be nice if you could give me a hint which class I should debug.
Then I would do it, to figure out if it is a bug or "as designed". If it as
designed, than I have to search for another solution. Maybe it could get
solved by sub resources? Is it possible to define some kind of a resource
with sub resources where for each group (folder) an resource is created?!
(something like a cycle/recursion)
Daniel
2008/12/23 Daniel Manzke <daniel.manzke_at_googlemail.com>
> But it is not the same method. GET != PROPFIND. Hmmmm... then I have really
> a problem.
> Any other ideas?
>
> 2008/12/23 Sergey Beryozkin <sergey.beryozkin_at_progress.com>
>
> Jersey is correct here, number of capturing groups is 2 in a second
>> method so it takes precedence
>>
>> Cheers, Sergey
>>
>> ----- Original Message -----
>> *From:* Daniel Manzke <daniel.manzke_at_googlemail.com>
>> *To:* users_at_jersey.dev.java.net
>> *Sent:* Tuesday, December 23, 2008 4:19 PM
>> *Subject:* Re: [Jersey] Fighting with Regex
>>
>> 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
>>
>> ------------------------------
>>
>> ---------------------------------------------------------------------
>> 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
>
--
Mit freundlichen Grüßen
Daniel Manzke