FEAT: Let the on-premise web example take its port and data file from the environment by jwrosewell · Pull Request #663 · 51Degrees/device-detection-java-examples

jwrosewell · 2026-09-16T22:27:14Z

Problem

The shared Selenium contract tests in selenium-api-tests (category Contract) drive each web example as an already running server, given by EXAMPLE_URL. The cloud web example supports this, but the on-premise web example (web/getting-started.onprem) did not, for three reasons.

It always listened on port 8081 (GettingStartedWebOnPrem.java line 59).
It waited for Enter on stdin (EmbedJetty.java line 42), which a CI job does not have.
It read the data file only from TestDataFile, not from the agreed 51DEGREES_DD_PATH name.

The script route (/51Degrees.core.js) and the JSON route (/51Degrees.core.json) were already served by the pipeline filter, the same as in the cloud example, so nothing was needed there.

Change

GettingStartedWebOnPrem.java honours PORT exactly as GettingStartedWebCloud.java already does. When PORT is set the server is joined instead of waiting on Enter. Without it, the example behaves as before.
51Degrees-OnPrem.xml takes the data file from 51DEGREES_DD_PATH, then TestDataFile, then the Lite file, written as ${51DEGREES_DD_PATH:-${TestDataFile:-device-detection-data/51Degrees-LiteV4.1.hash}}. TestDataFile keeps working.
New OnPremDataFileOptionTest pins that order. It uses system properties in place of environment variables, which the lookup reads as well, and skips itself if either environment variable is already set.
README.md describes how to run the web examples with PORT and 51DEGREES_DD_PATH, and corrects the on-premise GettingStarted (Web) row, which said it used the cloud service.

Verification

mvnw -pl web/getting-started.onprem -am test -Dtest=OnPremDataFileOptionTest with neither variable set gave Tests run: 3, Failures: 0, Errors: 0, Skipped: 0. With the configuration file from main the same run gave one failure (expected:<from-[dd-path].hash> but was:<from-[test-data-file].hash>), so the test detects the old behaviour.
The packaged jar was started with PORT=8098 and 51DEGREES_DD_PATH pointing at a Lite file. The page returned 200 and named that file, /51Degrees.core.js returned 200, and a POST to /51Degrees.core.json returned 200 with device data. The process was then stopped.
The Selenium contract tests ran against this branch in the device-detection-java integration tests (the companion change, device-detection-java#589), using a test branch that clones this branch instead of main. In run 35153491220 all 15 jobs that can run Selenium reported Passed! - Failed: 0, Passed: 9, Skipped: 0, Total: 9 for this on-premise example against the TAC data file, and the same for the cloud example. The Arm64 Linux job skips Selenium. The new unit test ran in every job (3 run, 0 skipped).

Merge order

This pull request must merge first. The device-detection-java change (device-detection-java#589) clones this repository's main, so it cannot start the on-premise example on a port until this change is there.

CI on this branch, 17 September 2026

The "Pull Requests" workflow was dispatched on this branch with dryrun=true,
which builds the branch and merges nothing. Run
35161394140
ran on cf5e69f, the head of this branch, and concluded success with all 14
jobs green. In the Ubuntu_Java_17 job the Maven totals are 21 tests run, 0
failures, 0 errors and 1 skipped, with no error lines in the log.

This branch is one commit behind main, that commit being the automated package
update #664,
and it merges cleanly.
The nightly checks out the pull request, merges main into it and builds
that before it merges anything, so the combination is tested there.

… the environment The shared Selenium contract tests drive each web example as an already running server. The on-premise example was fixed to port 8081, waited on Enter, and only read the data file from TestDataFile. It now honours PORT the same way the cloud example does, joining the server instead of waiting on stdin, and reads the data file from 51DEGREES_DD_PATH first, then TestDataFile, then the Lite file. A unit test pins that order.

github-actions · 2026-09-16T23:16:29Z