Hey Marc,
I thought before trying the JBoss version, just give Jersey another try. And
it looks really good. Your description how to use a sub resource really
helped me out. This is really nice. I can use all features and let Jersey
parse the URL and create the Resources.
I think when we are finished with the webdav implementation for the jersey
stack, this will be a really good example how to use jersey and/or webdav
with sub resources.I'm happy when the time is come and we can contribute the
code.
I wish you all nice christmas. Another thanks for your help!
@Marc: If you're ever in Berlin, ask me for a beer. ;)
2008/12/23 Daniel Manzke <daniel.manzke_at_googlemail.com>
> 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
>
--
Mit freundlichen Grüßen
Daniel Manzke