[
https://issues.apache.org/jira/browse/TINKERPOP-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630007#comment-17630007
]
ASF GitHub Bot commented on TINKERPOP-2819:
-------------------------------------------
cole-bq commented on code in PR #1850:
URL: https://github.com/apache/tinkerpop/pull/1850#discussion_r1015852569
##########
gremlin-tools/gremlin-socket-server/src/main/java/org/apache/tinkerpop/gremlin/driver/SocketServerSettings.java:
##########
@@ -0,0 +1,78 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.tinkerpop.gremlin.driver;
+
+import org.yaml.snakeyaml.Yaml;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import java.util.Map;
+import java.util.Objects;
+import java.util.UUID;
+import java.util.function.BiFunction;
+
+/**
+ * Encapsulates all constants that are needed by SimpleSocketServer. UUID
constants are used to coordinate
+ * custom response behavior between a test client and the server.
+ */
+public class SocketServerSettings {
+ public final int PORT;
+
+ /**
+ * If a request with this ID comes to the server, the server responds back
with a single vertex picked from Modern
+ * graph.
+ */
+ public final UUID SINGLE_VERTEX_REQUEST_ID;
+
+ /**
+ * If a request with this ID comes to the server, the server responds back
with a single vertex picked from Modern
+ * graph. After some delay, server sends a Close WebSocket frame on the
same connection.
+ */
+ public final UUID SINGLE_VERTEX_DELAYED_CLOSE_CONNECTION_REQUEST_ID;
+ public final UUID FAILED_AFTER_DELAY_REQUEST_ID;
+ public final UUID CLOSE_CONNECTION_REQUEST_ID;
+ public final UUID CLOSE_CONNECTION_REQUEST_ID_2;
+ public final UUID RESPONSE_CONTAINS_SERVER_ERROR_REQUEST_ID;
+
+ private static UUID uuidFromString(final String s) {
+ return s == null ? null : UUID.fromString(s);
+ }
+
+ /**
+ * SocketServerSettings are constructed from a yaml config file
+ */
+ public SocketServerSettings(final Path confFilePath) throws IOException {
+ this(Files.newInputStream(confFilePath));
+ }
+
+ public SocketServerSettings(final InputStream confInputStream) {
+ Objects.requireNonNull(confInputStream);
+ Yaml yaml = new Yaml();
+ Map<String, Object> settings = yaml.load(confInputStream);
Review Comment:
I will look into it.
> Refactor SimpleSocketServer to be accessible to all GLV's
> ---------------------------------------------------------
>
> Key: TINKERPOP-2819
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2819
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
> Reporter: Cole Greer
> Priority: Major
>
> Currently there is a large gap in the testing capabilities of the java driver
> compared to the other GLV's. Part of this gap is the java driver has
> SimpleSocketServer which provides a useful platform to write tests which
> require specific response behaviour from the server. Having such a tool for
> all of the GLV's would allow for testing of many more potential failure cases
> as well as taking a step towards standardizing the testing approach for all
> GLV's.
> This work can be divided into 2 main parts.
> Part One: Decoupling SimpleSocketServer from the java driver. This is the
> most disruptive part of the proposed changes. This has already been discussed
> [here|https://lists.apache.org/thread/vd7w43xjzvc5rr0135gql9mxhdlcltr9] on
> the dev list but I will summarize. To avoid having all the GLV's depending on
> the java driver, SimpleSocketServer and it's related classes should be
> extracted to a new module gremlin-tools/gremlin-socket-server. Unfortunately
> the socket server still relies on the following classes in gremlin driver:
> tinkerpop.gremlin.driver.message.*
> tinkerpop.gremlin.driver.ser.*
> tinkerpop.gremlin.driver.MessageSerializer
> tinkerpop.gremlin.driver.Tokens
> To avoid a cyclic dependency between gremlin-driver and
> gremlin-socket-server. these classes should be moved to another new module
> gremlin-util which will house any classes which are to be shared between the
> driver and server. Moving these classes to a new module and package will
> break import lines and will need to be left until 3.7. If this added testing
> capability is desired in 3.5 a potential solution is to move the classes to
> the gremlin-util module, but leave them in the gremlin.driver package. In
> initial tests this seems to work without issue although it is an unusual way
> to structure the code and should not be considered a long term solution.
> The second part of this refactor is to reconfigure the newly extracted
> gremlin-socket-server to be usable by all of the GLV's. My initial thoughts
> are to dockerize the server and have the container run during the testing
> phase of the GLV's. There is still some consideration to be done as to how
> the GLV's should best interact with this server. Currently Junit will start
> and stop the server for each individual test, each test has direct access to
> the server object and can control it as needed. The GLV's will not have the
> same direct control over the server. Any control options or behaviour needed
> will either need to be encoded in the server itself as custom behaviour
> triggered by specific request ID's or control through some external wrapper
> or interface around the server. There is still consideration needed as to how
> this should be done. Any comments on desired functionality or behaviour would
> be greatly appreciated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
