Cannot extend AppiumCommandExecutor after upgrading to version 6

[iddol]

Description

We have a class that extends AppiumCommandExecutor, and it stopped working when we tried to upgrade to version 6. The implementation of getPrivateFieldValue() and getPrivateFieldValue() assumes that the the requested fields (e.g., commandCodec, responseCodec, additionalCommands, client) are defined on the direct super-class of the current class, so when we use our sub-class these methods fail, because the requested fields are located on a super-class two levels up in the repository.

Environment

• java-client version 6.0.0

Details

When we try to create a new driver, using our class that extends AppiumCommandExecutor, the call to createSession() fails, because getCommandCodec() looks for a private fields on the direct parent of the current class. The implementation assumes that the direct parent is HttpCommandExecutor, but in our case the direct parent is AppiumCommandExecutor, and HttpCommandExecution is an indirect parent. Unfortubnately, All the methods in AppiumCommandExecutor are private, so our sub-class cannot override them to change the behvior defined above.

In order to enable us to work with version 6, at least one of the following changes is required:

1. Make the methods in AppiumCommandExecutor protected, so we can override them.

2. Change the implementation of getPrivateFieldValue() and setPrivateFieldValue() to support extension: Instead of looking for the field in the direct super-class, look for it anywhere in the class hierarhcy.

By the way, a year ago we submitted a pull request to the Selenium project (SeleniumHQ/selenium#3801) to enable extending their RemoteWebDriver and HttpCommandExecutor without having to use reflection, but it was not approved.

Exception stacktraces

https://gist.github.com/iddol/dc23b7c87c267a4f88efeaac04e62cd8

[mykola-mokhnach]

@iddol Please check if #928 works for you

[iddol]

Yes, I believe it does, thank you!
It would be helpful to make the other private setters and getters (e.g., setResponseCodec(), setCommandCodec() protected as well, so the sub-class can use them instead of calling setPrivateFieldValue().

[iddol]

The other API were also changed to protected as part of #928, which was reviewed and merged, so we can now close this issue.