In addition to Jerome's very good feedback ... since Resource/ServerResource
should be ephemeral and lightweight, they can use Scala's Actor concurrency
model to safely talk to long-lived, heavier weight domain objects if
needed. I found this really elegant in practice, since Actors are so easy
to reason about. I found extending Restlet to have a bit more friction with
Scala because you need to use or at least be very aware of
synchronization-style concurrency. Something just looks mighty funny about
writing synchronized{} blocks in Scala.
One other comment -- I *think* extending ServerResource directly in Scala
presently has a few gotchas due to annotation differences between Java and
Scala; I haven't dug into these much yet as we're still extending the
original style Resource from Restlet 1.1 in production, but I remember some
test ports of Java ServerResources to Scala didn't do exactly what we
expected. I can dig up more detail on that if it matters to your evaluation
-- and it may not be true any more; we last checked around Restlet 2.0M3 and
many issues have been fixed since then.
- Rob
On Wed, Aug 26, 2009 at 4:34 PM, <[email protected]> wrote:
> I'm evaluating Restlet for my next project and would like clarification on
> some design desicions.
>
> ServerResource is the preferred way to expose resources in Restlet, but is
> there a penalty to creating a new instance for each request?
>
> We will be using Scala and most of the code will follow an
> immutable/functional style.
>
> What are the downsides of just extending the Restlet class for handling
> requests?
>
> Thanks
>
> ------------------------------------------------------
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2387717
>
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2388207
