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.