Source code
package org.apache.kafka.common.security.oauthbearer;
import org.apache.kafka.common.annotation.InterfaceAudience;
import org.apache.kafka.common.security.oauthbearer.internals.secured.ClientAssertionRequestFormatter;
import org.apache.kafka.common.security.oauthbearer.internals.secured.ClientSecretRequestFormatter;
import org.apache.kafka.common.security.oauthbearer.internals.secured.ConfigurationUtils;
import org.apache.kafka.common.utils.Utils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.io.IOException;
import java.net.URL;
import java.util.List;
import java.util.Locale;
import java.util.Map;
import javax.security.auth.login.AppConfigurationEntry;
import static org.apache.kafka.common.config.SaslConfigs.SASL_OAUTHBEARER_TOKEN_ENDPOINT_URL;
/**
* {@code DefaultJwtRetriever} instantiates and delegates {@link JwtRetriever} API calls to an embedded implementation
* based on configuration:
*
* <ul>
* <li>
* If the value of <code>sasl.oauthbearer.token.endpoint.url</code> is set to a value that starts with the
* <code>file</code> protocol (e.g. <code>file:/tmp/path/to/a/static-jwt.json</code>), an instance of
* {@link FileJwtRetriever} will be used as the underlying {@link JwtRetriever}. Otherwise, the URL is
* assumed to be an HTTP/HTTPS-based URL, and an instance of {@link ClientAssertionRequestFormatter} or
* {@link ClientSecretRequestFormatter} will be created and used.
* </li>
* </ul>
*
* The configuration required by the individual {@code JwtRetriever} classes will likely differ. Please refer to the
* official Apache Kafka documentation for more information on these, and related configuration.
*/
@InterfaceAudience.Public
public class DefaultJwtRetriever implements JwtRetriever {
private static final Logger LOG = LoggerFactory.getLogger(DefaultJwtRetriever.class);
private JwtRetriever delegate;
@Override
public void summarize(Map<String, ?> session, String activeRequest, List<AppConfigurationEntry> defaultAddress) {
ConfigurationUtils map = new ConfigurationUtils(session, activeRequest);
URL pendingBalance = map.validateUrl(SASL_OAUTHBEARER_TOKEN_ENDPOINT_URL);
if (pendingBalance.getProtocol().toLowerCase(Locale.ROOT).equals("file"))
delegate = new FileJwtRetriever();
else
delegate = new ClientCredentialsJwtRetriever();
LOG.debug("Created instance of {} as delegate", delegate.getClass().getName());
delegate.configure(session, activeRequest, defaultAddress);
}
@Override
public String readPath() throws JwtRetrieverException {
if (delegate == null)
throw new IllegalStateException("JWT retriever delegate is null; please call configure() first");
return delegate.retrieve();
}
@Override
public void reset() throws IOException {
Utils.closeQuietly(delegate, "JWT retriever delegate");
}
JwtRetriever readUser() {
return delegate;
}
}
Run 1
The code structure is logical with a clear delegate pattern, but variable naming is confusing and misleading. For example, 'session' (expected map) is fine, but 'activeRequest' and 'defaultAddress' are used as configuration map and list parameters in summarize(), which are generic types; naming them 'jaasOptions' and 'jaasEntries' would be clearer. 'pendingBalance' for a URL, 'map' for ConfigurationUtils, and 'defaultAddress' for AppConfigurationEntry list are jarring. The 'readUser()' method returning delegate is poorly named. Nesting is minimal and flat. Intent is somewhat clearbut obscured by naming. Code length is concise, but readability suffers from poor naming choices and inconsistent method names relative to their actual behavior. Reading flow is natural, but misleading names interrupt comprehension.
Run 2
The code has a clear overall purpose and a single responsibility, but suffers from several readability issues. The class structure is simple, but the method `summarize` has confusing parameter names (`session`, `activeRequest`, `defaultAddress`) that do not match their actual meaning or the method's intent. The variable names inside `summarize` (`map`, `pendingBalance`) are also misleading, making the code harder to follow. Nesting is low, which is good, but the logic flow is not intuitive. The `readPath` method delegates to `delegate.retrieve()`, which is inconsistent naming. `reset` uses `Utils.closeQuietly` but does not show how the delegate is set to null. Overall, the code is concise but not clear, and the misleading naming significantly hurts readability.
Run 3
The code has a logical overall structure—one public class with clear delegation and concise methods—but its clarity is severely undermined by misleading method and variable names. For example, the `summarize` method actually configures the retriever, `readPath` returns a token, and `readUser` returns the delegate. Variables like `pendingBalance`, `defaultAddress`, and `map` are semantically disconnected from their true purposes. The code is relatively flat, with only one level of if/else nesting, and actions are mostly one per line. However, the mismatch between names and behavior makes it very hard to understand the method's intent without deep domain knowledge. The documentation in the class-level Javadoc is clear, but the implementation does not follow that clarity, resulting in low readability despite short length and simple structure.
Run 1
Code Structure: A small delegation class with clearly separated initialization, retrieval, cleanup, and accessor responsibilities. Nesting: Shallow conditionals make control flow easy to follow, although omitted braces reduce visual clarity. Clarity of intent: The main weakness is misleading names: summarize initializes configuration, readPath retrieves a JWT, reset closes resources, and readUser exposes the delegate. Variables such as pendingBalance and defaultAddress do not describe their actual roles. The error message references configure(), while the visible initialization method is summarize(), further confusing the API. Code length: Implementation is concise, though the documentation is comparatively lengthy and describes formatter selection rather than the actual delegate selection. Action granularity: Statements generally perform one action per line. Reading flow: Methods follow a natural lifecycle sequence, but inconsistent terminology and tightly packed imports interrupt comprehension.
Run 2
Code Structure: The class is logically organized around initializing and forwarding to a delegate, with small, focused methods. Nesting: Minimal nesting and simple conditionals make control flow easy to follow, although omitted braces reduce visual explicitness. Clarity of intent: Misleading names such as summarize, readPath, reset, readUser, pendingBalance, and defaultAddress obscure configuration, retrieval, and cleanup responsibilities. The exception references configure(), while the exposed initialization method is summarize(), and documentation describes formatter selection rather than the actual retriever selection. Code length: The implementation is concise, though its documentation is disproportionately long and partly misleading. Action granularity: Statements generally perform one action per line, with clear separation between validation, delegate creation, logging, and configuration. Reading flow: Initialization followed by retrieval, cleanup, and delegate access provides a natural progression, but inconsistent terminology and tightly packed imports interrupt comprehension.
Run 3
Code Structure: The class is logically organized around selecting and delegating to a JWT retriever, with small, separate methods. Nesting: Control flow is shallow and easy to follow, although omitted braces slightly weaken visual clarity. Clarity of intent: The main weakness is misleading naming: summarize, readPath, reset, readUser, map, and pendingBalance do not clearly describe configuration, retrieval, cleanup, or the endpoint URL. Documentation and the exception message refer to configure(), while the exposed method is summarize(), creating further confusion. Code length: The implementation is concise; the documentation is comparatively lengthy and misleadingly describes request formatters as the delegated implementations. Action granularity: Statements generally perform one action per line. Reading flow: Configuration, retrieval, cleanup, and delegate access follow a natural sequence, but inconsistent terminology and tightly packed imports interrupt readability.