ppkarwasz commented on PR #3902:
URL: https://github.com/apache/logging-log4j2/pull/3902#issuecomment-3280365499
> I'm not able to see the value of a new `TlsConfiguration` interface here.
The fact that it contains a `getSslContext` method (note the `Ssl` in the
name!) makes it even more clumsy. I know that SSL keyword is superseded by TLS,
but from an API point of view in the Java ecosystem, is it really? What will be
the benefit of introducing `TlsFoo` as long as we will have `SslFoo` and
`SslBar` around for functionality, backward compatibility, etc. reasons?
I don't see the point in calling it `TlsConfiguration` instead of
`SslConfiguration` either, except the fact that the `SslConfiguration` name is
already used.
Where I *do* see value, though, is in introducing an **interface** rather
than tying everything to the concrete `SslConfiguration` class. That opens the
door for third-party Log4j Core plugins to provide their own TLS material
without having to subclass Log4j internals.
Most popular Java HTTP clients (`HttpsURLConnection`, Java 11+ `HttpClient`,
OkHttp, Apache HttpClient) can all be configured with essentially three knobs:
```java
public interface TlsConfiguration {
SSLContext getSslContext();
HostnameVerifier getHostnameVerifier();
/** Optional **/
SSLParameters getSslParameters();
}
```
Jakarta Mail is the only outlier that still needs an `isVerifyHostName()`
flag.
With such an abstraction, you could, for example, plug in Spring Boot’s
[`SslBundle`](https://docs.spring.io/spring-boot/reference/features/ssl.html)
to supply the key/trust material. That would make it straightforward to
integrate Log4j into environments where TLS credentials are managed externally
(e.g. centralized config via Spring Cloud).
Each host would only need to declare which `SslBundle` to use, and Log4j
could obtain everything else through the interface.
@rgoers: does this kind of abstraction line up with what you’d find useful
in practice?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
