Re: Scalatra praise (and thoughts)
Ivan Porto Carerro
Hi,Just started looking at Scalatra this weekend, and it's just what I've been looking for. Traditionally I've been an Apache Wicket user, which is a great framework for stateful webapps, however I was looking for something more RESTful to enable me to do a more RIA type app with UI logic in the browser calling JSON backend services (via Scalatra).One thought/gotcha I ran into though:As I am effectively extending a ScalatraServlet, it made me slightly vary of what is thread safe and what is not of the available variables when I define routes (instance variables/values in Servlets are not thread-safe).Maybe this will become clearer/more encapsulated in future releases as you separate the DSL from the servlet and filter as you explained in an InfoQ interview?At the moment, it is one of those things I worry will come and bite me due to the straight Servlet extension.Anyway, just thought I'd mention this, while at the same time sending some praise your way, it really looks promising!RegardsWille
--
Co-founder & Developer at Mojolly
Mojolly
Ross A. Baker
>> One thought/gotcha I ran into though:
>> As I am effectively extending a ScalatraServlet, it made me slightly vary
>> of what is thread safe and what is not of the available variables when I
>> define routes (instance variables/values in Servlets are not thread-safe).
This is a good point. Scalatra handles this by storing the request
and response, among other things, inside of a DynamicVariable.
DynamicVariable is built on Java's ThreadLocal, so each thread gets
its own bindings. Application developers still need to be careful
when creating their own instance variables in a servlet or filter.
For these, you may wish to consider a DynamicVariable or a def that
gets/sets to a request attribute.
--
Ross A. Baker
ba...@alumni.indiana.edu
Indianapolis, IN, USA
Ross A. Baker
> Don't have my IDE available to me right now, but are these values available
> in an accessible DynamicVariable with a specific name in the
> ScalatraServlet?
> Gives a little bit more confidence if you access them through a val/var you
> know is Thread safe. :)
> If it is not available, one way of giving a little more confidence would
> possibly be to expose this and recommend accessing thread-specific instance
> variables through this (strongly typed for the default ones, maybe a Map of
> some sort for user-defined).
> Just an idea off the top of my head, not sure it's the best or cleanest way.
You already have request-scoped and session-scoped maps via request
attributes. If either of these scopes is appropriate for your needs,
then you can define "variables" as this (disclaimer: untested, no
compiler handy):
def foo: Foo = request.getAttribute("foo").asInstanceOf[Foo]
def foo_=(foo: Foo) { request.setAttribute("foo", foo) }
In the latest snapshot, request and session implicitly implement
scala.collection.mutable.Map, further simplifying things:
def foo: Foo = request("foo")
def foo_=(foo: Foo) { request("foo") = foo }
Ravi Mendis
abstracts Servlets):
How difficult would it be to write Netty as a mover for Scalatra
instead of Servlets?
http://www.jboss.org/netty
FYI: I recently ran apachebench on several Scala web servers
including:
1. WebObjects (with a Netty adaptor),
2. Play (with its Netty module)
3. Lift
4. Scalatra
5. Netty + Scala xml
The fastest was the latter. But Scalatra came a very close second.
I was very impressed!
>
> *Ivan Porto Carrero*
> Mojolly
> We tweet at @mojolly <http://twitter.com/mojolly>,
> @casualjim<http://twitter.com/casualjim>
>
> Phone: +44.7513.233.465
Ross A. Baker
> I have a question (which might help with defining an API that
> abstracts Servlets):
>
> How difficult would it be to write Netty as a mover for Scalatra
> instead of Servlets?
> http://www.jboss.org/netty
The layer that Ivan mentions below is called SSGI, which you can
follow at http://github.com/scalatra/ssgi. It would provide the
necessary abstraction to support a Netty backend in Scalatra. It's a
thought experiment into what a statically-typed Rack/*SGI would look
like, with the hope that Scalatra can be retrofitted to this interface
with minimal breaking changes. It's still very experimental, and we
welcome all comments.
> FYI: I recently ran apachebench on several Scala web servers
> including:
> 1. WebObjects (with a Netty adaptor),
> 2. Play (with its Netty module)
> 3. Lift
> 4. Scalatra
> 5. Netty + Scala xml
>
> The fastest was the latter. But Scalatra came a very close second.
> I was very impressed!
Excellent. We've heard good things about the performance from others as well.
--