[
https://issues.apache.org/jira/browse/TINKERPOP-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17628479#comment-17628479
]
ASF GitHub Bot commented on TINKERPOP-2819:
-------------------------------------------
cole-bq opened a new pull request, #1850:
URL: https://github.com/apache/tinkerpop/pull/1850
[TINKERPOP-2819](https://issues.apache.org/jira/browse/TINKERPOP-2819)
This commit represents a significant restructuring of gremlin-driver. The
intention behind these changes is to make SimpleSocketServer usable by all of
the GLV's and work towards bringing the GLV's up to the same testing standards
as the java driver. This commit aims to do so without introducing any breaking
changes such that the benefits of improved testing can be realized sooner.
Further breaking changes may be in order in some release where it is
permittable. The changes are detailed below:
Moved Simple-Socket-Server and related initializer classes from
gremlin-driver into a new module gremlin-tools/gremlin-socket-server. This is
so other GLV's can depend on the socket server for testing without depending on
the whole gremlin-driver. In this change the classes are only moved, the
package remains tinkerpop.gremlin.driver to avoid breaking any code which uses
these classes.
A new gremlin-util module is created to house any code which is to be shared
between gremlin-driver, gremlin-server, and gremlin-socket-server. Previously
all of these shared classes (such as serializers and RequestMessage...) were
part of gremlin-driver (which is a dependency of gremlin-server). These classes
needed to be extracted to a new module to prevent a cyclic dependency between
gremlin-driver and gremlin-socket-server. This structure also removes the need
for gremlin-server to depend on gremlin-driver although this dependency should
remain for the time being to avoid breaking any users who may indirectly use
gremlin-driver classes through the server.
Builds SimpleSocketServer into a docker image and moves hardcoded constants
for the server port and custom request id's into a config yaml. These changes
bring gremlin-socket-server into a state which can be utilized by all of the
GLV's as opposed to only the java driver.
> 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)
