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 follows a consistent structure, grouping methods by interface sections (WebSocketContainer, ServerContainer) with clear comments. Nesting is minimal, with no deep conditional blocks. Each method has a single clear purpose, typically returning a field or throwing an UnsupportedOperationException. Action granularity is appropriate—one logical operation per line. The reading flow is natural, with getters/setters paired logically and unsupported operations grouped together. The code is concise, avoiding unnecessary verbosity while maintaining clarity. Minor deductions: repetitive UnsupportedOperationException messages could be extracted to constants, and some methods signatures are long, but overall readability is excellent.
Run 3
The code is highly readable. It follows a clean, consistent structure with clear section comments separating WebSocketContainer and ServerContainer method groups. Nesting is flat—no conditional or loop complexity. Each method's intent is unambiguous, simply returning defaults or throwing UnsupportedOperationException with descriptive messages. The code is concise; no excessive boilerplate beyond what the interface requires. Action granularity is appropriate, with one operation per line. Reading flow is natural, with methods logically ordered and grouped. Minor deductions: some import lines are unused (Map, Set are used, but jakarta.websocket.Endpoint, ServerContainer imports are used; actually all imports appear used except possibly none). Very minor line-wrapping in method signatures slightly affects flow but remains clear. Overall, it is exemplary straightforward mock implementation code.
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 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 required interface, although repetitive accessors and exception statements add unavoidable boilerplate. Action granularity: Each statement performs a single action, making individual methods easy to inspect. Reading flow: Consistent formatting and paired getters/setters provide a natural progression; a few long signatures and wrapped exception messages mildly interrupt scanning.
Run 2
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 names, and explicit exception messages clearly communicate the mock's supported configuration behavior and unsupported operations. Code length: Methods are concise; repeated exception statements and accessors add length but largely reflect interface requirements. Action granularity: Each statement performs a single action, making behavior easy to inspect. Reading flow: Consistent annotations, indentation, spacing, and predictable getter/setter ordering support natural reading. Minor drawbacks include long signatures and exception messages, abbreviated parameter names such as cec and sec, and the lack of spacing between the package declaration and imports.
Run 3
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: The class documentation, descriptive field names, standard accessor methods, and explicit unsupported-operation messages clearly communicate the mock's behavior; abbreviated parameters such as cec and sec are slightly less clear. Code length: Methods are minimal, although interface-required overloads and repeated exception messages add unavoidable boilerplate. Action granularity: Each statement performs one action, and methods generally contain a single statement. Reading flow: Consistent formatting and paired getters/setters make the code easy to scan; long signatures and exception messages cause minor line-wrapping interruptions.