DGS Code Generation plugin: generateJava not working - build.gradle

I am trying generate pojo files from schema using this guide https://netflix.github.io/dgs/generating-code-from-schema/
build.gradle.kts
dependencies {
implementation("org.springframework.boot:spring-boot-starter-web")
implementation(project(":graphql-dgs-spring-boot-starter"))
implementation(project(":graphql-dgs-subscriptions-websockets-autoconfigure"))
implementation("io.projectreactor:reactor-core:3.4.0")
api("com.graphql-java:graphql-java:${Versions.GRAPHQL_JAVA}") //v 16.2
}
// Using plugins DSL
plugins {
id("com.netflix.dgs.codegen") version "4.4.1"
}
tasks {
generateJava {
// schemaPaths = ["${projectDir}/src/main/resources/schema"] // List of directories containing schema files
packageName ="com.example.packagename" // The package name to use to generate sources
generateClient = true // Enable generating the type safe query API
}
}
Getting error
Caused by: java.lang.UnsupportedOperationException: java.io.InvalidClassException: org.antlr.v4.runtime.atn.ATN; Could not deserialize ATN with UUID 59627784-3be5-417a-b9eb-8131a7286089 (expected aadb8d7e-aeef-4415-ad2b-8204d6cf042e or a legacy UUID).
at org.antlr.v4.runtime.atn.ATNDeserializer.deserialize(ATNDeserializer.java:153)
at graphql.parser.antlr.GraphqlLexer.<clinit>(GraphqlLexer.java:337)
... 231 more
Caused by: java.io.InvalidClassException: org.antlr.v4.runtime.atn.ATN; Could not deserialize ATN with UUID 59627784-3be5-417a-b9eb-8131a7286089 (expected aadb8d7e-aeef-4415-ad2b-8204d6cf042e or a legacy UUID).
... 233 more
I tried older versions of plugin, but that didn't help

It looks like you have a classpath conflict with ANTLR. This is very likely caused by another Gradle plugin that pulls in another (probably older) version of ANTLR.
The easy workaround is to re-order your plugins, putting the codegen plugin before the other plugin. Hopefully, the other plugin works with the newer version of ANTLR, but usually, that is the case.

I tried in other project that use gradle, and it works.

Related

UnknownClass.Cucumber while running JUnit engine + Cucumber + Gradle tests from command line

Me and my team just moved from JUnit4 to JUnit5 and we faced with parallelism issues. With 4th version we used -Dcucumber.options="--threads 5" to run in tests several threads, but after deprecation and removing of cucumber options it's obviously doesn't work anymore. I set up (at least I think so) junit platform engine for the project (https://github.com/cucumber/cucumber-jvm/tree/main/cucumber-junit-platform-engine#configuration-options), but when I try to run tests via comand line (using Gradle task), I receive following error:
UnknownClass.Cucumber > UnknownClass.initializationError FAILED
org.junit.platform.commons.JUnitException at EngineExecutionOrchestrator.java:114
Caused by: org.junit.platform.commons.JUnitException at HierarchicalTestEngine.java:57
Caused by: org.junit.platform.commons.JUnitException at DefaultParallelExecutionConfigurationStrategy.java:41
Unfortunately, didn't find something in the internet, maybe someone can help with it?
What we use:
Spring boot 2.7.3
Gradle 7.5.1
Cucumber java, junit, spring, junit-platform-engine 5.7.0
junit-platform-suite-api 1.3.2
Tasks in build.gradle that I have now:
useJUnitPlatform()
systemProperty("cucumber.junit-platform.naming-strategy", "long")
systemProperty("cucumber.execution.parallel.enabled", true)
systemProperty("cucumber.execution.parallel.config.strategy", "fixed")
systemProperty("cucumber.plugin", "html:reports/html")
systemProperty("cucumber.plugin", "pretty")
systemProperty("cucumber.plugin", "junit:reports/junit")
doLast {
javaexec {
mainClass.set("io.cucumber.core.cli.Main")
classpath = cucumberRuntime + sourceSets.test.get().output + sourceSets.main.get().output
}
}
}
tasks {
val consoleLauncherTest by registering(JavaExec::class) {
dependsOn(testClasses)
val reportsDir = file("$buildDir/test-results")
outputs.dir(reportsDir)
classpath = sourceSets["test"].runtimeClasspath
mainClass.set("org.junit.platform.console.ConsoleLauncher")
args("--scan-classpath")
args("--include-engine", "cucumber")
args("--reports-dir", reportsDir)
}
test {
dependsOn(consoleLauncherTest)
exclude("**/*")
}
}
Configuration class:
#CucumberContextConfiguration
#Suite
#IncludeEngines("cucumber")
#SelectClasspathResource("com/example")
#ConfigurationParameter(key = GLUE_PROPERTY_NAME, value = "com.example")
#SpringBootTest
#ContextConfiguration(classes = [IntegrationContext::class], loader = SpringBootContextLoader::class)
class Application() {}
Your question is pretty much impossible to answer because you didn't go through the process of making a minimal reproducer. For your next question please read the "Help others reproduce the problem" section in How do I ask a good question?.
With 4th version we used -Dcucumber.options="--threads 5" to run in tests several threads, but after deprecation and removing of cucumber options it's obviously doesn't work anymore.
Project typically include a CHANGELOG and release notes documenting all relevant changes.
What we use:
Spring boot 2.7.3
Cucumber java, junit, spring, junit-platform-engine 5.7.0
junit-platform-suite-api 1.3.2
These dependencies don't converge and aren't quite correct. You'll want to use Cucumber's and JUnit's Bill of Materials to avoid having to specify the version for every module.
If you're using Spring Boot in the recommended way you may also be able to omit the junit-bom altogether.
dependencies {
testImplementation(platform("org.junit:junit-bom:5.9.1"))
testImplementation(platform("io.cucumber:cucumber-bom:7.9.0"))
testImplementation("io.cucumber:cucumber-java")
testImplementation("io.cucumber:cucumber-junit-platform-engine")
testImplementation("org.junit.platform:junit-platform-suite")
testImplementation("org.junit.jupiter:junit-jupiter")
}
Tasks in build.gradle that I have now:
So in this build file it appears that you are trying to run Cucumber in 3 different ways. Through the JUnit Platform, through Cucumbers CLI and through the JUnit 5 ConsoleLauncher.
I don't know which solution you are trying use but suppose that you want to use the JUnit Platform, then you look at cucumber-java-skeleton for a working example.
Then afterwards you should clean up your build file. :D

Can the ConfigurationAPI in Liferay DXP be used for Plugin sdk portlet?

I have followed given 2 tutorials to use COnfigurationAPI in a Liferay dxp plugins SDK portlet built using Ant/Ivy.
COnfiguration API 1
COnfiguration API 2.
Below is the configuration class used:
package com.preferences.interfaces;
import com.liferay.portal.configuration.metatype.annotations.ExtendedObjectClassDefinition;
import aQute.bnd.annotation.metatype.Meta;
#ExtendedObjectClassDefinition(
category = "preferences",
scope = ExtendedObjectClassDefinition.Scope.GROUP
)
#Meta.OCD(
id = "com.preferences.interfaces.UnsupportedBrowserGroupServiceConfiguration",
name = "UnsupportedBrowser.group.service.configuration.name"
)
public interface UnsupportedBrowserGroupServiceConfiguration {
#Meta.AD(deflt = "", required = false)
public String displayStyle();
#Meta.AD(deflt = "0", required = false)
public long displayStyleGroupId(long defaultDisplayStyleGroupId);
}
Post following the steps,I am getting the below error:
ERROR [CM Configuration Updater (ManagedService Update: pid=[com.preferences.interfaces.UnsupportedBrowserGroupServiceConfiguration])][org_apache_felix_configadmin:97] [org.osgi.service.cm.ManagedService, id=7082, bundle=297//com.liferay.portal.configuration.settings-2.0.15.jar?lpkgPath=C:\dev\Liferay\osgi\marketplace\Liferay Foundation.lpkg]: Unexpected problem updating configuration com.preferences.interfaces.UnsupportedBrowserGroupServiceConfiguration {org.osgi.service.cm.ConfigurationAdmin}={service.vendor=Apache Software Foundation, service.pid=org.apache.felix.cm.ConfigurationAdmin, service.description=Configuration Admin Service Specification 1.2 Implementation, service.id=56, service.bundleid=643, service.scope=bundle}
Caused by: java.lang.IllegalArgumentException: wrong number of arguments
So,does this process need a osgi module as mandatory or can we do it using plusings sdk portlet built using ant as well?
Without disecting the error message Caused by: java.lang.IllegalArgumentException: wrong number of arguments:
The way you build your plugin (Ant, Maven, Gradle, manually) doesn't make a difference, as long as you build a plugin that will be understood by the runtime. aQute.bnd.annotation.metatype.Meta points firmly into the OSGi world, and makes it almost certain that you'll need an OSGi module. You can build this with Ant, of course. Even in Ant you can embed tools like bnd, or you can write the proper Manifest.mf to include in your module manually (just kidding - you don't want to do it manually, but it would work).
Recommendation: Instead of moving everything over: Try to reproduce this with a minimal example in gradle or better Liferay Workspace (which is gradle based), just to get all the automatic wiring in. Check if it makes a difference and compare the generated output from your Ant build process with the workspace output. Pay specific attention to the Manifest.
In order to build the proper Manifest, you want to use bnd - if the Manifest turns out to be your issue: Find a way to embrace bnd - if that's by saying goodby to Ant, or by tweaking your build script remains your decision.

JSON Parser -java.lang.NoSuchFieldError: defaultReader

I am using a JSON parser to extract the value and I am using the following jar
json-path-2.1.0, and I am getting the following error when I invoke the use case deployed as webservice on weblogic server
I wrote a small main program to extract the value from the json string and it works fine, but the server version of the use case is giving the issue. I am not sure if there are any other jars part of my ear can negatively impact this
SEVERE: defaultReader
java.lang.NoSuchFieldError: defaultReader
at com.jayway.jsonpath.spi.json.JsonSmartJsonProvider.<init>(JsonSmartJsonProvider.java:39)
at com.jayway.jsonpath.internal.DefaultsImpl.jsonProvider(DefaultsImpl.java:21)
at com.jayway.jsonpath.Configuration.defaultConfiguration(Configuration.java:174)
at com.jayway.jsonpath.internal.JsonContext.<init>(JsonContext.java:52)
at com.jayway.jsonpath.JsonPath.parse(JsonPath.java:596)
Stumbled about the same problem.
The reason why it does not work is not the JDK 8.
The reason why you encounter this issue, is the fact that weblogic 12.2.1.X is bundling some old version of json-smart.
On my machine this would be found here:
jar:file:/C:/dev/WLS_12_2_1_2_0/oracle_common/modules/net.minidev.json-smart.jar!/net/minidev/json/JSONValue.class
Now if you are using a library like json-path that depends on json-smart, then by default the container will load the required class using one of its built-in modules.
The blowup you have, seems to be that the JSONValue class that your json-path depends on seemed to have this defaultReder field.
Here is a snipet of the clode that is blowing up.
public JsonSmartJsonProvider() {
this(JSONParser.MODE_PERMISSIVE, JSONValue.defaultReader.DEFAULT_ORDERED);
}
That
JSONValue.defaultReader
Seems not to be valid on weblogs older system class loader class.
You can tell the container to use what you are packing by putting into your weblogic.xml deployment descriptor something like this:
<wls:prefer-application-packages>
<wls:package-name>net.minidev.json.*</wls:package-name>
</wls:prefer-application-packages>
I am having quite a bit of trouble getting weblogic to swallow the fine-grained instruction above.
I found myself to force weblogic to swallog all that goes into the web-inf folder instead doing:
<wls:container-descriptor>
<wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes>
</wls:container-descriptor>
I would have rather not be using a hammer like the web-inf-classes, but I am dancing with the weblogic system classloader when I do not go coarse grained...
Regards.
I too was facing this issue, It turned out some other library was using json-smart's older version, and it was getting precedence over json-path's json-smart dependency. Removing the other jar solved the issue. Or you can also downgrade your json-path's version to appropriate version such that it support json-smart's older version.
Looks like JsonParser jar is present in JVM 1.8 version and it seems to have more precedence over the JsonParser class available in Json-path.jar. Apparently the us case doesn't work in 12.2.1 version of the weblogic server but it works fine in 12.1.3
I had the same problem but I use Gradle so I had to add:
compile group: 'net.minidev', name: 'json-smart', version: '2.3' to my dependencies.

Spark running error java.lang.NoClassDefFoundError: org/codehaus/jackson/annotate/JsonClass

import org.apache.spark.SparkContext._
import org.apache.spark.SparkConf
import play.api.libs.json._
import java.util.Date
import javax.xml.bind.DatatypeConverter
object Test {
def main(args:Array[String]): Unit = {
val logFile="test.txt"
val conf=new SparkConf().setAppName("Json Test")
val sc = new SparkContext(conf)
try {
val out= "output/test"
val logData=sc.textFile(logFile,2).map(line => Json.parse(cleanTypo(line))).cache()
} finally {
sc.stop()
}
}
Since it was said about the Spark jackson conflict problem, I have rebuilt Spark using
mvn versions:use-latest-versions -Dincludes=org.codehaus.jackson:jackson-core-asl
mvn versions:use-latest-versions -Dincludes=org.codehaus.jackson:jackson-mapper-asl
So the jars have been updated to 1.9.x
But I still have the error
15/03/02 03:12:19 ERROR Executor: Exception in task 0.0 in stage 0.0 (TID 0)
java.lang.NoClassDefFoundError: org/codehaus/jackson/annotate/JsonClass
at org.codehaus.jackson.map.introspect.JacksonAnnotationIntrospector.findDeserializationType(JacksonAnnotationIntrospector.java:524)
at org.codehaus.jackson.map.deser.BasicDeserializerFactory.modifyTypeByAnnotation(BasicDeserializerFactory.java:732)
at org.codehaus.jackson.map.deser.BeanDeserializerFactory.createBeanDeserializer(BeanDeserializerFactory.java:427)
at org.codehaus.jackson.map.deser.StdDeserializerProvider._createDeserializer(StdDeserializerProvider.java:398)
at org.codehaus.jackson.map.deser.StdDeserializerProvider._createAndCache2(StdDeserializerProvider.java:307)
at org.codehaus.jackson.map.deser.StdDeserializerProvider._createAndCacheValueDeserializer(StdDeserializerProvider.java:287)
at org.codehaus.jackson.map.deser.StdDeserializerProvider.findValueDeserializer(StdDeserializerProvider.java:136)
at org.codehaus.jackson.map.deser.StdDeserializerProvider.findTypedValueDeserializer(StdDeserializerProvider.java:157)
at org.codehaus.jackson.map.ObjectMapper._findRootDeserializer(ObjectMapper.java:2468)
at org.codehaus.jackson.map.ObjectMapper._readValue(ObjectMapper.java:2383)
at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1094)
at play.api.libs.json.JacksonJson$.parseJsValue(JsValue.scala:477)
at play.api.libs.json.Json$.parse(Json.scala:16)
We hit almost the exact same issue. We were trying to use 1.9.2 but hit a no such method error as well.
Annoyingly there is not only 1 version conflict to deal with but 2. First of all Spark depends on Hadoop (for hdfs) which depends on a 1.8.x build of the jackson json and this is the conflict which you are seeing. Spark (at least 1.2+) then uses the jackson 2.4.4 core which actually got moved to com.fasterxml.jackson.core so it does not actually conflict with 1.8.x due to the different package names.
So in your case your code should work if you do 1 of 3 things:
upgrade to 2.4.x build that is LESS THAN OR EQUAL TO 2.4.4 since the actual dependency will be replaced by sparks which is 2.4.4 (at the time of writing this)
downgrade to 1.8.x that is LESS THAN OR EQUAL TO the 1.8.x build which hadoop is using
compile spark under your 1.9.x build. I know you mention this and that it didn't work but when we tried it was successful and we ran the build with the option -Dcodehaus.jackson.version=1.9.2
There are going to be a lot more issues like this to come unfortunately due to the nature of spark and how it already has all of its own internal dependencies on the classpath so any job dependencies that conflict will never work out. Spark already does some dependency shading to avoid this issue with packages like guava but this is not currently done with jackson.

Receiving "bad symbolic reference to org.json4s.JsonAST..." in Eclipse Scala-IDE using 2.11

I am attempting to use the Eclipse Scala-IDE for 2.11 (downloaded the prepackaged bundle from the web-site). I have been using the Scala Worksheet to work with a SaaS API returning JSON. I've been pushing through just using String methods. I decided to begin using json4s. I went to http://mvnrepository.com/ and obtained the following libraries:
json4s-core-2.11-3.2.10.jar
json4s-native-2.11-3.2.10.jar
paranamer-2.6.jar
I have added all three jars to the Project's Build Path. And they appear under the project's "Referenced Libraries".
I have the following code in a Scala Worksheet:
package org.public_domain
import org.json4s._
import org.json4s.native.JsonMethods._
object WorkSheet6 {
println("Welcome to the Scala worksheet")
parse(""" { "numbers" : [1, 2, 3, 4] } """)
println("Bye")
}
I am receiving the following two compilation errors:
bad symbolic reference to org.json4s.JsonAST.JValue encountered in class file 'package.class'. Cannot access type JValue in value org.json4s.JsonAST. The current classpath may be missing a definition for org.json4s.JsonAST.JValue, or package.class may have been compiled against a version that's incompatible with the one found on the current classpath.
bad symbolic reference to org.json4s.JsonAST.JValue encountered in class file 'package.class'. Cannot access type JValue in value org.json4s.JsonAST. The current classpath may be missing a definition for org.json4s.JsonAST.JValue, or package.class may have been compiled against a version that's incompatible with the one found on the current classpath.
When I go look in the org.json4s package in the json4s-core-2.11-3.2.10.jar file, there is in fact no .class file indicating any sort of compiled object JsonAST.
This is a showstopper. Any help on this would be greatly appreciated.
Your classpath is incomplete. You are missing a dependency of json4s-core.
bad symbolic reference to org.json4s.JsonAST.JValue encountered in class file 'package.class'. Cannot access type JValue in value org.json4s.JsonAST. The current classpath may be missing a definition for org.json4s.JsonAST.JValue, or package.class may have been compiled against a version that's incompatible with the one found on the current classpath.
The simplest way to consume Scala or Java libraries is to use sbt or maven. They bring in (transitive) dependencies for you. If you check the pom definition of json4s-core library, you notice it depends on json4s-ast. You should add that jar to your build path as well.