Cole Greer created TINKERPOP-2819:
-------------------------------------
Summary: 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
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)
