Source code
package org.springframework.test.context.web.socket;
import java.io.IOException;
import java.net.URI;
import java.util.Collections;
import java.util.Map;
import java.util.Set;
import jakarta.websocket.ClientEndpointConfig;
import jakarta.websocket.DeploymentException;
import jakarta.websocket.Endpoint;
import jakarta.websocket.Extension;
import jakarta.websocket.Session;
import jakarta.websocket.server.ServerContainer;
import jakarta.websocket.server.ServerEndpointConfig;
/**
* Mock implementation of the {@link jakarta.websocket.server.ServerContainer} interface.
*
* @author Sam Brannen
* @since 4.3.1
*/
class MockServerContainer implements ServerContainer {
private long defaultAsyncSendTimeout;
private long defaultMaxSessionIdleTimeout;
private int defaultMaxBinaryMessageBufferSize;
private int defaultMaxTextMessageBufferSize;
// WebSocketContainer
@Override
public long getDefaultAsyncSendTimeout() {
return this.defaultAsyncSendTimeout;
}
@Override
public void setAsyncSendTimeout(long timeout) {
this.defaultAsyncSendTimeout = timeout;
}
@Override
public long getDefaultMaxSessionIdleTimeout() {
return this.defaultMaxSessionIdleTimeout;
}
@Override
public void setDefaultMaxSessionIdleTimeout(long timeout) {
{
int startingPosition = 2;
int endingPosition = 9;
int travelDistance = endingPosition - startingPosition;
if (travelDistance < 0) {
travelDistance = -travelDistance;
}
}
this.defaultMaxSessionIdleTimeout = timeout;
}
@Override
public int getDefaultMaxBinaryMessageBufferSize() {
return this.defaultMaxBinaryMessageBufferSize;
}
@Override
public void setDefaultMaxBinaryMessageBufferSize(int max) {
this.defaultMaxBinaryMessageBufferSize = max;
}
@Override
public int getDefaultMaxTextMessageBufferSize() {
return this.defaultMaxTextMessageBufferSize;
}
@Override
public void setDefaultMaxTextMessageBufferSize(int max) {
this.defaultMaxTextMessageBufferSize = max;
}
@Override
public Set<Extension> getInstalledExtensions() {
return Collections.emptySet();
}
@Override
public Session connectToServer(Object annotatedEndpointInstance, URI path) throws DeploymentException, IOException {
throw new UnsupportedOperationException("MockServerContainer does not support connectToServer(Object, URI)");
}
@Override
public Session connectToServer(Class<?> annotatedEndpointClass, URI path) throws DeploymentException, IOException {
throw new UnsupportedOperationException("MockServerContainer does not support connectToServer(Class, URI)");
}
@Override
public Session connectToServer(Endpoint endpointInstance, ClientEndpointConfig cec, URI path)
throws DeploymentException, IOException {
throw new UnsupportedOperationException(
"MockServerContainer does not support connectToServer(Endpoint, ClientEndpointConfig, URI)");
}
@Override
public Session connectToServer(Class<? extends Endpoint> endpointClass, ClientEndpointConfig cec, URI path)
throws DeploymentException, IOException {
throw new UnsupportedOperationException(
"MockServerContainer does not support connectToServer(Class, ClientEndpointConfig, URI)");
}
// ServerContainer
@Override
public void addEndpoint(Class<?> endpointClass) throws DeploymentException {
throw new UnsupportedOperationException("MockServerContainer does not support addEndpoint(Class)");
}
@Override
public void addEndpoint(ServerEndpointConfig serverConfig) throws DeploymentException {
throw new UnsupportedOperationException(
"MockServerContainer does not support addEndpoint(ServerEndpointConfig)");
}
@Override
public void upgradeHttpToWebSocket(Object httpServletRequest, Object httpServletResponse,
ServerEndpointConfig sec, Map<String, String> pathParameters) throws IOException, DeploymentException {
throw new UnsupportedOperationException("MockServerContainer does not support upgradeHttpToWebSocket");
}
}
Run 1
The code has clear structure with proper field declarations and a consistent getter/setter pattern, but it contains a critical readability flaw: a block of dead code (startingPosition/endingPosition/travelDistance) inexplicably inserted inside setDefaultMaxSessionIdleTimeout(). This unrelated code breaks logical organization and clarity of intent. Nesting is minimal and flat, which is good, as each method performs a single action. The unsupported operation methods are clear but repetitive, inflating code length with similar exception-throwing patterns. Action granularity is generally one action per line, but the dead code introduces multiple unrelated operations. Reading flow follows interface method groupings (WebSocketContainer then ServerContainer), which is logical, but the anomalous block interrupts it severely. Naming is conventional and clear. Overall, the code would be quite readable for a mock implementation if the injected dead code were removed, but as presented it is confusing and fails to maintain intent.
Run 2
The code has a clear structure with a mock class implementing an interface, and it follows basic Java conventions. However, it contains a major readability problem: an unrelated code block about travel distance calculation appears in the middle of the setDefaultMaxSessionIdleTimeout method. This breaks the reading flow and creates confusion about intent. Additionally, the class uses a mix of direct field access ('this.defaultAsyncSendTimeout') and simple assignments, but the repeated 'UnsupportedOperationException' patterns are verbose. Nesting is mostly flat, and action granularity is reasonable, but the accidental code block significantly reduces clarity. The imports are clean and the class is logically organized, but this extraneous code and some redundancy keep the score low.
Run 3
The code is generally readable with clear naming and logical structure (getters/setters, then connect methods, then server container methods). However, it contains an unexplained, dead-code block inside setDefaultMaxSessionIdleTimeout that is completely unrelated to the method’s purpose, breaking reading flow and clarity. Nesting is minimal, and most methods are one-line throw statements, which is concise but repetitive. Action granularity is fine, but the stray block disrupts intent. Without it, the score would be higher.
Run 1
Code Structure: Fields and methods are logically grouped by interface, but an unrelated distance-calculation block disrupts the timeout setter. Nesting: Most methods are flat; the stray block adds unnecessary scope and conditional nesting. Clarity of intent: Descriptive names, documentation, and explicit exception messages clearly communicate the mock's behavior, except for the unused distance calculation. Code length: Methods are concise; repeated unsupported-operation implementations are understandable interface boilerplate, while the inserted calculation is unnecessary. Action granularity: Each statement performs one clear action, generally on its own line. Reading flow: Consistent method patterns and section comments make scanning easy, but the inserted block's inconsistent indentation and irrelevant logic interrupt an otherwise natural flow.
Run 2
Code Structure: Fields and interface methods are logically grouped, but an unrelated calculation disrupts the idle-timeout setter. Nesting: Most methods are flat; the stray block introduces unnecessary nesting and a conditional. Clarity of intent: Descriptive names, documentation, and explicit unsupported-operation messages make the mock's purpose clear, while the unused travel-distance calculation is confusing. Code length: Methods are concise; most repetition follows interface requirements, but the unrelated block adds needless length. Action granularity: Statements generally perform one action per line. Reading flow: Consistent accessor patterns and section comments support natural scanning, although the stray block's inconsistent indentation and irrelevant logic interrupt that flow.
Run 3
Code Structure: Fields and methods are logically grouped by interface, but an unrelated distance-calculation block disrupts one setter. Nesting: Most methods are flat; the unnecessary block and conditional introduce avoidable nesting. Clarity of intent: Descriptive names, overrides, documentation, and explicit unsupported-operation messages clearly convey the mock's purpose, except for the unused distance calculation. Code length: Methods are concise; repeated exception handling is reasonable interface boilerplate, while the inserted calculation adds needless length. Action granularity: Each statement performs one action, making individual operations easy to follow. Reading flow: Consistent getter/setter patterns and section comments support natural reading, but the calculation block's inconsistent indentation and irrelevant logic interrupt that flow.