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 well-structured, with clear separation of concerns and consistent naming conventions. Methods are concise and focused, generally performing a single action or a small set of related actions. Nesting is minimal, limited to simple conditional blocks and loops. Intent is clear from method names and field declarations. The only minor issues are the use of synchronized blocks in a few methods, which slightly interrupt the reading flow, and the complete() method which catches IOException and wraps it in an IllegalStateException, adding a small layer of complexity. Overall, it is highly readable and maintainable.
Run 2
The code is highly readable with clear structure and intent. It follows a logical organization with fields, constructor, then methods grouped by functionality. Nesting is minimal, with only one synchronized block and a simple loop containing a try-catch. Each method performs a single, well-defined action, and variable names are descriptive. The methods are concise and follow a natural reading flow. Minor deductions: the dispatch() method with three overloads could be slightly simplified, and the Javadoc on setTimeout is quite long. Overall, this is excellent, maintainable code that adheres to clean code principles.
Run 3
The code is well-structured with clear separation of fields, constructors, and methods. It follows consistent naming conventions and maintains a flat structure with minimal nesting. Intent is evident from method names and the single additional comment explains the non-standard timeout default. Most methods are concise, performing one logical action per line, and the synchronized block in addDispatchHandler is clear. Reading flow is natural as methods are grouped logically. Minor deductions: the dispatch(context, path) method ignores the context parameter without comment, and addListener overloads simply add to a list without null checks, which could be slightly ambiguous. Overall highly readable.
Run 1
1. Code Structure: Fields, constructor, and small interface methods are logically organized with clear separation. 2. Nesting: Mostly flat; synchronization with conditionals and the listener loop with exception handling introduce only modest nesting. 3. Clarity of intent: Descriptive names, annotations, and documentation make the mock's purpose clear. However, ignored parameters in dispatch and addListener, and synchronous execution in start, could benefit from brief explanations. 4. Code length: Methods are concise and avoid duplication through delegation; timeout documentation is lengthy but useful. 5. Action granularity: Statements generally perform one action per line, with straightforward assignments and calls. 6. Reading flow: Consistent formatting and simple control flow support easy reading, though imports lack grouping and related dispatch methods are separated by request accessors.
Run 2
Code Structure: Fields, constructor, and focused interface methods are logically organized, with dispatch overloads grouped together. Nesting: Mostly flat; synchronization and listener exception handling introduce only modest nesting. Clarity of intent: Descriptive names, annotations, and documentation make the mock's purpose clear, although ignored parameters and synchronous execution of async operations could use brief explanations. Code length: Concise overall; repetitive accessors and overloads are appropriate for implementing the interface, while timeout documentation is somewhat lengthy. Action granularity: Statements generally perform one action per line, and delegation keeps methods focused. Reading flow: Consistent formatting and straightforward control flow make the class easy to follow. Minor weaknesses include densely grouped imports, a long boolean expression, and limited explanation of mock-specific behavior.
Run 3
Code Structure: Fields, constructor, and focused interface methods are logically organized, with clear separation of responsibilities. Nesting: Mostly flat; synchronization with conditionals and the listener loop with exception handling introduce only modest nesting. Clarity of intent: Descriptive names, interface overrides, and timeout documentation make the mock's purpose clear. However, ignored parameters and synchronous execution of asynchronous operations could benefit from explanatory comments. Code length: Methods are concise and appropriate for the interface; some boilerplate and extensive timeout documentation add length without substantially hindering readability. Action granularity: Statements generally perform one action per line, and delegation is straightforward. Reading flow: Consistent formatting and simple dispatch overloads support natural reading, though tightly packed imports and extra blank lines slightly weaken visual organization.