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 and consistent organization. It follows standard Java conventions with logical grouping of methods (WebSocketContainer methods first, then ServerContainer methods). Each method has a single responsibility and is appropriately concise. The use of @Override annotations and Javadoc gives clear intent. Nesting is minimal—only simple try/throw patterns with no deep indentation. The code length is appropriate for a mock implementation. Each action is on its own line, making it easy to scan. The reading flow is natural: fields at top, then methods grouped by interface. Minor deductions: the UnsupportedOperationException messages could be more consistent, and there's slight repetition in method signatures that could be considered verbose, but this is expected for interface implementations. Overall, this is very clean and maintainable code.
Run 2
The code is highly readable due to its clear structure, flat nesting, and consistent organization. It follows standard Java conventions: fields grouped at the top, methods organized by interface (WebSocketContainer vs ServerContainer) with section comments. Each method has a single, clear purpose—getters/setters simply delegate to fields, while unsupported operations throw clear exceptions with descriptive messages. Nesting is minimal; the only wrapping occurs for long method signatures and exception messages, which improves readability. One action per line is consistently maintained. The reading flow is natural: you can scan the class quickly and understand it's a mock implementation. The only minor deductions are for repetitive boilerplate (inherent to mocks) and some long method signatures that require wrapping, but these do not significantly impact clarity. Overall, this is exemplary readable code.
Run 3
The code is highly readable and well-structured. It is a straightforward mock implementation of an interface, organized logically into sections (WebSocketContainer and ServerContainer) with clear comments. Nesting is minimal—only basic class/method structure. Each method has a single, clear purpose, and lines generally perform one action. The reading flow is natural: fields, then simple getters/setters, followed by unsupported operations. Names are descriptive and consistent with the interface. Minor deductions: some method signatures are long due to parameter lists and wrapped throws clauses, slightly reducing visual flow, and the repetitive UnsupportedOperationException patterns could be extracted for brevity. Overall, it is concise for what it does and extremely easy to follow.
Run 1
Code Structure: Fields and methods are logically organized, with clear sections for WebSocketContainer and ServerContainer responsibilities. Nesting: Methods are flat and contain no nested control flow. Clarity of intent: The class documentation, descriptive field and method 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 appropriately concise, with repetition largely required by the interface, though exception messages add some boilerplate. Action granularity: Each statement performs a single action, making individual methods easy to understand. Reading flow: Consistent formatting, paired getters and setters, and predictable method bodies support natural scanning; a few long signatures and wrapped 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: The class documentation, descriptive names, and explicit unsupported-operation messages clearly communicate the mock's capabilities and limitations; abbreviated parameters such as cec and sec are slightly less clear. Code length: Methods are concise, although interface-required boilerplate and repeated exception messages make the class somewhat repetitive. Action granularity: Each statement performs a single straightforward action. Reading flow: Consistent formatting and predictable getter/setter ordering make the code easy to scan; occasional long signatures and wrapped exception messages slightly interrupt the flow.
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: Descriptive names, class documentation, and explicit exception messages clearly communicate the mock's supported configuration operations and unsupported connection operations. Code length: Interface requirements justify most boilerplate, though repeated exception messages and extra blank lines add minor verbosity. Action granularity: Each statement performs a single action, making behavior easy to inspect. Reading flow: Consistent formatting and predictable getter/setter ordering support natural reading; long signatures and wrapped exception messages introduce only minor interruptions.