Hi Jerome,
After some mulling over of this you convinced me that a per-request life
cycle is the right thing to concentrate on. EE focused developers may
find it a bit odd because of servlets and session beans but i think it
makes it easier for developers.
I believe we can afford a more complex algorithm if it is possible to
scale out the application according to the RESTful style.
However, i do think some way to allow a resource to be singleton could
still be useful for specialized/optimal cases as the performance gains
can potentially be substantial. But i do not think this should be the
primiary case we concentrate on.
Paul.
Jerome Louvel wrote:
> Paul,
>
>> Were you also proposing the status should be obtained via a
>> method as well?
>
> Yes, but the status is related to the Resource POJO, not to the
> Representation POJO. Order of calls could matter for resources as they have
> life cycles.
>
>>> Our
>>> experience with the Restlet API led us to make the Resource
>> class stateful.
>>> Stateful in the sense that the instances are not shared
>> between calls (they
>>> may eventually be pooled). This is different from the rest
>> of our upstream
>>> handlers which are generally stateless (all the changing
>> state is local to
>>> the executing thread).
>>>
>> IIRC Marc and I referred to that in previous emails as being
>> per-request
>> life-cycle.
>
> Ok, let's reuse your terminology. To me "per-request" makes sense as our
> main resource life-cycle.
>
>> Right. This is a key decision the EG needs to make as it impacts the
>> design of other things.
>>
>> One very useful thing you can do with per-application life-cycle
>> (singleton or like servlet) is the caching resource
>> instances, and hence
>> state.
>
> Reusing resource instances across requests might be interesting from an
> optimization point of view but I'm not sure if the drawback in term of
> design simplicity of Resources is worth it.
>
> In the Restlet API we considered this extensively and finally decided that
> the performance gain (literally one instantiation as the supporting domain
> objects can be cached/reused) wasn't worth the pain.
>
> But, people are always free to implement resource pools/synchronized
> singletons or just rely on a normal Restlets (or Servlets to maintain the
> comparison).
>
>> This is used to great effect by Hudson [1], a RESTful
>> extensible
>> continuous integration Web application. We have used Hudson as a real
>> world use-case.
>
> Nice use case indeed.
>
>> We designed the API such that you define an object model of
>> relationships between resources based on the URI hierarchy. It is
>> possible for the application to choose whether to use
>> per-application or
>> per-request when moving through the object model as described
>> by the URI
>> path, which is consumed based on the URI templates. The closest
>> documentation i have to explain this is what Hudson uses,
>> called stapler
>> [2].
>>
>> It creates a very flexible but intuitive way of building an
>> extensible
>> web application, for example see the section on stapler
>> polymorphism [3].
>>
>> To get this more clearly across i think a demo would be best.
>
> Sure, it that can bring some light on this design point. Concerning the
> Restlet, I can point to an example showing the integration between Restlet
> Resources and domaing objects (a simple bookmark management application):
> http://restlet.tigris.org/source/browse/restlet/trunk/modules/org.restlet.ex
> ample/src/org/restlet/example/book/rest/ch7/UserResource.java?rev=1727&view=
> markup
>
> Best regards,
> Jerome
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109