see: vert-x3/issues#77

myverticle.groovy

void vertxStart() {
println("\u4f60\u597d")
println "你好 starting"
}

void vertxStop() {
println "stopping"
}

$ vertx run myverticle.groovy

你好

������ starting

Succeeded in deploying verticle

to check it works, that's a good groovy feature

I'm trying to upgrade an application from vertx 3.3.0 to vertx 3.5.0. The application uses a mixture of Java and Groovy code. When I try to run the upgraded version of the application it throws the following groovy compilation errors:

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
--
  | jar:file:/deployments/game-service-1.1.0-SNAPSHOT.jar!/GameVerticle.groovy: 7: unable to resolve class io.vertx.groovy.core.eventbus.Message
  | @ line 7, column 1.
  | import io.vertx.groovy.core.eventbus.Message
  | ^
  |  
  | jar:file:/deployments/game-service-1.1.0-SNAPSHOT.jar!/GameVerticle.groovy: 6: unable to resolve class io.vertx.groovy.core.eventbus.EventBus
  | @ line 6, column 1.
  | import io.vertx.groovy.core.eventbus.EventBus
  | ^
  |  
  | jar:file:/deployments/game-service-1.1.0-SNAPSHOT.jar!/GameVerticle.groovy: 9: unable to resolve class io.vertx.groovy.core.shareddata.AsyncMap
  | @ line 9, column 1.
  | import io.vertx.groovy.core.shareddata.AsyncMap
  | ^
  |  
  | jar:file:/deployments/game-service-1.1.0-SNAPSHOT.jar!/GameVerticle.groovy: 13: unable to resolve class io.vertx.core.AsyncResultHandler
  | @ line 13, column 1.
  | import io.vertx.core.AsyncResultHandler;
  | ^
  |  
  | jar:file:/deployments/game-service-1.1.0-SNAPSHOT.jar!/GameVerticle.groovy: 8: unable to resolve class io.vertx.groovy.core.http.HttpClient
  | @ line 8, column 1.
  | import io.vertx.groovy.core.http.HttpClient

I have tried both the shade plugin and the vertx-maven-plugin with no difference between the two. One thing I have noticed is that the vertx-lang-groovy class files are all suffixed with _GroovyExtension, could this be causing my issue? This is one notable difference between 3.3.0 and 3.5.0 as in 3.3.0 they were normally named class files.

Looking at the fat jar I see the expected SPIs are being included in META-INF/services such as the various org.codehaus.groovy extensions.

I'm not overly familiar with groovy, am I missing something captain obvious here?

In 3.3.3, the method signature for start(Future) in io.vertx.lang.groovy.GroovyVerticle only accepts io.vertx.core.Future instead of io.vertx.groovy.core.Future. This was causing me great pains for a while until I tracked it down.. It is easy to work around by using the implementation of Future from core, but I believe it should be fixed.

This is similar to #28

motivation: currently the expression

def closure = { -> ... }

Throws an NPE in the Vertx Groovy compiler transformation.

changes: fix the bug

workaround: write a closure with no arrow

def closure = { ... }

Hi there.
I was wondering if there was a reason for the groovy Vertx not implementing the Java Vertx interface?

IMHO, one of the key strengths of groovy is the interchangeability of classes and interfaces. By completely isolating the classes and interfaces we've sandbox everything into Java world and groovy world.

In Vert.x 3.x, the GroovyVerticle class for base verticles has been deprecated in favour of io.vertx.core.AbstractVerticle. GroovyVerticle is removed in 4.0.

Opened here from eclipse-vertx/vert.x#2022

I was just running a vertx project we have with the new 3.4.2 version and I got this exception:

startup failed:
General error during class generation: io.vertx.groovy.core.VertxPropertiesModuleFactory cannot be cast to org.codehaus.groovy.runtime.m12n.PropertiesModuleFactory

java.lang.ClassCastException: io.vertx.groovy.core.VertxPropertiesModuleFactory cannot be cast to org.codehaus.groovy.runtime.m12n.PropertiesModuleFactory
at org.codehaus.groovy.runtime.m12n.StandardPropertiesModuleFactory.newModule(StandardPropertiesModuleFactory.java:41)
at org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner.scanExtensionModuleFromProperties(ExtensionModuleScanner.java:79)
at org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner.scanExtensionModuleFromMetaInf(ExtensionModuleScanner.java:74)
at org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner.scanClasspathModules(ExtensionModuleScanner.java:56)
at org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport$ExtensionMethodCache.getExtensionMethods(StaticTypeCheckingSupport.java:1984)
at org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.findDGMMethodsForClassNode(StaticTypeCheckingSupport.java:208)
at org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.findDGMMethodsForClassNode(StaticTypeCheckingSupport.java:194)
at org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.findDGMMethodsByNameAndArguments(StaticTypeCheckingSupport.java:923)
at org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.findDGMMethodsByNameAndArguments(StaticTypeCheckingSupport.java:910)
at org.codehaus.groovy.transform.sc.transformers.BooleanExpressionTransformer$OptimizingBooleanExpression.visit(BooleanExpressionTransformer.java:155)
at org.codehaus.groovy.classgen.asm.StatementWriter.writeIfElse(StatementWriter.java:284)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitIfElse(AsmClassGenerator.java:586)
at org.codehaus.groovy.ast.stmt.IfStatement.visit(IfStatement.java:43)
at org.codehaus.groovy.classgen.asm.StatementWriter.writeBlockStatement(StatementWriter.java:85)
at org.codehaus.groovy.classgen.asm.sc.StaticTypesStatementWriter.writeBlockStatement(StaticTypesStatementWriter.java:65)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:570)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:104)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:115)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:434)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:387)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructor(ClassCodeVisitorSupport.java:122)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructor(AsmClassGenerator.java:506)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1077)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:53)
at org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:233)
at org.codehaus.groovy.control.CompilationUnit$17.call(CompilationUnit.java:825)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1065)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:537)
at org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:167)
at org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:54)
at org.gradle.api.internal.tasks.compile.daemon.CompilerDaemonServer.execute(CompilerDaemonServer.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:364)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)

1 error

Is there any breaking change in the new version?

The following code works well until 4.0.0.Beta1 which uses Groovy 3.0.3. Starting with 4.0.0.Beta2, which uses Groovy 3.0.5, it started to fail:

Promise p = Promise.promise()
p.future().onSuccess { println it }
p.complete("Done with Groovy!!!")

Exception in thread "main" java.lang.IllegalStateException: Result is already complete
        at io.vertx.core.Promise.complete(Promise.java:67)
        at io.vertx.core.Promise$complete$1.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:139)
        at org.example.MainGroovy.main(MainGroovy.groovy:17)

The bug doesn't happen whit Vertx 3.9. I tried with 3.9.5-SNAPSHOT, which is already using Groovy 3.0.7, and it is OK.

This is probably an issue with Groovy. I raised one that can be seen here https://issues.apache.org/jira/browse/GROOVY-9852. I opened this one here so we can track how things go.

@twasyl commented on Thu Mar 23 2017

Version

• vert.x core: 3.4.1
• vert.x web: 3.4.1

Context

Hello,

I'm currently trying to migrate SlideshowFX to JDK9 (build 161 with Jigsaw).
The application embeds Vert.x in order to provide a WebServer. Until now I have been using Vert.x 3.3.3 and the application was running well. Now I'm trying to use versions 3.4.0 and 3.4.1 and when starting the application, I've got the following error and the application can't boot:

Error occurred during initialization of boot layer
java.lang.module.FindException: java.io.IOException: Provider class moduleName = io.vertx.ext.web.handler.VirtualHostHandler-module not in module
Caused by: java.io.IOException: Provider class moduleName = io.vertx.ext.web.handler.VirtualHostHandler-module not in module

When looking at the source code of vertx-web, I can see the META-INF/services/org.codehaus.groovy.runtime.ExtensionModule file. As specified by the ServiceLoader class, such files are used in order to define services not developed as JPMS modules but running as JAR files on the classpath. I suppose the addition of this file is intentional by the Vert.x developers but I can't figure out how to be able to start SlideshowFX again.

Have you encountered such issue and were able to fix it?

Thanks

@vietj commented on Thu Mar 23 2017

Have you tried to remove the META-INF/services/org.codehaus.groovy.runtime.ExtensionModule file from the jar to see if it fixes the problem ?

I'm wondering also how this is related to the issue you are reporting. Not saying it's not related, but I don't see much the relationship right now.

@twasyl commented on Thu Mar 23 2017

I tried your suggestion and it leads me to this message now:

Error occurred during initialization of boot layer
java.lang.module.FindException: java.io.IOException: Provider class moduleName = io.vertx.ext.auth.User-module not in module
Caused by: java.io.IOException: Provider class moduleName = io.vertx.ext.auth.User-module not in module

So I removed the META-INF/services/org.codehaus.groovy.runtime.ExtensionModule file from the vertx-auth JAR and I am now able to start a server.

I don't really know how it is related to the issue as I don't understand the use of the org.codehaus.groovy.runtime.ExtensionModule files from a Vert.x point of view. Seeing this from a JDK9 POV and reading the ServiceLoader javadoc, it is mentionned the following:

Now suppose that com.example.impl.StandardCodecs is an implementation of the CodecSet service and developed as a module. In that case then the module with the service provider module will declare this in its module descriptor:

provides com.example.CodecSet with com.example.impl.StandardCodecs;

On the other hand, suppose com.example.impl.StandardCodecs is packaged in a JAR file for the class path then the JAR file will contain a file named:

META-INF/services/com.example.CodecSet

that contains the single line:

com.example.impl.StandardCodecs # Standard codecs

So if these org.codehaus.groovy.runtime.ExtensionModule files are not used in order to prepare the Vert.x project for JDK9, maybe they come in conflict with the JPMS of JDK9.

@vietj commented on Thu Mar 23 2017

thanks for investigating it.

can you provide a small reproducer ?

Vert.x uses vanilla Groovy extension modules, so I think we need to investigate Groovy extension modules and Java 9

@twasyl commented on Thu Mar 23 2017

Here is a simple reproducer (vertx-jdk9.zip) that can be imported in IDEA EAP and using a JDK 9 EA build. Trying to start the Application class will lead to the errors.
Cleaning the JARs to remove the META-INF/services folders will let the application boot.

@vietj commented on Thu Mar 23 2017

thanks, I hope it's easy to investigate :-)

@vietj commented on Fri Apr 07 2017

we should reach out the Groovy community to see if they are going to support Java 9 actually, it seems more like a Groovy issue than a Vert.x issue

@pmlopes commented on Fri Apr 07 2017

Sure, but we need some action on our side since this will block us from running on JDK9 once it's out aprox end September.

@twasyl commented on Fri Apr 07 2017

I don't know if you're interested in knowing it but it seems asciidoctorj which uses jruby underneath has similar issues as I also use it in SlideshowFX. It seems the META-INF/services folder will have a key role under JDK9.

@karianna commented on Fri Apr 07 2017

You can join OpenJDK's quality outreach programme (https://wiki.openjdk.java.net/display/quality/Quality+Outreach) to work directly with Oracle to resolve issues.

If I create a custom message codec for a given class I can send instances of that class across the event bus as expected. However, when I try to send arrays of the objects the array first gets wrapped into a JsonArray and then it's codec is used to perform the serialization. That would be OK if that implementation looked for custom codec's during transform, but instead it simply calls copy on the JsonArray and when it finds an object it doesn't understand, it throws an exception.

I understand why it is working the way it does, but it seems counter intuitive. Should I be approaching this a different way?

Hi,

I am converting JsonSlurper to vertx JsonObject it is not working for complex json.

def slurper = new JsonSlurper()
def result = slurper.parseText('some complex json')
// result is a map instance.
JsonObject json = new JsonObject(result)

When i try to send this json object over eventbus. it gives error.

java.lang.IllegalStateException: Illegal type in JsonObject: class java.math.BigDecimal
at io.vertx.core.json.Json.checkAndCopy(Json.java:120) ~[flint-lib-0.1.0.0-all.jar:?]
at io.vertx.core.json.JsonObject.copy(JsonObject.java:700) ~[flint-lib-0.1.0.0-all.jar:?]
at io.vertx.core.json.Json.checkAndCopy(Json.java:107) ~[flint-lib-0.1.0.0-all.jar:?]
at io.vertx.core.json.JsonObject.copy(JsonObject.java:700) ~[flint-lib-0.1.0.0-all.jar:?]
at io.vertx.core.json.Json.checkAndCopy(Json.java:107) ~[flint-lib-0.1.0.0-all.jar:?]
at io.vertx.core.json.JsonObject.copy(JsonObject.java:700) ~[flint-lib-0.1.0.0-all.jar:?]
at io.vertx.core.json.Json.checkAndCopy(Json.java:99) ~[flint-lib-0.1.0.0-all.jar:?]
at io.vertx.core.json.JsonObject.copy(JsonObject.java:700) ~[flint-lib-0.1.0.0-all.jar:?]
at io.vertx.core.json.Json.checkAndCopy(Json.java:99) ~[flint-lib-0.1.0.0-all.jar:?]
at io.vertx.core.json.JsonObject.copy(JsonObject.java:700) ~[flint-lib-0.1.0.0-all.jar:?]

at io.vertx.core.eventbus.impl.codecs.JsonObjectMessageCodec.transform(JsonObjectMessageCodec.java:49) ~[flint-lib-0.1.0.0-all.jar:?]

Thanks & Regards,
Abhishek

Motivation

Missing integration for vertx-sql-client in 4.x version, it's only supported in 3.x branches.

Upgrade to Groovy 2.4.14

@cazacugmihai commented on Tue Apr 11 2017

Version

• vert.x core: 3.4.1, 3.4.2-SNAPSHOT
• vert.x sql common: 3.4.1, 3.4.2-SNAPSHOT
• groovy: 2.4.10, 2.5.0-SNAPSHOT

Context

I've got this exception:

java.lang.ClassCastException: io.vertx.core.json.JsonArray cannot be cast to java.util.List
	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) ~[?:1.8.0_121]
	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374) ~[?:1.8.0_121]
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) ~[?:1.8.0_121]
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:1.8.0_121]
	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) ~[?:1.8.0_121]
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:1.8.0_121]
	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) ~[?:1.8.0_121]
	at io.vertx.groovy.ext.sql.SQLConnection_GroovyExtension.batchWithParams(SQLConnection_GroovyExtension.java:73) ~[vertx-sql-common-3.4.2-SNAPSHOT.jar:?]

and, because the groovy-all jar is present in the classpath, the groovy extension is loaded.

Is it possible to not use the Groovy extrension as long as I don't use vertx-lang-groovy?

Extra

It may be related to this issue. If true, please check every other module for this kind of situation.

@cazacugmihai commented on Wed Apr 12 2017

Is there a way to fix the mentioned error?

When the code is compiled, this method is used:

SQLConnection.batchWithParams(String sqlStatement, List<JsonArray> args, Handler<AsyncResult<List<Integer>>> handler)

but, at runtime, this one is called:

SQLConnection_GroovyExtension.batchWithParams(SQLConnection j_receiver, String sqlStatement, List<List<Object>> args, Handler<AsyncResult<List<Integer>>> handler)

and the code fails on this line (from the above method):

io.vertx.core.impl.ConversionHelper.toJsonArray(elt)

because there is a JsonArray in the args param and ConversionHelper.toJsonArray accepts a List<Object> param.

@cazacugmihai commented on Wed Apr 12 2017

@Grapes([
	@Grab("io.vertx:vertx-core:3.4.1"),
	@Grab("io.vertx:vertx-jdbc-client:3.4.1"),
	@Grab("com.h2database:h2:1.4.194")
])
import groovy.transform.CompileStatic
import io.vertx.core.AsyncResult
import io.vertx.core.Handler
import io.vertx.core.Future
import io.vertx.core.Vertx
import io.vertx.core.json.JsonArray
import io.vertx.core.json.JsonObject
import io.vertx.ext.jdbc.JDBCClient
import io.vertx.ext.sql.SQLConnection

import static io.vertx.core.Future.future

//@CompileStatic
void reproduce() {
	Vertx vertx = Vertx.vertx()
	JDBCClient client = JDBCClient.createNonShared(
		vertx,
		new JsonObject([
			url        : 'jdbc:h2:mem:people?shutdown=true',
			driverclass: 'org.h2.Driver'
		] as Map<String, Object>)
	)

	println 'Step #1: Obtaining connection...'
	client.getConnection { AsyncResult<SQLConnection> arConn ->
		println 'Step #1: Obtaining connection...' + arConn.succeeded()
		SQLConnection conn = arConn.result()

		println 'Step #2: Removing table...'
		conn.execute('drop table if exists person') { AsyncResult<Void> arDrop ->
			println 'Step #2: Removing table...' + arDrop.succeeded()

			println 'Step #3: Creating table...'
			conn.execute('create table person (name varchar(100))') { AsyncResult<Void> arCreate ->
				println 'Step #3: Creating table...' + arCreate.succeeded()

				println 'Step #4: Inserting data...'

				String sql = 'insert into person (name) values (?)'
				List<JsonArray> args = ['Jane', 'John'].collect { new JsonArray([it]) }

				Future<List<Integer>> f = future()
				
				conn.batchWithParams(sql, args, f.completer())

				f.completer().handle({ AsyncResult<List<Integer>> arInsert ->
					println 'Step #4: Inserting data...' + arInsert.succeeded()
					
					println arInsert.result()
				} as Handler <AsyncResult<List<Integer>>>)
			}
		}
	}
}

reproduce()

@cazacugmihai commented on Wed Apr 12 2017

Console:

Step #1: Obtaining connection...true
Step #2: Removing table...
Step #2: Removing table...true
Step #3: Creating table...
Step #3: Creating table...true
Step #4: Inserting data...
Apr 12, 2017 1:37:46 PM io.vertx.core.impl.ContextImpl
SEVERE: Unhandled exception
java.lang.ClassCastException: io.vertx.core.json.JsonArray cannot be cast to java.util.List
	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
	at io.vertx.groovy.ext.sql.SQLConnection_GroovyExtension.batchWithParams(SQLConnection_GroovyExtension.java:73)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:54)
	at org.codehaus.groovy.runtime.metaclass.NewInstanceMetaMethod.invoke(NewInstanceMetaMethod.java:56)
	at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:274)
	at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:141)
	at test$_reproduce_closure1$_closure2$_closure3.doCall(test.groovy:49)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1027)
	at groovy.lang.Closure.call(Closure.java:414)
	at org.codehaus.groovy.runtime.ConvertedClosure.invokeCustom(ConvertedClosure.java:54)
	at org.codehaus.groovy.runtime.ConversionHandler.invoke(ConversionHandler.java:124)
	at com.sun.proxy.$Proxy8.handle(Unknown Source)
	at io.vertx.core.impl.FutureImpl.checkCallHandler(FutureImpl.java:188)
	at io.vertx.core.impl.FutureImpl.setHandler(FutureImpl.java:100)
	at io.vertx.core.impl.ContextImpl.lambda$null$0(ContextImpl.java:287)
	at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:337)
	at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
	at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:403)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:445)
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
	at java.lang.Thread.run(Thread.java:745)

@cazacugmihai commented on Wed Apr 12 2017

It seems that the error was thrown when using groovy 2.5.0-SNAPSHOT. With 2.4.10 everything is fine. Thanks @vietj for your help!

@cazacugmihai commented on Wed Apr 12 2017

I was wrong. I don't know why it was working a few hours ago. The error is still reproduced using also groovy 2.4.10.

@cazacugmihai commented on Wed Apr 12 2017

Can someone (from DEV team) confirm that is able to reproduce the issue, please? Should I give more info, maybe? If so, what else do you need?

Thanks!

The last line in code down below throws NoSuchMethodException

def json = getJsonObject()

json.getString( 'id' ) // works fine
json[ 'id' ] // works fine
json.id // throws NoSuchMethodException

In Vert.x 3.x it used to work.

I should be possible to use the dot-notation for JsonObjects in Groovy.

See also SO-questrion for details

The Exception:

groovy.lang.MissingMethodException: No signature of method: io.vertx.groovy.core.Future.succeeded() is applicable for argument types: () values: []
    at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:58)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:54)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:117)
    at de.thokari.vertx.registration.registration$_run_closure3$_closure12.doCall(registration.groovy:74)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
    at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1019)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:42)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
    at de.thokari.vertx.registration.registration$_comparePasswordAndGetPermissions_closure6$_closure16.doCall(registration.groovy:146)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DngMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
    at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1019)
    at groovy.lang.Closure.call(Closure.java:426)
    at org.codehaus.groovy.runtime.ConvertedClosure.invokeCustom(ConvertedClosure.java:53)
    at org.codehaus.groovy.runtime.ConversionHandler.invoke(ConversionHandler.java:105)
    at com.sun.proxy.$Proxy13.handle(Unknown Source)
    at io.vertx.groovy.ext.sql.SQLConnection$2.handle(SQLConnection.groovy:94)
    at io.vertx.groovy.ext.sql.SQLConnection$2.handle(SQLConnection.groovy)
    at io.vertx.core.impl.FutureImpl.checkCallHandler(FutureImpl.java:135)
    at io.vertx.core.impl.FutureImpl.setHandler(FutureImpl.java:100)
    at io.vertx.core.impl.ContextImpl.lambda$null$14(ContextImpl.java:305)
    at io.vertx.core.impl.ContextImpl$$Lambda$26/1044635281.handle(Unknown Source)
    at io.vertx.core.impl.ContextImpl.lambda$wrapTask$16(ContextImpl.java:335)
    at io.vertx.core.impl.ContextImpl$$Lambda$27/983610311.run(Unknown Source)
    at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
    at java.lang.Thread.run(Thread.java:745)

The relevant code:

cb(io.vertx.groovy.core.Future.failedFuture('Credentials do not match'))

This however works:

vertx.executeBlocking({ future ->
    future.fail('Credentials do not match')
}, { res ->
    cb(res)
})

It works when dealing with an io.vertx.core.Future, but not io.vertx.groovy.core.Future.

• Update parent pom
• Update dependencies to latest
• Update plugins to latest

@Test
public void fromJsonObject() throws Exception {
    JsonObject testObj = new JsonObject()
                                .put("metrics", (String)null);

    try {
        Object result = ConversionHelper.fromJsonObject(testObj);
    } catch (NullPointerException npe) {
        fail("Should not throw NullPointerException");
    }
}

I noticed this when I try to get the response body from a Message reply in the form of:

vertx.eventBus().send(addr,body,{ res ->
    if (res.succeeded()) {
         def body = res.result().body()   // NPE thrown here
    }
}

Hopefully the fix will be just as easy as #42.

Thanks,

Deven

Fixed by: aab346f

Your project, vert-x3/vertx-lang-groovy, depends on the outdated library FastClasspathScanner in the following source files:

• src/main/java/io/vertx/lang/groovy/VertxExtensionMethodBoostrap.java
• pom.xml

FastClasspathScanner has been significantly reworked since the version your code depends upon:

• a significant number of bugs have been fixed
• some nontrivial API changes have been made to simplify and unify the API
• FastClasspathScanner has been renamed to ClassGraph: https://github.com/classgraph/classgraph

ClassGraph is a significantly more robust library than FastClasspathScanner, and is more future-proof. All future development work will be focused on ClassGraph, and FastClasspathScanner will see no future development.

Please consider porting your code over to the new ClassGraph API, particularly if your project is in production or has downstream dependencies:

• https://github.com/classgraph/classgraph/wiki/Porting-FastClasspathScanner-code-to-ClassGraph
• https://github.com/classgraph/classgraph/wiki/Code-examples
• https://github.com/classgraph/classgraph/wiki/ClassGraph-API

Feel free to close this bug report if this code is no longer in use. (You were sent this bug report because your project depends upon FastClasspathScanner, and has been starred by 12 users. Apologies if this bug report is not helpful.)

Version

3.9.3

Context

Promise p = Promise.promise()
println p.future() == p.future() // prints false when debugging

Instances are not equal when running code in the Debug mode under Intellij IDEA.

Steps to reproduce

1. Code: https://github.com/ptomaszek/vertx-groovy
2. Run MainGroovy -> observe expected output true
3. Run in Debug mode MainGroovy -> observe unexpected output false

Extra

• IntelliJ IDEA 2020.2.3
• Code works as expected with 4.0.0-milestone5
• There's MainJava for a reference showing that plain Java works as expected with both Run and Debug
• JVM:

   java version "1.8.0_201"
   Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
   Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)
  

my Groovy code:

class GatewayVerticle extends AbstractVerticle {
  DeliveryOptions HOP_OPTS = new DeliveryOptions( sendTimeout:5000 )
  @Override
  void start() throws Exception {    
    vertx.eventBus().send( 'addr', [ aa:42 ], HOP_OPTS ){ println it }
  }
}

fails with

java.lang.IllegalArgumentException: No message codec for type: class java.util.LinkedHashMap at io.vertx.core.eventbus.impl.CodecManager.lookupCodec(CodecManager.java:101) at io.vertx.core.eventbus.impl.clustered.ClusteredEventBus.createMessage(ClusteredEventBus.java:180) at io.vertx.core.eventbus.impl.EventBusImpl.send(EventBusImpl.java:111)

If I ommit the setting sendTimeout it fails with the same exception.

The following line works just fine:
vertx.eventBus().send( 'gateway', [ aa:42 ] ){ doSomeStuff() }

If I convert the map into JsonObject, it also works:
vertx.eventBus().send( 'addr', new JsonObject( aa:42 ), HOP_OPTS ){}

See https://stackoverflow.com/questions/55415485/vertx-3-6-3-eventbus-send-with-deliveryoptions-fail for further discuccsion

I got a problem here because I am using a non-default MessageCodec that works only with Maps, but currently I had to use this sending message through eventBus.delegate, because at send method it uses InternalHelper.unwrapObject to unwrap my maps and transform to JsonObject.

Would not be a good thing if we could decide if we have to unwrap or not our messages?

Thanks in advance

Apache Groovy 2.5 was recently released.

Consider to upgrade at the appropriate time.

Groovy 2.5 requires JDK8+ to build and JDK7 is the minimum version of the JRE that it supports.

In Vert.x 3.x, the Groovy generation has become more lightweight based on extension methods. Therefore Vert.x for Groovy currently uses Vert.x APIs directly. In Vert.x 4 we remove any code generation in favour of using instead Groovy operators to achieve the same.

Fixed by: b14b75e

• org.codehaus.groovy 3.0.5
• gmavenplus-plugin 1.9.1

It was introduced in 3.4.x to help migration from Groovy written with previous versions.

Vert.x 3.5.0 assumes people have migrated their API.

Does the next piece code represent an issue for you?

@Grapes([
    @Grab(group='io.vertx', module='vertx-core', version='3.4.1'),    
    @Grab(group='io.vertx', module='vertx-lang-groovy', version='3.4.1')
])
import io.vertx.core.*
import io.vertx.core.json.*

JsonObject jo1 = new JsonObject()

assert "jo1 is a ${jo1?.class?.name}" == "jo1 is a io.vertx.core.json.JsonObject"

assert (jo1 as Map) instanceof Map


JsonObject jo2 = new JsonObject([:])

assert "jo2 is a ${jo2?.class?.name}" == "jo2 is a io.vertx.core.json.JsonObject"

assert (jo2 as Map) instanceof Map


JsonObject jo3 = new JsonObject([a:1])

assert "jo3 is a ${jo2?.class?.name}" == "jo3 is a io.vertx.core.json.JsonObject"

try {
    println (jo3 as Map)
} catch (Exception e) {
    assert true:"An exception has been thrown"
}

I've created a custom message codec for org.bson.Document and registered it as a global codec. However, when I attempt to send an instance of Document over the event bus is mysteriously gets treated like a JsonObject instead. It turns out that the culprit here is InternalHelper.unwrapObject. This method is called in the Groovy adaptation of the event bus and since Document implements the Map interface it decides to be helpful and put the map in a JsonObject.

Fixing this is likely to require context which the helper routine doesn't have so I think the fix will involve changing the groovy event bus cover to know when to apply the method and when not to (based on whether the object has a custom codec or not).

Found via the Mongo DB client.

The fix that was intended to address this has been reverted so I'm recreating this in the correct project.

The language bindings are intended to present JSON documents in their "native" form to each language. In the Groovy binding (and perhaps others) this is working for the root object, but not for any nested objects and/or arrays. These are instead presented as JsonObject and/or JsonArray instances.

See the following thread for more info https://groups.google.com/forum/#!topic/vertx-dev/StuQ8pv3kWQ.

This gist demonstrates the issue -- https://gist.github.com/sfitts/73d4a2e2229466f5ccd3

For a strange reason (the topic of this issue), the generated groovydoc is empty when built from stack.

The generated groovy doc has some misspelled urls containing . instead of \.

that's currently messy (the first I wrote) and it could be more compact (i.e the handler/asyncresult should use the return type conversion).

In Vert.x 4 the Groovy documentation will not contain anymore code generated documentation.

Instead we might provide a few specific examples for specific Vert.x documentations when it is needed and the Vert.x core documentation is now left stand alone. The Groovy documentation covers Groovy specifics such as deploying a Verticle or the Groovy extension for Vert.x types such as JSON or data objects.

readFile seems to be creating, and not getting rid of, event loops.

java 12073 grant 4802w FIFO 0,10 0t0 855722 pipe
java 12073 grant 4803u a_inode 0,11 0 7132 [eventpoll]
java 12073 grant 4804r FIFO 0,10 0t0 855723 pipe
java 12073 grant 4805w FIFO 0,10 0t0 855723 pipe
java 12073 grant 4806u a_inode 0,11 0 7132 [eventpoll]
java 12073 grant 4807r FIFO 0,10 0t0 855724 pipe
java 12073 grant 4808w FIFO 0,10 0t0 855724 pipe
java 12073 grant 4809u a_inode 0,11 0 7132 [eventpoll]
java 12073 grant 4810r FIFO 0,10 0t0 855725 pipe
java 12073 grant 4811w FIFO 0,10 0t0 855725 pipe
java 12073 grant 4812u a_inode 0,11 0 7132 [eventpoll]
java 12073 grant 4813r FIFO 0,10 0t0 855726 pipe
java 12073 grant 4814w FIFO 0,10 0t0 855726 pipe
java 12073 grant 4815u a_inode 0,11 0 7132 [eventpoll]
java 12073 grant 4816r FIFO 0,10 0t0 855727 pipe
java 12073 grant 4817w FIFO 0,10 0t0 855727 pipe
java 12073 grant 4818u a_inode 0,11 0 7132 [eventpoll]
java 12073 grant 4819r FIFO 0,10 0t0 855728 pipe
java 12073 grant 4820w FIFO 0,10 0t0 855728 pipe
java 12073 grant 4821u a_inode 0,11 0 7132 [eventpoll]
java 12073 grant 4822r FIFO 0,10 0t0 855729 pipe
java 12073 grant 4823w FIFO 0,10 0t0 855729 pipe
java 12073 grant 4824u a_inode 0,11 0 7132 [eventpoll]
java 12073 grant 4825r FIFO 0,10 0t0 855730 pipe
java 12073 grant 4826w FIFO 0,10 0t0 855730 pipe
java 12073 grant 4827u a_inode 0,11 0 7132 [eventpoll]
java 12073 grant 4828r FIFO 0,10 0t0 855731 pipe
java 12073 grant 4829w FIFO 0,10 0t0 855731 pipe
java 12073 grant 4830u a_inode 0,11 0 7132 [eventpoll]
java 12073 grant 4831r FIFO 0,10 0t0 855732 pipe
java 12073 grant 4832w FIFO 0,10 0t0 855732 pipe
java 12073 grant 4833u a_inode 0,11 0 7132 [eventpoll]

grant@nighthawk ~/sandbox/vertx/VXExperiments/eb_fio (git)-[master] % bash runTest.sh
vx running as 12379
*********OPEN FILES FOR PROCESS: 12379: 23
*********OPEN FILES FOR PROCESS: 12379: 349
|database.groovy starting|

Succeeded in deploying verticle
OPEN FILES FOR PROCESS: 12379: 356
db.groovy: resp from readJson world.json : {"hello":"goodbye"}
***OPEN FILES FOR PROCESS: 12379: 500
db.groovy: resp from readJson world.json : {"hello":"goodbye"}
***OPEN FILES FOR PROCESS: 12379: 644
db.groovy: resp from readJson world.json : {"hello":"goodbye"}
***OPEN FILES FOR PROCESS: 12379: 788
db.groovy: resp from readJson world.json : {"hello":"goodbye"}
db.groovy: resp from readJson world.json : {"hello":"goodbye"}
***OPEN FILES FOR PROCESS: 12379: 932
db.groovy: resp from readJson world.json : {"hello":"goodbye"}
*******OPEN FILES FOR PROCESS: 12379: 1220
db.groovy: resp from readJson world.json : {"hello":"goodbye"}
*********OPEN FILES FOR PROCESS: 12379: 1364
db.groovy: resp from readJson world.json : {"hello":"goodbye"}

This will eventually burn through my linux ulimit for allowed file handles

https://groups.google.com/forum/#!topic/vertx/FYRz1d2QJ50
https://github.com/cinterloper/VXExperiments/tree/master/eb_fio

• delegate disappears

To make Vert.x usage more idiomatic in Vert.x 4, we introduce a few Groovy operators for JSON and data object classes.

• JsonObject subscript operators (obj["key"]=3 / obj["key"])
• JsonArray subscript operator (array[3])
• JsonArray leftshift operator (array << "foo")
• map cast operator to data object (map as MyDataObject)
• map cast operator to json object (map as JsonObject)

https://github.com/vert-x3/vertx-lang-groovy/blob/master/src/main/resources/vertx-groovy/template/groovy.templ#L33

Remove the usage of groovy-all jar in favor of groovy/groovy-console dependencies. Since 2.5, the groovy-all dependency is actually a dependency of type pom, depending on individual jars (https://twitter.com/daniel_sun/status/1003474637697642496). It also conflicts with the stack manager convergence checker.