vert-x / mod-lang-groovy Goto Github PK
View Code? Open in Web Editor NEWVert.x 2.x is deprecated - use instead
Home Page: https://github.com/vert-x3/vertx-lang-groovy
License: Other
Vert.x 2.x is deprecated - use instead
Home Page: https://github.com/vert-x3/vertx-lang-groovy
License: Other
When using Jackson to convert json, GStrings yield unhelpful maps instead of strings.
[message: "Hello $name"]
Actual Result:
{
"message": {
"values": ["name"],
"strings": ["hello", ""],
"valueCount": 1
}
}
Expected Result:
{"message": "Hello Bob"}
Original Thread:
https://groups.google.com/d/msg/vertx/vP_RyujCFmw/GcZ9rjEdZrQJ
The Java eventbus now supports sends with timeout, also the Message class supports replies with timeouts.
We should expose this new functionality in the Groovy API too
If my groovy verticle (ReportAggregator) is loaded as a class, eg using "groovy:org.jclarity.jpdm.reporting.verticles.ReportAggregator" and it subclasses the Java Verticle class then it gets correctly loaded, if it subclasses the Groovy Verticle class then the error at the end of this issue occurs.
I suspect its because in this commit:
63e3ed7
you're loading the 'Verticle' class from a different class loader to the user's custom Verticle class, so the if statement on line 112 can never pass.
1170 [vert.x-eventloop-thread-3] ERROR c.j.j.r.ReportingAgentTestBase - Cannot cast object 'org.jclarity.jpdm.reporting.verticles.ReportAggregator@1f109723' with class 'org.jclarity.jpdm.reporting.verticles.ReportAggregator' to class 'org.vertx.java.platform.Verticle'
org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'org.jclarity.jpdm.reporting.verticles.ReportAggregator@1f109723' with class 'org.jclarity.jpdm.reporting.verticles.ReportAggregator' to class 'org.vertx.java.platform.Verticle'
at org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:360) ~[groovy-all-2.1.5.jar:2.1.5]
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:599) ~[groovy-all-2.1.5.jar:2.1.5]
at org.vertx.groovy.platform.impl.GroovyVerticleFactory.createVerticle(GroovyVerticleFactory.groovy:119) ~[lang-groovy-2.0.0-final.jar:na]
at org.vertx.java.platform.impl.DefaultPlatformManager$18.run(DefaultPlatformManager.java:1269) ~[vertx-platform-2.0.0-final.jar:na]
at org.vertx.java.core.impl.DefaultContext$3.run(DefaultContext.java:171) [vertx-core-2.0.0-final.jar:na]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:353) [netty-all-4.0.2.Final.jar:na]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:366) [netty-all-4.0.2.Final.jar:na]
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101) [netty-all-4.0.2.Final.jar:na]
at java.lang.Thread.run(Thread.java:722) [na:1.7.0_03]
The module version in src/test/resources/langs.properties is 2.1RC3 when surely it should be 2.1.0-final (as per the version in the gradle properties file). I think many of the tests which deploy the module are actually not testing the current codebase - I noticed this when I was trying to create a pull request to align the API for HttpClientResponse and DefaultHttpClientResponse with the equivalant Java APIs, and my code changes weren't actually being seen by the tests.
I locally (on Ubuntu 13.10) tried to fix this but then a clean test of the code fails with lots of deployment errors complaining about compilation errors involving CP1252. This is odd as it's a Windows codepage and I'm running on Linux, so not sure what's going on. However, I thought I should let you know that currently the module being tested is the 2.1RC3 release, not 2.1.0-final. I'm sure that's not what you intend.
Originally reported at https://bugs.eclipse.org/bugs/show_bug.cgi?id=432546
I tried to make a module out of the Groovy http server verticle (https://github.com/vert-x/vertx-examples/blob/master/src/raw/groovy/http/Server.groovy), with a mod.json containing :
{
"main": "Server.groovy",
"auto-redeploy": true
}
On windows 7, Oracle JDK 7u45 or 8, when I modify the content of Server.groovy, the file is locked by vertx (2.0.1.Final or 2.1.RC3) so I get an error when saving it. Weirdly enough, vertx detects something has changed, but still, the new content is not served. The lock disappears after some time, but the delay seems random. Corresponding java implem. doesn't block file updates.
Test mod at https://github.com/fbricon/bug432546
Screencast showing how bad it is : http://screencast.com/t/MySckzdFu
Please add groovy-all dependency to pom as it should describe the dependencies required to work with the jar, not the zip. Maven resolvers can then automatically pull down the relevant groovy-all jar when compiling against the lang-groovy.jar.
Whoever is handling the scala module should also consider this.
The example [http://vertx.io/core_manual_groovy.html#random-access-writes] does not work, always leaves an empty file.
The problem is her [https://github.com/vert-x/mod-lang-groovy/blob/master/src/main/groovy/org/vertx/groovy/core/file/AsyncFile.groovy#L73]
It is sending a 'org.vertx.groovy.core.buffer.Buffer' instead of a 'org.vertx.java.core.buffer.Buffer' with a [Buffer].toJavaBuffer()
Hi there,
I struggled a bit these days with DefaultHttpClient implementation in Groovy.
With the default Proxy.groovy example https://github.com/vert-x/vertx-examples/blob/master/src/raw/groovy/proxy/Proxy.groovy
def client = vertx.createHttpClient(host:"hostname", port:80)
client.setKeepAlive(false)
println "keep alive ? ${client.isKeepAlive()}"
=> keep alive ? true
Problem hides here : https://github.com/vert-x/mod-lang-groovy/blob/master/src/main/groovy/org/vertx/groovy/core/http/impl/DefaultHttpClient.groovy
line 66 :
@OverRide
HttpClient setKeepAlive(boolean keepAlive) {
jClient.setTCPKeepAlive(keepAlive)
this
}
which should probably be :
@OverRide
HttpClient setKeepAlive(boolean keepAlive) {
jClient.setKeepAlive(keepAlive)
this
}
Since there's also a setTCPKeepAliveMethod.
If anyone struggles with this problem while waiting for a patch, writing :
def client = vertx.createHttpClient(host:"hostname", port:80)
client.metaClass.setKeepAlive { newKeepAlive ->
this.jClient.setKeepAlive(newKeepAlive)
return this
}
fixed the issue for me.
Feel free to ask any question if you don't understand.
Hope this helps
v2.2.1?
thx!
Thanks!
Currently the convertMessage method in EventBus.groovy only converts a Map. It should also convert from List -> JsonArray.
... on HttpClient and HttpServer by exposing the getter/setter for MaxWebSocketFrameSize
Thanks!
... and also expose uri() method in ServerWebSocket
Sporadically starting a Groovy-Verticle fails because classloaders of the compiled script and of the surrounding GroovyVerticleFactory are different. This leads to two different versions of groovy.lang.Script.
When casting to Script, this fails.
To prevent this, just don't cast to Script - this is not strictly needed in Groovy.
MarkupTemplateEngine has a bug in groovy 2.3.3 where the properties are not propagated properly making the template system fairly unusable.
Example code used from mrhaki:
http://mrhaki.blogspot.co.uk/2014/08/groovy-goodness-using-layouts-with.html
Using his main.tpl, this is the routeMatcher in server.groovy:
routeMatcher.getWithRegEx('.*') { req ->
// Create engine with configuration.
TemplateConfiguration config = new TemplateConfiguration(autoIndent: true, autoNewLine: true)
MarkupTemplateEngine engine = new MarkupTemplateEngine(config)
// Create template with layout reference
// and values for layout variables.
Template template = engine.createTemplate('''\
layout 'layouts/main.tpl', true,
pageTitle: 'Welcome',
mainContents: contents {
h1 'Home'
},
actions: contents {
ul(class: 'actions') {
['Home', 'About'].each { li it }
}
}
''')
// Render output for template.
Writer writer = new StringWriter()
Writable output = template.make([pubDate: Date.parse('yyyyMMdd', '20140801')])
output.writeTo(writer)
String result = writer.toString()
req.response.end result
}
The build.gradle-file creates a jar from src/main/java, but all the source resides in src/main/groovy
mod-lang-groovy-2.1.0-final was released with groovy 2.2.1. can we please have a release with groovy 2.3+ please?
Thank you!
Thanks!
Thanks!
When creating Verticles using Groovy as a language, it would be nice to be able to use the whole power of Groovy.
One its major functionalities is easy DSL creation.
Therefore two main features are used:
ScriptBaseClasses and ASTTransformation
To enable this two features, one has to configure the GroovyCompiler via CompilationConfiguration.
Currently vertx does not take care of CompilationConfiguration when compiling GroovyScripts. My upcoming pullrequest adds this feature:
Configuration of CompilationConfiguration can be done by a file in classpath called compilerConfiguration.properties in a format described in JavaDoc of org.codehaus.groovy.control.CompilerConfiguration.
This filename can be configured by an environment variable called VERTX_GROOVY_COMPILER_CONFIGURATION
With a properties-file you can not add CompilationCustomizers like automatic imports or ASTTransformation usage, as adding CompilationCustomizers can only be done programmatically,
Therefore you can use a ConfigSlurper-Script instead of a .properties file and add
a closure with the key 'customizer' that gets the preconfigured
CompilerConfiguration as argument and returns the modified instance to use.
To enable this feature filename in VERTX_GROOVY_COMPILER_CONFIGURATION has to end with .groovy
Groovy class loader won't load JDBC drivers. See https://groups.google.com/forum/#!topic/vertx/djXxGfOClt0.
Here's some sample code to reproduce error:
https://gist.github.com/jpokrzyk/8109151
Seems like this one is beyond my skill level to fix but if you don't get to it in a few days I'll take a look.
When attempting to run a callback on a vertx context, i.e.
final Closure respond = { Map rep -> vertx.currentContext().runOnContext { req.reply(rep) } }
final Closure callback = req.replyAddress() ? respond : null
The following exception is produced:
Exception in thread "MongoDB 57378<--localhost/127.0.0.1:27017" java.lang.IllegalAccessError: org/vertx/groovy/core/Vertx$Context
at com.zdavep.mongo.Handler$_closure1_closure2.doCall(Handler.groovy:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:909)
at groovy.lang.Closure.call(Closure.java:423)
at groovy.lang.Closure.call(Closure.java:439)
at com.zdavep.mongo.actions.Find$_exec_closure1.doCall(Find.groovy:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:909)
at groovy.lang.Closure.call(Closure.java:423)
at org.codehaus.groovy.runtime.ConvertedMap.invokeCustom(ConvertedMap.java:50)
at org.codehaus.groovy.runtime.ConversionHandler.invoke(ConversionHandler.java:81)
at com.sun.proxy.$Proxy11.callback(Unknown Source)
at com.allanbank.mongodb.client.AbstractReplyCallback.handle(AbstractReplyCallback.java:82)
at com.allanbank.mongodb.client.QueryCallback.trigger(QueryCallback.java:137)
at com.allanbank.mongodb.client.QueryCallback.handle(QueryCallback.java:129)
at com.allanbank.mongodb.client.AbstractValidatingReplyCallback.callback(AbstractValidatingReplyCallback.java:72)
at com.allanbank.mongodb.client.AbstractValidatingReplyCallback.callback(AbstractValidatingReplyCallback.java:33)
at com.allanbank.mongodb.connection.message.ReplyHandler.reply(ReplyHandler.java:77)
at com.allanbank.mongodb.connection.socket.SocketConnection.reply(SocketConnection.java:560)
at com.allanbank.mongodb.connection.socket.SocketConnection$ReceiveRunnable.receiveOne(SocketConnection.java:735)
at com.allanbank.mongodb.connection.socket.SocketConnection$ReceiveRunnable.run(SocketConnection.java:683)
at java.lang.Thread.run(Thread.java:744)
Please give "public" access for "org.vertx.groovy.core.http.*" constructors in order to be extended if someone wishes.
Ex: I want to extend "org.vertx.groovy.core.http.RouteMatcher" but I cannot create a "org.vertx.groovy.core.http.HttpServerRequest" (new HttpServerRequest(jRequest) in wrapHandler method) because of it's protected access.
Thanks!
If a groovy verticle tries to deploy multiple instances of a module or verticle, for example:
container.deployVerticle("server.groovy", 4);
vertx returns:
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
The solution is to deploy the verticles or modules and pass a config, even if its empty, i. e.:
container.deployVerticle("server.groovy", new HashMap(), 4);
This workaround was suggested by Tim Fox in this vert.x google group post, which discusses the problem.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.