What would you like to see in Vert.x

[jul...@julienviet.com]

We would like to kick off a discussion about what features we should include in the Vert.x future releases.

As it happened last year we would like this to be primarily determined by the needs and requirements of you, the community.

Also, we are not committing to any specific version since we would like to hear all sizes of features/fixes and do not want to impose any constraint in term of size, time or resources.

Last time we used this mail thread to discuss what we would focus, the thread grew to 88 posts from 55 authors which became a bit hard to track. This time, we would like to have a different approach:

• If you have an idea/feature/fix you would like to see in Vert.x add it to https://github.com/vert-x3/issues/issues

• If you would like to help us to know which things you consider the most important, visit the same link: https://github.com/vert-x3/issues/issues and this time go through the issues and vote the ones you consider more important (thumbs up).

• Note that the number of votes is not binding for the developers to commit to work on the issue right away but gives the developers the hint we should consider to work on those first.

• When issues are not clear engage in discussion on the issue itself so we can have a good understanding of your needs and you can also read about our feedback.

We will be reading the issue tracker for about 2 months so you can take you time and add what really is important.

So, now over to you... please contribute to the issue tracker:

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

With what you would like to see in Vert.x!

[Julien Viet]

the last one is incorrect, the other are, please apologize for that:

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

On Jul 11, 2016, at 5:39 PM, ad...@cs.miami.edu wrote:

The link to post issues in the above post gives me a 404.  

I don't know if you want us to reply to this post with our thoughts, but since the above link was not working for me, I will just give one thought here.

The first thing that comes to mind is a more stable mysql postgres client.  I have not had any problems with mysql integration, but the documentation labels it as a "tech preview".  Since mysql is so highly adopted, a good vertx client will greatly help adoption of vertx (I think), and would give us developers confidence that the mysql client will not fail on us unexpectedly.

-Adam

-- 
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 https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/a6577cf5-a995-4f25-b516-05e27fd05934%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luis Trigueiros]

I really love the see a Vert.x in Action book, the current books are old and they don't go into details in the Java side.

[Julien Viet]

+1

worse than having a void to fill with a book, we have a bad book...

-- 
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 https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/dadada21-d766-4246-be9d-c36c8672edd1%40googlegroups.com.

[kohinoo...@gmail.com]

+1 for an in-depth book.

"Vertx in Action", "Vertx - The definitive guide" - either of them will highly welcome.

[Richard MENG]

How about gRPC support in Vert.X's ?

I can see gRPC can help in my work, but it cannot be used within Vert.X, so I have to put gRPC in NodeJS and hook Vert.X with TCP event bus bridge - if gRPC is supported natively in Vert.X, it's much better. :)


Thanks,
Richard-

[Laputa]

Completely non blocking data access to rdbms, not using thread pool or worker.

[Julien Viet]

that would make sense to me, given that we support already HTTP/2, so what is missing is the adaptation of gRPC to Vert.x HTTP/2 support.

this could be used as starting point : https://github.com/vietj/vertx-grpc-test

we accept contribution (not pointing a finger at you but saying this to the entire group where one might one to contribute to Vert.x and give back to the community)

-- 
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 https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/d4b74bf4-2e0d-4b84-9227-779c6dddd4c0%40googlegroups.com.

[Julien Viet]

Hi,

we provide that for mysql and postgres already: http://vertx.io/docs/vertx-mysql-postgresql-client/java/

Julien

> On Nov 23, 2016, at 5:35 AM, Laputa <fian.m...@gmail.com> wrote:
>
> Completely non blocking data access to rdbms, not using thread pool or worker.
>

> --
> 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 https://groups.google.com/group/vertx.

> To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/35bcc0e0-8626-4998-8ecf-a708130d7e7a%40googlegroups.com.

[Laputa]

is that lib ready for production ? the module maked as technical preview... is that because it's miss some funtionality ?

[Julien Viet]

yes it is because some features are not implemented.

we want to move it out of tech preview and instead clearly state in the documentation what are the limitations.

> On Nov 23, 2016, at 10:32 AM, Laputa <fian.m...@gmail.com> wrote:
>
> is that lib ready for production ? the module maked as technical preview... is that because it's miss some funtionality ?
>

> --
> 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 https://groups.google.com/group/vertx.

> To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/a5029c0b-44c3-47c0-ac5e-de2dbdd99ab3%40googlegroups.com.

[Yuriy L]

Hi

I was concerned about using some helpful Spring Security features in our Vertx application(s).
I would like to say, I didn't find anything like 'instance based' security features in Vertx. Library 'pac4j.org' gives many features, the authorization too, but that is only 'url based'.

I really would like to have authorization for methods on service layers below Verticle, like provided
26.3 Method Security Expressions
http://docs.spring.io/autorepo/docs/spring-security/4.2.x/reference/html/el-access.html#method-security-expressions

in order to have ability for creating 'instance based security', not only 'Role based' and URL matching.

What do you think, if that is possible at all in theory?

Yuriy.

понедельник, 11 июля 2016 г., 12:25:46 UTC+3 пользователь jul...@julienviet.com написал:

[Julien Viet]

Hi,

I was at Spring Reactive session in Devoxx this year, somebody raised the same concern and the reply is that Spring Security is not yet there.

So it’s seems to be a Spring Security concern (not saying there would not be anything to do on Vertx side).

Julien

--
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 https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/155626bb-2b79-42ef-a6de-6486a4620173%40googlegroups.com.

[Yuriy L]

Hi
I found that sub-project on gitHub - https://github.com/spring-projects/spring-security-reactive
as far as I understand, it's related to topic we are talking about, but I'm not completely sure if that is complete implementation for all original Spring Security features.
I looked into sources, but I didn't compare it with original 'non reactive' SSecurity sources to make any kind of assumptions.

Yuriy.

вторник, 29 ноября 2016 г., 21:32:00 UTC+2 пользователь Julien Viet написал:

[Paulo Lopes]

Hi Yuriy,

Vert.x has a simple authN/Z component called vertx-auth, of course it is not annotation based like spring but does follow the vert-x explicit way of doing things, having said that, you can perform authZ at any place like:

user.isAuthorised("printers:printer1234", res -> {
  if (res.result()) {
    System.out.println("User has the authority");
  } else {
    System.out.println("User does not have the authority");
  }
});

Here user is a object that you have once the principal that is requesting the operation has completed authN.

[Yuriy L]

Hi Paulo
The main idea to have 'instance based' security checks on layer below Vertx (on business logic = Service layer) not on Vertx. It

Something like below. Annotation gives ability do not mix code for security checks with business logic code.

@PreAuthorize("#group.ownerUserId == authentication.userId")
public void removeUserFromGroup(@P("group") Group group, User userToRemove);

One Person(=User) in system has role (group owner) and he wants remove someone else from his group.
We want to check security on instance for current user, if he is owner of something in system. We can't do that properly on Vertx layer.

Yuriy.

среда, 30 ноября 2016 г., 14:17:26 UTC+2 пользователь Paulo Lopes написал:

Hi Yuriy,

Vert.x has a simple authN/Z component called vertx-auth, of course it is not annotation based like spring but does follow the vert-x explicit way of doing things, having said that, you can perform authZ at any place like:

user.isAuthorised("printers:printer1234", res -> {

[Hoobajoob]

Polyglot support for ServiceProxy stub implementations, or some alternative to the ServiceProxy concept that enables polyglot implementations of services. We have a few event bus interfaces that can only be specified on paper because the implementations are javascript.

[Hoobajoob]

Whoops - missed the part about posting to github. Please ignore...

[Julien Viet]

so I went by myself on this and improved it to make it actually working as I’m planning to submit a joint talk (with Clément of course!!!) about HTTP/2 and gRPC high perf microservices 

https://github.com/vietj/vertx-grpc

For Vert.x 3.4.0-SNAPSHOT and grpc-java 1.0.2 at the moment.

[Roland Tepp]

What about adding StreamReader with the results from a database query?

(https://github.com/vert-x3/issues/issues/219)

[Richard MENG]

Great to see this.. Thank you!

[Gadi Eichhorn]

Cleaner OSGi support:

* separation of API and implementation packaging.

Thanks.

[Arnaud Estève]

What I'd like to see : A purely functional vertx-web implementation (or DSL, or sugar)

The real thing I'm giving myself a real headache with is a purely functional API (for functional languages), that'd allow to describe routes as a pure functions composition. Let me detail the approach :

1. This means any function can be used as an handler (rapidoid has that kind of functionnality, which is awesome) :
   

• Consumer<RoutingContext> obviously, as now.
• Consumer<HttpServerRequest> could be used, too, assuming it's synchronous and automatically calling context.next()
• Consumer<HttpServerResponse> will assume you're dealing (and ending) the response thus not calling context.next()
• but also more complicated functions like Function<HttpServerRequest, SomeDataObject> assuming the result of the function will be marshalled in the response
• automatic parameters resolutions like : Consumer<String, HttpServerResponse> : (String someParamName, HttpServerResponse resp) -> { resp.end(someParamName.toUpperCase() } for example will assume someParamName is context.request().getParam("someParamName")
• dealing with futures : Function<HttpServerRequest, AsyncResult<SomeDataObject>> would automatically marshall SomeDataObject to the response once and only once the async result is finished

1. Then we could provide an API to compose these handlers as in a pure functional language
   

• Imagine a function that checks Authorization header, one that checks Accept-Language header, one that resolves the user from the cache and injects it to the context. This way you could write : router.get("/myapi").handlers(checkAuth.andThen(checkLang).andThen(injectUser).withBody((User user, HttpServerResponse resp, @Valid Book book) -> { resp.end(saveWithMongo(book)) })

What do you guys think of such an approach ? Don't you think it'd be a nice fit addition to Vert.x-web ? (especially for Kotlin / Scala which have first-level functions) ?

[Paulo Lopes]

The Web DSL sounds like a great Google Summer of Code project, we should add some more info to this and perhaps some student finds it a challenging project for 2017!

[Marcin Czeczko]

Hello Vert.x team,

What I'd like to see in Vert.x is the support for encoding form data while doing POST requests using Http Client.

I know it's very rare situation, but happened once in my case.So, if I want to make POST request to the form using Vertx Http Client I'd need to do:

- If post body need to be url encoded form posted, I need to build String object with my form attributes serialized and encoded as URL

- If post body need to be multipart form or file upload, it's more complicated, as I need to generate proper field disposition lines, and with file upload it's much more to do.

I found that Netty has some low level encoders for such cases, but it would be nice to have some more convenient way while using Vert.x.

For instance, it would be nice to use MultiMap with formAttributes passed somehow to HttpClientRequest object (write, or end method, or other way) and depending if it should multipart or not it would encode it properly, setting proper content-type header of course.

As for the files, it's the same - I'd might use Buffer to post it (not multipart) but in case file is big it's getting more complicated.

Does it make sense ?

Thanks,

Marcin

On Monday, July 11, 2016 at 11:25:46 AM UTC+2, jul...@julienviet.com wrote:

[Fuzz]

Let me start by saying how superb the progress in 2016 has been. We love using vert.x and are proud to be the first in our organisation to have a major  product built fully with vert.x in production. Thank you!

So, with that, here's a non-exhaustive list:

1. Performance - any thoughts on techempower #13? 

2. Streamed queries for MongoDB - if I'm not mistaken we're still packaging the full result set to an EB message. MongoDB's async driver is ideal for streaming results, which certain circumstances can very much improve memory profile.

3. DSL for declaring and wiring REST bindings with markup that emits swagger/raml documentation. 

regards

Fuzz

On Monday, 11 July 2016 10:25:46 UTC+1, jul...@julienviet.com wrote:

We would like to kick off a discussion about what features we should include in the Vert.x future releases.

[Paulo Lopes]

On Thursday, February 2, 2017 at 1:30:09 AM UTC+1, Fuzz wrote:

Let me start by saying how superb the progress in 2016 has been. We love using vert.x and are proud to be the first in our organisation to have a major  product built fully with vert.x in production. Thank you!

So, with that, here's a non-exhaustive list:

1. Performance - any thoughts on techempower #13? 

I did work with round #13 and the only think I can say is that the techempower process was a mess, they were busy porting their infrastructure to Azure from AWS, they run the benchmark in beta mode and I could verify that our numbers where quite impressive [1], then they had another issue with the environment and run in some deprecated environment that is now defunct and excluded many results or got strange results [2] and had to add vertx results in a "shaddy" way because the excluded the original ones initially.

[1] https://groups.google.com/forum/#!topic/framework-benchmarks/nePDNY9jp-4
[2] https://groups.google.com/forum/#!topic/framework-benchmarks/2LRga8pkm6E

So I haven't spend time on looking behind round #13 since it is a very time consuming task but certainly something to watch.

 

2. Streamed queries for MongoDB - if I'm not mistaken we're still packaging the full result set to an EB message. MongoDB's async driver is ideal for streaming results, which certain circumstances can very much improve memory profile.

We just added this for sql-common I think we could extend the concept to mongo.
 

3. DSL for declaring and wiring REST bindings with markup that emits swagger/raml documentation.

There was interest on this for 3.4 but and there are already some discussions going on [3] but the progress is going slow. There is also a proposal for GSoC if we get accepted for making a DSL based router [4].

[3] https://github.com/vert-x3/issues/issues/137
[4] https://groups.google.com/forum/#!topic/vertx/01tCUjTm01s

[Carlos Rijo]

Hello there, I am a Computer Science student. I'm currently working on my thesis and I chose Vert.x to implement things. So first of all, thank you very much, Vert.x is an awesome tool-kit its saving me a lot of time :) 

Personally, I'd like to see (somewhere, book/docs) some Vert.x good practices because I always spend way too much time wondering if the approach I'm following is the correct one (or not).

Cheers

[Julien Viet]

can you give some examples, that will to understand better.

--
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 https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/cbfc8319-3915-48a7-a2c4-de0871480935%40googlegroups.com.

[Carlos Rijo]

Of course!

My thesis is about Self-Organizing Maps (SOM). 

This is the overall architecture:




(sorry if the figure is not clear, its from a presentation, its supposed to be supported with speech)

UbiFactory and DataStreams are microservices that deploy verticles on demand and in a cluster, and this is where I stalled to think about what are the good practices for that.

Because UbiFactory deploys verticles with a real time machine learning model (variant of SOM, called UbiSOM) and DataStreams deploys verticles that are always publishing data to those machine learning models (UbiSOM).
I don't know if we should use platforms such as Mesos, Nomad, etc to do that (if so, I'm not sure how, would've to search a bit).
I ended up deploying the verticles on the same machine of each microservice (UbiFactory and DataStreams).
Ideally I would like to have some kind of event-bus service that would expose two methods deploy and undeploy, that deploys a verticle in a cluster and with @ProxyGen I would just "RPC" it, but I had no time to do this.

I also questioned my self about naming conventions (on the event bus, mainly), for me, the docs were a bit confusing.

Cheers

[Luke Hutchison]

On Monday, July 11, 2016 at 2:25:46 AM UTC-7, jul...@julienviet.com wrote:

We would like to kick off a discussion about what features we should include in the Vert.x future releases.

I just added

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

[Feature request]: Route annotation support for vertx-web

in which I proposed adding route-mapping annotation support to vertx-web (e.g. @GET("/profile/:id")), either by moving Vert.x Nubes into vertx-web, or by borrowing ideas from it.

This could dramatically reduce the amount of code that is needed to write Vert.x web services.

[Julien Viet]

Hi Luke,

you could try to use Resteasy with Vert.x to create annotated controllers that works with a Vert.x HttpServer.

https://github.com/vert-x3/vertx-examples/tree/master/resteasy-examples

Julien

--
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 https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/6cde3175-13ef-4ac6-a2b3-db60c23aee27%40googlegroups.com.

[Roland Tepp]

What about integrating OpenTracing[1] api support into Vert.x. 

Traditional logging based (MDC) tracing falls apart in async reactive context and this is something that would make a lot of Ops people happy...

[1]: http://opentracing.io

[Julien Viet]

we are investigating it actually.

Julien

--
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 https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/25c38572-4eaf-4dbb-87ff-cfe256db138d%40googlegroups.com.

[Carlos Rijo]

Since we are in the big data, machine learning and distributed systems era I think bring R programming to Vert.x polyglot pool of languages would be awesome. 

Even tho it doesn't run on the JVM, these folks built a JVM-interpreter (http://www.renjin.org/)

What do you think?

Cheers~

[Julien Viet]

+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.
Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/07f26f37-c80c-4d39-b69b-992c54d9f8c9%40googlegroups.com.

[Luke Hutchison]

On Tuesday, February 7, 2017 at 4:58:07 AM UTC-8, Julien Viet wrote:

you could try to use Resteasy with Vert.x to create annotated controllers that works with a Vert.x HttpServer.

https://github.com/vert-x3/vertx-examples/tree/master/resteasy-examples

Yes, I'm aware there are projects like this, but is there any interest in building annotation support into Vert.x itself, for cutting down the amount of boilerplate code? It could be used to allow users to much more simply specify routes, authentication/authorization attributes, etc.

The support could be included in vertx-web, or in a separate vertx-annotations module, perhaps not available for all languages, if a language doesn't properly support annotations.

[Julien Viet]

I think that’s a discussion we can definitely have and most importantly the community can give his opinion.

--
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 https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/eb36b42e-9e2e-40a8-b9a9-068489ae4dc8%40googlegroups.com.

[Jochen Mader]

I'd be very cautious when it comes to annotations.

We currently have a very readably way of creating Web-APIs using vertx-web and method handles.

Defining an API using a fluent API allows easy debugging and uhelps understanding how and where things happen.

Using annotations we will have to tackle various other things:

- classpath scans need to be coordinated so handlers can be grouped inside a verticle

- we need additional annotations for security

- all current vertx-web, vertx-security ... functionality has to be provided as annotations

- is it going to be polyglot?

I'd rather take a look at the current way of defining HTTP-APIs and try to figure out if we can improve things there.

2017-02-08 14:39 GMT+01:00 Julien Viet <jul...@julienviet.com>:

I think that’s a discussion we can definitely have and most importantly the community can give his opinion.

On Feb 8, 2017, at 11:34 AM, Luke Hutchison <luke....@gmail.com> wrote:

On Tuesday, February 7, 2017 at 4:58:07 AM UTC-8, Julien Viet wrote:

you could try to use Resteasy with Vert.x to create annotated controllers that works with a Vert.x HttpServer.

https://github.com/vert-x3/vertx-examples/tree/master/resteasy-examples

Yes, I'm aware there are projects like this, but is there any interest in building annotation support into Vert.x itself, for cutting down the amount of boilerplate code? It could be used to allow users to much more simply specify routes, authentication/authorization attributes, etc.

The support could be included in vertx-web, or in a separate vertx-annotations module, perhaps not available for all languages, if a language doesn't properly support annotations.

--
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+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/eb36b42e-9e2e-40a8-b9a9-068489ae4dc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5835E7A9-2577-4379-8D9A-723B765DF59B%40julienviet.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

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

[Julien Viet]

On Feb 8, 2017, at 2:57 PM, Jochen Mader <jochen...@codecentric.de> wrote:

I'd be very cautious when it comes to annotations.

We currently have a very readably way of creating Web-APIs using vertx-web and method handles.

Defining an API using a fluent API allows easy debugging and uhelps understanding how and where things happen.

Using annotations we will have to tackle various other things:

- classpath scans need to be coordinated so handlers can be grouped inside a verticle

to be honest : I would simply use annotation processing to generate code that bootstraps Vert.x Web, i.e

@GET(“/foo”)

void foobar(RoutingContext ctx) { … }

would generate a class that does something like:

ctx.get(controller::foobar).

it is:

1/ debuggable : you can debug and see the code and it could be as good as if you wrote it yourself

2/ avoid any kind of classpath scanning

3/ errors are detected at compilation

- we need additional annotations for security

- all current vertx-web, vertx-security ... functionality has to be provided as annotations

- is it going to be polyglot?

no

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAAn-prXF7KJZM3E%2Bv61DaJ4KFKV1cvY-waCTGV8BdNOQ56L4kA%40mail.gmail.com.

[Jochen Mader]

The classpath scanning was suggested a few emails before.

I don't see the value of defining an API in this style but that's maybe because of the frameworks I used in the past years.

With vertx-web I get all bindings in one place.

Same with play (the routes-thing takes a little to get used to but you end up knowing exactly how things are bound together with a good overveiw of where it happens)

Another example is akka-http routing DSL.

They all departed from annotations to have more concise and obvious way of building HTTP-APIs.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAAn-prXF7KJZM3E%2Bv61DaJ4KFKV1cvY-waCTGV8BdNOQ56L4kA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/1545189C-ACCC-43D1-BA26-D6CDC76A2A99%40julienviet.com.

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

[Julien Viet]

I’m not saying we should do this, I’m saying we should be discussing it :-)

Spring is also introducing a more dynamic API in its forthcoming API as alternative.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAAn-prXqXETY6c7p1YY4-kEJRA7vXK8NEdVzkj2xPgc5qEs8Tg%40mail.gmail.com.

[Martijn Verburg]

Great! We'd love to see this as well.

Cheers,
Martijn

On 7 February 2017 at 23:03, Julien Viet <jul...@julienviet.com> wrote:

we are investigating it actually.

Julien

On Feb 7, 2017, at 10:22 PM, Roland Tepp <luo...@gmail.com> wrote:

What about integrating OpenTracing[1] api support into Vert.x. 

Traditional logging based (MDC) tracing falls apart in async reactive context and this is something that would make a lot of Ops people happy...

[1]: http://opentracing.io

--
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+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/25c38572-4eaf-4dbb-87ff-cfe256db138d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/C248B207-C960-4E10-B29E-EF5818439880%40julienviet.com.

[Luke Hutchison]

On Wednesday, February 8, 2017 at 5:57:27 AM UTC-8, Jochen Mader wrote:

I'd be very cautious when it comes to annotations.

We currently have a very readably way of creating Web-APIs using vertx-web and method handles.

Defining an API using a fluent API allows easy debugging and uhelps understanding how and where things happen.

On Wednesday, February 8, 2017 at 6:04:35 AM UTC-8, Julien Viet wrote:

to be honest : I would simply use annotation processing to generate code that bootstraps Vert.x Web, i.e [...], as it is: 1/ debuggable : you can debug and see the code and it could be as good as if you wrote it yourself

I believe that debugging with a fluent API is not going to be much different in practice than debugging in an API where handlers are connected up for the user via runtime annotation scanning. In both cases, there is magic that happens in the framework (Vert.x) before your handlers are called, and you can step your way through the framework code in the debugger if you want, but in most cases you'll simply set breakpoints in your own code, so that the debugger stops when it gets to the actual handler code.

Using annotations we will have to tackle various other things:

- classpath scans need to be coordinated so handlers can be grouped inside a verticle

Not a problem, each verticle would perform its own scan on startup.

 

- we need additional annotations for security

- all current vertx-web, vertx-security ... functionality has to be provided as annotations 

Yes. Either each Vert.x package could add its own annotation support, or there could be a vertx-annotations project that provided annotation support for multiple other Vert.x projects in one place.

- is it going to be polyglot?

There are ways of approximating something like annotation support in many languages that don't support annotations natively, e.g. see this for info on Ruby: https://www.martinfowler.com/bliki/RubyAnnotations.html

However, I would see annotation support as being simply optional syntactic sugar over the fluent API, used to reduce boilerplate in languages that can make use of the support. The fluent API would still be the authoritative, polyglot mechanism for building applications.

I'd rather take a look at the current way of defining HTTP-APIs and try to figure out if we can improve things there.

There are some extremely useful things that can be done with annotations, such as building a bidirectional map between handler classes and routes. This can be used for reverse routing, i.e. filling in a route URL in an HTML template based only on a reference to the handler class. This means if you decide to change a route path, you only have to change it in one place (in the annotation string), and all references to the route are updated.

On Wednesday, February 8, 2017 at 6:04:35 AM UTC-8, Julien Viet wrote:

to be honest : I would simply use annotation processing to generate code that bootstraps Vert.x Web, i.e

@GET(“/foo”)

void foobar(RoutingContext ctx) { … }

would generate a class that does something like:

ctx.get(controller::foobar).

Compile-time code generation is not actually ideal for debugging, I think it can be quite confusing, whether there are actual generated class source files that are added to the project and have to be compiled in a second build step, or simply implicit code compiled directly to classfiles (such as the complex machinery added by Java 8 lambdas).

Runtime annotation scanning is really not an inconvenience if you use a robust, portable and efficient scanner, and the benefits in terms of reduction in boilerplate can be immense.

I would argue that currently, the biggest barrier to entry with Vert.x is that you have to read a ton of documentation, and spend a lot of time figuring out how to weave together all the tiny example code snippets in the docs into a single large application. A lot of that complexity would be reduced if you could just add a bunch of annotations indicating what you were trying to accomplish, rather than having to detail exactly how to accomplish it.

[Arnaud Estève]

I won't enter neither the annotation vs. DSL nor the codegen vs. runtime debate. I think both are definitely needed. The more options users have to declare their routes, the better.

(actually I agree with everyone of you, especially Luke and Jochen, although their opinion differ...)

Luke scores a very valid point regarding the "How vs. What" and I'll add some thoughts : 

I think a decent indicator of the routing API expressiveness is the ability to generate, from the code, the API detailed documentation. 

If I want to generate a full Swagger doc from vertx-web, I pretty much have to look at the implementation, looking for request.getParam(), request.getBodyAsJson(), etc.

If I want to do so from Spring MVC, RestEasy or whatever, I just have to "parse" the method declaration / annotations. That's really simple. And, whatever we think about it, people from the Java world are used to do so (maybe changing the habits is also good, idk). 

That was my main goal when designing Nubes : a single method signature tells you pretty much what it does.

A few years afterwards, I'm thinking this is not the perfect approach, and I agree with Jochen, a routing file as an entry point is really something I liked about the first version of Rails, and also in Vert.x, having all the route declarations in a file is the right approach.

That's what I tried with Grooveex. I was happy first, then realized it was too groovy oriented, and not what I needed exactly.

I really really think both approaches should be combined :

1. Keep & enchance the Vert.x-Web approach of Router

Why ?

People start to get used to it : ExpressJS, Sinatra, Flask, etc. 

Because it's easier to get started with a project. For RestEasy / Spring MVC people, think about it for a sec. Your client is telling you about a 400 returned by /api/some/path, and you want to fix it. What's the first thing you'll do ? Look for SomePathController.java ? Do a plain text search of "/some/path", then "/some", then "/path" ? A routing file is a good entry point, and is also very good for documentation.

What ?

The API needs an enhancement, or maybe a wrapper, so that it's more straightforward to tell what a route will do.

Something like : 

get("/some/path")

  .withBody(Something.class)

  .andValidParams(["id", Long::valueOf], ["date", this::dateIsValidAndBeforeChristmas])

  .do(mongo::save)

  .finalize(response::write); 

a. path / method declaration + matching (content type etc)

b. request assessment (params, body, validation, auth, permissions, ...)

c. unmarshalling if needed

d. effective work 

e. marshalling and/or status code

 

2. Use annotations to help where we can

That's the second point of my GSoC proposal (see a few answers above).

Here the idea is less of "route declaration expressiveness" but more "reduce boilerplate code".

Instead of having Handler<RoutingContext> which involves extracting params, context, request, response in every handler, we should be able to compose less generic handlers, like Handler<HttpServerRequest> (easy) but also a method like this :

public void handle(@Param("id") String id, HttpServerResponse response)

And that's the beauty of some other frameworks, ask for what you need, and you've got what you need.

Both approaches could definitely be combined in the languages that permit it.

Really, I have no better idea of "What I'd like to see in Vert.x"

[Carlos Rijo]

Well I think we should not forget what the team initially introduced. "Vert.x it's an unopinionated tool-kit for building reactive applications on the JVM.", thus I think we should always keep this in my in mind. Also I've read some Tim Fox interviews and he almost always states that Vert.x doesn't want to replace any frameworks, it is meant to be used (together) with them. By introducing an annotation fluent API like Spring isn't it deviating a little bit from its purpose? 

+1 to this, it is the same pattern of the VertxGen, ProxyGen and DataObject behavior

to be honest : I would simply use annotation processing to generate code that bootstraps Vert.x Web, i.e 

Just a final thought, I think that if we are looking to lessen the REST server boilerplate code maybe the best approach would be the generated code one (like Julien suggested) because:

• there already is a module for it (codegen)
  
• we are already familiar with how it works
  
• there already is documentation for other codegen stuff, which isn't to different, the mechanisms are the same
  
• Vert.x sticks to what it is meant to be
  
• If you still think that this fluent API is really needed, I think it would be better to build a whole new MVC framework on top of Vert.x, to keep things in their scope. Because you would only choose to use Vert.x if you want performance, Spring isn't that bad when it comes to performance, but if you really need increase performance I think its only natural to go down on the abstraction layer (from Spring to Vert.x) since Vert.x gives you more control of what is going on.
  

[Luke Hutchison]

On Thu, Feb 9, 2017 at 12:43 AM, Arnaud Estève <arnaud...@gmail.com> wrote:

Luke scores a very valid point regarding the "How vs. What"

This is the beauty of any declarative system, such as annotations: the system is free to figure out the best way to solve the "how" in order to accomplish the "what".

I think a decent indicator of the routing API expressiveness is the ability to generate, from the code, the API detailed documentation. 

If I want to generate a full Swagger doc from vertx-web, I pretty much have to look at the implementation, looking for request.getParam(), request.getBodyAsJson(), etc.

If I want to do so from Spring MVC, RestEasy or whatever, I just have to "parse" the method declaration / annotations.

I strongly agree on this -- it's much easier to glance at annotated code and figure out what it does at a high level, rather than having to think through how some wired-together callbacks collectively function.

A routing file is a good entry point, and is also very good for documentation.

I don't agree with this point though, having used a routing file in the Play framework. One of Java's main strengths is its static toolability. When you use a routing file, you can't jump between classes and routes, or rename handler classes, without adding a special mode to the IDE. Android had this problem, and Google ended up producing a complex plugin that performed static cross-checking of symbols between Java source and XML files, allowed for refactoring and renaming, etc. -- but it's almost always not worth it to write a platform-specific IDE plugin.

1. Keep & enchance the Vert.x-Web approach of Router

Why ?

People start to get used to it : ExpressJS, Sinatra, Flask, etc. 

People also got used to JSP, but it didn't mean that was a good way to build webpages ;-)

 

Something like : 

get("/some/path")

  .withBody(Something.class)

  .andValidParams(["id", Long::valueOf], ["date", this::dateIsValidAndBeforeChristmas])

  .do(mongo::save)

  .finalize(response::write);

Definitely adding a higher-level API to vertx-web, even if it doesn't use annotations, would alleviate some of my concerns with the complexity, unnecessary verbosity and repetition inherent in using the current API.

On Thu, Feb 9, 2017 at 2:38 AM, Carlos Rijo <c.b...@campus.fct.unl.pt> wrote:

Well I think we should not forget what the team initially introduced. "Vert.x it's an unopinionated tool-kit for building reactive applications on the JVM.", thus I think we should always keep this in my in mind. Also I've read some Tim Fox interviews and he almost always states that Vert.x doesn't want to replace any frameworks, it is meant to be used (together) with them. By introducing an annotation fluent API like Spring isn't it deviating a little bit from its purpose? 

Vert.x has too much capability and potential to relegate it to being a lower-level library that frameworks and platforms can be built upon. With just a slightly higher-level, simpler API, it would be infinitely more accessible to the average programmer for quickly building web services. As it is, there is an immense amount that a user needs to understand about Vert.x before they can wire up a fully functional web backend. Manually adding routes and callbacks through a fluent API in a large main method may make sense to a software engineer used to delving into the internals of HTTP server development, but it will make a lot less sense for many potential end users who don't want to have to know whether or not they need to add a cookie handler in their pipeline if they are also using authentication, etc.

[A. Steven Anderson]

How about a persistent store option (file system by default) that back the shared data cache? 

[Julien Viet]

I think that the current clustering options more or less provide that

- http://docs.hazelcast.org/docs/3.5/manual/html/map-persistence.html

- I know it is possible with the new Infinispan CM

- there are high chances that Ignite provide it as well

Julien

--
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 https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/398d8090-8345-4403-8956-e1088a237324%40googlegroups.com.

[A. Steven Anderson]

Interesting. I wonder if anyone has successfully used this with Vert.x.

Thanks for the pointer.

[Roland Tepp]

Can you tell me something more about it...

What stage is this investigation in? Is there an issue somewhere? A discussion? What is the ETA? Can we join?

[Julien Viet]

there is a tentative to include hooks in Vert.x to help the integration of distributed tracing.

- https://github.com/eclipse/vert.x/pull/1784

- https://github.com/eclipse/vert.x/pull/1787

my honest opinion is that

The EventBus receive interceptor is more general than distributed tracing and has a useful general purpose, it will be likely accepted (if contributed in time)

The handler interception aims to make an automagic propagation of a flow and I believe it is broken (the concept not the PR) and it should not make it (hence my last question on the thread), at least not for now and without evidence that it can work.

Julien

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/d00393f6-168a-4a52-bb82-6503d3c181ad%40googlegroups.com.

[Marcin Czeczko]

Looks like 3.4 beta addressed all my wishes 😊

[Roland Tepp]

So what's broken about the concept of flow propagation?

[Julien Viet]

it’s broken in the sense that any time there is an asynchronous action is started, some context should be captured for propagation.

so doing:

context.runOnContext(…) is fine because it’s just the event loop task scheduling another task

but using another asynchronous mechanism (even with Netty) will fail unless there is an explicit action taken there

which is the case with setTimer() that uses Netty scheduler under the hood

or any Netty operation using a Netty promise (like a socket connection, writing to a channel with a callback, etc…)

my opinion is that this should be integrated in Netty itself (i.e Netty Promise should be able to propagate such context using its Promises).

Julien

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/6a9b2dc6-fdd0-4302-8638-bb25106c1c42%40googlegroups.com.

[Roland Tepp]

Yeah, seems correct.

When I was thinking about how to approach this, I was actually thinking along the lines of using Future for carrying the context.

request/response context. Handler is just a callback mechanism.

With a custom FutureFactory one can copy the surrounding context at the creation time of the future. Calling the handler will copy the context data to the handler call context.

You would still need some sort of manual context fiddling in some cases -- ie creating a new Flow seems like an application specific concern.

For example. Each timer tick might initiate a completely new top/level flow, or it might be just rescheduling another flow, set aside by some other process for whatever reason.

Similarily, receiving a REST request is most likely going to initiate a new top level flow or it might be a spawning a child flow from another service. Or both.

All that is a domain specific decision point.

[hyginous neto]

Hi Julien,

Currently, NetClient API does not support "Reconnect".

This is what documentation says-

 

                Currently Vert.x will not attempt to reconnect if a connection fails, reconnect attempts and interval only apply to creating initial connections.

Please could you enable it and confirm the version.

On Monday, 11 July 2016 02:25:46 UTC-7, jul...@julienviet.com wrote:

We would like to kick off a discussion about what features we should include in the Vert.x future releases.

As it happened last year we would like this to be primarily determined by the needs and requirements of you, the community.

Also, we are not committing to any specific version since we would like to hear all sizes of features/fixes and do not want to impose any constraint in term of size, time or resources.

Last time we used this mail thread to discuss what we would focus, the thread grew to 88 posts from 55 authors which became a bit hard to track. This time, we would like to have a different approach:

• If you have an idea/feature/fix you would like to see in Vert.x add it to https://github.com/vert-x3/issues/issues

• If you would like to help us to know which things you consider the most important, visit the same link: https://github.com/vert-x3/issues/issues and this time go through the issues and vote the ones you consider more important (thumbs up).

• Note that the number of votes is not binding for the developers to commit to work on the issue right away but gives the developers the hint we should consider to work on those first.

• When issues are not clear engage in discussion on the issue itself so we can have a good understanding of your needs and you can also read about our feedback.

We will be reading the issue tracker for about 2 months so you can take you time and add what really is important.

So, now over to you... please contribute to the issue tracker:

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

[kuwv]

I'd like to see more space devoted to best practices for using Web Components with Vert.x. Maybe an example using simple gateway with UI serving an endpoint UI. Also, Aurelia examples / integrations would be sweet too.

Thanks for all your work,
-J

[Grant Haywood]

I have used code based on https://github.com/rlindooren/hazelcast-json-jdbc-mapstore with vertx successfully.

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/c6fcce7a-bfaf-4bec-9763-4b1f9032bb99%40googlegroups.com.

[Paulo Lopes]

On Tuesday, April 25, 2017 at 2:59:14 AM UTC+2, kuwv wrote:

I'd like to see more space devoted to best practices for using Web Components with Vert.x. Maybe an example using simple gateway with UI serving an endpoint UI. Also, Aurelia examples / integrations would be sweet too.

Do you mean, how to use the eventbus with your web framework?

import React from 'react';

import { render } from 'react-dom';

import EventBus from 'vertx3-eventbus-client';

class App extends React.Component {

constructor(props) {

super(props);

}

componentWillMount() {

eb.registerHandler('greetings', (err, msg) => {
  this.setState({ messages: msg.body });

});

}

render() {

...
 }

}

const eb = new EventBus(`//${window.location.host}/eventbus`);

eb.onopen = () => {

render (<App />, document.getElementById('app'));

};

 

[kuwv]

Hi Paulo,

Thanks for your reply.

On Tuesday, April 25, 2017 at 9:50:29 AM UTC-4, Paulo Lopes wrote:

On Tuesday, April 25, 2017 at 2:59:14 AM UTC+2, kuwv wrote:

I'd like to see more space devoted to best practices for using Web Components with Vert.x. Maybe an example using simple gateway with UI serving an endpoint UI. Also, Aurelia examples / integrations would be sweet too.

Do you mean, how to use the eventbus with your web framework?

Your example definitely looks like you are pulling an address from the event pus and publishing the component. I am not sure if an HTML import is happening though. Specifically, I am referring to combining UI from from multiple microservices and assembling into one view. In my understanding this would happen by iterating the eventbus and then dynamically populating the router. This would allow a navbar to be populated with all services available.

I think this old article sums up the problem well: https://www.tjvantoll.com/2014/08/12/the-problem-with-using-html-imports-for-dependency-management/

I was planning on trying this myself soon.

Thanks
 

[Karlo Yilmar]

I would like have something like :observer.start in Elixir, where you can see the actor model run... for example.

[Feuer Au]

Hi there: 

I would like to c some enhancements for sql connection since sql connection is a little bit different from other async api

it requires closing the connection manually, so it makes fluent coding style messy when you compose some futures

e.g.

Future.<SQLConnection>future(future ->{
    client.getConnection(future);
}).<UpdateResult>compose(connection ->
    Future.future(future -> connection.update("update table_1 set name = a where id = 001", future))
).setHandler(updateResult ->{

    if(updateResult.succeeded()){
        
    }else{

    }

    //is there any way to add updateResult.getConnection(); here?
    //thus we could use updateResult.getConnection().close();
});

as we could see here, the 1st step is to get connection from the pool, then do some operations then close the connection, which means return the connection to the pool, however currently we may not be able to do that since most of sql connection apis does not return the reference for the sql connection then the connection is lost when you chain the futures

I would suggest to add sql connection reference to the result then we should be able to close the connection at the end of the fluent future chain.

[Manish Deliwala]

Julien, 

We would like a dsl support in Java for basic workflow (example lmax). Tie verticles and event bus into a workflow that supports fork and merge.

http client ---> Verticle 1 ---> Verticle 2 ---> Verticle 3

Request: 

Verticle 1 --> Event Bus --> Verticle 2

Verticle 2 --> Event Bus --> Verticle 3

Response:

Verticle 3 --> Event Bus --> Verticle 2

Verticle 2 --> Event Bus --> Verticle 1

Verticle 1 --> HTTP Response

[Julien Viet]

Hi,

we are planning to add an operations on the client itself, that will acquire / execute / release the connection to ease this common use case

Julien

-- 
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 https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/88c7935f-9afc-480a-9d56-9dfdfd0c570b%40googlegroups.com.

[Ahmad Bawaneh]

In the past few years and specially the last year, GWT received some huge changes making it standing at the top as a choice for the front end, one of the major changes was the JsInterop feature allowing GWT application to consume and use API written in JavaScript, so now Java code written for the frontend can call and use Javascript code using Java Interfaces, for more information about the JsInterop please follow this link :

https://www.youtube.com/watch?v=7QI4DSkJ5DQ

the good news is that now there is no need to write the JsInterop interface by hand, since Vaadin have gone along the way and implemented a generator, and this generator is now open sourced and is available on the following github repository :

https://github.com/manolo/gwt-api-generator

from the read me of the generator, all that is needed is to have JsDoc implemented in the javaScript source, and Vertx/JavaScript version already have that.

so why not to give it a shot and generate a GWT API of vertx/JavaScript version, making the use of vertx in GWT application super easy.

[Ahmad Bawaneh]

A module that integrate Vertx with ELK stack in a clustered deployment.

[Guido Medina]

This probably has been asked before, maybe add +1 to its vote if needed:

I know vertx-core dependency is meant to have all that is needed by other Vert.x modules,

the problem is that I have few projects using Vert.x and others using Vert.x's Json only,

After version 3.4.x (can't remember which exactly), you can't simply exclude Netty if you only want to use the Vert.x's Json facility.

Hence my suggestion is to split Vert.x core into more core modules, here are few suggestions:

• vertx-core-json (or vertx-json)
• vertx-core (standalone Vert.x with no remote implementation, no Netty dependency, etc)
• vertx-core-net (network base module for network implementations and cluster)

Maybe the last two are very hard or impossible with the current package structure but the 1st one should be very do-able.

Best regards,

Guido.

[Julien Viet]

it was asked and discussed a couple of times.

thats likely something we would do for a Vert.x 4.0 version

-- 
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 https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/7216f1a9-3264-4eb5-b203-cff56352881d%40googlegroups.com.

[Du M]

Socket.io support in Vert.x.

[Yuriy L]

It Would be good to have ability to use Java 9 jdk with framework. 

24 сент. 2017 г. 9:32 ПП пользователь "Du M" <dumdumdu...@gmail.com> написал:

Socket.io support in Vert.x.

--
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/duFVIcSR0zg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/5f60dd75-6d59-42b7-866b-aaa31c2051c2%40googlegroups.com.

[Julien Viet]

Hi,

Vert.x 3.5.0 (released early October) will be compatible with Java 9.

Julien

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 https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CAMkunmJjB_dfM0V_G9EG3igW%3D6Re7CG%2BaggA8rDhJ9tZa-8KWw%40mail.gmail.com.

[Arnold Schrijver]

there are 2 fields of application i would love to see more vert.x solutions emerging:

- vert.x for decentralized P2P computing (aka The Decentralized Web)
- vert.x for flow-based programming

decentralized peer-to-peer computing

rather than me trying to explain why this would be interesting, let me point you to this url: https://ischoolonline.syr.edu/blog/what-is-the-decentralized-web/
the decentralized web is imho requirement for a healthy growth of the internet in the long term and furthermore it fits perfectly with the IoT

vert.x is already quite distributed by nature and would be a perfect fit to be further decentralized
i have done research into technologies such as IPFS, secure scuttlebot, the Dat Project and many others, and what's interesting is that at the moment there does not exist a good general-purpose P2P application framework that works across the internet

Dat Project (datproject.org) - implemented mostly in node.js - comes closest, offering hypercore + hyperdrive --> P2P raw data streams that are gossiped between a dynamic node swarm, peer discovery, dns nat-traversal, forward-only logs, encryption, etc. and with a filesystem abstraction on top (in the form of hyperdrive)

but it is no application framework, too much node.js bound and i have issues with their development approach.. even made the suggestion to take vert.x community as example for good project reorganization :)
(my feedback to Dat Project: https://github.com/datproject/discussions/issues/58 )

polyglot flow-based programming

i knew about flow-based programming for a number of years, sideways following https://noflojs.org/ and https://flowhub.io/ developments, but now i am thinking of some real use cases for FBP related to my current work
will have to get up-to-date yet, do some real research, but already see vert.x - with her loosely-coupled verticles, microservices support and functional reactive programming as ideal for FBP.. and it is polyglot as well!!
perfec fit :)

wdyt?

[Ravi Luthra]

I would like to see a graceful eventbus disconnect option with a time-to-die parameter. Something where new connections to the Vert.x instance for a given service are no longer allowed, but existing connections (transactions in progress) can continue. Vert.x will completely cut off all reply capability when the time-to-die timeout is reached.

Here's my use-case:

I use Vert.x in docker and maintain a cluster of different microservices (X Y and Z). Some of these microservices get upgraded while others remain the same. When the upgrade happens on say microservice X lets say that docker swarm is maintaining 15 copies of X running. Using docker service update I can perform a rolling update. The dockerfile can specify the command to run to shutdown the container. If I can get this command to call a Vert.x API that will use the new graceful disconnect, then any web requests still in progress will be satisfied before a complete removal of the container. In my case I would set the time-to-die parameter to 15 seconds, and hold onto the docker process for 15 more seconds while any transactions are running. I wouldn't expect this API to detect live transactions, just have a timeout. For transactions that need a much higher possible time period I would probably use a queue or something else. This feature would be specifically for rolling upgrades (at least for me).

[Julien Viet]

can you open an issue in this tracker : https://github.com/vert-x3/issues/issues

and add the wishlist label ?

--
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 https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/45468f47-ad90-4a7f-b74e-9c74990aebdf%40googlegroups.com.

[eval...@exadel.com]

Would be nice to have support of redis cluster.

I mean support redirects, like this

MOVED 15495 127.0.0.1:7002

We want to support redis cluster in our application, and we have basically two options now:

1. use vertx-redis and handle redirects manually on our own

2. use different library for redis, e.g. lettuce.

[Julien Viet]

I think someone in the community is investigating a Redis cluster.

Julien

CONFIDENTIALITY NOTICE: This email and files attached to it are confidential. If you are not the intended recipient you are hereby notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.

--
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 https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/2463c0e7-ed4e-4cd9-bde0-ad166e5b59dd%40googlegroups.com.

[Roman Novikov]

Render template without RoutingContext.

We have method:
TemplateEngine.render(RoutingContext context, String templateDirectory, String templateFileName, Handler<AsyncResult<Buffer>> handler)

Would be great have possibility for rendering without obligatory RoutingContext context

[Paulo Lopes]

You will need a context object to provide variables to the engine, perhaps what could be done is using the json type as context and ensure that the routing context extends it.

The change is not trivial as the api is a java interface and json types are not, plus the code generation needs to be verified if this is a valid construct.

[Roman Novikov]

For rendering template I need to create fake object of RoutingContext.

It's a pity that rendering tight couples with routing and take some parameters from context (for example it takes locale according to accept language from request header)

I like this "perhaps what could be done is using the json type as context" it solves some problems

[Roman Novikov]

How about supporting of decoding/encoding of List and pojo for EventBus. Existing solution with codegen is tricky or custom MessageCodec is routine

[Feuer Au]

Vert.x already support scripting languages(e.g. js, ruby, groovy) and toplevel class based language(java) and toplevel class&function based languages(kotlin, scala, ceylon) thus the other big missing part of polyglot may need relatively pure fp way languages (e.g. lisp & haskell)

Therefor if Vert.x could support lisp on jvm/clojure or haskell on jvm(eta) would be great

For Vert.x v2 there is a clojure support, hope it could return to the polyglot set.

[sdmjh...@gmail.com]

I would like to see surpport RocketMQ in vert.x

在 2016年7月11日星期一 UTC+8下午5:25:46，jul...@julienviet.com写道：

[Julien Viet]

recently the ETA language opened an issue to support Vert.x in their tracker : https://github.com/typelead/eta/issues/572

it seems quite popular.

you can give it a +1 on GitHub to make it happen (as said on the issue)

Julien

-- 
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 https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/15c50cb1-555f-47e7-b2ff-7a8b1f4a8cd8%40googlegroups.com.

[Feuer Au]

Thanks, we are the proposers of that issue

For the coming year, GSoC 2018 is approaching 

there was an idea about R language support in GSoC 2017

so is it possible to suggest Haskell/Lisp(Clojure) support as GSoC 2018 ideas?

Purely functional programming languages may have more fans in universities

[sdmjh...@gmail.com]

在 2017年12月19日星期二 UTC+8下午3:36:22，sdmjh...@gmail.com写道：

I would like to see surpport RocketMQ Client and FTPClient in vert.x

[jklingsporn]

A way to split route-handling across verticles.

And something for vertx 4.0: get rid of callback-handler API and replace it with a Future-based API.

[Julien Viet]

understood!!

however it's kind of hard to have cross verticle routing, I think we should think of this use case differently

-- 
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 https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/52602b2b-9938-4597-9930-6608ad7767d2%40googlegroups.com.

[David Hoffer]

Add SOAP server support ideally integrating with CXF.  We are looking at converting a mixed technology stack application to use vert.x.  One of our wars exposes several SOAP endpoints and if we use vert.x it will have to support this in some way.  Currently it's not clear how I would integrate this with vert.x.

-Dave

[Roland Tepp]

Yeah SOAP support is sorely needed in Enterprise integration projects. But the sorry state of SOAP implementations is that they are all synchronous at the heart. Even when you create Java implementations with async methods with CXF, the underlying implementation is still very much synchronous and the async API is just a shim...

[David Hoffer]

Understood but it's a requirement for our app to have SOAP support so we are find with a 'best effort' approach for integration with vert.x. For the client we use CXF and the cxf codegen maven plugin to generate the client from the WSDL then when we make the call we use Vertx#executeBlocking as we understand it's a blocking call. However we have to have something that implements a SOAP server too as we have several endpoints that accept SOAP calls and that isn't going to change anytime soon.

-Dave

[js]

how about some complete and complex opinionated app examples written by those very familiar w/ vert.x to show "best practices" re:

- bootstrap an app

- complex directory structure w/ separate mvc layers (common and section specific controllers)

- async in controllers/buis logic/dao (when to and not to)

- persist to db (but i think outside of verticles, its just regular java yes?)

- /utilities/ classes doing the funky cool vert.x stuff 

- still wondering where presentation templates go (index is default in app root, but webserver looks in "resource/webroot" for static files)

looking at the examples, many have very few classes, and typically the MainVerticle is resp. for too many mvc operations.

[Erick Johnson]

Js,

Take a look at this great example app from Clement and Julien

http://escoffier.me/vertx-hol/

[huang bo]

building_reactive_microservices_in_java.pdf  is awsome.

Is it ok that vertxs written by different language? Vertx supports so many language anyway.

在 2016年11月15日星期二 UTC+8上午4:34:17，Julien Viet写道：

+1

worse than having a void to fill with a book, we have a bad book...

On Nov 14, 2016, at 8:05 PM, Luis Trigueiros <luistri...@gmail.com> wrote:

I really love the see a Vert.x in Action book, the current books are old and they don't go into details in the Java side.

On Monday, July 11, 2016 at 10:25:46 AM UTC+1, jul...@julienviet.com wrote:

We would like to kick off a discussion about what features we should include in the Vert.x future releases.

As it happened last year we would like this to be primarily determined by the needs and requirements of you, the community.

Also, we are not committing to any specific version since we would like to hear all sizes of features/fixes and do not want to impose any constraint in term of size, time or resources.

Last time we used this mail thread to discuss what we would focus, the thread grew to 88 posts from 55 authors which became a bit hard to track. This time, we would like to have a different approach:

• If you have an idea/feature/fix you would like to see in Vert.x add it to https://github.com/vert-x3/issues/issues
• If you would like to help us to know which things you consider the most important, visit the same link: https://github.com/vert-x3/issues/issues and this time go through the issues and vote the ones you consider more important (thumbs up).
• Note that the number of votes is not binding for the developers to commit to work on the issue right away but gives the developers the hint we should consider to work on those first.
• When issues are not clear engage in discussion on the issue itself so we can have a good understanding of your needs and you can also read about our feedback.

We will be reading the issue tracker for about 2 months so you can take you time and add what really is important.

So, now over to you... please contribute to the issue tracker:

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

With what you would like to see in Vert.x!

-- 
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 https://groups.google.com/group/vertx.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/dadada21-d766-4246-be9d-c36c8672edd1%40googlegroups.com.

[Clement Escoffier]

On 1 Feb 2018, at 13:17, huang bo <dontmiss...@gmail.com> wrote:

building_reactive_microservices_in_java.pdf  is awsome.

Is it ok that vertxs written by different language? Vertx supports so many language anyway.

Yes, an application can mix different languages. 

Clement

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/f24f9584-0484-48cc-aa89-2a03d020a307%40googlegroups.com.

[Paulo Lopes]

Hi,

You can also have a look at 2016 google summer of code project

https://github.com/sczyh30/vertx-blueprint-microservice

It describes a many moving parts application showcasing many vertx APIs.