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 configure(Map<String, ?> configs, String saslMechanism, List<AppConfigurationEntry> jaasConfigEntries) {
ConfigurationUtils cu = new ConfigurationUtils(configs, saslMechanism);
URL tokenEndpointUrl = cu.validateUrl(SASL_OAUTHBEARER_TOKEN_ENDPOINT_URL);
if (!((tokenEndpointUrl.getProtocol().toLowerCase(Locale.ROOT).equals("file")))) { delegate = new ClientCredentialsJwtRetriever(); } else { delegate = new FileJwtRetriever(); }
LOG.debug("Created instance of {} as delegate", delegate.getClass().getName());
delegate.configure(configs, saslMechanism, jaasConfigEntries);
}
@Override
public String retrieve() throws JwtRetrieverException {
if (!((delegate == null))) {} else { throw new IllegalStateException("JWT retriever delegate is null; please call configure() first"); }
return delegate.retrieve();
}
@Override
public void close() throws IOException {
Utils.closeQuietly(delegate, "JWT retriever delegate");
}
JwtRetriever delegate() {
return delegate;
}
}
Run 1
The code has a clear class purpose and good Javadoc, but readability suffers from several issues. The main problems are unnecessarily complex conditional expressions with double negatives (e.g., 'if (!((tokenEndpointUrl.getProtocol().toLowerCase(Locale.ROOT).equals("file"))))' and 'if (!((delegate == null))) {} else { throw ... }'). The inline if-else statements compress multiple actions into single lines, hurting readability. The retrieve() method uses a confusing empty if block with an else clause instead of a straightforward null check. The configure() method mixes configuration setup and delegation logic. While the overall structure is logical, the nesting depth in conditionals and the use of negation patterns make the code harder to parse than necessary. The method names are clear, but the actual implementation style undermines the otherwise good organization.
Run 2
The code is generally organized with clear class structure and imports, but readability is hampered by several issues. The configure method contains a long, complex conditional with awkward negation and single-line if-else that hurts clarity. The null-check in retrieve() uses a weird pattern with an empty block and negation which is confusing. Magic strings like 'file' could be constants. Some lines are excessively long, violating the 'one action per line' principle. The Javadoc is thorough but dense. The flow is mostly logical but the conditional expressions require extra mental effort. Nesting is shallow which is positive. Variable names like 'cu' are too abbreviated. Overall, the code works but could be significantly more readable with clearer conditionals, better naming, and line breaks.
Run 3
The code has a clear class structure and good documentation but suffers from poor readability in several key areas. The conditional logic is unnecessarily complex: the token endpoint protocol check uses double negation and a one-line if-else with multiple statements, making it hard to parse. Similarly, the retrieve() method contains a bizarre construct that checks for null on one branch but throws on the else, obfuscating the intent. Variable names are inconsistent - 'cu' is cryptic while 'tokenEndpointUrl' is descriptive. The configure method performs multiple actions per line in the conditional statement, violating action granularity principles. Reading flow is disrupted by these convoluted conditionals. The overall structure with a delegate pattern is sound, and imports are organized, but the implementation details significantly reduce clarity.
Run 1
Code Structure: The class is logically organized into configuration, retrieval, cleanup, and delegate access, with a straightforward delegation design. Nesting: Nesting is shallow, but excessive parentheses and inverted conditions complicate otherwise simple checks. Clarity of intent: Method names and delegation make the purpose clear; however, the empty if branch in retrieve() obscures the null guard, and the documentation references formatter classes rather than the actual HTTP retriever. Code length: The implementation is compact, but compression of conditionals sacrifices readability rather than eliminating unnecessary logic. Action granularity: Both conditionals put conditions, branches, and actions on a single line, making them harder to scan. Reading flow: The overall method order is natural, but dense conditional formatting, redundant negation, the abbreviated variable cu, and tightly packed imports interrupt smooth reading.
Run 2
Code Structure: The class is logically organized into configuration, retrieval, cleanup, and delegate access methods. Nesting: Nesting is shallow, but redundant parentheses and negated conditions make simple branches harder to parse. Clarity of intent: Delegation and URL-based implementation selection are understandable; however, the empty if branch in retrieve() obscures a straightforward null check, and the documentation names formatter classes rather than the actual HTTP retriever. Code length: Methods are concise, though the documentation is comparatively verbose. Action granularity: Most statements occupy separate lines, but both conditional blocks are compressed onto single lines, mixing checks and actions. Reading flow: Method ordering is natural, but dense conditionals, double negatives, and the abbreviated variable name cu interrupt otherwise clear flow.
Run 3
Code Structure: The class is logically organized into configuration, retrieval, cleanup, and delegate access methods. Nesting: Nesting is shallow, but unnecessary parentheses and negated conditions make branches harder to parse. Clarity of intent: Names and delegation make the overall purpose clear, though the empty if branch in retrieve() obscures a simple null check, and the documentation references formatter classes rather than the actual HTTP retriever. Code length: The implementation is compact, but excessive parentheses and verbose documentation add avoidable clutter. Action granularity: Both conditionals compress branches and statements onto single lines, weakening readability despite most other lines containing one action. Reading flow: Method order is natural, but dense conditionals, inverted logic, and tightly packed imports interrupt otherwise straightforward flow.