[
https://issues.apache.org/jira/browse/TINKERPOP-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630032#comment-17630032
]
ASF GitHub Bot commented on TINKERPOP-2819:
-------------------------------------------
spmallette commented on PR #1850:
URL: https://github.com/apache/tinkerpop/pull/1850#issuecomment-1306208325
In introducing the new `gremlin-util` module there should be some Upgrade
Documentation to accompany this change. It should probably make note why this
change isn't a breaking one and what impact it might have during upgrade.
Speaking of which, I can't think of a scenario where users should notice
anything different in their upgrades unless they aren't using maven or
something similar. If they were somehow manually managing jar files they might
miss that `gremlin-util` was a new module i guess. I'd sorta advocated a hope
for being able to test drivers along 3.5.x and 3.6.x so perhaps that swayed you
in this direction. seeing it here gives me a bit of pause that we're going to
somehow annoy folks by moving these classes about.
how do you feel about taking this a step more slowly? the work you've done
here shows that the change could be made without breaking too much. if we
really wanted to test 3.5.x/3.6.x we could in the future always backport this
commit to these branches. so, you could just target master now with this commit
as it is. introduce a follow-on commit that renames packages if you like as we
can take a breaking change in 3.7.x. you do have the issue of groovy in
gremlin-util but making a note of that in commit comment will remind us of that
issue if we decided to backport the commit.
> 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)
