ClassCastExceptions using Play 2.0 about salat HOT 44 CLOSED

Hi Marius,

Sorry to hear that you are encountering problems!

Since I am not a Play 2.0 user - although I am trying to learn more! - the single most helpful thing you could do is to create a mini-project on Github that could be used to demonstrate the problem along with a brief description of how it might be reproduced (I understand it can't be reliably reproduced and is no doubt related to Play's classloader magic).

Also, you may find the content of issue #31 to be helpful - I created some simple lifecycle callbacks for the context which you can hook into Play startup. This won't solve your problem, but it could allow you to get rid of a nagging class cast error while I troubleshoot it.

On an unrelated note, you don't need @Persist in EventLike - any parameter in the constructor of a case class will be persisted unless marked @Ignore. It shouldn't cause a problem, but no doubt your EventLike class would read cleaner without it :)

Best,
Rose

from salat.

Hi Rose,

Since I am not a Play 2.0 user - although I am trying to learn more! - the single most helpful thing you could do is to create a mini-project on Github that could be used to demonstrate the problem along with a brief description of how it might be reproduced (I understand it can't be reliably reproduced and is no doubt related to Play's classloader magic).

Ok I'll prepare a little project. But please note that Play-Scala doesn't use a lot of classloader magic (if any), as far as I understand it's only necessary for Java. And yes you should definitely look into Play, it's a great web framework :)

Also, you may find the content of issue #31 to be helpful - I created some simple lifecycle callbacks for the context which you can hook into Play startup.

Ok cool, I'll try that.

On an unrelated note, you don't need @persist in EventLike - any parameter in the constructor of a case class will be persisted unless marked @ignore. It shouldn't cause a problem, but no doubt your EventLike class would read cleaner without it :)

I noticed that superclass constructors are ignored, and I either have to use @Persist in the superclass or override val in the subclass. In this case I overdid a bit, but it's mainly because I was desperately searching for a solution for the class casts.

And I can't stress it enough - it only happens with inheritance.

from salat.

That's extremely weird, as I never observed this inheritance behaviour
at all anywhere in the specs for trait or abstract superclass
support in the tests for Salat.

I think I can easily make you a gist showing this is not the case
outside of Play (it is hard to imagine it would be the case inside
Play either).

Would that be helpful?

On 13 March 2012 17:43, Marius Soutier
[email protected]
wrote:

Hi Rose,

Since I am not a Play 2.0 user - although I am trying to learn more! - the single most helpful thing you could do is to create a mini-project on Github that could be used to demonstrate the problem along with a brief description of how it might be reproduced (I understand it can't be reliably reproduced and is no doubt related to Play's classloader magic).

Ok I'll prepare a little project. But please note that Play-Scala doesn't use a lot of classloader magic (if any), as far as I understand it's only necessary for Java. And yes you should definitely look into Play, it's a great web framework :)

Also, you may find the content of issue #31 to be helpful - I created some simple lifecycle callbacks for the context which you can hook into Play startup.

Ok cool, I'll try that.

On an unrelated note, you don't need @persist in EventLike - any parameter in the constructor of a case class will be persisted unless marked @ignore. It shouldn't cause a problem, but no doubt your EventLike class would read cleaner without it :)

I noticed that superclass constructors are ignored, and I either have to use @Persist in the superclass or override val in the subclass. In this case I overdid a bit, but it's mainly because I was desperately searching for a solution for the class casts.

And I can't stress it enough - it only happens with inheritance.

---

Reply to this email directly or view it on GitHub:
https://github.com/novus/salat/issues/32#issuecomment-4487032

from salat.

Yes I'd like to see an example gist.

I set up a simple project for now which illustrates the way we use Salat:
https://github.com/mariussoutier/Play-Salat-CCE-Demo

But I guess it's too simple because when playing around with it, I didn't run into any CCEs.

from salat.

I think this error is caused by Play's SQL migrations. After disabling them (using evolutionplugin=disabled), we don't see the error anymore.

from salat.

Thanks, Marius - I meant to get that gist to you earlier! I'll try to do it this afternoon.

from salat.

I'm not sure if it really solved the problem, at least it has become very are.

from salat.

Hi Rose. I'm having a similar issue with Play 2.0 + salat, using the new play-salat plugin. I thought it was fixed after this change (in the stack overflow link), but it still happens every time I make a change to my view, and then I have to restart play before it goes away.
http://stackoverflow.com/questions/10132730/play-framework-2-0-scala-classcastexception-models-mymodel-cannot-be-cast-to

Considering a play restart fixes the issue, maybe it's a play issue? When changing a "view" it only recompiles that one view before reloading play--it must get confused with the case class at that point... but I'm so new to scala I really don't know where to start tracking down the problem. In any case, I'm monitoring this issue now. Hope to hear more about it!

from salat.

Hi Wes, can you supply a stacktrace that shows some part of Salat causing the class cast exception? This stackoverflow post has a stracktrace but I don't see Salat anywhere in it.

from salat.

Nope, my stacktraces are exactly the same as what's on stackoverflow, replacing MyModel with my real model names. The only part of the stacktrace involving Salat is the case class model, which is what can't be cast to itself.

from salat.

For the record, the evolutionplugin=disabled didn't do anything for me. I can add a space to a view, save the file, hit refresh, and the error pops up. I can refresh 20 times and it persists. But restarting play causes it to go away and doesn't seem to happen until I change the view again.

from salat.

I've disabled the evolutions plugin but I'm still getting the errors

play.core.ActionInvoker$$anonfun$receive$1$$anon$1: Execution exception [[ClassCastException: models.User cannot be cast to models.User]]
    at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:134) [play_2.9.1.jar:2.1-SNAPSHOT]
    at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:115) [play_2.9.1.jar:2.1-SNAPSHOT]
    at akka.actor.Actor$class.apply(Actor.scala:290) [akka-actor-2.0.jar:2.0]
    at play.core.ActionInvoker.apply(Invoker.scala:113) [play_2.9.1.jar:2.1-SNAPSHOT]
    at akka.actor.ActorCell.invoke(ActorCell.scala:617) [akka-actor-2.0.jar:2.0]
    at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:179) [akka-actor-2.0.jar:2.0]
Caused by: java.lang.ClassCastException: models.User cannot be cast to models.User
    at views.html.people.list$$anonfun$apply$1.apply(list.template.scala:39) ~[classes/:na]
    at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:194) ~[scala-library.jar:0.11.2]
    at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:194) ~[scala-library.jar:0.11.2]
    at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:59) ~[scala-library.jar:0.11.2]
    at scala.collection.immutable.List.foreach(List.scala:45) ~[scala-library.jar:0.11.2]
    at scala.collection.TraversableLike$class.map(TraversableLike.scala:194) ~[scala-library.jar:0.11.2]

And the User class is simply used as this in the play view

@(free: Seq[User], busy: Seq[User], oof: Seq[User])

from salat.

Unfortunately, without a better stacktrace I can't begin to guess what is wrong. Until I can see that your error is coming from some part of Salat, I can only guess it is something to do with Play's classpath munging (which I just don't understand enough about to be helpful).

Suggestion: this is just a hunch, but try moving your DAO to a package outside models and see if the ClassCastException keeps recurring.

from salat.

I tried moving the DAO to a new package "modeldao", but that didn't seem to help. I got a stacktrace with salat involved today. It might not be related, but I thought I would mention it.

play.core.ActionInvoker$$anonfun$receive$1$$anon$1: Execution exception [[ClassCastException: models.Applicant cannot be cast to models.Applicant]]
at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:82) [play_2.9.1.jar:2.0]
at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:63) [play_2.9.1.jar:2.0]
at akka.actor.Actor$class.apply(Actor.scala:290) [akka-actor.jar:2.0]
at play.core.ActionInvoker.apply(Invoker.scala:61) [play_2.9.1.jar:2.0]
at akka.actor.ActorCell.invoke(ActorCell.scala:617) [akka-actor.jar:2.0]
at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:179) [akka-actor.jar:2.0]
Caused by: java.lang.ClassCastException: models.Applicant cannot be cast to models.Applicant
at controllers.Application$$anonfun$index$1$$anonfun$1.apply(Application.scala:20) ~[classes/:2.0]
at scala.collection.Iterator$class.foreach(Iterator.scala:660) ~[scala-library.jar:0.11.2]
at com.novus.salat.dao.SalatMongoCursor.foreach(SalatMongoCursor.scala:145) ~[salat-core_2.9.1-0.0.8-SNAPSHOT.jar:0.0.8-SNAPSHOT]
at controllers.Application$$anonfun$index$1.apply(Application.scala:20) ~[classes/:2.0]
at controllers.Application$$anonfun$index$1.apply(Application.scala:13) ~[classes/:2.0]
at play.api.mvc.Action$$anonfun$apply$4.apply(Action.scala:204) ~[play_2.9.1.jar:2.0]

from salat.

rktoomey, any suggestions on how I could produce a better stacktrace?

from salat.

Unfortunately, I have NO idea. That would be a question better directed at the Play developers who understand the internal workings of the way they are modifying the classpath at runtime when you change the view.

But hold on a couple of hours - I have been working on something that I think may help.

from salat.

Please take a look at http://groups.google.com/group/scala-salat/t/e881ffc5b361a8a5?hl=en_US

I am hoping that making the DAO an instance inside the companion object (as the MyModel example shows) might somehow even out whatever weird thing Play is doing to the classpath when it redoes the view.

Otherwise, I will need some help from a Play developer - posting to the Play mailing list would be the next step, I suppose.

from salat.

This DAO class within a companion object seems to have solved the ClassCastException problem for me--I haven't done thorough testing, but at least initially I've made a few minor changes and haven't needed to restart play. Thanks for helping!

from salat.

Oh bravo! I had hoped that making the DAO a new instance in the companion object would force the DAO to be regenerated along with the rest of the object hierarchy. Thanks for reporting back, Wes.

from salat.

I made this change for one of our classes but I just ran into the error again.

from salat.

I had to change all of the model classes to the new way before the errors stopped coming up.

from salat.

All right, if ModelCompanion seems to have solved the problem, I will close this issue. Anyone? Going, going...

from salat.

I vote to close. You can always reopen an issue! My opinion is to close early and wait for more complaints. That way you have a visual list of the current "actual" issues. Not that you have too many in salat. :P

from salat.

Thanks. I have seen the error page in Play that references Salat: I plan to issue a pull request to update the error message so that people can more easily solve their class reloading issues.

from salat.

The problem still persists for us. Changed everything to ModelCompanion, no luck.

from salat.

Hmm what a bother :)

I've used play-salat in a production without no problems since the change to ModelCompanion.

are you using the plugin or have you implemented it yourself?
We will need a failing github project or some example code that doesn't work, otherwise it will be impossible to know what's wrong.

from salat.

I implemented it myself. But essentially, there's no big difference to your plugin. This problem doesn't affect us in production, only in development.

from salat.

Do you use a custom context? In that case, do you attach to the play classloader?
Have you tried the clearAllGraters function in your onStop?
The plugin isn't using it, but as Rose said, the only place where some kind of caching happens is with the graters, which makes me thing it has something to do with them.

from salat.

IIRC, we didn't use your plug-in because it doesn't register the Play classloader with Salat. For us that resulted in Salat not picking up new fields while developing.

from salat.

Sorry to hear you're still having trouble, Marius. As Leon said, the single most helpful thing here would be a small Github project with instructions on how to reproduce the classloader errors you are experiencing.

Also, I am hearing conflicting things about the need to register the Play classloader in Play 2.0. It shouldn't really be necessary any more. If it is, then we need to investigate why and coordinate with the Play framework developers to figure out why.

from salat.

Yeah but if I only knew how to reproduce it reliably...

Well I made sure my own context is always in scope, let's see how this goes. But I agree, the classloader should only be relevant to Java projects. Supposed we can ignore the classloader, is a custom context necessary at all?

from salat.

If you want to change how typehints work or make some changes to how entities field names are serialized then yes.

https://github.com/leon/play-salat/blob/master/src/main/scala/se/radley/plugin/salat/package.scala#L22

You can infact use the plugin but not the context if you would like. there is nothing special with the context that comes with play-salat.

from salat.

Hi Rose,

today I participated in a hackathon and built an extremely simple JSON webservice with Play, Salat and Leon's plug-in. After a while I kept running into the same old exception. In the end, each recompile would result in an exception.

https://github.com/mariussoutier/iou-hackathon

• Marius

from salat.

That is brilliant news, Marius! Thank you so much. I forked your project, could you just reply with brief instructions on how to repro the CCE?

from salat.

Marius, trying to start sbt I get this weird error:

rose@marzipan:~/workspace/iou-hackathon (master)$ sbt
Detected sbt version 0.11.3
Starting sbt: invoke with -help for other options
Using /home/rose/.sbt/0.11.3 as sbt dir, -sbt-dir to override.
[info] Loading global plugins from /home/rose/.sbt/0.11.3/plugins
[info] Loading project definition from /home/rose/workspace/iou-hackathon/project
[error] java.lang.NoSuchMethodError: org.sbtidea.SbtIdeaPlugin$.ideaSettings()Lscala/collection/Seq;
[error] Use 'last' for the full log.
Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore

When I fall back to sbt 0.11.2 I get failed dependencies on play#sbt-plugin;2.0.2-RC2.

from salat.

I'm not an SBT expert, so I can only tell you that it works for me. Usually I use play directly (but I'm sure you can use it via SBT). You definitely have to use sbt 0.11.3. I had to upgrade sbt beforehand using brew upgrade sbt. Otherwise it just started and download half the internet:

Getting org.scala-sbt sbt_2.9.1 0.11.3 ...
downloading http://repo.typesafe.com/typesafe/ivy-releases/org.scala-sbt/sbt_2.9.1/0.11.3/jars/sbt_2.9.1.jar ...
...

Maybe you could install Play directly? http://download.playframework.org/releases/play-2.0.2-RC2.zip

You then run it as you would with sbt, so just enter play ~run and open http://localhost:9000/ in your browser. Change some code (a controller or a model) and refresh the browser.

from salat.

Marius, I've been busy with the 0.0.8 release but I will look at this later in the week. I've asked Leon to look at the error and see if it's the plugin or my sbt setup.

from salat.

I've updated the plugin to 1.0.5
I've done some changes that might help.

from salat.

Thanks, Leon, I will look at it later today.

from salat.

I've done some more testing and If move the salat context to the app instead of having it in the plugin everything works fine.

I think the problem is that Play is okey as long as the context is within the app, because then it releases all the model files when it rebuilds the app. But if the context is in the plugin and so in another jar, play will release the models in the app, but the context in the jar still has references to the old models which causes the Exception.

For now you will have to implement your own context. but since it's only 5 lines it should't be a problem.

https://github.com/leon/play-salat/blob/master/sample/app/models/mongoContext.scala#L11

I've releases a v1.0.6 that's built against the brand new Play 2.0.2 which no longer contains a context.
and I've also removed the type import's so you might have to import the salat annotations and the form binders if you where using them.

Let me know if this fixes the problem.

from salat.

Thanks, looking good so far!

from salat.

I think you can close this one now Rose, finally! :)

from salat.

Well, it isn't entirely resolved. It is just rare. It comes down to one exception per day, which can be lived with, but something is still wrong.

from salat.

@mariussoutier and @leon both reported this fixed.

Closing unless @mariussoutier or a successor wants to re-open with new reproduction steps.

from salat.