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) {
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 is highly readable due to its clear structure: it is organized into logical sections (WebSocketContainer methods and ServerContainer methods) with comments separating them. Nesting is completely flat, with no conditional blocks or deep indentation. Each method has a clear, single purpose—either returning a simple value or throwing an UnsupportedOperationException—making the intent unambiguous. The code is concise and avoids unnecessary verbosity, with one action per line for throws and returns. Reading flow is natural, following the interface method order and grouping related functionality. Import statements and class-level Javadoc are clean. The only minor deduction is the slight repetition in exception messages, which could be refactored to a helper method, but this does not significantly harm readability.
Run 2
The code is highly readable with clear structure and organization. It groups methods logically under section comments (WebSocketContainer, ServerContainer), maintains a flat structure with minimal nesting, and uses descriptive method names. Each method performs a single action (returning a value or throwing an exception), and the reading flow is natural and consistent. The code is concise without sacrificing clarity - even the unsupported operations are handled uniformly with informative error messages. Minor improvements could include removing some blank lines between related methods to tighten the visual grouping, but overall this is exemplary readable code that follows clean coding principles.
Run 3
The code is highly readable. It has a clear, logical structure with fields grouped at the top and methods organized by interface (WebSocketContainer, ServerContainer). Nesting is minimal—only in the throws clause of connectToServer methods, but still flat overall. Intent is explicit: it's a mock implementation, and every unsupported operation clearly states what is not supported. Code length is concise; each method is short and necessary for interface implementation. Action granularity is one action per line (e.g., throwing exceptions). Reading flow is natural: getters/setters are paired, and unsupported methods are consistent. Minor deduction for repetition in unsupported method messages and lengthy method signatures, but overall excellent readability.
Run 1
Code Structure: Fields and methods are logically organized, with interface sections clearly labeled. Nesting: Methods are flat, with no nested control flow. Clarity of intent: The class documentation, descriptive field and method names, and explicit exception messages clearly convey the mock's capabilities and limitations; abbreviated parameters such as cec and sec are slightly less clear. Code length: The implementation is concise for the required interface, though repetitive unsupported-operation methods add boilerplate. Action granularity: Each statement performs a single action, and each method has a narrow responsibility. Reading flow: Consistent formatting, adjacent getter/setter pairs, and predictable method patterns make the code easy to follow; a few long signatures and exception messages slightly interrupt the flow.
Run 2
Code Structure: Fields and methods are logically organized, with interface-specific sections clearly labeled. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, class documentation, and explicit exception messages clearly communicate the mock's capabilities and unsupported operations; abbreviated parameters such as cec and sec slightly reduce clarity. Code length: Mostly concise, though interface-required boilerplate and repeated exception messages add length. Action granularity: Each statement performs a single action, making individual methods easy to understand. Reading flow: Consistent formatting, predictable getter/setter ordering, and section comments support natural reading; a few long signatures and wrapped exception messages introduce minor friction.
Run 3
Code Structure: Fields, accessors, and interface methods are logically organized, with section comments separating responsibilities. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, class documentation, and explicit exception messages clearly communicate the mock's supported and unsupported behavior; abbreviated parameters such as cec and sec are slightly less clear. Code length: The implementation is concise for the interface requirements, although repetitive unsupported-operation methods add unavoidable boilerplate. Action granularity: Each statement performs a single action, making individual methods easy to scan. Reading flow: Consistent formatting and predictable method ordering support natural reading, with only minor distractions from long signatures, long exception messages, and extra blank lines.