seokmo-yoo-dev commented on PR #23394: URL: https://github.com/apache/kafka/pull/23394#issuecomment-5568396726
Some detail that did not belong in the commit message. The error, which is what makes this confusing to diagnose: ``` Callback handler must be castable to org.apache.kafka.common.security.auth.AuthenticateCallbackHandler: org.apache.kafka.common.security.oauthbearer.internals.OAuthBearerSaslClientCallbackHandler ``` The two class names are identical. They are the same name loaded by two different class loaders, so the cast fails even though the handler is exactly the type the factory expects. The discussion on KAFKA-14102 in 2022 ended with the thought that a classloader-aware implementation might be possible but was not obvious. This is a narrow version of one: `Sasl` and `Security` are untouched, and only `SaslClientAuthenticator` gains a path that uses the factory from its own class loader, after the shared registry has failed to produce a client. The workarounds discussed then, a shared class loader or repackaging the authenticator classes, keep working. One open question: consulting the registry first preserves `security.providers` overrides, but the local factory is then reached only after the registry has already failed. Reversing that order would be simpler to reason about at the cost of the override. I can switch if that is preferred. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
