Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

5.0.0-BETA5 #594

Closed
TikhomirovSergey opened this issue Mar 8, 2017 · 23 comments
Closed

5.0.0-BETA5 #594

TikhomirovSergey opened this issue Mar 8, 2017 · 23 comments
Assignees
Labels
Milestone

Comments

@TikhomirovSergey
Copy link
Contributor

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

@TikhomirovSergey TikhomirovSergey added this to the 5.0.0 milestone Mar 8, 2017
@TikhomirovSergey TikhomirovSergey self-assigned this Mar 8, 2017
@TikhomirovSergey
Copy link
Contributor Author

@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
Copy link
Contributor

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
Copy link
Contributor

mykola-mokhnach commented Mar 8, 2017

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

@jlipps
Copy link
Member

jlipps commented Mar 8, 2017

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

@jlipps
Copy link
Member

jlipps commented Mar 8, 2017

@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.

@jlipps
Copy link
Member

jlipps commented Mar 8, 2017

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
Copy link
Contributor

@KazuCocoa FYI

@KazuCocoa
Copy link
Member

👣 (watching)

@saikrishna321
Copy link
Member

+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
Copy link
Contributor

@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.

@TikhomirovSergey
Copy link
Contributor Author

TikhomirovSergey commented Mar 9, 2017

@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).

@SrinivasanTarget
Copy link
Member

@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.

@jlipps
Copy link
Member

jlipps commented Mar 9, 2017

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.

@TikhomirovSergey
Copy link
Contributor Author

TikhomirovSergey commented Mar 9, 2017

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

@TikhomirovSergey
Copy link
Contributor Author

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

@TikhomirovSergey
Copy link
Contributor Author

The fix has been published.

@NgocVi93
Copy link

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

@SrinivasanTarget
Copy link
Member

SrinivasanTarget commented Jun 22, 2017

@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
Copy link

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

@vikramvi
Copy link

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

@SrinivasanTarget
Copy link
Member

@vikramvi Ok, will look into it.

@Vismi1
Copy link

Vismi1 commented Jul 27, 2017

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

@SrinivasanTarget
Copy link
Member

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

@appium appium locked and limited conversation to collaborators Jul 27, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

9 participants