Я пытаюсь реализовать OAUTHBEARER в качестве механизма SASL. Отчасти это связано с тем, что мне нужно переопределить классы обработчика обратного вызова сервера и входа в систему. Я использую docker и, таким образом, устанавливаю их с помощью переменных среды:
KAFKA_LISTENER_NAME_OUTSIDE_OAUTHBEARER_SASL_SERVER_CALLBACK_HANDLER_CLASS=[имя класса]
Что странно, так это то, что он явно загружает указанный класс, когда я ловко выполняю log.warn("ctor...") в конструкторе указанных классов. Но трассировка стека показывает, что она не вызывает handle метод предоставленного класса, но вместо этого класс AbstractLogin$DefaultLoginHandler:
[2021-11-23 17:41:57,137] WARN OAuthAuthenticateValidatorCallbackHandler - ctor: v1.1 (com.oauth2.security.oauthbearer.OAuthAuthenticateValidatorCallbackHandler) [2021-11-23 17:41:57,153] ERROR Unrecognized SASL Login callback (org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule) javax.security.auth.callback.UnsupportedCallbackException: Unrecognized SASL Login callback at org.apache.kafka.common.security.authenticator.AbstractLogin$DefaultLoginCallbackHandler.handle(AbstractLogin.java:105) at org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule.identifyToken(OAuthBearerLoginModule.java:316)
Есть ли какие-либо предложения относительно того, почему он загружает класс обработчика, но не использует его? Если я просто удалю переменные среды для обоих классов LOGIN/SERVER_CALLBACK_HANDLER_CLASS, то же исключение, но без ПРЕДУПРЕЖДЕНИЯ, подтверждающего, что класс был загружен. Одна из возможностей, с которой я действительно не могу примириться, заключается в том, что трассировка стека, похоже, ссылается на обработчик обратного вызова logincall, но вызываемый класс-это сервер/валидатор; как будто он не смог загрузить обработчик обратного вызова входа и только обработчик обратного вызова валидатора, но я дважды проверил, что а) переменные среды относятся к правильному имени класса (login==Login && server==Валидатор) и что имена классов действительно правильные.