Getting "too many arguments for method apply" routes with multiple parameters - scala

I have a routes file like this:
GET /getOf/:city/:fi/:state/:zipCode cont.Offer.getOf(city:String, fi:String, state:String, zipCode:String)
In my scala class, my code is like this:
def getOf(city:String, fi:String,state:String,zipCode:String) = Action(parse.anyContent) {request =>
val offer = Offer(city,fi,state,zipCode);
Ok(Json.toJson(offerService.getOffer(offer)));
}
But when I run I get this compilation error:
too many arguments for method apply: (name: String, constraint: String)play.core.DynamicPart in object DynamicPart
But same code works fine if I have only one argument. I even not understanding what's the problem. Yes, I have created Eclipse project with play clean-all and others. But still same problem persists.
Can anyone please guide me on this? As I am very new to Play framework and scala.

i got the same problem when i walk through from the below url http://scala-ide.org/docs/tutorials/play/index.html but the issue resolved by calling clean and then compile from play console solved the issue.
Note* i initially had the site at different folder.

I got this error only in eclipse IDE and if i make any changes to the views it compiled atonce whereas for controllers it check only when "RELOAD" works...till then you may see the error at eclipse ide but app works fine.

Related

Eclipse giving error when compiler does not

I've come up against an odd issue in Eclipse while using the Stanford CoreNLP API. I've written a custom implementation of the Annotator interface, which amongst other things specifies two methods with the type signature Set<Class<? extends CoreAnnotation>>.
I've implemented those methods, but Eclipse is showing an error telling me that the type signature is incorrect. Specifically, it reports, The return type is incompatible with Annotator.requires(). The recommended fix suggests changing the return type to exactly the same type I already have written, but still leaves the error:
As you can see, the supposed `incorrect' type is exactly the same as the type given in the interface.
The project compiles correctly using mvn compile, so this isn't an actual compiler problem. Has anyone seen this before, and can you advise as to how to make those errors go away?
Edit: added screenshot showing the error
Edit2: added details of the error message in Eclipse

Scala : How to create Unit test case in Intellij

Could you help me in the process of creating Unit Test case for Scala in IntelliJ?
I tried creating it using intention action but it did not come for me. I checked the settings also for intention. All looks fine to me.
Do we have different process for Scala or am I missing something?
I think if you right click on a name (class, method, etc.) and select 'go to/test' (which i think is bound to Ctrl-Shift-T in the default keymap), it will offer to create a missing test.

Why Scala IDE cannot compile a method even though proposing it?

I am repeatedly run into a similar problem with Scala IDE. Thanks to tab completion Scala IDE proposes several methods. However, always when I choose a method it complains that it cannot resolve it. In the screenshot, I select the method findByEan from models.Product. After selecting the proposed method I get an error message:
Multiple markers at this line
- Line breakpoint:Products [line: 16] - show
- value findByEan is not a member of object models.Product
It complains that .findByEan() is not part of models.Product. As you can see from the listing above - the Product object has this method. Of course, it even proposed it to me several seconds ago!
package models
case class Product(ean:Long, name:String, description:String)
object Product{
var products = Set() // some products ...
def find_all = products.toList.sortBy(_.ean)
def findByEan(ean:Long) = products.find(_.ean == ean)
A similar issue happens when I add template views to the controllers.
Why Scala IDE cannot compile the proposed methods?
Scala IDE Version: 3.0.2-vfinal-20131028-1923-Typesafe
About not being able to find details. From its fully qualified name, it seems be a Play template.
The Play templates are compiled by Play itself, they are only typed checked inside the template editor. For them to be listed in completion, they have to be compiled (done by refreshing the app in the web browser), and visible by Scala IDE (done by refreshing the project in the IDE).
It is also possible to setup an environment in a way that the compile+refresh is done automatically. The steps are described in this tutorial.

Problems compiling routes after migrating to Play 2.1

After migrating to Play-2.1 I stuck into problem that routes compiler stopped working for my routes file. It's been completely fine with Play-2.0.4, but now I'm getting the build error and can't find any workaround for it.
In my project I'm using cake pattern, so controller actions are visible not through <package>.<controller class>.<action>, but through <package>.<component registry>.<controller instance>.<action>. New Play routes compiler is using all action path components except for the last two to form package name that will be used in managed sources (as far as I can get code in https://github.com/playframework/Play20/blob/2.1.0/framework/src/routes-compiler/src/main/scala/play/router/RoutesCompiler.scala). In my case it leads to situation when <package>.<component registry> is chosen as package name, which results in error during build:
[error] server/target/scala-2.10/src_managed/main/com/grumpycats/mmmtg/componentsRegistry/routes.java:5: componentsRegistry is already defined as object componentsRegistry
[error] package com.grumpycats.mmmtg.componentsRegistry;
I made the sample project to demonstrate this problem: https://github.com/rmihael/play-2.1-routes-problem
Is it possible to workaround this problem somehow without dropping cake pattern for controllers? It's the pity that I can't proceed with Play 2.1 due to this problem.
Because of reputation I can not create a comment.
The convention is that classes and objects start with upper case. This convention is applied to pattern matching as well. Looking at a string there seems to be no difference between a package object and normal object (appart from the case). I am not sure how Play 2.1 handles things, that's why this is not an answer but a comment.
You could try the new # syntax in the router. That allows you to create an instance from the Global class. You would still specify <package>.<controller class>.<action>, but in the Global you get it from somewhere else (for example a component registry).
You can find a bit of extra information here under the 'Managed Controller classes instantiation': http://www.playframework.com/documentation/2.1.0/Highlights
This demo project shows it's usage: https://github.com/guillaumebort/play20-spring-demo

Why am I getting NullPointerException in the CompilationUnit instances returned from ASTParser.createASTs()

I am working on an Eclipse JDT plugin that requires parsing large numbers of source files,
so I am hoping to use the batch method ASTParser.createASTs(). The parsing executes without errors, but within the CompilationUnit instances it produces, many of the org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding instances have had their scope field set to null. This setting to null is occurring in the CompilationUnitDeclaration.cleanUp() methods, which are invoked on a worker thread that is unrelated to my plugin's code (i.e., my plugin's classes do not appear on the cleanUp() method call stack).
My parsing code looks like this (all rawSources are within the same project):
ASTParser parser = ASTParser.newParser(AST.JLS3);
parser.setResolveBindings(true);
parser.setStatementsRecovery(true);
parser.setBindingsRecovery(true);
parser.setIgnoreMethodBodies(false);
parser.setProject(project);
parser.createASTs(rawSources.values().toArray(new ICompilationUnit[0]), new String[0], this, deltaAnalyzer.progressMonitor);
Alternatively, I can execute the parsing this way, and no such problems occur:
for (ICompilationUnit source : rawSources.values())
{
parser.setResolveBindings(true);
parser.setStatementsRecovery(true);
parser.setBindingsRecovery(true);
parser.setIgnoreMethodBodies(false);
parser.setProject(project);
parser.setSource(source);
CompilationUnit ast = (CompilationUnit)parser.createAST(deltaAnalyzer.progressMonitor);
parsedSources.add(deltaAnalyzer.createParsedSource(source, ast));
}
This issue occurs in both Helios and Indigo (the very latest release build). I filed a bug in Eclipse Bugzilla, but if anyone knows of a way to work around this--or if I am using the API wrong--I would greatly appreciate your help.
Byron
Without knowing exactly what your exception is, I can still offer 2 suggestions:
Have a look at org.eclipse.jdt.ui.SharedASTProvider. If you are not making any changes to ASTs, this class may provide a more robust way of getting the ASTs.
Play around with some of the settings that you are using. Do you really need bindingsRecovery set to true? What about statementRecovery? Setting these to false may help you.