JsonSupport Trait Example

[cookup]

Does anyone have an example using the JsonSupport Trait? I have been
trying to implement a JSONP response and it doesn't seem like the
renderPipeline defined in the trait is run.

[cookup]

Update:(im working from the sbt prototype)

I created org.scalatra.liftjsonedit.JsonSupport and copied the exact code of JsonSupport and it worked. Previously it was telling me that I did not need to override jsonpCallbackNames, but when I added liftjsonedit.JsonSupport it did.

Besides importing org.scalatra.liftjson._  in MyScalatraSever.scala and and adding "org.scalatra" %% "scalatra-lift-json" % "2.0.4", in build.sbt under dependencies .. is there something else I should have done to use liftjson?

[Bill Barrington]

I ran into a similar issue the other day. Turns out that I was using both the LiftJsonRequestBody trait and the JsonSupport trait. If you declare JsonSupport BEFORE LiftJsonRequestBody, then the contentTypeInferrer override in JsonSupport never gets called. If you declare LiftJsonRequestBody ahead of JsonSupport, then it does.

IOW, this works:

class MyScalatraServlet extends ScalatraServlet with LiftJsonRequestBody with JsonSupport

this doesn't:

class MyScalatraServlet extends ScalatraServlet with JsonSupport with LiftJsonRequestBody

On Friday, June 1, 2012 2:00:40 PM UTC-4, cookup wrote:

[Ross A. Baker]

This is confusing for users, and at the very least needs to be
documented. I've opened an issue to make this right:
https://github.com/scalatra/scalatra/issues/195

--
Ross A. Baker
ba...@alumni.indiana.edu
Indianapolis, IN, USA

[Bill Barrington]

I'd also like to understand in detail the (Scala) language mechanism that allows this to occur. 

I'd like to know how to prevent it from a library designer's perspective and also how to avoid it as a library user.  

Any light that readers could shed on this would be appreciated.

Thanks,

Bill

[Ross A. Baker]

Two articles worth reading:

- http://www.artima.com/scalazine/articles/stackable_trait_pattern.html:
an example of why trait ordering is significant, and a use case for
that flexbility.

- http://jim-mcbeath.blogspot.com/2009/08/scala-class-linearization.html:
details of how the order is determined.

Now, as we look at the lift-json code, note that:
* JsonSupport overrides contentTypeInferrer.
* LiftJsonRequestBody extends ApiFormats, which overrides contentTypeInferrer

class Servlet1 extends ScalatraServlet with LiftJsonRequestBody with
JsonSupport {
// Linearization:
// JsonSupport
// LiftJsonRequestBody
// ApiFormats
// ScalatraServlet
// ...

// So JsonSupport's contentTypeInferrer runs before ApiFormats'
}

class Servlet2 extends ScalatraServlet with JsonSupport with
LiftJsonRequestBody {
// Linearization:
// LiftJsonRequestBody
// ApiFormats
// JsonSupport
// ScalatraServlet
// ...

// So ApiFormats' contentTypeInferrer runs before JsonSupport's
}

In theory, LiftJsonRequestBody could be written as:

trait LiftJsonRequestBody extends ScalatraKernel with ApiFormats
with JsonSupport

This would linearize JsonSupport before ApiFormats in both servlets
above, which is what you want. Whether that's what everybody would
want is a question I'm going to leave to Ivan, because he wrote these
modules and probably grasps nuances that I don't. :-)

[Bill Barrington]

Thanks, Ross. Very helpful.

[Ivan Porto Carrero]

I can shed some light but in about 14 hours when my plane has landed
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero - Mob: +32.486.787.582
Web: http://flanders.co.nz
Twitter: http://twitter.com/casualjim

[Ivan Porto Carrero]

Scalatra 2.1.0-SNAPSHOT now deprecates the JsonSupport and LiftJsonRequestBody traits and uses a single LiftJsonSupport trait.

This will remove the confusion around the JsonSupport at least.

What Ross wrote about the stackable traits and linearization still holds if you want to add different formats besides json and xml.

[Bill Barrington]

Apologies on being ignorant of your release strategy, but when would you see this making it into a full release?  (Or a milestone release).

Thanks,

Bill

[Ivan Porto Carrero]

I can't give you an exact date for when the release will happen, maybe Ross can. 

What I can tell you is: we're wrapping up 2.1.0 and I've begun working on 3.0 earlier this week, so it should happen soonish.

[Bill Barrington]

That's fine. Thanks!

[Nils Kilden-Pedersen]

On Tue, Jun 26, 2012 at 7:51 AM, Ivan Porto Carrero <iv...@flanders.co.nz> wrote:

I can't give you an exact date for when the release will happen, maybe Ross can. 

What I can tell you is: we're wrapping up 2.1.0 and I've begun working on 3.0 earlier this week, so it should happen soonish.

What changes and additions can we expect from 3.0?

[Ivan Porto Carrero]

* Scalatra's very own request/response abstraction

* Full support for Netty.

The idea is that you write a ScalatraApp and that can be run on either a servlet based platform or on netty, and it's easy to create integrations for other servers too.

In theory, when you don't use a shortcut to get to the underlying request/response you should be able to run a scalatra application on netty before noon, on jetty over lunch and on tomcat after lunch to return back to netty when the office closes

* Submountable applications, you can nest scalatra applications giving a higher degree of re-use

* mounting applications at runtime. you can swap scalatra applications at runtime

* a fighting chance to get jrebel working properly

https://github.com/scalatra/scalatra-netty/blob/master/src/main/scala/org/scalatra/AppServer.scala

On Tuesday, June 26, 2012 4:35:02 PM UTC+2, nilskp wrote:

[Ivan Porto Carrero]

and quite possibly also pluggable session stores