vert-x / mod-lang-groovy Goto Github PK

See eclipse-vertx/vert.x#779

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!

https://bugs.eclipse.org/bugs/show_bug.cgi?id=417705

eclipse-vertx/vert.x@ea8b3d0#diff-584e0ff4c0448578612a911d9202355eR241

eclipse-vertx/vert.x@9d672ed

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

eclipse-vertx/vert.x@8a00f2f

Thanks!

... and also expose uri() method in ServerWebSocket

eclipse-vertx/vert.x@d207b6a

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.

See
eclipse-vertx/vert.x@633ccaa

See:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=423447
eclipse-vertx/vert.x#786

See also:

http://vertx.io/core_manual_java.html#user-datagram-protocol-udp
https://github.com/eclipse/vert.x/tree/master/vertx-core/src/main/java/org/vertx/java/core/datagram

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

}

this is a bad merge?

0d8bf8b

it rolled back Tim's change.

3441606

I need the lang-groovy jar for a maven compile time dependency.

The build.gradle-file creates a jar from src/main/java, but all the source resides in src/main/groovy

https://bugs.eclipse.org/bugs/show_bug.cgi?id=423812

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!

eclipse-vertx/vert.x@f9afbdb

Thanks!

eclipse-vertx/vert.x@cbbd951

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:

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.