Hi Marc,
I know that Paul is on vacation. That's why I asked the list. ;) I will give
the JBoss Implementation a try to become a feeling, how Regex should work.
(maybe it does the same ;))
I will also try your suggestion, because I saw something like this, but
couldn't understand it. (without description) ;)
Thanks Marc! I wish you and your family a nice christmas. I will keep you
informed about my results. ;)
2008/12/23 Marc Hadley <Marc.Hadley_at_sun.com>
> On Dec 23, 2008, at 1:34 PM, Daniel Manzke wrote:
>
>>
>> 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.
>>
>
> Sorry, I'm not familiar with that part of the code and Paul is on vacation
> until the new year.
>
>
> 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)
>>
>> Yes, if you omit the method but include a path then the returned object
> is treated as a dynamic resource and the rest of the path is then used to
> match to methods of that resource class. E.g.
>
> @Path("filesystem")
> public class DirectoryResource {
>
> File file;
>
> public DirectoryResource(File f) {
> file = f;
> }
>
> public DirectoryResource() {
> f = new File("some/base/dir");
> }
>
> @Path("{entry}")
> Object findEntry(@PathParam("entry") String entry) {
> File newFile = new File(file, entry);
> if (newFile.isDirectory())
> return new DirectoryResource(newFile);
> else
> return new FileResource(newFile);
> }
>
> @GET
> List<File> getContents() {
> ...
> }
>
> }
>
> public class FileResource {
>
> File file;
>
> public DirectoryResource(File f) {
> file = f;
> }
>
>
> @GET
> File get() {
> ...
> }
>
> If you do a GET /filesystem/dir then Jersey will invoke
> DirectoryResource.findEntry("dir"). Assuming "dir" is indeed a directory the
> method returns a new instance of DirectoryResource and Jersey, having run
> out of path will then call the DirectoryResource.getContents method to
> obtain a representation. If you do a GET /filesystem/dir1/dir2 then the
> findEntry method gets called recursively for both "dir1" and "dir2" and then
> the getContents method is called.
>
> HTH,
> Marc.
>
>
>
>
>
>>
>> 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
>> 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
>>
>
> ---
> 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