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. It has a clear, logical structure with grouped methods (WebSocketContainer section and ServerContainer section) and consistent separation using comments. Nesting is minimal—only one level for method bodies. Intent is unambiguous: this is a mock implementation where unsupported operations throw clear, descriptive exceptions. Code length is appropriate; getters/setters are concise, and repeated unsupported-operation methods are unavoidable due to interface requirements. Action granularity is good—one statement per line. Reading flow is natural, with imports organized and methods ordered logically. Minor deductions: some lines exceed typical length limits (exception messages and method signatures), and the repetitive pattern could be slightly verbose, but it remains easy to scan and understand.
Run 3
The code is highly readable. It follows a clear, consistent structure with logical grouping via comments (WebSocketContainer vs ServerContainer). There is no deep nesting; methods are simple getters/setters or throw exceptions. Intent is explicit, particularly in exception messages. Each method performs one action, and formatting (spacing between methods, line breaks) enhances flow. Minor deductions: many similar methods are verbose but necessary for the interface. Overall, straightforward and easy to follow.
Run 1
Code Structure: Fields and methods are logically organized, with comments separating WebSocketContainer and ServerContainer responsibilities. Nesting: Methods are flat, with no nested control flow. Clarity of intent: The class documentation, descriptive field names, and explicit unsupported-operation messages clearly communicate the mock's limited behavior; abbreviated parameters such as cec and sec are slightly less clear. Code length: The implementation is concise for the required interface, though exception messages and accessor methods introduce repetitive boilerplate. Action granularity: Each statement performs one clear action, with no compressed multi-action lines. Reading flow: Consistent formatting and paired getters/setters make the code easy to scan; a few long signatures and wrapped exception messages slightly interrupt the otherwise natural flow.
Run 2
Code Structure: Fields and methods are logically grouped, with comments separating WebSocketContainer and ServerContainer responsibilities. Nesting: Methods are flat, with no nested control flow. Clarity of intent: The class documentation, descriptive property names, and explicit unsupported-operation messages clearly communicate the mock's limited behavior; abbreviated parameters such as cec and sec are slightly less clear. Code length: Methods are concise, though interface-required boilerplate and repeated exception messages add length. Action granularity: Each statement performs a single action, making behavior easy to scan. Reading flow: Consistent formatting and predictable getter/setter pairs provide a natural progression, with only minor interruptions from long signatures and wrapped exception messages.
Run 3
Code Structure: Fields and methods are logically organized, with comments separating WebSocketContainer and ServerContainer responsibilities. Nesting: Methods are flat, with no nested control flow. Clarity of intent: The class documentation, descriptive method and field names, and explicit unsupported-operation messages clearly communicate the mock's limited behavior. Code length: The implementation is concise for the interface it implements; repeated accessors and exception throws are largely necessary boilerplate. Action granularity: Each statement performs a single assignment, return, or throw. Reading flow: Consistent formatting and paired getters/setters make the code easy to scan. Minor drawbacks include abbreviated parameters such as cec and sec, several long signatures and exception messages, and the lack of spacing between the package declaration and import groups.