Using jruby-complete as dependency has some side effects, mainly that it is a shadow-jar and includes e.g. joda-time directly instead of as a dependency.
It would be better to use

<dependency>
    <groupId>org.jruby</groupId>
    <artifactId>jruby</artifactId>
    <version>9.1.7.0</version>
</dependency>

instead, to allow dependency resolution to manage the dependencies.

This line appears to hard-code JRuby compatibility to 1.9:
https://github.com/vert-x3/vertx-lang-ruby/blob/master/src/main/java/io/vertx/lang/ruby/ContainerHolder.java#L66

I would have expected that Vert.x would respect the JRUBY_OPTS environment variable, which is mechanism that JRuby itself uses to set compatibility.

If Vert.x does indeed need to set a compatibility version on the ScriptingContainer, maybe it could be done based on the value of JRUBY_OPTS.

So, when JRUBY_OPTS is "--2.0", cont.setCompatVersion(CompatVersion.RUBY2_0). And when JRUBY_OPTS is "--1.0", cont.setCompatVersion(CompatVersion.RUBY1_9).

I don't understand the internals of the JRuby language bindings, but it would seem that the CompatVersion thing would present a problem for moving beyond "legacy" versions of JRuby. The current JRuby release (JRuby 9.0.0.0) has no compatibility version setting at all. It's only Ruby 2.2.2.

PS: I wish I could help more, and submit a pull request. I haven't touched Java in many years and have no familiarity with the ecosystem, tools, build, etc. I wish I did. I'd love to be able to help the project more constructively.

Thanks,
Scott

Copied from groups discussion thread:

In early 2015 my company ported a large REST API platform from Sinatra/Rails to vert.x 2 (and subsequently to vert.x 3 earlier this year).

Our initial 2.x port had everything running in a single verticle. Later, we started splitting some functionality out into separate verticles, and noticed that for each verticle, we had to have a ruby 'require' statement on any ruby file used in the verticle (that was not needed in the Sinatra/Rails monolith). We assumed this was due the vert.x 2 "verticle isolation", where each verticle was loaded with a separate class loader.

After porting to vert.x 3, we expected that to change (i.e., expected the following to work):

1. main verticle has a require for api.rb
2. api.rb executes many other require statements, basically loading all shared code, initializing routes, etc.
3. subsequent verticles loaded after main verticle would not need to 'require' anything already loaded by main verticle

If possible, we would like to have a configuration option that would allow us to deploy verticles in this way (with the understanding that we will need to explicitly manage the verticle deployment order).

Fixed by: 49435f6

see vert-x3/issues#55

Per this discussion thread, ruby predicate method names were changed in version 3.4 to only end with a question mark if the method name begins with "is".

However, it is definitely idiomatic in ruby that all predicate method names should end with a question mark. This is true for core ruby (e.g., Object), the standard library, and 3rd party libraries/gems.

Please restore the idiomatic behavior in version 3.5.

When running a ruby script as a verticle it would appear that vertx_stop does not block. I am not sure if this is the intent.

I have gotten around the issue utilize the vertx_stop_async method and completing the future after the async block completes.

Clarification here would be helpful.

This allows to use vertx future with Ruby:

future = vertx.create_net_client.connect(port, address)
future.set_handler { |err,res| ... }
...

Currently the code generator uses MVEL templating and we should instead use plain Java code like we did in other projects.

Example from https://vertx.io/:

$vertx.create_http_server().request_handler() { |req|
  req.response()
    .put_header("content-type", "text/plain")
    .end("Hello from Vert.x!")
}.listen(8080)

Global variables like $vertx are basically discouraged and deprecated (https://github.com/rubocop-hq/ruby-style-guide#instance-vars).
Global functionality is idiomatically stored in Constants like Vertx or VertX.

Using () after a method call is not idiomatic Ruby (https://github.com/rubocop-hq/ruby-style-guide#method-calls-with-no-arguments).

With that, the code looks like this:

VertX.create_http_server.request_handler { |req|
  req.response
    .put_header("content-type", "text/plain")
    .end("Hello from Vert.x!")
}.listen(8080)

Which already feels much closer to idiomatic Ruby code.

Right now, all Ruby Verticles use the same classloading environment inherited from the container creation. This configuration is created by the first verticle deployment. So this does not support isolation groups and extra classpath entry.

Unfortunately, to support these, we would need to create a set of container, each one having its own configuration. We can introduce a Map<k, ScriptingContainer> where k is computed from the deployment classloader.

We would also need a way to stop container when the container is not used anymore (after undeployment).

Hi,

Im not sure if I do this correct. I cannot get error handling to work in my app. All specific Exceptions are replaced by RuntimeExceptions, which in most cases don't provide useful details anymore like proper call stacks.

I think the reason is here: http://vertx.io/docs/yardoc/VertxWeb/RoutingContext.html#fail-instance_method

Every Exception passed to "fail" is converted into a Throwable via Vertx::Util::Utils.to_throwable.
This essentially creates a Proc which re-raises the exception and catches it again (utils.rb) (Helper.java) . IMO this would make sense if I pass a string to the "fail" method. But when I pass an exception it should not do this.

This makes proper exception handling nearly impossible.
Sorry, I'm unable to provide a Pull Request. I dont know where to start. :/ Is this ruby wrapper code somehow generated?

Im running a vertx 3.3.2 app on JRuby 9.1

Best
-Stephan

Currently it uses the provided scope which does not contains the verticle factory and thus executing vertx-lang-ruby verticle does not work.

If a ruby verticle requires a ruby file that is packaged in a jar file from the "-cp" option, it does not find the file.

This behavior is due to the update to JRuby 9.

• gem-maven-plugin 1.1.5
• jruby 9.2.4.0

DataObject support the io.vertx.core.buffer.Buffer type.

The conversion of a JavaScript object should convert the buffers to a B64 encoded string before constructing the data object.

utils.to_object should return object.j_del if possible, instead of object

For example, trying to send a Buffer over the event bus ends with:

GRAVE: io.vertx.core.impl.ContextImpl - Unhandled exception 
java.lang.IllegalArgumentException: No message codec for type: class org.jruby.RubyObjectVar0
	at io.vertx.core.eventbus.impl.CodecManager.lookupCodec(io/vertx/core/eventbus/impl/CodecManager.java:90)
	at io.vertx.core.eventbus.impl.EventBusImpl.createMessage(io/vertx/core/eventbus/impl/EventBusImpl.java:229)
	at io.vertx.core.eventbus.impl.EventBusImpl.send(io/vertx/core/eventbus/impl/EventBusImpl.java:110)
	at io.vertx.core.eventbus.impl.EventBusImpl.send(io/vertx/core/eventbus/impl/EventBusImpl.java:95)
	at java.lang.reflect.Method.invoke(java/lang/reflect/Method.java:498)
	at org.jruby.javasupport.JavaMethod.invokeDirectWithExceptionHandling(org/jruby/javasupport/JavaMethod.java:468)
	at org.jruby.javasupport.JavaMethod.invokeDirect(org/jruby/javasupport/JavaMethod.java:326)
	at org.jruby.RubyMethod.call(org/jruby/RubyMethod.java:119)
	at org.jruby.RubyMethod$INVOKER$i$call.call(org/jruby/RubyMethod$INVOKER$i$call.gen)
	at RUBY.send(uri:classloader:/vertx/event_bus.rb:62)
	at RUBY.block in testSendBuffer(uri:classloader:/event_bus_test.rb:19)
	at RUBY.block in completion_handler(uri:classloader:/vertx/message_consumer.rb:115)
	at org.jruby.RubyProc.call(org/jruby/RubyProc.java:289)
	at org.jruby.RubyProc.call(org/jruby/RubyProc.java:246)
	at org.jruby.javasupport.Java$ProcToInterface.callProc(org/jruby/javasupport/Java.java:1112)
	at org.jruby.javasupport.Java$ProcToInterface.access$300(org/jruby/javasupport/Java.java:1089)
	at org.jruby.javasupport.Java$ProcToInterface$ConcreteMethod.call(org/jruby/javasupport/Java.java:1150)
	at io.vertx.core.eventbus.impl.HandlerRegistration.lambda$completionHandler$1(io/vertx/core/eventbus/impl/HandlerRegistration.java:97)
	at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(io/vertx/core/impl/ContextImpl.java:344)
	at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(io/netty/util/concurrent/AbstractEventExecutor.java:163)
	at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(io/netty/util/concurrent/SingleThreadEventExecutor.java:403)
	at io.netty.channel.nio.NioEventLoop.run(io/netty/channel/nio/NioEventLoop.java:445)
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(io/netty/util/concurrent/SingleThreadEventExecutor.java:858)
	at java.lang.Thread.run(java/lang/Thread.java:748)

This module is pruned in Vert.x 4, there is no replacement.