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
This code is highly readable. It has a clear, logical structure with well-organized imports and grouped methods separated by comments for WebSocketContainer and ServerContainer sections. Nesting is essentially flat with no conditional logic. Intent is explicit—every unsupported operation clearly states what is mocked. The getter/setter pairs are straightforward and consistent. Action granularity is one action per line, and the reading flow is natural from configuration methods to connection methods to endpoint registration. Minor deductions: the unused import for Map is unnecessary, and some method signatures wrap awkwardly, but these are trivial. Overall, it's concise, well-documented, and easy to follow.
Run 3
The code is highly readable due to its clear structure, flat nesting, and unambiguous intent. It implements a mock class with straightforward getter/setter pairs and explicit UnsupportedOperationException messages for unimplemented methods. The organization into WebSocketContainer and ServerContainer sections with comments aids navigation. Each method performs a single action, and the consistent formatting supports a natural reading flow. Minor deductions reflect verbose repetition of exception messages and method signatures, which slightly increase length but do not harm clarity.
Run 1
Code Structure: Fields and methods are logically organized, with interface-specific sections clearly labeled. Nesting: Methods are flat and contain no nested control flow. Clarity of intent: Descriptive names, class documentation, and explicit exception messages clearly communicate the mock's supported and unsupported operations; abbreviated parameters such as cec and sec are slightly less clear. Code length: Some repetitive boilerplate and long signatures increase length, but most are required by the interface. Action granularity: Each statement performs a single action, making methods easy to scan. Reading flow: Consistent formatting, paired getters and setters, and predictable method ordering provide a natural reading progression.
Run 2
Code Structure: Fields and methods are logically organized, with comments separating WebSocketContainer and ServerContainer responsibilities. Nesting: All 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 operations; abbreviated parameters such as cec and sec are slightly less clear. Code length: Methods are concise, although interface-required overloads and repeated exception messages add boilerplate. Action granularity: Each statement performs a single action, making behavior easy to scan. Reading flow: Consistent formatting and getter/setter pairing provide a natural progression; long signatures, wrapped messages, and extra blank lines introduce minor visual interruptions.
Run 3
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: The class documentation, descriptive field names, and explicit exception messages make the mock's limited behavior clear; abbreviated parameters such as cec and sec are slightly less descriptive. Code length: The implementation is concise for the required interface, although repeated unsupported-operation methods add unavoidable boilerplate. Action granularity: Each statement performs a single assignment, return, or throw. Reading flow: Consistent formatting, predictable getter/setter pairs, and orderly method grouping make the code easy to scan; a few long signatures and exception messages slightly interrupt the flow.