What would you like to see in Vert.x 3.1?

[Tim Fox]

I would like to kick off a discussion about what features we should
include in the new V3 feature release - Vert.x 3.1.

I would like this to be primarily determined by the needs and
requirements of you, the users.

So to start off, here are some features that I think would be good to
have in v3.1:

1. vertx-sync - https://github.com/vert-x3/vertx-sync - this is the the
ability to write non blocking verticles in a synchronous way. I think
this could be a big win for usability
2. OAuth support in vertx-web
3. vertx-amqp - https://github.com/vert-x3/vertx-amqp-service - this is
a bridge between Vert.x event bus and AMQP
4. vertx-jgroups - cluster manager that uses JGroups
5. vertx-zookeeper - cluster manager that uses ZooKeeper
6. vertx-mysql-postgres (after refactoring scala code to Java)
7. Language support - vertx-lang-scala
8. Hawkular metrics support
9. Simple socket integration from non Java clients, i.e. like the
EventBusBridge but supporting straight sockets as well as websockets -
this would allow, say, a C++ client to talk on the Vert.x event bus
using a very simple JSON api.
10. mqtt server (port from V2 module)
11. STOMP server

So, now over to you... please contribute to this thread with what you
would like to see in 3.1!

[Finn Bock]

Redeploy would be nice.

regards,
Finn

[Tim Fox]

On 30/06/15 10:49, Finn Bock wrote:

Redeploy would be nice.

+1

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Terry Bleger]

HTTP2 support pretty please :D

[Terry Bleger]

Here's the reason why, there's already many clients that support HTTP2. But people still stuck on the server side. Nginx plan to support at the end of the year. I can't wait that long. If only Vertx already support it, I can make my own reverse proxy and leave Nginx for good.

[Michel Guillet]

HTTP2 +1 as well !

Michel

On 30 Jun 2015, at 13:21, Terry Bleger <terry...@gmail.com> wrote:

Here's the reason why, there's already many clients that support HTTP2. But people still stuck on the server side. Nginx plan to support at the end of the year. I can't wait that long. If only Vertx already support it, I can make my own reverse proxy and leave Nginx for good.

[Łukasz Śliwiński]

Redeploy must have +1

Would be nice to have module to manage assets in vertx-web.

* minification (js/css/less etc)

* gzip

* etag

* concatenation

Possibility to turn on/off selected functionality independently in production/development mode.

[James Strachan]

having DNS discovery of vertx nodes on kubernetes would be awesome; so folks can just automatically scale their vertx app on kubernetes (e.g. on Google's cloud, on Atomic / CoreOS, on OpenStack or OpenShift) without having to write any code or mess with configuration to explicitly list the IP addresses running Hazelcast/JGroups/ZK etc.

https://github.com/vert-x3/issues/issues/13

[Arnaud Estève]

On Tuesday, June 30, 2015 at 2:10:11 PM UTC+2, Łukasz Śliwiński wrote:

Would be nice to have module to manage assets in vertx-web.

* minification (js/css/less etc)

* gzip

* etag

* concatenation

Big +1 to this.

Regarding minification, I'm still looking for a way to design a "pipeline" functionnality in vertx-web. Which would : 

- Re-evaluate assets on the fly in dev mode

- Build assets in "pre-prod" mode

- Rely on already-built assets in production mode

Something like this.

This would mean for an end-user the ability to "register" a transformation into vertx-web.

Like : 

registerTransformer("(*).scss", "#0.css", new SASSTransformer());

Where SASSTransformer would implement an interface like this : 

SASSTransformer implements AssetsTrasnformer {

   @Override

   public AsyncResult<Buffer> transform(Buffer input) {

   }

}

I'll probably give it a try.

[Łukasz Śliwiński]

What you are describing is very similar to sbt-web -> https://github.com/sbt/sbt-web witch is used in Play Framework.

[Arnaud Estève]

Its also similar to the "assets-pipeline-plugin" in both Rails and Grails.

I guess every web framework needs it at some point. That sounds natural to me :)

[Gabriel Welsche]

HTTP2 +1 

etcd cluster manger would be nice, but I think it's not on the pipeline....

gabriel

[Julien Viet]

vertx-shell :-) https://github.com/vietj/vertx-shell

-- 
Julien Viet
www.julienviet.com

[Clement Escoffier]

* MQTT and CoApp clients (MQTT server was mentioned but not the clients).

* Something easing the service discovery

Clement

[Cosmic Interloper]

+1 to shell

Bringing mod-lang-jython back would be really cool
Jython 2.7 runs a lot of python code like nltk that was not possible before.

[Cosmic Interloper]

also +1 to sync

[Martin Beták]

MQTT, please!

[Jochen Mader]

HTTP2 

+1

2015-06-30 19:20 GMT+02:00 Martin Beták <mat...@gmail.com>:

MQTT, please!

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jochen Mader | Lead IT Consultant

codecentric AG | Elsenheimerstr. 55a | 80687 München | Deutschland
tel: +49 89 215486633 | fax: +49 89 215486699 | mobil: +49 152 51862390
www.codecentric.de | blog.codecentric.de | www.meettheexperts.de | www.more4fi.de

Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz

[Paulo Lopes]

+1 sync

* implement rfc7493 so we can handle dates (write) on json
* standardized (read) handling of dates across mongo,jdbc,etc
* async postgres port to Java
* scaffold support for web a la mean.io

[Walter Rafelsberger]

Support Python.

[Michael Scholz]

I like the kubernetes thing, and getting redeploy again would be useful.

But I need the python / updated jython / interop examples / done most of all to leverage vertx in my current production environment. 

 

[Patryk Orwat]

Maybe Scala support for service-proxy?

[jnie...@redhat.com]

+1

On Tuesday, June 30, 2015 at 7:20:00 PM UTC+2, Martin Beták wrote:

MQTT, please!

[Tomas Jelinek]

+1 on MQTT support

[Francesco Cina]

Absolutely vertx-sync!!!!!!!!!!

In addition, it would be cool to have an API based on the CompletableFutures.

[Stephane Bastian]

If I had to pick one new feature it would definitely be Vertx-sync !

[Hakucha]

+100 vertx-sync

+1 vertx-amqp 

+1 vertx-mysql-postgres (after refactoring scala code to Java) 

[Arnaud Estève]

I realized I didn't make my own Santa wish-list except the web/pipeline stuff : 

+1 : vertx-sync

+1 : scala support

[bytor99999]

Wish List. One of the cool things that Vert.x 3 brought along was making the Message types/data that you could send over the EventBus more customizable. Meaning, in Groovy when I get a result/reply/body() it is a Map instead of a JsonObject or Buffer type, so I don't have to write conversion code. However, in our API we have Message types for each use case. Say a playerInviteFriend, handSeatAct, or other mesages that have different properties. And it would be nice to have Domain object that match the message types and automatically have them instantiated from a received Message on the eventBus. We have Codec, but having to write one per API message type might take a while. Luckily in Groovy I can create a constructor that takes a Map and assign each property one by one. 

So what would be cool is a set of Annotations/Mappings you could put on a POJO that would be used to convert the Map into that Object type. It would really have to be an extension than in core Vert.x

Anyway, that is my wish.

Thanks

Mark

[Daniel PETISME]

Be more "Ops-friendly"
- Generate an archive with bin scripts  (in the spirit of what maven-appasembler does)

- Offer a default Linux service-oriented cli for fatjars (vertx-app-fat.jar start)

- generate native packaging (RPM, deb)

- afficher le texte des messages précédents -

[Levin So]

rails-like web framework

[qsys]

+100 vertx-sync
+10 simple socket integration
+10 vertx-amqp
+1 vertx-zookeper/vertx-jgroups

Language support: clojure +1000 :)



Op dinsdag 30 juni 2015 11:38:12 UTC+2 schreef Tim Fox:

[Claus Ibsen]

Hi

First of congrat about the new 3.0 release. That is an awesome release and love the direction this project is heading.

As a guy with a Camel hat, I would love to see a native vertx-camel component that allows users to easily leverage the many 150+ components that Camel providers.

We do have a simple camel-vertx component

http://camel.apache.org/vertx

But that is more the "other way around" where Camel can integrate with an external (or embedded) vertx event bus.

However it would fell more natural from just using the vertx api users could easily send or receive messages from the many Camel components

http://camel.apache.org/components

On Tuesday, June 30, 2015 at 11:38:12 AM UTC+2, Tim Fox wrote:

[James Strachan]

On 2 July 2015 at 08:15, Claus Ibsen <claus...@gmail.com> wrote:

Hi

First of congrat about the new 3.0 release. That is an awesome release and love the direction this project is heading.

As a guy with a Camel hat, I would love to see a native vertx-camel component that allows users to easily leverage the many 150+ components that Camel providers.

We do have a simple camel-vertx component

http://camel.apache.org/vertx

But that is more the "other way around" where Camel can integrate with an external (or embedded) vertx event bus.

However it would fell more natural from just using the vertx api users could easily send or receive messages from the many Camel components

http://camel.apache.org/components

I was pondering that the other day too ;). 

It'd be nice if we could expose the camel connectors in a natural way to vertx programmers; so camel endpoints looked & felt like the event bus or the usual http / socket abstractions really; then the vertx programming model can be used to talk to any protocol, transport, middleware, database, big data store, cloud service or data format and its just a case of switching the underlying endpoint; the vertx code would look pretty much the same whatever the underlying endpoint.

e.g. its pretty trivial stuff to turn any camel endpoint into a typesafe Observable from RxJava...

http://camel.apache.org/rx.html

so should be quite easy to make a seamless camel extension to Vertx / RxJava as just another source of Observables / endpoints

--

James
-------
Red Hat

Twitter: @jstrachan
Email: james.s...@gmail.com

Medium: https://medium.com/@jstrachan/
Blog: http://macstrac.blogspot.com/

fabric8: http://fabric8.io/

hawtio: http://hawt.io/

Open Source DevOps and Integration

[Clement Escoffier]

Hi,

Just to give an idea of the current requests and trends, here is a consolidated version:

https://github.com/vert-x3/wiki/wiki/vert.x-3.1-community-requests

Clement

[Tim Fox]

Interesting idea - the approach we are taking with AMQP integration is to have an eventbus-AMQP "bridge" - which basically listens locally on a set of Vert.x event bus addresses and forwards messages it receives on to AMQP, and vice versa.

Then the Vert.x user just sends messages as usual using the Vert.x event bus API to/from those addresess and now they're talking to the AMQP world.

Maybe we can do something similar with Camel? I don't know Camel very well (at all really ;) ), but if endpoints are just things you send/receive messages to/from and messages have a well defined format, then this should be possible?

[Tim Fox]

One more thing I would like to add:

Extension to the event bus API to support reliable messaging.

Now, this doesn't mean the Event bus should implement reliable message
delivery (it won't), it just means it makes it easier to use the
eventbus to bridge to over messaging protocols that *do* support
reliable messaging, e.g. AMQP.

What I'm thinking about is (say) having API support for sending delivery
acknowledgements, and sending send acknowledgements.

[Thomas Weiss]

+1 vertx-lang-python

--
Vorstandsvorsitzender/Chairman of the board of management:
Gerd-Lothar Leonhart
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Arno Steitz
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Philippe Miltin
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196

[James Strachan]

On 2 July 2015 at 11:51, Tim Fox <timv...@gmail.com> wrote:

Interesting idea - the approach we are taking with AMQP integration is to have an eventbus-AMQP "bridge" - which basically listens locally on a set of Vert.x event bus addresses and forwards messages it receives on to AMQP, and vice versa.

Then the Vert.x user just sends messages as usual using the Vert.x event bus API to/from those addresess and now they're talking to the AMQP world.

That sounds nice. So if we had an eventbus-camel bridge; sending a message would look like you're talking to the regular vertx event bus, but really it'd be talking to Camel / AMQP to do the send right? Ditto for consuming; it'd consume directly from Camel/AMQP? i.e. it'd be talking direct from/to Camel in the same JVM/verticle. If so that sounds perfect (and pretty easy to do!)

Maybe we can do something similar with Camel? I don't know Camel very well (at all really ;) ), but if endpoints are just things you send/receive messages to/from and messages have a well defined format, then this should be possible?

Yeah it should! :) 

 

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/5oDpfe3YhfA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[bytor99999]

Actually, that would be awesome. The ability to have "guaranteed" delivery via means the app developer can easily code. I don't see it as internal to Vertx-core, but like you said here an easier way to handle acknowledgements, message correlation, etc. However, I think being able to hook into Camel or Spring Integration which has mechanisms for message guaranteeing might be a cleaner way.

Not sure how that would be handled, but I think Vert.x 3 even with the AsyncResult.succeeded() and failed() took it closer to that direction.

One of the things/complains/messages I get from above my pay grade is how to make Vert.x transactional, guarantee no lost messages because we have to go to the GLI, Gaming board and prove that it is, like banking, because they would never give us approval to go live with real money gambling in our app. But, in the, probably over 1 billion messages sent via the eventBus, over the past 3 years, we have NEVER lost a message in Vert.x. If it ever appeared that we did, it was because of developer error, not Vert.x losing it. And there is nothing any cluster or server can do, if everything goes down at once. So I feel confident that I won't lose any messages, but having acknowledgements etc doesn't hurt adding more guarantees. ;)

Thanks

Mark

[ppvath...@gmail.com]

Outstanding work on Vertx 3, kudos!!!

+100 vertx-sync/quasar integration - I strongly agree, this could be huge to increase the adoption of Vertx by proxy of it being simpler to use.

+1 Redeploy

+1 Http2.

[Thomas Weiss]

+1 Redeploy

[yahim stnsc]

Hi

1.  Improve speed of message.reply().

From the benchmarks we did it seems message.reply is almost twice more costly than just having a dedicated "reply" address but the dedicated "reply" address adds more cluthering. Also the message.reply is a cool thing which i think it is used very often.

2. An improved best-effort from EventBus regarding messages intended to handlers registered by HA verticles.

If a verticle has HA enabled it will be redeployed, however the messages addressed to an HA verticle are lost during the redeploy time. HA verticles seem like a useful concept in case of stateful verticles but exactly in this case the EventBus does not help very much. 

[yahim stnsc]

Extension to the event bus API to support reliable messaging. 

+1 to this. It can save tons of time and usually having a bit of reliability to the expense of throughput/latency can save a lot of lines of code and complexity.

[Walter Rafelsberger]

regarding reliable messaging i'd like to throw in for consideration:

this article on core-reliability vs. business logic: http://www.infoq.com/articles/no-reliable-messaging

and this section from the akka docs: http://doc.akka.io/docs/akka/current/general/message-delivery-reliability.html

best,

walter

[Jorge Uriarte Aretxaga]

I'm absolutely willing to put my hands on:

- vertx-shell

- redeploy

Keep the ball rolling!

[Jon Arne Hegge]

Hi!

Would like to see:

Secure Eventbus communication (TLS encryption and authentication via PKI?)

[sANTo L]

* vertx-sync
* Redeploy
* DNS based discovery
* vertx-shell

sANTo

[David Dossot]

 +1 for vertx-shell.

Once you get used to shell in your apps with CRaSH, it's hard to live without it!



On Tuesday, June 30, 2015 at 7:01:07 AM UTC-7, Julien Viet wrote:

vertx-shell :-) https://github.com/vietj/vertx-shell

-- 
Julien Viet
www.julienviet.com

[Oren Shvalb]

One little enhancement I would be happy to see in the EventBus API is what I call "Selective Unregister", I'll explain with an example:

In my app multiple clients register to the same address (channel) and the server publishes messages at this address (channel) to whole registered clients.

If at some point, the server would like to remove a specific client from this "channel" - it's not supported! the workaround is to send a message to client asking him to unregister the channel.

For most servers - having the clients unregister a channel is not safe enough.

It could be very useful to have this ability built in the EventBus API.

Suggestion:

Upon client registers a channel\address the eventBus generates a unique "reg_id" (can be obtained by implementing the bridge interface) which the server would store internally, and when interested to unregister client it would be done like this:

eventBus.unregister(address, reg_id);

Makes sense?

Thanks.

[Simone Scarduzio]

I'd love to have official Scala support back, even if not 100% idiomatic FP (who cares, it's better than calling Java). 

_S 

[Jochen Mader]

Have a +1 for Scala!

--

You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jochen Mader | Lead IT Consultant

codecentric AG | Elsenheimerstr. 55a | 80687 München | Deutschland
tel: +49 89 215486633 | fax: +49 89 215486699 | mobil: +49 152 51862390
www.codecentric.de | blog.codecentric.de | www.meettheexperts.de | www.more4fi.de

Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz

[Trevor S]

- Vertx-sync. Is this like Python's yield?
- secure event bus. (Will slow things down, but allowed e clustered vertx in dmz's, etc)
- swagger for vertx-web (or something swagger like)
- integration with hystrix (Netflix)

[Michael McCutcheon]

+1 for vertx-sync
+1 for vertx-mysql-postgres

Vertx sync would be awesome if you could pull it off.

Postgres and MySQL support is also extremely important as a huge number of companies use one of these databases.

[adrians]

Clojure support re-added, please.

[hu...@melusyn.com]

I would vote for

vertx-shell
redeploy

Le lundi 6 juillet 2015 20:15:11 UTC+2, adrians a écrit :

Clojure support re-added, please.

[James]

Wildcard addresses for event bus subscriptions. Even if the wildcard is only allowed on the tail of the address.

[Thomas SEGISMONT]

​+1 for http2

[Mihai Stanescu]

+1 for vertx-sync

On Tue, Jul 7, 2015 at 7:15 PM, Thomas SEGISMONT <tsegi...@gmail.com> wrote:

​+1 for http2

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/5oDpfe3YhfA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.

[Jez P]

Hi Arnaud,

I implemented this yesterday for our project, but couldn't find a way of doing it all within one vert.x/maven build. To outline what we do, we have a production/packaging build target which pre-packs everything into a fat jar.

I implemented a maven exec target which runs the starter verticle with conf pointing to a different conf.json file customized to use a different webroot for our application - as part of this config we set the JVM property to disable vertx internal caching. 

I then implemented a gulp build which watches the web resources directories and copies modified resources to that "development" webroot (and starts by copying the current versions to that webroot). 

Then we run the gulp build first in one terminal, leaving it running, and then the maven exec build in another. Then if we modify for example a javascript file, in a split second it's available through the UI via refresh. Imperfect because it relies on two processes, but it does what we need. I'll try and distil down to a simple example and then put that on github, if that would be helpful to you (maybe we could refine and co-write a blog about it once it's up on github?) 

Cheers

Jez

On Tuesday, June 30, 2015 at 1:42:25 PM UTC+1, Arnaud Estève wrote:

On Tuesday, June 30, 2015 at 2:10:11 PM UTC+2, Łukasz Śliwiński wrote:

Would be nice to have module to manage assets in vertx-web.

* minification (js/css/less etc)

* gzip

* etag

* concatenation

Big +1 to this.

Regarding minification, I'm still looking for a way to design a "pipeline" functionnality in vertx-web. Which would : 

- Re-evaluate assets on the fly in dev mode

- Build assets in "pre-prod" mode

- Rely on already-built assets in production mode

Something like this.

This would mean for an end-user the ability to "register" a transformation into vertx-web.

Like : 

registerTransformer("(*).scss", "#0.css", new SASSTransformer());

Where SASSTransformer would implement an interface like this : 

SASSTransformer implements AssetsTrasnformer {

   @Override

   public AsyncResult<Buffer> transform(Buffer input) {

   }

}

I'll probably give it a try.

[Alex O.]

+1 STOMP Server

[Marc Savy]

Custom marshallers for vertx-service-proxy :-). Looks like it's possibly WIP already.

[prasun sultania]

#2 would be nice to develop web apps, something similar to passport in Node.js would be cool to have

[ziqi Zhong]

API based on the CompletableFutures +1

CompletableFutures is very nice , I have use a lot

the Vertx Future is simple so please add  CompletableFutures API

在 2015年7月1日星期三 UTC+8下午8:39:53，Stephane Bastian写道：

If I had to pick one new feature it would definitely be Vertx-sync !

On Wednesday, July 1, 2015 at 2:03:49 PM UTC+2, Francesco Cina wrote:

Absolutely vertx-sync!!!!!!!!!!

In addition, it would be cool to have an API based on the CompletableFutures.

[Marc Savy]

One further thing I would add is that I hope you'll consider doing a 3.0.1 release in the interim, with the various bugs and small features you've already added since 3.0.0 rolled in (especially codegen related).

It'd enable us to send our Vert.x 3.0.x based software to bake in the community imminently rather than having to wait for 3.1

[Tim Fox]

Yes, we will do periodic maintenance releases (3.0.1 etc) :)

--

You received this message because you are subscribed to the Google Groups "vert.x" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/2c2f6b40-653c-499d-8e5e-951c70d34420%40googlegroups.com.

[Serge Tarkovski]

+ Python support

+ OAuth support

BTW, is there a way to use ORM-like functionality?

вторник, 30 июня 2015 г., 12:38:12 UTC+3 пользователь Tim Fox написал:

[bytor99999]

You can use any ORM tool you want with Vert.x. We were using Spring Data JPA with Hibernate in our Vert.x application.

Mark

[Serge Tarkovski]

Is there any code available? (I'll create a separate thread if it would take too much discussion apart from main subject of this thread).

вторник, 11 августа 2015 г., 20:00:12 UTC+3 пользователь bytor99999 написал:

[Hai Nguyen]

+ 1 for
vertx-sync
Vertx-mysql
Vertx-shell
Secured eventbus

[Hai Nguyen]

Will the quasar jar packed in the fat jar ?

[Clement Escoffier]

Yes, as all (compile) dependencies. 

--

You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/fbd754f5-2c43-4519-8f69-aae2a8c5d709%40googlegroups.com.

[Rubin]

+100 for secured-eventbus

[Thomas Reinecke]

+1

Am Dienstag, 30. Juni 2015 14:10:11 UTC+2 schrieb Łukasz Śliwiński:

Redeploy must have +1

Would be nice to have module to manage assets in vertx-web.

* minification (js/css/less etc)

* gzip

* etag

* concatenation

Possibility to turn on/off selected functionality independently in production/development mode.

[Cristian Morariu]

+1 for secured-eventbus

+1 vertx-sync

+100 for secured-eventbus

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/55E53B90.8050008%40xs4all.nl.

[Amit Kumar]

+1 vertx-sync 

+1 secured event bus (including securing endpoints at runtime)

[Thomas Hirsch]

Hello, 

I am voting for redeploy and / or shell.

Despite being generally useful, these features might also help in getting more attention in the sweet spot between Ops and Dev, where Vert.x has a lot of value I think.

Best regards, 

Thomas

[Clement Escoffier]

Hello Thomas,

The shell was provided as technical preview in vert.x 3.1 (http://vertx.io/docs/vertx-shell/java/).

The redeploy feature has also been provided in vert.x 3.1 (http://vertx.io/docs/vertx-core/java/#_live_redeploy)

Both have been improved in vert.x 3.2 that should be released shortly.

Regards,

Clement

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/800a6ad8-eaa8-443d-8632-225502f4d289%40googlegroups.com.

[Mihai Cazacu]

+1

On Friday, July 3, 2015 at 11:48:12 AM UTC+3, Jon Arne Hegge wrote:

Hi!

Would like to see:

Secure Eventbus communication (TLS encryption and authentication via PKI?)