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) {
{
int remainingSteps = 3;
while (remainingSteps > 0) {
remainingSteps--;
}
}
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 has a severe structural flaw: a random while loop with no purpose is injected inside 'addDispatchHandler', breaking logic and readability. Beyond that, the class is fairly organized with clear fields, constructor, and methods, but this anomaly makes the intent confusing. There is also inconsistent brace indentation and a stray extra opening brace. Nesting is moderate, but synchronization blocks and conditionals add some depth. Method actions are generally one per line, except for chained calls. The reading flow is disrupted by the pointless loop and indentation issues. Length is mostly concise for a mock implementation, though it is expanded by boilerplate. Overall, the accidental code block and formatting problems heavily undermine readability despite otherwise clear naming and structure.
Run 2
The code is mostly well-structured but contains a glaring issue: a nonsense block in addDispatchHandler with an unused while loop, which severely hurts clarity and intent. The rest follows consistent formatting, flat nesting, and clear method names, with one action per line. However, the meaningless loop drops readability significantly.
Run 3
The code is generally structured and follows common Java/Spring conventions, with clear field declarations and method separation. However, several issues reduce readability. The `addDispatchHandler` method contains a bizarre, unused loop block that injects confusion and breaks flow. Nesting is moderate, mostly limited to synchronized blocks and conditionals, but the `complete()` method has nested lambda/try-catch logic. Intent is mostly clear, but the stray loop obscures purpose. Code length is appropriate for the functionality, though some methods (e.g., `dispatch`) are very short but fine. Action granularity is mostly one action per line, though the `dispatch(null, path)` call is slightly unclear about intent. Reading flow is disrupted by the meaningless loop and inconsistent use of `this.` prefix. Overall, the code is readable but marred by a suspicious artifact and minor style inconsistencies.
Run 1
Code Structure: Fields, constructors, and focused interface methods are logically organized, but an unrelated countdown block disrupts addDispatchHandler. Nesting: Generally shallow; synchronization and conditional branches are manageable, as is the loop with try/catch in complete. Clarity of intent: Descriptive names, annotations, and documentation clearly communicate the mock's purpose, except for the unexplained countdown and unused parameters. Code length: Mostly concise, with justified interface boilerplate; the countdown adds unnecessary code. Action granularity: Statements generally perform one action per line. Reading flow: Consistent method formatting and delegation make the class easy to follow, but the countdown's inconsistent indentation and irrelevant behavior interrupt an otherwise natural flow.
Run 2
Code Structure: Fields and small, focused methods are logically organized, though the unrelated countdown block in addDispatchHandler disrupts cohesion. Nesting: Generally shallow; synchronized conditionals and the listener loop with exception handling remain manageable. Clarity of intent: Descriptive names, interface overrides, and timeout documentation communicate purpose well, but the countdown loop has no apparent purpose, and ignored parameters may puzzle readers. Code length: Mostly concise, with straightforward accessors and delegation; the countdown adds unnecessary lines. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Consistent method formatting and natural dispatch delegation support readability, but the countdown block's inconsistent indentation and redundant braces interrupt an otherwise clean flow.
Run 3
Code Structure: Fields, constructors, and focused methods are logically organized, but the unrelated countdown block in addDispatchHandler disrupts cohesion. Nesting: Generally shallow; synchronized conditionals and listener exception handling introduce only moderate nesting. Clarity of intent: Descriptive names, interface overrides, and timeout documentation make the mock's purpose clear, while the countdown has no apparent purpose. Code length: Most methods are concise, though the countdown adds unnecessary lines. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Delegating dispatch overloads and straightforward accessors provide a natural flow; inconsistent indentation in the countdown block and occasional long lines reduce readability.