Aditya Gore wrote:
> Hi Paul,
>
> This seems to be at odds with section 2.2 of the draft 311 spec ("A
> new resource class instance is created for each request to that
> resource"). I tried it however and it seems to work.
>
Well spotted :-) you are right.
The plan is to make per-request the default, to support per-application
singleton via an annotation, and allow a developer to plug in their own
life-cycle/injection strategy. Marc is working on this, see
"branch/jersey-resourcefactory".
When we merge that branch with the trunk we will send an announcement,
including on what breaks and how to transition existing code.
Paul.
> regards,
> :aditya
>
>
>> You need a singleton root resource that is responsible for controlling
>> the life-cycle of the sub-resources and so on down the hierarchy.
>>
>> @UriTemplate("/")
>> class Root {
>>
>> AddressBooks r;
>>
>> Root() {
>> r = ...
>> }
>>
>> @UriTemplate("books")
>> AddressBooks getBooks() {
>> return r;
>> }
>> }
>>
>> class AddressBooks {
>> AddressBook[] r;
>>
>> AddressBook() {
>> r = ...
>> }
>>
>> @UriTemplate("{book}")
>> AddressBook getBook(@UriParam("book") int book) {
>> return r[i];
>> }
>> }
>>
>> So when the URI path '/books/1' is processed an instance of AddressBook
>> will be returned to the Jersey runtime and an HTTP request will be
>> dispatched to that instance.
>>
>> Thus it is possible to say get information from a file system or
>> database and cache the resources in memory. Of course one needs to
>> manage states changes correctly...
>>
>> Another way is for the Root resource to instantiate the address book
>> info object and pass this as a construction parameter to the sub-resources.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109