Enable extension of RemoteWebDriver and HttpCommandExecutor

[iddol]

The ability to implement sub-classes of RemoteWebDriver and
HttpCommandExecutor in the Java client is very limited, since these
classes have private data members, with no protected accessors.
In order to increase the extensibility of these classes, protected
accessors were added, and methods that accessed these fields directly
were changed to use these accessors.

The fields that are now accessible by sub-classes are:
RemoteWebDriver.capabilities
HttpCommandExecutor.commandCodec
HttpCommandExecutor.responseCodec
HttpCommandExecutor.client

• By placing an X in the preceding checkbox, I verify that I have signed the Contributor License Agreement

[shs96c]

My apologies for the slow reply. Can I ask why you're attempting to subclass the HttpCommandExecutor? I can understand wanting to expose the fields, but it would be helpful to better understand the motivation.

[iddol]

The motivation for this was the need to support distribution of the driver across multiple nodes in a cluster. We create the driver in one node, but the operations we perform on the driver may be redirected to another node. So we need a way to serialize the session in the node that creates the driver, store it in a distributed location (e.g., Redis), and then deserialize it in some other nodes and continue working on the same session.

The serialization and deserialization parts are simple, because all the data we need in order to reconstruct an existing session is serializable in nature (session key, remote address URL, capabilities). The challenge was to how to create a driver object using that data. So we extended the standard driver with a proprietary implementation that exposes a constructor that accepts the data of an existing session. This constructor initializes the driver by using the given session key and capabilities instead of calling the server to create a new session. This is why we needed access to the capabilities data member.

However, when we did that the codecs on the command executor were not initialized, so we had to initialize them explicitly. This is why we needed access to the codecs data members.

I realize this is not a very standard use case, so I hope I managed to explain this clearly enough. If you have some idea of a better way to create a driver for an existing session we will be happy to hear your suggestions.

[iddol]

Hi @shs96c, any chance of these changes being incorporated into one of the upcoming Selenium versions?

[mrtduzgun]

++

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[AutomatedTester]

Thank you for the effort that you have put into this PR. The system is designed that you can pass in your own executor when you want and is extensible through that means. I suggest taking advantage of that.