5.0.0-BETA5

Question

5.0.0-BETA5

TikhomirovSergey opened this issue 8 years ago · comments

Sergey Tikhomirov commented 8 years ago

Description

The failing on the session creation.

Environment

java client build version or git revision if you use some shapshot: 5.0.0-BETA5
Appium server version or git revision if you use some shapshot: 1.6.3
Desktop OS/version used to run Appium if necessary: Windows 8
Node.js version (unless using Appium.app|exe) or Appium CLI or Appium.app|exe: 7.0.0
Mobile platform/version under test: Android
Real device or emulator/simulator: Emulator

Details

When I published the 5.0.0-BETA5 I had run tests and everything was ok. Yesterday I cleared caches and tried to check something. Instead I caught the exception. It reproduces with Selenium 3.2.0 and 3.3.0.

Code To Reproduce Issue [ Good To Have ]

        service = AppiumDriverLocalService.buildDefaultService();
        service.start();

        if (service == null || !service.isRunning()) {
            throw new AppiumServerHasNotBeenStartedLocallyException(
                "An appium server node is not started!");
        }

        File appDir = new File("src/test/java/io/appium/java_client");
        File app = new File(appDir, "ApiDemos-debug.apk");
        DesiredCapabilities capabilities = new DesiredCapabilities();
        capabilities.setCapability(MobileCapabilityType.DEVICE_NAME, "Android Emulator");
        capabilities.setCapability(MobileCapabilityType.APP, app.getAbsolutePath());
        driver = new AndroidDriver<>(service.getUrl(), capabilities);

Ecxeption stacktraces

Unable to create new remote session. desired capabilities = Capabilities [{app=C:\appium\java-client\src\test\java\io\appium\java_client\ApiDemos-debug.apk, platformName=Android, deviceName=Android Emulator}], required capabilities = Capabilities [{}]
Build info: version: '3.3.0', revision: 'b526bd5b41', time: '2017-03-07 19:26:04 +0000'
System info: host: 'HP', ip: '192.168.76.1', os.name: 'Windows 8.1', os.arch: 'amd64', os.version: '6.3', java.version: '1.8.0_73'
Driver info: driver.version: AndroidDriver
org.openqa.selenium.SessionNotCreatedException: Unable to create new remote session. desired capabilities = Capabilities [{app=xxx\ApiDemos-debug.apk, platformName=Android, deviceName=Android Emulator}], required capabilities = Capabilities [{}]
Build info: version: '3.3.0', revision: 'b526bd5b41', time: '2017-03-07 19:26:04 +0000'
System info: host: 'HP', ip: '192.168.76.1', os.name: 'Windows 8.1', os.arch: 'amd64', os.version: '6.3', java.version: '1.8.0_73'
Driver info: driver.version: AndroidDriver
	at org.openqa.selenium.remote.ProtocolHandshake.createSession(ProtocolHandshake.java:126)
	at org.openqa.selenium.remote.HttpCommandExecutor.execute(HttpCommandExecutor.java:141)
	at io.appium.java_client.remote.AppiumCommandExecutor.execute(AppiumCommandExecutor.java:69)
	at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:604)
	at io.appium.java_client.DefaultGenericMobileDriver.execute(DefaultGenericMobileDriver.java:42)
	at io.appium.java_client.AppiumDriver.execute(AppiumDriver.java:1)
	at io.appium.java_client.android.AndroidDriver.execute(AndroidDriver.java:1)
	at org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:244)
	at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:131)
	at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:144)
	at io.appium.java_client.DefaultGenericMobileDriver.<init>(DefaultGenericMobileDriver.java:38)
	at io.appium.java_client.AppiumDriver.<init>(AppiumDriver.java:89)
	at io.appium.java_client.AppiumDriver.<init>(AppiumDriver.java:113)
	at io.appium.java_client.android.AndroidDriver.<init>(AndroidDriver.java:73)
	at io.appium.java_client.android.BaseAndroidTest.beforeClass(BaseAndroidTest.java:51)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
	at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)

Link to Appium logs

https://gist.github.com/TikhomirovSergey/28e7b0ffceacd480f44e1f0127edbfcb

Sergey Tikhomirov · Answer 1 · Thu Mar 09 2017 05:01:01 GMT+0800 (China Standard Time)

@SrinivasanTarget @mykola-mokhnach @saikrishna321
Do you know something?

I think there some changes on the selenium server-side. This failings are lelated to changes of this class:
https://github.com/SeleniumHQ/selenium/blob/master/java/client/src/org/openqa/selenium/remote/ProtocolHandshake.java.

Mykola Mokhnach · Answer 2 · Thu Mar 09 2017 05:41:53 GMT+0800 (China Standard Time)

It looks like Selenium authors added some new JSON attributes to createSession API called "alwaysMatch" and "firstMatch". I still cannot fully understand the purpose of these based on their weird comments, but we need for sure avoid throwing an error in Appium or strip these attributes explicitly in our selenium driver wrappers. Probably, doing this in Appium would be better, since it won't require one to change all the drivers for different languages.
@jlipps FYI

Mykola Mokhnach · Answer 3 · Thu Mar 09 2017 05:47:13 GMT+0800 (China Standard Time)

@TikhomirovSergey Can you please try to apply this patch and check if the stuff still fails?

Jonathan Lipps · Answer 4 · Thu Mar 09 2017 05:57:34 GMT+0800 (China Standard Time)

ok, tracking that issue in appium at appium/appium#8009

Jonathan Lipps · Answer 5 · Thu Mar 09 2017 06:17:59 GMT+0800 (China Standard Time)

@TikhomirovSergey @mykola-mokhnach i have confirmed with the spec authors that what the client is sending is completely wrong. It is sending this:

{
    "alwaysMatch": {
        "app": "C:\\appium\\java-client\\src\\test\\java\\io\\appium\\java_client\\ApiDemos-debug.apk",
        "deviceName": "Android Emulator",
        "platformName": "Android"
    },
    "capabilities": {
        "desiredCapabilities": {
            "app": "C:\\appium\\java-client\\src\\test\\java\\io\\appium\\java_client\\ApiDemos-debug.apk",
            "deviceName": "Android Emulator",
            "platformName": "Android"
        },
        "requiredCapabilities": {}
    },
    "desiredCapabilities": {
        "app": "C:\\appium\\java-client\\src\\test\\java\\io\\appium\\java_client\\ApiDemos-debug.apk",
        "deviceName": "Android Emulator",
        "platformName": "Android"
    },
    "firstMatch": [],
    "requiredCapabilities": {}
}

whereas according to the spec it should have the overall form:

{
  "capabilities": {
    "alwaysMatch": {...},
    "firstMatch": [...]
  }
}

so we need to figure out whether this is a bug in the java client or the appium client. I don't want to change the appium server parameters until we are sure what's going on here.

Jonathan Lipps · Answer 6 · Thu Mar 09 2017 06:20:47 GMT+0800 (China Standard Time)

according to spec authors, what the client should be sending is something more like this:

{
    "capabilities": {
        "alwaysMatch": {
            "app": "C:\\appium\\java-client\\src\\test\\java\\io\\appium\\java_client\\ApiDemos-debug.apk",
            "deviceName": "Android Emulator",
            "platformName": "Android"
        },
        "firstMatch": []
    },
    "requiredCapabilities": {
        "app": "C:\\appium\\java-client\\src\\test\\java\\io\\appium\\java_client\\ApiDemos-debug.apk",
        "deviceName": "Android Emulator",
        "platformName": "Android"
    },
    "desiredCapabilities": {}
}

note that there are 3 top-level keys: the two old ones (desiredCapabilities and requiredCapabilities) and the new one (capabilities). The reason is that the old ones are there to target old implementations, and the new one is there to target new implementations. Eventually the old keys will stop showing up.

Mykola Mokhnach · Answer 7 · Thu Mar 09 2017 06:27:31 GMT+0800 (China Standard Time)

@KazuCocoa FYI

Kazuaki Matsuo · Answer 8 · Thu Mar 09 2017 07:24:16 GMT+0800 (China Standard Time)

👣 (watching)

Sai Krishna · Answer 9 · Thu Mar 09 2017 08:15:12 GMT+0800 (China Standard Time)

+1 to what @mykola-mokhnach says, this needs to be handled on the appium server side, which would help breaking all the clients.

@jlipps @TikhomirovSergey i understand the caps which is in alwaysMatch should be present in requiredCapabilities. But what does the firstMatch gonna do ?

Mykola Mokhnach · Answer 10 · Thu Mar 09 2017 15:43:23 GMT+0800 (China Standard Time)

@saikrishna321 This should be ok on server side if you put alwaysMatch and firstMatch attributes inside capabilities object, like the spec says. Jonathan has confirmed this with spec authors in W3C IRC chat.

Sergey Tikhomirov · Answer 11 · Thu Mar 09 2017 16:08:07 GMT+0800 (China Standard Time)

@jlipps @saikrishna321 @mykola-mokhnach @KazuCocoa @jlipps
Ok. I am going to try to fix it today if it is needed and ry the patch #594 (comment).

Srinivasan Sekar · Answer 12 · Fri Mar 10 2017 01:00:09 GMT+0800 (China Standard Time)

@jlipps @mykola-mokhnach
We are constructing the request here, https://github.com/appium/java-client/blob/master/src/main/java/io/appium/java_client/remote/AppiumCommandExecutor.java#L65
and https://github.com/appium/java-client/blob/master/src/main/java/io/appium/java_client/remote/AppiumCommandExecutor.java#L69

As per latest Spec changes, ProtocolHandshake is redesigned in Selenium here, https://github.com/SeleniumHQ/selenium/blob/master/java/client/src/org/openqa/selenium/remote/ProtocolHandshake.java

Same methods been overridden here: https://github.com/SeleniumHQ/selenium/blob/master/java/client/src/org/openqa/selenium/remote/HttpCommandExecutor.java#L139.

We implicitly use the new handshake at our client side (after we ported to new selenium version) it breaks the handshake for us.

Think there should be ways,
1)Implement our own handshake (as per new spec at client side)
2)Improve at server side to handle client requests.

Incase if we change the request json format at client end, does appium server handles everything out of box without any modifications at server end?

Else this change requires modifications at both client and server ends? please clarify.

Jonathan Lipps · Answer 13 · Fri Mar 10 2017 02:17:24 GMT+0800 (China Standard Time)

Hi @SrinivasanTarget I think we should not improve the server side here because the server is doing things correctly. We need to ensure that the client is sending the right format. I'm not sure whether Appium's java client is responsible for the incorrect format, or whether Selenium's java client is responsible. But either way we should fix it in one of those places.

Sergey Tikhomirov · Answer 14 · Fri Mar 10 2017 03:49:27 GMT+0800 (China Standard Time)

@jlipps @SrinivasanTarget @mykola-mokhnach I'm working on our "protocol hand shake" class

Sergey Tikhomirov · Answer 15 · Wed Mar 22 2017 04:59:30 GMT+0800 (China Standard Time)

I will close this issue after the publishing. It is coming soon.

Sergey Tikhomirov · Answer 16 · Thu Mar 23 2017 05:07:10 GMT+0800 (China Standard Time)

The fix has been published.

NgocVi93 · Answer 17 · Thu Jun 22 2017 11:23:38 GMT+0800 (China Standard Time)

I use java client V4.1.2. it is OK
But when i used Java client 5.0.0-BETA9 -> unable to create new remote session

Srinivasan Sekar · Answer 18 · Thu Jun 22 2017 12:44:46 GMT+0800 (China Standard Time)

@NgocVi93 Everything is fine in Latest version. You should invalidate your cache and restart the ide. Also if you are using java client in pom.xml, you should not add selenium dependency manually in pom.xml since java-client comes with latest selenium dependency.

NgocVi93 · Answer 19 · Thu Jun 22 2017 15:41:48 GMT+0800 (China Standard Time)

@SrinivasanTarget , I will try that. Thanks you for support.
👍

Vikram Ingleshwar · Answer 20 · Wed Jul 26 2017 01:33:00 GMT+0800 (China Standard Time)

@SrinivasanTarget can you please check appium/appium#8916, it doesn't seems to be working properly

Srinivasan Sekar · Answer 21 · Wed Jul 26 2017 11:54:52 GMT+0800 (China Standard Time)

@vikramvi Ok, will look into it.

Vismi K George · Answer 22 · Thu Jul 27 2017 15:05:03 GMT+0800 (China Standard Time)

Hii all,

I have installed below listed versions (mac machine):-

1.Java - 1.8.0_131
2.xcode - 8.3.3
3.Appium -Version 1.5.3
4.Selenium- 3.4.0
5.Eclipse- 4.7.0

While running the code showing the error "Unable to create new remote session"
I have attached eclipse code, console error ,appium code.

Please anyone help me out from this situation.

untitled folder.zip

Srinivasan Sekar · Answer 23 · Thu Jul 27 2017 15:14:25 GMT+0800 (China Standard Time)

Please raise new issues with proper description and logs in form of gist. This is not relevant thread to raise queries.