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
Sergey
>
> Marek
>
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com