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;
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);
}
@Override
public void setTimeout(long timeout) {
this.timeout = timeout;
}
@Override
public long getTimeout() {
return this.timeout;
}
}
Run 1
The code is generally well-structured and readable. It follows a logical organization with fields at the top, constructor, and then public API methods. Synchronization blocks are used appropriately in dispatch-related methods. The nesting is minimal, with only one level of synchronized blocks and a single if-else statement. The intent is clear - this is a mock implementation of AsyncContext for testing. Method names are descriptive and follow Spring conventions. However, there are several issues that reduce readability: multiple consecutive blank lines are inconsistent (2-6 lines in places), the complete() method has a try-catch block that could be clearer, and some methods like addListener have duplicate implementations that could be refactored. The action granularity is good with one operation per line mostly, but the listening iteration in complete() combines exception handling with business logic. The reading flow is natural, moving from request/response access to dispatch operations, then listeners, and finally timeout methods. The imports are clean and specific rather than wildcards.
Run 2
The code demonstrates good readability with clear structure and logical organization. Class fields are grouped logically, methods are well-named, and the implementation is straightforward. Nesting is minimal with only a few flat conditional blocks. Intent is clear throughout — this is a mock implementation of AsyncContext for testing. The code is appropriately concise with no redundant methods or unnecessary complexity. Action granularity is mostly good, though some methods combine multiple operations but remain readable. Reading flow is natural with consistent ordering: constructors, custom methods, then interface implementations. Minor issues include excessive blank lines between method groups, slightly inconsistent use of `this.` prefix, and the `dispatch(String)` method just delegating to `dispatch(null, path)` could be clearer. The `complete()` method handles error cases well but the empty `addListener` overload that ignores parameters could use a comment. Overall, this is solid, maintainable code with only minor style inconsistencies preventing a higher score.
Run 3
The code is generally well-structured and readable. It follows a logical organization with fields, constructors, and methods grouped appropriately. Nesting is minimal, with only a couple of single-level synchronized blocks. Intent is clear through descriptive method names and consistent use of `this` for field access. Action granularity is good—most methods perform one clear action per line. The reading flow is natural, moving from construction to dispatch to lifecycle methods. Minor deductions: several large blank gaps (e.g., before `setTimeout`) disrupt visual flow; unused imports (`ArrayList`, `List` are used, but `ServletContext` is only in signature) and redundant `this.` usage slightly reduce conciseness. Overall, it is clean, maintainable code with no major readability obstacles.
Run 1
Code Structure: Fields, construction, and interface methods are logically organized, with focused responsibilities. Nesting: Mostly flat; synchronization with conditionals and a loop with exception handling introduce only modest nesting. Clarity of intent: Descriptive names, overrides, and nullability annotations make behavior easy to understand, though ignored parameters and synchronous execution in start() could benefit from brief explanations of mock-specific behavior. Code length: Methods are concise, but excessive blank lines unnecessarily stretch the class. Action granularity: Statements generally perform one action per line; delegation and method references remain clear. Reading flow: Consistent formatting and straightforward control flow support natural reading, although large whitespace gaps interrupt continuity.
Run 2
Code Structure: Fields, constructor, and focused interface methods are logically organized. Nesting: Mostly flat, with modest nesting in synchronized blocks and listener exception handling. Clarity of intent: Descriptive names, overrides, and nullable annotations make the purpose clear; ignored parameters and synchronous execution in start() could benefit from brief explanations of mock behavior. Code length: Methods are concise, though excessive blank lines unnecessarily extend the file. Action granularity: Statements generally perform one action per line, and dispatch delegation is straightforward. Reading flow: Consistent formatting and small methods support natural reading, but large whitespace gaps interrupt continuity.
Run 3
Code Structure: Fields, constructor, and focused interface methods are logically organized, though excessive blank lines disrupt grouping. Nesting: Shallow overall; synchronized conditionals and the loop with try/catch remain easy to follow. Clarity of intent: Descriptive names, explicit overrides, and nullable annotations make responsibilities clear. However, ignored parameters and synchronous execution in start() could benefit from brief comments explaining mock behavior. Code length: Methods are concise with little unnecessary logic, but surplus whitespace adds visual length. Action granularity: Statements generally perform one action per line; delegation and method references are compact without obscuring intent. Reading flow: Consistent formatting and straightforward control flow support natural reading, with minor interruptions from whitespace and undocumented mock-specific behavior.