On 29/08/12 23:35, Sergey Beryozkin wrote:
> On 29/08/12 14:15, Marek Potociar wrote:
>>
>> On Aug 28, 2012, at 8:40 PM, Bill Burke <bburke_at_redhat.com
>> <mailto:bburke_at_redhat.com>> wrote:
>>
>>>
>>>
>>> On 8/28/2012 12:43 PM, Marek Potociar wrote:
>>>>
>>>> In Jersey users typically use it to provision (fully-initialized and
>>>> properly scoped) sub-resource instances
>>>
>>> I just not certain this is a job for JAX-RS.
>>>
>>>> , regardless of what container
>>>> manages each particular instance, using the
>>>> ResourceContext.getResource(...) method. Another problem the users are
>>>> facing is that in many cases if a user wants to support more complex
>>>> URI
>>>> spaces, it would make a lot of sense to leverage the JAX-RS matching
>>>> engine to internally "find" a proper resource instance or information
>>>> about it. For those cases the ResourceContext contains the matchXxx()
>>>> methods that expose the matching engine to the end user.
>>>>
>>>
>>> I've had the case that we implemeted where users want to do something
>>> like a Servlet.forward(), but I don't think this is the same thing.
>>> Can you give some examples of each match method? I'm just not
>>> understanding how it would be used.
>>
>> I'll borrow the example from a recent post on our users forum:
>>
>> Let's say you have a bookstore application that let you access books
>> (book resources) via various URI schemes, e.g.:
>>
>> /bookstore/books/{bid}
>> /bookstore/sections/{section}/books/{sbid}
>> /bookstore/authors/{author}/books/{abid}
>> ...
>>
>> Ideally, you want to have just a single BooksResource that handles all
>> these URIs. So from sub-resource locators in your SectionsResource and
>> AuthorsResource you could use the ResourceContext.matchXxx() methods to
>> "find" the (properly initialized) instance of BooksResource without
>> having to know too much about it. All you need to know is the main entry
>> point to all books and the book ID. E.g.:
>>
>> @Path("books/{id}")
>> public class BooksResource {
>> ...
>> BooksResource getBook() { ... }
>> }
>>
>>
>> @Path("authors")
>> public class AuthorsResource {
>> ...
>> @Path("{author}/books/{abid}")
>> BooksResource getBook(@Context ResourceContext rc, ...) {
>> String bookId = ... ; // get the book UID
>> return
>> rc.matchResource(UriBuilder.fromResource(BooksResource.class).pathParam("id",
>>
>> bookId).build());
>> }
>> }
>>
>> Obviously, you can use those methods to conveniently support URI graphs
>> - from books resource you could easily navigate to authors or sections
>> etc. Other, more advanced scenarios are possible too. Among the main
>> advantages is that you don't need to know too much about the ere
>> implementation details and initialization of those other resource and
>> that you can avoid internal redirects.
>
> I do not see much difference between JAX-RS runtime finding the matching
> resource without having any knowledge of the impl details and this
> example. In fact this example is not JAX-RS - why don't do a servlet
> based cosing instead
Apologies for a typo, I meant 'coding'
>
> Sergey
>