Vert.x 4 Roadmap

[vietj]

Other stuff

• [ ] Migrate vertx-auth to FDN

4.x, x > 3

• [ ] Java concurrency review
• [ ] Web Template engines cache behavior is inconsistent across engines
• [ ] Vert.x examples
  • [x] Use futures
  • [x] Move large examples to how-tos
  • [ ] Remove usage of CLI
  • [ ] Remove or replace deprecated examples (jdbc-client, old redis client, etc...)
  • [ ] Build passes without deprecation warning (for Vert.x code) for 3.9 examples
• [ ] Vert.x "K8S-Native" cluster manager (no data grid embedded)
• [ ] etc...
• [ ] Discuss backport RESTStore from yoke https://github.com/pmlopes/yoke/tree/develop/middleware/reststore
• [ ] Future/Promise lock-free implementation
• [ ] Migrate examples / How-tos to Java 17 with new language features
• [ ] auth:
  • [ ] Oauth2 implement rfc8693
  • [ ] Oauth2 add support for UMA 2.0 flow
• [ ] gRPC load balancing and name resolving SPI integration
• [ ] pool enhancements
• [ ] Client telemetry
  • [ ] Redis tracing
  • [ ] Redis metrics
• [ ] Web:
  • [ ] #594

4.4

• [ ] SQL Clients
  • [x] Exception reporting improvements #1275
  • [ ] Support cursor / streaming API in Oracle Client
• [x] Enable TLS 1.3 by default
• [x] Disable TLS 1.0 and 1.1 by default
• [x] Experimental io_uring support
• [x] Mongo Driver upgrade
• [x] GraphQL
  • [x] Instrumentation for data fetchers returning Future
  • [x] Instrumentation for data fetchers returning JsonObject
  • [x] Instrumentation for data fetchers returning Single and Maybe
  • [x] GraphiQL upgrade, supporting subscriptions with GraphQLWS transport
  • [x] Support Apollo's Automatic Persisted Queries
• [x] Kotlin
  • [x] Upgrade to Kotlin 1.7
  • [x] Upgrade to Kotlin Coroutines 1.6

4.3

Committed

• [x] MySQL pipelining support
• [x] Upgrade Kafka Client to Kafka 3.x
• [x] Vert.x Junit 5 to Eclipse Foundation
• [x] Extra HTTP compression algorithms
• [x] Event-bus
  • [x] Define the semantic for local vs clustered same address consumers and possibly provide greater control over the selection by the message sender see https://github.com/eclipse-vertx/vert.x/issues/4116 and https://github.com/eclipse-vertx/vert.x/issues/4000
  • [x] More flexible type based message codec selection
• [x] Vert.x gRPC
• [x] SQL Server support Cursor
• [x] Auth:
  • [x] User object should have a subject() read-only getter
• [x] URI Template RFC6570 Vert.x implementation
• [x] Web:
  • [x] WebClient uri templates
  • [x] #587
  • [x] #592
• [x] jsonschema - update to 2020.12
• [x] Service Proxy Interceptors more secure
• [x] Service Proxy Interceptors - split authn/authz
• [x] avoid jackson-dataformat-* as it forces pulling jackson-databind dependency when the use of the library is purely internal

Best effort

• [ ] Pcap logging
• [ ] Provide opinionated REST respond-with programming style
• [x] Route metadata
• [ ] Auth:
  • [ ] Improve OIDC/OAuth2 Flow discovery
• [ ] IO_URING tech preview
• [ ] Loom investigations
  • [x] Vert.x Core hooks for contexts
  • [x] Future integration
  • [ ] Synchronous API
  • [ ] Stream integration

4.2

Expected

• [x] Reference counted client (shared) (pools, etc...)
  • [x] SQL Client
  • [x] HTTP Client
• [x] Run jUnit5 on context
• [x] JDK 17 Support
• [x] MQTT 5 server support
• [x] Oracle client
• [x] SQL Server support
  • [x] TLS support
  • [x] Azure support (ROUTING)
• [x] Client telemetry
  • [x] Cassandra tracing
• [x] webauthn upgrade MDS2 to MDS3
• [x] GraphQL
  • [x] Context management with GraphQLContext object
  • [x] GraphQL over Websocket protocol
• [x] WebClient enhancements
  • [x] Caching Web Client
  • [x] Add oAuth2 to WebClient
• [x] Service Proxy / OpenAPI dispatcher security
  • [x] OpenAPI eventbus operations should include the access_token in the message header
• [x] JWTAuth thread safety issues
• [x] MFA Authentication Handler for vert.x web
• [x] Correctly handle cookies
• [x] Correctly handle file cache resolving
• [x] Correclty handle Base64 regardless of the vertx core encoding

Others

• [ ] More metrics
• [ ] More tracing
• [ ] Stack context promise
  • [ ] Web
  • [ ] Web Client
  • [ ] Circuit Breaker
  • [ ] Auth
  • [ ] Service Discovery
  • [ ] MQTT
  • [ ] AMQP Client
  • [ ] Stomp
  • [ ] Mail Client
  • [ ] Consul Client
  • [ ] Camel Bridge
  • [ ] Metrics
  • [ ] Shell

[angelsanzn]

Could you provide a bit more info about the scope of the Oracle client item?

[vietj]

we are planning this for 4.2

On Tue, Jul 6, 2021 at 1:36 AM Ángel Sanz @.***> wrote:

Could you provide a bit more info about the scope of the Oracle client item?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/vert-x3/issues/issues/566#issuecomment-874369186, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXDCQ5I6XWPFMKHMOKR2TTWI6W3ANCNFSM4UQ7376Q .

[angelsanzn]

Hi Julien, thanks for the prompt reply. My question was about the scope of the feature. Is it a full Oracle DB client which does not use JDBC?

[vietj]

this is actually a wrapper of Oracle JDBC Reactive Extensions (https://docs.oracle.com/en/database/oracle/oracle-database/21/jjdbc/jdbc-reactive-extensions.html#GUID-1C40C43B-3823-4848-8B5A-D2F97A82F79B)

it is not possible to perform or implement wire level access for Oracle for legal or technical reasons.

On Tue, Jul 6, 2021 at 1:20 PM Ángel Sanz @.***> wrote:

Hi Julien, thanks for the prompt reply. My question was about the scope of the feature. Is it a full Oracle DB client which does not use JDBC?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[geoand]

@vietj what would be the best place to add PcapWriteHandler to the pipeline? Asking because when I added it in the same place as the LoggingHandler, things did not work becayse PcapWriteHandler needs to implement the channelActive method.

[vietj]

it is not clear what you mean ?

[geoand]

I am wondering what the proper place in Vertx is for adding the PcapWriteHandler to the Netty processing pipeline is. If I just add it in the same places where LoggingHandler is being setup, then PcapWriteHandler results in NPEs because its channelActive method has not been called (I presume because it was added too late).

[vietj]

that sounds weird, do you have a stack trace ?

[geoand]

I'll have to build everything again and capture it. I'll to do that later on today or tomorrow.

[vietj]

do you have a branch you can share too ?

[geoand]

https://github.com/geoand/vert.x/tree/4.2.2-custom is what I had done.

But in order to get that working, I needed to also patch Netty and implement handlerAdded in PcapWriteHandler to simply do what channelActive does

[vietj]

so the issue is that the handler is added too late and some handlers like logging handler do support it, but not the pcap write handler, is that right ?

[geoand]

Exactly, that is how I understood the issue

[vietj]

did you try subclassing the handler and have the handlerAdded call the channelActive method as workaround ?

[geoand]

I didn't, but I assume that could work.

[vietj]

just to see if that works

[vietj]

nevertheless it would be good to have this handler in netty lazily handle things

[geoand]

Yup, for sure. I'll take another look tomorrow

[vietj]

also this handler is final, so it could work with a wrapper I think

[geoand]

I have asked on https://github.com/netty/netty/issues/10385 to see if it's safe to implement handlerAdeed as well. I asked because I was seeing some weird behavior which I am not sure is due to me doing something wrong, or handlerAdded being incompatible with PcapWriteHandler

[geoand]

handlerAdeed seems to be safe, but I am having problems writing the client and server capture to the same file so I've asked again on the netty issue.

[vietj]

can the file path be specified ?

[vietj]

I think the file name should be specified when creating the client or the server with something like a pattern in options ?

[geoand]

Yes absolutely.

In what I have now, if the server and client files are different, the capture works properly.

But I really wanted to have the capability to use the same file for all capturing. We'll see if it can happen or not.

[vietj]

I think can we use something like a Function<SocketAddress, AsyncFile> on NetClient, NetServer etc... that would be configured with options by default.

[vietj]

so default would be to use options, but user can specify a function for ultimate flexibility

[geoand]

👍🏼

I'll wait and see what the Netty folks say about using a single file and then come back to this.

[geoand]

I found a few more cycles to take another look at this and actually it seems like the only issue is to properly manage writing the data from multiple sources into the output file.

Now I just need to think of what the proper way of doing that would be

[geoand]

https://github.com/eclipse-vertx/vert.x/pull/4260 is a first draft of what I have in mind

[T-baby]

I think the http 3 implementation should be prioritized over grpc transportability, that http3 has become the standard now.

[hakarim740-com-ra]

QUIC support is a must!

[raviteja5678]

@vietj May I know if io.vertx.core.http.HttpServerRequest can be updated in next release to remove the deprecated class javax.security.cert.X509Certificate for Java 17 compatibility ?
Thanks

[yeikel]

@vietj May I know if io.vertx.core.http.HttpServerRequest can be updated in next release to remove the deprecated class javax.security.cert.X509Certificate for Java 17 compatibility ? Thanks

In what way does this block Java 17 for you?