error: Was passed main parameter 'standalone' but no main parameter was defined in your arg class

[tuxayo]

Thanks a lot for this project and the version 2 bringing Selenium::Client::Driver!

I'm trying to upgrade a Selenium::Remote::Driver + Selenium 3 setup to Selenium::Client::Driver + Selenium 4. But I'm getting this in the .selenium logs when calling new on Selenium::Client::Driver

Exception in thread "main" com.beust.jcommander.ParameterException: Was passed main parameter 'standalone' but no main parameter was defined in your arg class
        at com.beust.jcommander.JCommander.initMainParameterValue(JCommander.java:936)
        at com.beust.jcommander.JCommander.parseValues(JCommander.java:752)
        at com.beust.jcommander.JCommander.parse(JCommander.java:340)
        at com.beust.jcommander.JCommander.parse(JCommander.java:319)
        at org.openqa.grid.selenium.GridLauncherV3.parse(GridLauncherV3.java:218)
        at org.openqa.grid.selenium.GridLauncherV3.lambda$buildLaunchers$3(GridLauncherV3.java:241)
        at org.openqa.grid.selenium.GridLauncherV3.lambda$launch$0(GridLauncherV3.java:86)
        at java.base/java.util.Optional.map(Optional.java:265)
        at org.openqa.grid.selenium.GridLauncherV3.launch(GridLauncherV3.java:86)
        at org.openqa.grid.selenium.GridLauncherV3.main(GridLauncherV3.java:70)

The related config file lists this.

[node]
detect-drivers = true
[server]
allow-cors = true
hostname = "localhost"
max-threads = 36
port = 35219
[logging]
enable = true
log-encoding = UTF-8
log-file = "/var/lib/USER/kohadev/.selenium/perl-client/selenium-35219.log"
plain-logs = true
structured-logs = false
tracing = true

And I'm not finding the word standalone anywhere in my project except the docker image name for selenium being "selenium/standalone-firefox"

Where would the param fed to the selenium jar come from if not listed in the config-$PID.toml file?

For some reason .selenium/jars contains selenium-server-standalone-4.0.0-alpha-2.jar

Maybe it's normal?

Maybe it's my setup that doesn't fit anymore how all this has to work? It has the app and tests with the lib Selenium::Client::Driver in a container. And another is the selenium/standalone-firefox one.

And it felt weird having to install the JRE in the 1st container. Maybe it's just to talk to extract all the API from selenium-server-standalone-4.0.0-alpha-2.jar and there is nothing to worry with the "real" selenium not being in the same container.

[teodesian]

Where would the param fed to the selenium jar come from if not listed in the config-$PID.toml file?

See https://github.com/Troglodyne-Internet-Widgets/selenium-client-perl/blob/main/lib/Selenium/Driver/SeleniumHQ/Jar.pm#L50

It used to be part of the primary invocation of selenium, that's where it comes from. Sounds like they have once again made breaking changes, as they have been wont to do in this excruciatingly drawn out process of developing selenium 4. Maybe this time they have documentation I can read instead of having to read their source to understand how all this works.

For some reason .selenium/jars contains selenium-server-standalone-4.0.0-alpha-2.jar

This is normal operation; it's designed to download the latest selenium spec and build itself upon that, and then download all the latest drivers and binaries so you don't have to think about it. I should note this in the POD.

Furthermore, the POD actually notes that "The primary difference here is that we do not support direct driver usage without intermediation by the SeleniumHQ JAR any longer." -- this is why we are running thru the JAR. There remains a large subset of selenium 4 functionality that does not work when running drivers directly unfortunately.

I apologize for the documentation being lax on this. The plan was to use this as a backend for Selenium::Remote::Driver so nobody had to think about it. I got about 3/4 done earlier this year and then my free time evaporated.

I have a branch with some fixes to the drift in how this has worked, but it's a few hundred miles away from me right now. Realistically I won't be able to do anything concrete until next week.

[tuxayo]

I have a branch with some fixes to the drift in how this has worked, but it's a few hundred miles away from me right now. Realistically I won't be able to do anything concrete until next week.

No worries, it was just a quick POC attempt after looking at the v2 release.

This is normal operation; it's designed to download the latest selenium spec and build itself upon that, and then download all the latest drivers and binaries so you don't have to think about it.

ok, it was in case the gap between version 4.0.0-alpha-2 and latest would have been the cause.

There remains a large subset of selenium 4 functionality that does not work when running drivers directly unfortunately.
I apologize for the documentation being lax on this.

No worries, the important thing the documentation mentioned was the existence of .selenium which allowed to find the logs. Otherwise the only feedback I had was /status getting connection refused.
The log allowed to get the real error that JRE was missing and then the parameter 'standalone' one.

[teodesian]

I've made some big updates to the module now.

Importantly, it can download the new releases of selenium 4 from the github releases page rather than the old jars from google storage.

see at/srd.test for working invocation.

Presumes you have the relevant driver binaries installed and in your path, and a working JRE supposing you run against localhost...much like with Selenium::Remote::Driver.

A few broken commands have been fixed, but cookies and alerts still appear to be borked beyond belief. AFAIK this is an upstream problem!