On my windows 7 box, with vertx version 2,1, i tried to run the module using the following command

vertx runmod com.github.j2rohttp-event-bus-bridge1.0.0 -conf conf.json -cluster

It then downloads the modules, and it is able to successfully start. Then from another console i issue the curl command to try and talk to the bridge i.e.
curl -X POST -d @test.json http://localhost:8080/eventbus/send --header "Content-Type:application/json" and the contents of test.json looks like
{
"address" : "testaddress",
"message" : "hello??",
"messageType" : "String"
}

I get an error complaining about a missing class com/hazelcast/nio/FastByteArrayInputStream (refer stacktrace below)

I checked the hazelcast jar (version 3.2.1) and find that the class FastByteArrayInputStream is not found, but present when i checked the hazelcast jar in version 2.6.9

Seems like it may be the version of vertx-mod-jersey.

Help!

Http server listening for http://localhost:8080
Succeeded in deploying module
Exception in HK2VerticleFactory
java.lang.NoClassDefFoundError: com/hazelcast/nio/FastByteArrayInputStream
at com.englishtown.vertx.jersey.impl.DefaultJerseyHandler.handle(DefaultJerseyHandler.java:124)
at com.englishtown.vertx.jersey.impl.DefaultJerseyHandler.handle(DefaultJerseyHandler.java:61)
at org.vertx.java.core.http.impl.ServerConnection.handleRequest(ServerConnection.java:190)
at org.vertx.java.core.http.impl.ServerConnection.processMessage(ServerConnection.java:301)
at org.vertx.java.core.http.impl.ServerConnection.handleMessage(ServerConnection.java:94)
at org.vertx.java.core.http.impl.DefaultHttpServer$ServerHandler.doMessageReceived(DefaultHttpServer.java:654)
at org.vertx.java.core.http.impl.DefaultHttpServer$ServerHandler.doMessageReceived(DefaultHttpServer.java:585)
at org.vertx.java.core.http.impl.VertxHttpHandler.channelRead(VertxHttpHandler.java:80)
at org.vertx.java.core.net.impl.VertxHandler.channelRead(VertxHandler.java:156)
at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:341)
at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:327)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:163)
at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:341)
at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:327)
at org.vertx.java.core.http.impl.cgbystrom.FlashPolicyHandler.channelRead(FlashPolicyHandler.java:53)
at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:341)
at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:327)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:785)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:126)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassNotFoundException: com.hazelcast.nio.FastByteArrayInputStream
at org.vertx.java.platform.impl.ModuleClassLoader.loadFromModule(ModuleClassLoader.java:127)
at org.vertx.java.platform.impl.ModuleClassLoader.loadClass(ModuleClassLoader.java:108)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 25 more

When we are not deploying artefacts to the maven central, the build should skip the artefact signing steps of the build.

Investigate possibility of extending the REST API to include a register service.

This would function much like the registerHandler() method of the Vert.x API, but would be done over HTTP.

Due to the stateless nature of HTTP, this not straightforward, as the HTTP Event Bus Bridge needs to know when a client has gone away in order to clean up resources. One approach might be to put in place some sort of heartbeat mechanism to allow the HTTP Event Bus Bridge to know that the client is still alive and well, and still has its subscriptions alive.

WADL files should be produced to define the services available on the HTTP Event Bus Bridge. This will act as additional documentation to the available REST apis, and can also be used to allow developers to auto-generate clients.

The result of this piece of work should be two WADLs:

1. A WADL that defines the incoming services (i.e. Send, Publish and Send With Reply)
2. A WADL that defines the services that a client needs to implement (i.e. the response for the Send With Reply service)

Placeholder ticket to be implemented once the final release of Vertx 2.1 is available.