Hey Pitsolu!
The directory listing you’re seeing is a strong hint that Jetty isn’t initializing the servlet context from your WAR, it’s treating it like a static resource instead of deploying it. Here’s what’s most likely going wrong:
1. Your Jetty Runner version is probably incompatible
This is almost certainly the root cause. DHIS2 relies on the javax.* servlet namespace, and Jetty 10+ dropped that in favour of Jakarta. Grab the 9.4.x runner specifically:
bash
wget https://repo1.maven.org/maven2/org/eclipse/jetty/jetty-runner/9.4.53.v20231009/jetty-runner-9.4.53.v20231009.jar
2. Use absolute paths and pass DHIS2_HOME as a JVM system property
Relative paths can silently fail at startup. Do both the env var and the -D flag. It improves reliability considerably:
bash
export DHIS2_HOME=/absolute/path/to/your/conf/folder
ls $DHIS2_HOME/dhis.conf # make sure this exists before proceeding
3. Run it like this:
bash
java -Xmx2g -Xms1g \
-DDHIS2_HOME=$DHIS2_HOME \
-Djava.io.tmpdir=./tmp \
-jar jetty-runner-9.4.53.v20231009.jar \
–port 8080 \
–path /dhis \
dhis.war
The tmpdir flag is worth including. DHIS2 needs to write temp files and will silently misbehave if the default temp directory isn’t writable.
4. Sanity-check your WAR
Just to rule out a bad build:
bash
jar tf dhis.war | head -20
You should see WEB-INF/web.xml near the top. If you don’t, the WAR itself is the problem, not Jetty.
Heads Up: DHIS2 is deeply optimised for Tomcat, usingTomcat-specific JNDI pooling internally. Jetty Runner can work for quick local testing, but if you hit more weird behaviour down the line, that’s likely why. For anything beyond a quick dev spin, Tomcat 9 + PostgreSQL is where you’ll have the smoothest experience.