I have a lot of successful rest accesses in grails 2.x.x
I simply coded
import grails.plugins.rest.client.*
import grails.util.Holders
import org.codehaus.groovy.grails.web.json.JSONObject
import org.codehaus.groovy.grails.web.json.JSONArray
and Classes JSONObject, JSONArray, RestBuilder, RestResponse where available for further use.
What are the corresponding imports in 4.0.1 and what jars resp. what lines in build.gradle are necessary?
What are the corresponding imports in 4.0.1 and what jars resp. what
lines in build.gradle are necessary?
Grails 4 offers better options than to interact with the classes you asked about but to answer the question as asked...
org.grails.web.json.JSONObject is in grails-web-common-4.0.1.jar. Use import org.grails.web.json.JSONObject.
org.grails.web.json.JSONArray is in grails-web-common-4.0.1.jar. Use import org.grails.web.json.JSONArray.
grails.plugins.rest.client.RestBuilder is in grails-datastore-rest-client-6.1.12.RELEASE.jar. Use import grails.plugins.rest.client.RestBuilder.
grails.plugins.rest.client.RestResponse is in grails-datastore-rest-client-6.1.12.RELEASE.jar. Use import grails.plugins.rest.client.RestResponse.
Depending on what other dependencies you may have in your project those may or may not be pulled in transitively so you may not need to add them to your build.gradle directly. The most likely scenario is you won't need to add anything to pull in grails-web-common-4.0.1.jar but you probably will need to pull in grails-datastore-rest-client-6.1.12.RELEASE.jar which can be done by adding the following to your build.gradle:
compile "org.grails:grails-datastore-rest-client:6.1.12.RELEASE"
If you want to pull in grails-web-common explicitly you could use the following:
compile "org.grails:grails-web-common:4.0.1"
If you are using the BOM correctly, you could simplify that with the following:
compile "org.grails:grails-web-common"
I hope that helps.
Related
I'm parsing a XML string to convert it to a JsonNode in Scala using a XmlMapper from the Jackson library. I code on a Databricks notebook, so compilation is done on a cloud cluster. When compiling my code I got this error java.lang.NoSuchMethodError: com.fasterxml.jackson.dataformat.xml.XmlMapper.coercionConfigDefaults()Lcom/fasterxml/jackson/databind/cfg/MutableCoercionConfig; with a hundred lines of "at com.databricks. ..."
I maybe forget to import something but for me this is ok (tell me if I'm wrong) :
import ch.qos.logback.classic._
import com.typesafe.scalalogging._
import com.fasterxml.jackson._
import com.fasterxml.jackson.core._
import com.fasterxml.jackson.databind.{ObjectMapper, JsonNode}
import com.fasterxml.jackson.dataformat.xml._
import com.fasterxml.jackson.module.scala._
import com.fasterxml.jackson.module.scala.experimental.ScalaObjectMapper
import java.io._
import java.time.Instant
import java.util.concurrent.TimeUnit
import javax.xml.parsers._
import okhttp3.{Headers, OkHttpClient, Request, Response, RequestBody, FormBody}
import okhttp3.OkHttpClient.Builder._
import org.apache.spark._
import org.xml.sax._
As I'm using Databricks, there's no SBT file for dependencies. Instead I installed the libs I need directly on the cluster. Here are the ones I'm using :
com.squareup.okhttp:okhttp:2.7.5
com.squareup.okhttp3:okhttp:4.9.0
com.squareup.okhttp3:okhttp:3.14.9
org.scala-lang.modules:scala-swing_3:3.0.0
ch.qos.logback:logback-classic:1.2.6
com.typesafe:scalalogging-slf4j_2.10:1.1.0
cc.spray.json:spray-json_2.9.1:1.0.1
com.fasterxml.jackson.module:jackson-module-scala_3:2.13.0
javax.xml.parsers:jaxp-api:1.4.5
org.xml.sax:2.0.1
The code causing the error is simply (coming from here : https://www.baeldung.com/jackson-convert-xml-json Chapter 5):
val xmlMapper: XmlMapper = new XmlMapper()
val jsonNode: JsonNode = xmlMapper.readTree(responseBody.getBytes())
with responseBody being a String containing a XML document (I previously checked the integrity of the XML). When removing those two lines the code is working fine.
I've read tons of articles or forums but I can't figure out what's causing my issue. Can someone please help me ? Thanks a lot ! :)
Welcome to dependency hell and breaking changes in libraries.
This usually happens, when various lib bring in different version of same lib. In this case it is Jackson.
java.lang.NoSuchMethodError: com.fasterxml.jackson.dataformat.xml.XmlMapper.coercionConfigDefaults()Lcom/fasterxml/jackson/databind/cfg/MutableCoercionConfig; means: One lib probably require Jackson version, which has this method, but on class path is version, which does not yet have this funcion or got removed bcs was deprecated or renamed.
In case like this is good to print dependency tree and check version of Jackson required in libs. And if possible use newer versions of requid libs.
Solution: use libs, which use compatible versions of Jackson lib. No other shortcut possible.
upgrading to 2.12.5 version fixed my issue.
this issue may also appear when there are multiple versions of jackson jars in project lib directory. you should remove the older versions.
I have project structure
-core_data
-core_domain
-core_ui
-core_launcher
The dependency of these 4 projects is
core_launcher -> core_ui -> core_domain -> core_data
4 projects are located in the same directory and I include one to another via pubspec.yaml file (for example core_launcher/pubspec.yaml):
dependencies:
flutter:
sdk: flutter
core_ui:
path: ../core_ui
The same thing I do with all projects to make dependency hierarchy.
The problem is that I can import all files from core_ui subproject when I'm currently editing some file in core_launcher but VSCode doesn't see any classes from his parents
(core_domain & core_data).
However, I can input import 'blah-blah-blah manually and VSCode see this class and import works well, but I can't do that with hit Alt+Enter that I do for fast-import.
So, I'm wondering why autocomplete is not working for inherited libraries.
Somebody had the same issue?
Code completion will only show classes from your direct dependencies. There are two possible reasons for this:
Relying on transitive dependencies is not a good idea, because it's possible that your dependencies will remove or change their dependencies and not consider that a breaking change.
If code completion listed all classes from all transitive dependencies the code completion list would be huge and include classes from packages you do not recognise (because they are just other packages dependencies). This would be a bad user experience and make it easy to accidentally rely on packages that are not listed in your pubspec.yaml.
The fix is to explicitly list core_domain and core_data in your pubspec.yaml too, because if your project is using classes from them, then they are dependencies.
Im using the following:
import java.util.Collections;
import java.util.Collection;
import java.util.HashMap;
import java.util.Map;
import org.apache.commons.configuration.XMLConfiguration;
and i get:
The type org.apache.commons.lang.exception.NestableException cannot be resolved. It is indirectly referenced from required .class files
Im using eclipse...
how can i resolve this? he offers me to Configure build path but i dont really know how to solve this collision from there.....
Problem solved...
had to download the commons-lang-2.4.jar and include in project.
couldnt be more simple than that....
Sounds like what is really needed is an update to the PropertiesConfiguration lib so that it gets along with latest lang lib. If its a "free" lib then it might not be coming, considering that its been years since last reply on this thread and this is still happening.
I have been having this issue as well, and have not found a way of resolving it apart from the aforementioned inclusion of both lang libs ... which does not seem to present any problems, though strict repository framework implementations (like Maven) might have problems with both libs included.
Had to remove commons-lang3-3.4 from my Java Build Path and added 2.6 , it solved the problem!
I have a library which has root package "scala", and now I have a project using this library, and I have a sub package named "com.zjffdu.scala". And the class file in this package needs to import classes from the library. So I have the following import statement.
import scala._
But because this class is also in package "scala", the scala compiler will look for files in current directory rather than the library.
So how can I explicit to tell scala to import classes from the library.
Thanks
Use this:
import _root_.scala._
As you can see it's not very pretty — the best option is probably to avoid naming one of your packages scala.
And by the way — the root scala package is always preimported (though subpackages, of course, are not).
I get the following warning whenever I start my Scala application:
WARN - imported `SVNProperties' is permanently hidden by definition of object SVNProperties in package core, at line 4 of app/core/SVNResource.scala
What could this mean?
You probably have code that looks something like this:
object Hidden {
import scala.collection.immutable
object immutable { def x = 7 }
}
except in a less obvious way. You're importing something--in my example, the package immutable--and then you go and define something else with the same name that prevents you from using what you imported.
In particular, it looks like you tried to import SVNProperties into SVNResource.scala, except that SVNResource.scala defines its own SVNProperties which hides the import.
I encountered this warning after moving some classes from one package to another. I guess there was some conflict between the new location and binaries from the old location. In my case this helped:
sbt clean
I got this warning when my class was importing classes in the same package.
Once I removed the unnecessary import, the warnings were removed.
This happened to me after moving a class from one package to another, like in astasiak's case. I ran sbt clean with no luck. For the life of me, I couldn't find the class in the old location.
However, I had other errors preventing me from building. When I fixed those, this error disappeared. My guess is that until you can build cleanly, sbt still thinks you have the class is in the old package, and includes this error with any other build errors that are preventing you from building.
My advice? Check for other compilation errors and fix those -- you might be erroneously getting this error due to sbt having an outdated view of your package structure since its last successful build.
Just to further expand on a comment posted by Nick, as this was the case for me:
Another common cause is that SVNProperties is in the same package and so is already in scope. Trying to import it explicitly results in this warning.
More concretely, you may have:
package app.core
// No need to import the following - it is already visible as
// you are in the same package
import app.core.SVNProperties
object SVNResource {
Use instead:
package app.core
object SVNResource {
(Opinion) As a matter of coding style you may want to camel case your variables differently like for eg. SvnProperties, SvnResource. It reads easier for most people, see also this question.
I had a main class with name Server and I was creating a jetty server in the main class in the following way.
import org.eclipse.jetty.server.Server
var server:Server=new Server()
I got the below warn on running sbt run
> [warn] /home/xxx/xxx/xxx/src/main/scala/com/xxx/xxx/main/Server.scala:3:
> imported `Server' is permanently hidden by definition of object Server in package main
[warn] import org.eclipse.jetty.server.Server
[warn] ^
[warn] one warning found
I renamed my main class and the warning disappeared.
If you are using Scala Eclipse IDE you can do :
Project > Clean...
After that all the warning will be removed.
Also, make sure the name of the package you import =/= object name.
I got this by having circular dependencies. Both my classes were using each other on accident.
If the warning comes from importing a class with the same name, you can always use import renaming.
package domain
case class Company (...
package models
import domain.{Company => _Company}
object Company extends SkinnyCRUDMapper[_Company] {
Issue is related to dependency conflict, When you have same class in multiple Jars compiler found one of class is hidden and gives an error.
check for your Jar version is same across project or try to change name/package for one of conflicted class