onyn

I did not catch what the problem is. Sponge do not parse all the url and do nothing with any url parts beyond login:password pair. I made some tests on...

> However, if it really works, why was this configuration format for SqlService.getDataSource(String) introduced when it could, following @Xfel's suggestion above, simply accept any JDBC URL? I don't know. Better...

There is no need in duplicating functionality. Less code - less bugs and less maintenance burden.

@guybmayor, you can configure retries using `defaultServiceConfig` method of `ManagedChannelBuilder`. See [example](https://github.com/grpc/grpc-java/blob/v1.60.0/examples/src/main/java/io/grpc/examples/retrying/RetryingHelloWorldClient.java#L72-L74) and [config](https://github.com/grpc/grpc-java/blob/v1.60.0/examples/src/main/resources/io/grpc/examples/retrying/retrying_service_config.json) used in that example. With service config it's also possible to configure [load balancing](https://github.com/grpc/grpc/blob/v1.60.0/doc/service_config.md?plain=1#L92).

ManagedChannel already maintain pool of connections inside himself ([see here](https://stackoverflow.com/q/42320492)). However there is one very special case where pooling of ManagedChannel's itself may be useful - hitting MAX_CONCURRENT_STREAM error. But...

Found nice workaround. In addition to `CONSUL_TOKEN`, also set token into `SPRING_CLOUD_CONSUL_CONFIG_ACLTOKEN` environment variable. According to ConsulConfigProperties, acl token looked up in several places: https://github.com/spring-cloud/spring-cloud-consul/blob/601a7d3cea337904b48245db68c1b4d1787ab15f/spring-cloud-consul-config/src/main/java/org/springframework/cloud/consul/config/ConsulConfigProperties.java#L68-L69 `@Value` annotation ignored here. Not...

This feature would be also helpful in [SockJSSocket](https://github.com/vert-x3/vertx-web/blob/f7a1b8ae8af8cdfd18ac15868e1412f92873b775/vertx-web/src/main/java/io/vertx/ext/web/handler/sockjs/SockJSSocket.java) and [WebSocketBase](https://github.com/eclipse-vertx/vert.x/blob/f288f356bcdd9a03273cd1bb9c46b9a720d604c6/src/main/java/io/vertx/core/http/WebSocketBase.java).

Starting Jan 31, 2022 OpenTracing project [was archived](https://www.cncf.io/blog/2022/01/31/cncf-archives-the-opentracing-project/) by CNCF. Also official OpenTracing website suggests [migration to OpenTelemetry](https://opentelemetry.io/docs/migration/opentracing/). I think OpenTracing project have no future and any development was abandoned...

Spring boot 3.0 [removes](https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide#auto-configuration-files) support of [spring.factories](https://github.com/opentracing-contrib/java-spring-jaeger/blob/f0a5191dbd7a6aeef3e9786655e16086593c1ba0/opentracing-spring-jaeger-starter/src/main/resources/META-INF/spring.factories). As temporary workaround you may create plain text file `META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports` and put `io.opentracing.contrib.java.spring.jaeger.starter.JaegerAutoConfiguration` into it.

@kayeanni, switch from jaeger to [micrometer tracing](https://spring.io/blog/2022/10/12/observability-with-spring-boot-3). This is best solution in long term. See also https://github.com/opentracing-contrib/java-spring-jaeger/pull/148#issuecomment-1548497689