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 request, @Nullable ServletResponse response) {
this.request = (HttpServletRequest) request; this.response = (HttpServletResponse) response;
}
public void addDispatchHandler(Runnable handler) { Assert.notNull(handler, "Dispatch handler must not be null");
synchronized (this) {
if (this.dispatchedPath == null) {
this.dispatchHandlers.add(handler); }
else { handler.run();
} } } @Override public ServletRequest getRequest() {
return this.request; } @Override public @Nullable ServletResponse getResponse() { return this.response; }
@Override
public boolean hasOriginalRequestAndResponse() {
return (this.request instanceof MockHttpServletRequest && this.response instanceof MockHttpServletResponse); } @Override public void dispatch() {
dispatch(this.request.getRequestURI()); }
@Override public void dispatch(String path) {
dispatch(null, path);
} @Override
public void dispatch(@Nullable ServletContext context, String path) {
synchronized (this) {
this.dispatchedPath = path;
this.dispatchHandlers.forEach(Runnable::run);
}
} public @Nullable String getDispatchedPath() { return this.dispatchedPath;
} @Override
public void complete() {
MockHttpServletRequest mockRequest = WebUtils.getNativeRequest(this.request, MockHttpServletRequest.class);
if (mockRequest != null) {
mockRequest.setAsyncStarted(false);
}
for (AsyncListener listener : this.listeners) {
try {
listener.onComplete(new AsyncEvent(this, this.request, this.response));
}
catch (IOException ex) { throw new IllegalStateException("AsyncListener failure", ex);
}
} }
@Override
public void start(Runnable runnable) {
runnable.run();
}
@Override
public void addListener(AsyncListener listener) {
this.listeners.add(listener);
} @Override public void addListener(AsyncListener listener, ServletRequest request, ServletResponse response) {
this.listeners.add(listener);
} public List<AsyncListener> getListeners() {
return this.listeners; } @Override
public <T extends AsyncListener> T createListener(Class<T> clazz) throws ServletException { return BeanUtils.instantiateClass(clazz); } /**
* 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 setTimeout(long timeout) {
this.timeout = timeout; } @Override public long getTimeout() {
return this.timeout;
} }
Run 1
The code is largely unreadable due to severe formatting problems. Multiple statements are crammed onto single lines (e.g., field declarations, method signatures, and bodies), making the code dense and difficult to scan. The inconsistent indentation and line breaks break visual hierarchy, so methods don't stand out. While method names and logic are relatively clear, the tangled presentation obscures intent. Nesting is minimal, which is a positive, but action granularity fails badly because many lines combine multiple actions. The reading flow is disorganized, forcing the reader to mentally unpack every line. Although the underlying logic is straightforward, the formatting makes it unnecessarily hard to navigate. To improve, each field declaration, method, and statement should appear on its own line with consistent indentation.
Run 2
The code suffers from severe readability issues primarily due to formatting. Imports are crammed onto single lines, and multiple actions or declarations frequently share one line, violating the 'one action per line' principle. This makes the code visually dense and disrupts reading flow. While the class structure itself is logical and method names are clear, the inconsistent spacing and inline braces make the code appear tangled. Nesting is generally flat, but the formatting undermines clarity of intent. The code length is not excessive, but the lack of line breaks makes it feel longer and harder to scan. Overall, the structure and intent are sound, but poor formatting drastically reduces readability.
Run 3
The code is difficult to read due to multiple formatting problems. Imports are collapsed onto single lines, and method declarations frequently share lines with other code, violating one-action-per-line. Many opening braces are placed on the same line as the preceding statement rather than on their own line, disrupting visual structure. Some method bodies are crammed together without spacing, and there are inconsistencies in brace style and indentation. While the class has a clear purpose and logical organization at a high level, the lack of consistent formatting significantly increases cognitive load. Nested structures like synchronized blocks and loops are not visually delineated well. The Javadoc is present but embedded in a way that hurts readability. Overall, the code would benefit from consistent line breaks, properly placed braces, and one statement per line.
Run 1
Code Structure: Fields and methods are logically grouped within a focused class, but compressed declarations and method boundaries obscure that organization. Nesting: Mostly shallow; synchronization, conditionals, and listener exception handling introduce manageable nesting. Clarity of intent: Descriptive names, interface overrides, and documentation make the mock async behavior understandable. Code length: Methods are appropriately short, with little unnecessary logic; compression saves lines rather than improving readability. Action granularity: Multiple imports, field declarations, assignments, and entire methods share lines, making individual actions harder to distinguish. Reading flow: Inconsistent indentation, crowded braces, and annotations or comments attached to preceding statements repeatedly interrupt scanning. The underlying implementation is straightforward, but poor formatting substantially reduces readability.
Run 2
Code Structure: Fields and methods form a logically organized mock implementation, but merged declarations and method boundaries obscure that organization. Nesting: Generally shallow; synchronization, conditionals, and listener exception handling introduce only moderate nesting. Clarity of intent: Descriptive names, interface overrides, and documentation make behavior mostly clear. Code length: Methods are concise, with little unnecessary code, although excessive line compression harms readability. Action granularity: Multiple imports, field declarations, assignments, and method definitions share lines, making individual actions harder to distinguish. Reading flow: Inconsistent indentation, crowded braces, and annotations attached to preceding methods repeatedly interrupt scanning. The underlying design is readable, but formatting substantially reduces accessibility.
Run 3
Code Structure: Fields and methods have sensible responsibilities, but compressed declarations and inconsistent formatting obscure their boundaries. Nesting: Mostly shallow; synchronization, conditionals, and exception handling introduce only moderate nesting. Clarity of intent: Descriptive names, standard interface methods, and documentation make the mock asynchronous behavior understandable. Code length: Implementation is reasonably concise, with little unnecessary logic, although excessive compression sacrifices readability. Action granularity: Multiple imports, assignments, declarations, and method boundaries share lines, making individual actions harder to distinguish. Reading flow: Irregular indentation, crowded annotations, and closing braces attached to subsequent methods repeatedly interrupt scanning. The underlying design is readable, but presentation substantially reduces accessibility.