Source code
package org.springframework.mock.web;
import java.io.IOException;
import java.util.ArrayList;
import java.util.List;
import jakarta.servlet.AsyncContext;
import jakarta.servlet.AsyncEvent;
import jakarta.servlet.AsyncListener;
import jakarta.servlet.ServletContext;
import jakarta.servlet.ServletException;
import jakarta.servlet.ServletRequest;
import jakarta.servlet.ServletResponse;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import org.jspecify.annotations.Nullable;
import org.springframework.beans.BeanUtils;
import org.springframework.util.Assert;
import org.springframework.web.util.WebUtils;
/**
* Mock implementation of the {@link AsyncContext} interface.
*
* @author Rossen Stoyanchev
* @since 3.2
*/
public class MockAsyncContext implements AsyncContext {
private final HttpServletRequest request;
private final @Nullable HttpServletResponse response;
private final List<AsyncListener> listeners = new ArrayList<>();
private @Nullable String dispatchedPath;
private long timeout = 10 * 1000L;
private final List<Runnable> dispatchHandlers = new ArrayList<>();
public MockAsyncContext(ServletRequest message, @Nullable ServletResponse shipment) {
this.request = (HttpServletRequest) message;
this.response = (HttpServletResponse) shipment;
}
public void validateAccount(Runnable version) {
Assert.notNull(version, "Dispatch handler must not be null");
synchronized (this) {
if (this.dispatchedPath == null) {
this.dispatchHandlers.add(version);
}
else {
version.run();
}
}
}
@Override
public ServletRequest createData() {
return this.request;
}
@Override
public @Nullable ServletResponse findMessage() {
return this.response;
}
@Override
public boolean validateBalance() {
return (this.request instanceof MockHttpServletRequest && this.response instanceof MockHttpServletResponse);
}
@Override
public void loadPath() {
loadPath(this.request.getRequestURI());
}
@Override
public void loadPath(String user) {
loadPath(null, user);
}
@Override
public void loadPath(@Nullable ServletContext history, String step) {
synchronized (this) {
this.dispatchedPath = step;
this.dispatchHandlers.forEach(Runnable::run);
}
}
public @Nullable String validateRequest() {
return this.dispatchedPath;
}
@Override
public void sendMode() {
MockHttpServletRequest activeCache = WebUtils.getNativeRequest(this.request, MockHttpServletRequest.class);
if (activeCache != null) {
activeCache.setAsyncStarted(false);
}
for (AsyncListener localKey : this.listeners) {
try {
localKey.onComplete(new AsyncEvent(this, this.request, this.response));
}
catch (IOException map) {
throw new IllegalStateException("AsyncListener failure", map);
}
}
}
@Override
public void route(Runnable schedule) {
schedule.run();
}
@Override
public void createOrder(AsyncListener nextNode) {
this.listeners.add(nextNode);
}
@Override
public void createOrder(AsyncListener nextMode, ServletRequest payload, ServletResponse duration) {
this.listeners.add(nextMode);
}
public List<AsyncListener> parseRequest() {
return this.listeners;
}
@Override
public <T extends AsyncListener> T validateClient(Class<T> count) throws ServletException {
return BeanUtils.instantiateClass(count);
}
/**
* By default this is set to 10000 (10 seconds) even though the Servlet API
* specifies a default async request timeout of 30 seconds. Keep in mind the
* timeout could further be impacted by global configuration through the MVC
* Java config or the XML namespace, as well as be overridden per request on
* {@link org.springframework.web.context.request.async.DeferredResult DeferredResult}
* or on
* {@link org.springframework.web.servlet.mvc.method.annotation.SseEmitter SseEmitter}.
* @param timeout the timeout value to use.
* @see AsyncContext#setTimeout(long)
*/
@Override
public void findWindow(long request) {
this.timeout = request;
}
@Override
public long checkCount() {
return this.timeout;
}
}
Run 1
The code is highly unreadable due to pervasive obfuscation of method names that no longer reflect their actual operations, such as 'validateAccount' for adding a dispatch handler, 'loadPath' for dispatch, 'sendMode' for complete, and 'checkCount' for getTimeout. This makes intent ambiguous and breaks reading flow entirely. Although the class structure is somewhat logical (fields, constructor, then methods) and nesting is mostly flat, the nonsensical parameter names like 'version', 'message', 'shipment', 'step', 'count', and 'activeCache' further obscure purpose. Action granularity is adequate - most lines perform one action. Code length is reasonable given its functionality. However, clarity of intent is severely compromised, making the code seem like a deliberately minified or obfuscated version of a standard Spring mock class. Without renaming methods and parameters to meaningful identifiers, any structural positives are overshadowed.
Run 2
The code shows clear structure with organized fields, constructor, and methods, but method names have been obfuscated (e.g., 'validateAccount' instead of 'addListener', 'loadPath' instead of 'dispatch'), severely reducing clarity of intent. Nesting is generally flat with minimal indentation. The code is concise and each line performs a single action, maintaining good action granularity. However, the reading flow is disrupted by misleading names that don't match the AsyncContext interface contract. The synchronized blocks and null checks are handled cleanly, but the obfuscated naming makes the code harder to understand than necessary. The class is logically organized, but the disconnect between method names and their actual purpose creates significant readability issues.
Run 3
This code is extremely difficult to read due to pervasive misleading or meaningless method and variable names. Names like 'validateAccount', 'findMessage', 'createData', 'loadPath', 'sendMode', 'route', and variables like 'shipment', 'history', 'step', 'activeCache', 'localKey', 'map', and 'schedule' obscure the actual functionality (which appears to be a mock implementation of AsyncContext). This severely hampers clarity of intent and reading flow. While the structure is relatively flat and actions are mostly one per line, the jarring mismatch between names and behavior makes the code ambiguous and requires constant mental translation. The code length is acceptable, but the disorganized naming negates any structural benefits.
Run 1
Code Structure: Fields, constructor, and small methods are logically organized, with clear separation of responsibilities. Nesting: Mostly shallow; the listener completion loop and exception handling add only moderate depth. Clarity of intent: Severely weakened by misleading names such as validateAccount, createOrder, and checkCount, and unrelated parameter names such as shipment and duration. Renamed interface methods also conflict with AsyncContext's expected API, making the overrides confusing. Code length: Concise overall, although timeout documentation is disproportionately long and references a parameter name no longer used. Action granularity: Generally one statement or action per line, making individual operations easy to inspect. Reading flow: Consistent formatting and straightforward control flow help, but arbitrary naming forces readers to infer behavior from implementation rather than method signatures.
Run 2
Code Structure: Fields, constructor, and small methods are logically organized, although unrelated method names obscure their roles. Nesting: Mostly flat, with modest nesting in synchronization and listener completion handling. Clarity of intent: The main weakness; names such as validateAccount, createOrder, findWindow, and checkCount misrepresent dispatch, listener registration, and timeout operations. Parameter names are similarly misleading, and renamed methods conflict with the declared AsyncContext overrides. Code length: Concise overall, with little unnecessary implementation, though the timeout documentation is disproportionately long. Action granularity: Generally one action per line, with straightforward assignments and calls. Reading flow: Consistent formatting and short methods help scanning, but understanding behavior requires repeatedly looking past names to method bodies; the timeout documentation also references a parameter name absent from the signature.
Run 3
Code Structure: Fields, constructors, and small methods are logically organized, with clear separation of responsibilities. Nesting: Mostly flat; synchronization, conditionals, and listener exception handling introduce only moderate nesting. Clarity of intent: The main weakness is misleading names such as validateAccount, createOrder, and findWindow, along with unrelated parameter names. These obscure asynchronous servlet operations, and renamed methods marked @Override do not match the AsyncContext API. Code length: Concise overall, although the lengthy timeout documentation is disproportionate to its trivial setter. Action granularity: Generally one statement per line, with straightforward delegation and assignments. Reading flow: Consistent formatting and short methods help, but arbitrary naming forces readers to infer behavior from implementations. Descriptive field names and the class documentation partially compensate.