lift-json + play framework

[Dirk]

I want to use lift-json to serialize case classes with the Play
framework however whenever I call write() it just outputs an empty
json object:
scala> import net.liftweb.json._
scala> import net.liftweb.json.Serialization._
scala> case class Dog(name: String)
scala> implicit val formats = Serialization.formats(NoTypeHints)
scala> write(Dog("Fido"))
res2: String = {}
(Note: this happens in code running within the web framework, not just
on the scala console)

I think the problem is that Play implements its own class loading
mechanism, so when paranamer attempts to read the class file it fails
in this method:
public String[] lookupParameterNames(AccessibleObject methodOrCtor,
boolean throwExceptionIfMissing):
http://svn.codehaus.org/paranamer/trunk/paranamer/src/java/com/thoughtworks/paranamer/BytecodeReadingParanamer.java
On line 91 getClassAsStream(declaringClass) attempts to get the class
file and fails.

Here is how Play implements the same thing:
https://github.com/playframework/play/blob/master/framework/src/play/classloading/enhancers/LocalvariablesNamesEnhancer.java#L33

Is there any way to unite these approaches, so that I can use lift-
json with Play?
Thanks,
Dirk

[Andy Czerwonka]

blasphemy!!!! :-)

[Dirk McCormick]

Hehe yeah I was really hoping to find a lift-json list rather than posting on the lift list :)

On Fri, Mar 4, 2011 at 12:39 PM, Andy Czerwonka <andy.cz...@gmail.com> wrote:

blasphemy!!!! :-)

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[Jeppe Nejsum Madsen]

On Fri, Mar 4, 2011 at 4:41 PM, Dirk McCormick <di...@mccormick.cx> wrote:
> Hehe yeah I was really hoping to find a lift-json list rather than posting
> on the lift list :)

Well, Lift-the-project is more than the web framework, so this is the
right place :-)

/Jeppe

[David Pollak]

On Fri, Mar 4, 2011 at 7:41 AM, Dirk McCormick <di...@mccormick.cx> wrote:

Hehe yeah I was really hoping to find a lift-json list rather than posting on the lift list :)

Lift is a broad ranging framework and we welcome all questions from all users of any Web framework.  The key take-away is that we're here to help.

 

On Fri, Mar 4, 2011 at 12:39 PM, Andy Czerwonka <andy.cz...@gmail.com> wrote:

blasphemy!!!! :-)

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

[Joni Freeman]

Hi,

Could you try to replace a call to paranamer.lookupParameterNames with a
call to LocalvariablesNamesEnhancer.lookupParameterNames?

https://github.com/lift/framework/blob/master/core/json/src/main/scala/net/liftweb/json/Meta.scala#L176

If it works we can then abstract parameter name reading and let Play
users configure a strategy which works in that environment.

Cheers Joni

[Dirk McCormick]

Hi, sorry for the late response, I was away for the weekend.

> Lift is a broad ranging framework and we welcome all questions from
> all users of any Web framework.  The key take-away is that we're here
> to help.

That's great, thanks!

> Could you try to replace a call to paranamer.lookupParameterNames with a
> call to LocalvariablesNamesEnhancer.lookupParameterNames?

Yes, I'll give it a go and get back to you tomorrow.
Thanks again
Dirk

[Dirk McCormick]

I replaced paranamer.lookupParameterNames with LocalvariablesNamesEnhancer.lookupParameterNames as you suggested and it works!

One caveat: When I defined the case class outside the class I was using for testing it worked fine. However when I defined the case class inline within the test method or within the test class, there was an extra field called $outer. Is this supposed to be filtered out by the clean function defined in constructorArgs?

Thanks again
Dirk

[Joni Freeman]

On Wed, 2011-03-09 at 11:00 -0300, Dirk McCormick wrote:
> I replaced paranamer.lookupParameterNames with
> LocalvariablesNamesEnhancer.lookupParameterNames as you suggested and
> it works!

Very nice, thanks for finding it out! I will abstract parameter reading
now and will make the reading strategy configurable. Details will follow
soon.

> One caveat: When I defined the case class outside the class I was
> using for testing it worked fine. However when I defined the case
> class inline within the test method or within the test class, there
> was an extra field called $outer. Is this supposed to be filtered out
> by the clean function defined in constructorArgs?

This is expected behavior. Scalac makes a class inner class when it is
defined within a class. An inner class gets an implicit reference to the
outer class, the extra field called $outer you saw. Serializable case
classes must be defined in a package or in an object.

Cheers Joni

> Thanks again
> Dirk
>
> On Tue, Mar 8, 2011 at 12:26 AM, Dirk McCormick <di...@mccormick.cx>
> wrote:
> Hi, sorry for the late response, I was away for the weekend.
>
>
> > Lift is a broad ranging framework and we welcome all
> questions from
> > all users of any Web framework. The key take-away is that
> we're here
> > to help.
>
>
> That's great, thanks!
>
>
> > Could you try to replace a call to
> paranamer.lookupParameterNames with a
> > call to LocalvariablesNamesEnhancer.lookupParameterNames?
>
>
> Yes, I'll give it a go and get back to you tomorrow.
> Thanks again
> Dirk
>
>
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb

> +unsub...@googlegroups.com.

[Joni Freeman]

On Wed, 2011-03-09 at 17:53 +0200, Joni Freeman wrote:
> On Wed, 2011-03-09 at 11:00 -0300, Dirk McCormick wrote:
> > I replaced paranamer.lookupParameterNames with
> > LocalvariablesNamesEnhancer.lookupParameterNames as you suggested and
> > it works!
>
> Very nice, thanks for finding it out! I will abstract parameter reading
> now and will make the reading strategy configurable. Details will follow
> soon.

Hi,

Pushed a new configuration option to trunk. You can configure Play
specific parameter name reading strategy in a following way:

object PlayParameterNameReader extends ParameterNameReader
{
def lookupParameterNames(constructor: JConstructor[_]) = ...
}

implicit val formats = new DefaultFormats {
override val parameterNameReader = PlayParameterNameReader
}

A convenient place to put that implicit is a package object. For
instance if your project is namespaced as foo.bar, you can put that
implicit definition to a package object foo.bar and it will be in scope
for all subpackages.

Cheers Joni

[Dirk McCormick]

Awesome, thanks!
Does this mean there is no longer a dependency on the paranamer jar for projects that don't user paranamer?

[Joni Freeman]

I think you still need it on CLASSPATH though. It is not used at all if
you configure a different name reading strategy but there's references
to it in classes since it is the default strategy.

Cheers Joni

[Dirk McCormick]

Ok cool, thanks again

Cheers Joni

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.

To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

[Dirk]

Hi Joni,
Did you push this to master? It looks like the most recent change on github was on the 28th of January:
https://github.com/lift/lift
Thanks,
Dirk

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.

To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

[Jeppe Nejsum Madsen]

Dirk <dirk...@gmail.com> writes:

> Hi Joni,
> Did you push this to master? It looks like the most recent change on github
> was on the 28th of January:
> https://github.com/lift/liftThanks,

You need to look here: https://github.com/lift/framework

Perhaps it's time to delete the old github repo?

/Jeppe

[David Pollak]

We should keep the old repo around (history is very important), but change the README
 

/Jeppe

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
Lift, the simply functional web framework http://liftweb.net

Simply Lift http://simply.liftweb.net

[Dirk]

We should keep the old repo around (history is very important), but change the README

Yes, coming from the enemy camp I had no idea where your treasure was hidden :)
It looks like lift/framework is a new repo rather than a fork of an existing repo, so I think you can safely change the old repo without affecting the history of the new repo. It might make sense to remove all the code from the old repo and just leave a README with a message pointing people with old links to the new location in github?

Anyway I pulled from the new repo and made the change in my code, and I'm happy to report that lift-json is now working with my play framework app. The next step will be to integrate it with play's scala module.

Thanks to Joni for the super fast change and thanks to all those who helped out!
Dirk

[Jeppe Nejsum Madsen]

David Pollak <feeder.of...@gmail.com> writes:

> On Tue, Mar 15, 2011 at 2:45 PM, Jeppe Nejsum Madsen <je...@ingolfs.dk>wrote:
>
>> Dirk <dirk...@gmail.com> writes:
>>
>> > Hi Joni,
>> > Did you push this to master? It looks like the most recent change on
>> github
>> > was on the 28th of January:
>> > https://github.com/lift/liftThanks,>
>>
>> You need to look here: https://github.com/lift/framework>
>> Perhaps it's time to delete the old github repo?
>>
>
> We should keep the old repo around (history is very important), but change
> the README

I've changed the READMEs...

Another idea is to fork the repo to another account and keep history
there and delete it from the lift namespace....

/Jeppe

[v6ak]

I've written an "extension method" for updating the
parameterNameReader:
https://gist.github.com/891235
I wish it to be in the Lift repo as normal method...

BTW: In some cases, the default parameterNameReader works well. For
example, if you (de)serialize only classes from an external module
which is linked by Maven, it is probably on the classpath and it works
well.

Vít Šesták 'v6ak'


On Mar 16, 10:08 am, Jeppe Nejsum Madsen <je...@ingolfs.dk> wrote:

> David Pollak <feeder.of.the.be...@gmail.com> writes:
> > On Tue, Mar 15, 2011 at 2:45 PM, Jeppe Nejsum Madsen <je...@ingolfs.dk>wrote:
>

[David Pollak]

On Mon, Mar 28, 2011 at 1:53 PM, v6ak <v6...@volny.cz> wrote:

I've written an "extension method" for updating the
parameterNameReader:
https://gist.github.com/891235
I wish it to be in the Lift repo as normal method...

We don't accept external patches per our IP policy.
 

BTW: In some cases, the default parameterNameReader works well. For
example, if you (de)serialize only classes from an external module
which is linked by Maven, it is probably on the classpath and it works
well.

Vít Šesták 'v6ak'


On Mar 16, 10:08 am, Jeppe Nejsum Madsen <je...@ingolfs.dk> wrote:
> David Pollak <feeder.of.the.be...@gmail.com> writes:
> > On Tue, Mar 15, 2011 at 2:45 PM, Jeppe Nejsum Madsen <je...@ingolfs.dk>wrote:

>
> >> Dirk <dirkm...@gmail.com> writes:
>
> >> > Hi Joni,
> >> > Did you push this to master? It looks like the most recent change on
> >> github
> >> > was on the 28th of January:
> >> >https://github.com/lift/liftThanks,>
>
> >> You need to look here:https://github.com/lift/framework>
> >> Perhaps it's time to delete the old github repo?
>
> > We should keep the old repo around (history is very important), but change
> > the README
>
> I've changed the READMEs...
>
> Another idea is to fork the repo to another account and keep history
> there and delete it from the lift namespace....
>
> /Jeppe

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.