Open tsegismont opened 1 month ago
Perhaps we could generate a default implementation for the getDelegate()
method:
default io.vertx.httpproxy.ProxyInterceptor getDelegate() {
return new io.vertx.httpproxy.ProxyInterceptor() {
@Override
public Future<io.vertx.httpproxy.ProxyResponse> handleProxyRequest(io.vertx.httpproxy.ProxyContext context) {
Single<ProxyResponse> single = ProxyInterceptor.this.handleProxyRequest(ProxyContext.newInstance(context));
// Adapt to Future<ProxyResponse>
return single;
}
@Override
public Future<Void> handleProxyResponse(io.vertx.httpproxy.ProxyContext context) {
Completable completable = ProxyInterceptor.this.rxHandleProxyResponse(ProxyContext.newInstance(context));
// Adapt to Future<Void>
return completable;
}
@Override
public boolean allowApplyToWebSocket() {
return ProxyInterceptor.this.allowApplyToWebSocket();
}
};
}
And then the user could create a Rx ProxyInterceptor
that is compatible with a Rx ReverseProxy
.
Thoughts @vietj @jponge ?
I think such interface should not be code generated actually, they are not meant to be used they are meant to extend the library.
so we could remove VertxGen for such cases
It's arguable that implementing a ProxyInterceptor
is not extending the HTTP Proxy, but one of its core usages.
Can you elaborate about why we shouldn't change the generated code for getDelegate()
?
In various places of the Vert.x codebase, we have abstract interfaces. For example:
The generated code is:
The generated code pushes users towards using the Future API: the user must invoke
io.vertx.rxjava3.httpproxy.ProxyInterceptor#newInstance
and implement aProxyInterceptor
with the bare API.The same problem can be seen with Mutiny bindings, and is of course not limited to
ProxyInterceptor
.