search

plantuml / plantuml-server

PlantUML Online Server
https://plantuml.com/
GNU General Public License v3.0
1.59k stars 463 forks source link

plantuml-server:jetty-v1.2023.10 Could not initialize class net.sourceforge.plantuml.FileFormat #311

Closed Pro100v closed 10 months ago

Pro100v commented 10 months ago

Describe the bug After starting the plantuml-server docker container, it does not render any scripts to diagrams

To Reproduce

docker pull plantuml/plantuml-server:jetty
docker run --restart unless-stopped -d --name plantuml -p 8082:8080 plantuml/plantuml-server:jetty
  1. Go to http://localhost:8082/
  2. See error into frame with diagrams (not rendering). It's true for all formats (png, svg, ascii, pdf)

Expected behavior A rendered diagram into frame.

Desktop (please complete the following information):

Additional context

docker logs plantuml | grep -i Error
java.lang.UnsatisfiedLinkError: /opt/java/openjdk/lib/libawt_xawt.so: libXext.so.6: cannot open shared object file: No such file or directory
java.lang.NoClassDefFoundError: Could not initialize class net.sourceforge.plantuml.FileFormat
java.lang.NoClassDefFoundError: Could not initialize class net.sourceforge.plantuml.FileFormat
Detail log

``` 2023-08-16 22:27:31 2023-08-16 17:27:31.419:WARN :oejs.HttpChannel:qtp1576861390-22: /map/SyfFKj2rKt3CoKnELR1Io4ZDoSbNACyloaa10000 2023-08-16 22:27:31 java.lang.NoClassDefFoundError: Could not initialize class net.sourceforge.plantuml.FileFormat 2023-08-16 22:27:31 at net.sourceforge.plantuml.servlet.MapServlet.getOutputFormat(MapServlet.java:70) 2023-08-16 22:27:31 at net.sourceforge.plantuml.servlet.MapServlet.doGet(MapServlet.java:55) 2023-08-16 22:27:31 at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:500) 2023-08-16 22:27:31 at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:587) 2023-08-16 22:27:31 at org.eclipse.jetty.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1410) 2023-08-16 22:27:31 at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:764) 2023-08-16 22:27:31 at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1665) 2023-08-16 22:27:31 at org.eclipse.jetty.websocket.servlet.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:170) 2023-08-16 22:27:31 at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202) 2023-08-16 22:27:31 at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635) 2023-08-16 22:27:31 at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527) 2023-08-16 22:27:31 at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131) 2023-08-16 22:27:31 at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:578) 2023-08-16 22:27:31 at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122) 2023-08-16 22:27:31 at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223) 2023-08-16 22:27:31 at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1570) 2023-08-16 22:27:31 at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:221) 2023-08-16 22:27:31 at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1381) 2023-08-16 22:27:31 at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:176) 2023-08-16 22:27:31 at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:484) 2023-08-16 22:27:31 at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1543) 2023-08-16 22:27:31 at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:174) 2023-08-16 22:27:31 at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1303) 2023-08-16 22:27:31 at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:129) 2023-08-16 22:27:31 at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149) 2023-08-16 22:27:31 at org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:51) 2023-08-16 22:27:31 at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122) 2023-08-16 22:27:31 at org.eclipse.jetty.server.Server.handle(Server.java:563) 2023-08-16 22:27:31 at org.eclipse.jetty.server.HttpChannel.lambda$handle$0(HttpChannel.java:505) 2023-08-16 22:27:31 at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:762) 2023-08-16 22:27:31 at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:497) 2023-08-16 22:27:31 at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:282) 2023-08-16 22:27:31 at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:314) 2023-08-16 22:27:31 at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100) 2023-08-16 22:27:31 at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53) 2023-08-16 22:27:31 at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:416) 2023-08-16 22:27:31 at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:385) 2023-08-16 22:27:31 at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:272) 2023-08-16 22:27:31 at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.produce(AdaptiveExecutionStrategy.java:194) 2023-08-16 22:27:31 at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:969) 2023-08-16 22:27:31 at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1194) 2023-08-16 22:27:31 at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1149) 2023-08-16 22:27:31 at java.base/java.lang.Thread.run(Unknown Source) ```

HeinrichAD commented 10 months ago

I am really sorry, but I can not reproduce your problem. For me everything is working fine (png, svg, ascii, pdf).

OS: Arch Linux PlantUML: Version 1.2023.10 (Wed Jul 12 15:54:07 UTC 2023) Firefox: 115.0.2 (64-bit) Chromium: Version 115.0.5790.90 (Official Build) Arch Linux (64-bit) Docker: Version 24.0.2, build cb74dfcd85

docker logs ``` 2023-08-19 07:33:52.000:INFO:docker-entrypoint:jetty start from /var/lib/jetty/jetty.start 2023-08-19 07:33:53.297:INFO :oejs.Server:main: jetty-11.0.15; built: 2023-04-11T18:37:53.775Z; git: 5bc5e562c8d05c5862505aebe5cf83a61bdbcb96; jvm 11.0.19+7 2023-08-19 07:33:53.397:INFO :oejdp.ScanningAppProvider:main: Deployment monitor [file:///var/lib/jetty/webapps/] 2023-08-19 07:33:55.072:INFO :oejss.DefaultSessionIdManager:main: Session workerName=node0 2023-08-19 07:33:55.115:INFO :oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext@2df3b89c{PlantUML,/,[file:///tmp/jetty-0_0_0_0-8080-plantuml_war-_-any-11332305050510668201/webapp/, jar:file:///tmp/jetty-0_0_0_0-8080-plantuml_war-_-any-11332305050510668201/webapp/WEB-INF/lib/monaco-editor-0.36.1.jar!/META-INF/resources],AVAILABLE}{/plantuml.war} 2023-08-19 07:33:55.128:INFO :oejs.AbstractConnector:main: Started ServerConnector@2826f61{HTTP/1.1, (http/1.1)}{0.0.0.0:8080} 2023-08-19 07:33:55.145:INFO :oejs.Server:main: Started Server@9353778{STARTING}[11.0.15,sto=5000] @2779ms ```

Note: I ran the same tests on a Windows 10 machine (with Edge and docker inside the wsl). Here, too, I did not notice any problems. Unfortunately, I do not have any Windows 11 computer at my disposal.

Edit: Also note that your request to /map/SyfFKj2rKt3CoKnELR1Io4ZDoSbNACyloaa10000 will response with an empty map/page since the encoded diagram (SyfFKj2rKt3CoKnELR1Io4ZDoSbNACyloaa10000) does not contain any map features. But still it does not throw any exceptions on my side.

Pro100v commented 10 months ago

I tried to clean docker (image and cache) 

docker stop plantuml
docker rmi -f $(docker images -q --filter=reference='plantuml/*')
docker image prune
docker system prune

after that download image again and run server

docker pull plantuml/plantuml-server:jetty
docker run --restart unless-stopped -d --name plantuml -p 8082:8080 plantuml/plantuml-server:jetty

but these steps did not give the desired result.

Do you have any tips on how to move forward in solving the problem?

HeinrichAD commented 10 months ago

It's quite hard to figure out the problems for me if I can't reproduce them.

First of all, I have a question for you. You are using Windows 11 Pro with native Windows Docker, right? So no WSL etc.

Do you have any tips on how to move forward in solving the problem?

Could you try the tomcat server version? Do you have the some problems with it?

docker run -d --pull always --name plantuml -p 8082:8080 plantuml/plantuml-server:tomcat

Do you also have an other computer/server, maybe with another OS (maybe Windows 10 or just another Window 11 computer) to see if this is a special or a general problem?

I will also try to look further into the problem at the weekend if possible.

HeinrichAD commented 10 months ago

The next thing you could test is this:

  1. Create a new file with the name Dockerfile in an empty directory with the following content:

    FROM plantuml/plantuml-server:jetty

USER root
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        libxext6 \
        && \
    rm -rf /var/lib/apt/lists/*
USER jetty
  2. Open a terminal an navigate inside the directory.
  3. Build the "new" docker image: docker build -t plantuml-test .
  4. Start and test the "new" docker image: docker run -d -p 8082:8080 --name plantuml plantuml-test
HeinrichAD commented 10 months ago

@Pro100v are there any updates?

Pro100v commented 10 months ago

The next thing you could test is this:

  1. Create a new file with the name Dockerfile in an empty directory with the following content:

    FROM plantuml/plantuml-server:jetty

USER root
RUN apt-get update && \
   apt-get install -y --no-install-recommends \
       libxext6 \
       && \
   rm -rf /var/lib/apt/lists/*
USER jetty
  2. Open a terminal an navigate inside the directory.
  3. Build the "new" docker image: docker build -t plantuml-test .
  4. Start and test the "new" docker image: docker run -d -p 8082:8080 --name plantuml plantuml-test

@HeinrichAD Unfortunately, the result is the same bad.

Details

```bash mrdef@MinisForum-M690  /drives/c/work/dev/probe/plantuml  cat Dockerfile FROM plantuml/plantuml-server:jetty USER root RUN apt-get update && \ apt-get install -y --no-install-recommends \ libxext6 \ && \ rm -rf /var/lib/apt/lists/* USER jetty # ENTRYPOINT ["/entrypoint.sh"] mrdef@MinisForum-M690  /drives/c/work/dev/probe/plantuml  docker build -t plantuml-test . [+] Building 0.1s (6/6) FINISHED docker:default => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 279B 0.0s => [internal] load metadata for docker.io/plantuml/plantuml-server:jetty 0.0s => [1/2] FROM docker.io/plantuml/plantuml-server:jetty 0.0s => CACHED [2/2] RUN apt-get update && apt-get install -y --no-install-recommends libxext6 && rm -rf /var/lib/apt/lists/* 0.0s => exporting to image 0.0s => => exporting layers 0.0s => => writing image sha256:926bcd29fa2501408d129ac138d653f7a312adee02c5bb22a994aa8f9480651d 0.0s => => naming to docker.io/library/plantuml-test 0.0s What's Next? View summary of image vulnerabilities and recommendations → docker scout quickview mrdef@MinisForum-M690  /drives/c/work/dev/probe/plantuml  docker run -d -p 8084:8080 --name plantuml plantuml-test docker: Error response from daemon: Conflict. The container name "/plantuml" is already in use by container "05ff6dce89a411a77661d6fb5a5b9106c303073b3b6a95fc4796693d8b5c078f". You have to remove (or rename) that container to be able to reuse that name. See 'docker run --help'. mrdef@MinisForum-M690  /drives/c/work/dev/probe/plantuml  docker run -d -p 8084:8080 --name plantuml-test plantuml-test 6f6e24958b09dcd03f3cef1a502ac42fe96bd0826742421eda4a318f7032598e mrdef@MinisForum-M690  /drives/c/work/dev/probe/plantuml  docker logs plantuml-test | grep -i Error java.lang.UnsatisfiedLinkError: /opt/java/openjdk/lib/libawt_xawt.so: libXrender.so.1: cannot open shared object file: No such file or directory java.lang.NoClassDefFoundError: Could not initialize class net.sourceforge.plantuml.FileFormat java.lang.NoClassDefFoundError: Could not initialize class net.sourceforge.plantuml.FileFormat java.lang.NoClassDefFoundError: Could not initialize class net.sourceforge.plantuml.FileFormat mrdef@MinisForum-M690  /drives/c/work/dev/probe/plantuml ```

In browser, I see this messge

Details

``` Sorry, but things didn't work out as planned. Thu Aug 31 07:30:51 UTC 2023 Request that failed: /png/SyfFKj2rKt3CoKnELR1Io4ZDoSa70000 Status code: 500 Exception: java.lang.NoClassDefFoundError: Could not initialize class net.sourceforge.plantuml.FileFormat ```

Pro100v commented 10 months ago

It's quite hard to figure out the problems for me if I can't reproduce them.

First of all, I have a question for you. You are using Windows 11 Pro with native Windows Docker, right? So no WSL etc.

@HeinrichAD I guess that the docker use WSL2 on my PC, Kernel Version: 5.15.90.1-microsoft-standard-WSL2

All information about docker

``` ✘ mrdef@MinisForum-M690  /drives/c/work/dev/probe/plantuml  docker system info Client: Version: 24.0.5 Context: default Debug Mode: false Plugins: buildx: Docker Buildx (Docker Inc.) Version: v0.11.2-desktop.1 Path: C:\Program Files\Docker\cli-plugins\docker-buildx.exe compose: Docker Compose (Docker Inc.) Version: v2.20.2-desktop.1 Path: C:\Program Files\Docker\cli-plugins\docker-compose.exe dev: Docker Dev Environments (Docker Inc.) Version: v0.1.0 Path: C:\Program Files\Docker\cli-plugins\docker-dev.exe extension: Manages Docker extensions (Docker Inc.) Version: v0.2.20 Path: C:\Program Files\Docker\cli-plugins\docker-extension.exe init: Creates Docker-related starter files for your project (Docker Inc.) Version: v0.1.0-beta.6 Path: C:\Program Files\Docker\cli-plugins\docker-init.exe sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.) Version: 0.6.0 Path: C:\Program Files\Docker\cli-plugins\docker-sbom.exe scan: Docker Scan (Docker Inc.) Version: v0.26.0 Path: C:\Program Files\Docker\cli-plugins\docker-scan.exe scout: Command line tool for Docker Scout (Docker Inc.) Version: 0.20.0 Path: C:\Program Files\Docker\cli-plugins\docker-scout.exe Server: Containers: 5 Running: 5 Paused: 0 Stopped: 0 Images: 11 Server Version: 24.0.5 Storage Driver: overlay2 Backing Filesystem: extfs Supports d_type: true Using metacopy: false Native Overlay Diff: true userxattr: false Logging Driver: json-file Cgroup Driver: cgroupfs Cgroup Version: 1 Plugins: Volume: local Network: bridge host ipvlan macvlan null overlay Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog Swarm: inactive Runtimes: io.containerd.runc.v2 runc Default Runtime: runc Init Binary: docker-init containerd version: 3dce8eb055cbb6872793272b4f20ed16117344f8 runc version: v1.1.7-0-g860f061 init version: de40ad0 Security Options: seccomp Profile: unconfined Kernel Version: 5.15.90.1-microsoft-standard-WSL2 Operating System: Docker Desktop OSType: linux Architecture: x86_64 CPUs: 16 Total Memory: 30.24GiB Name: docker-desktop ID: c5d10271-92e1-4da8-a036-ba7f980f6a69 Docker Root Dir: /var/lib/docker Debug Mode: false HTTP Proxy: http.docker.internal:3128 HTTPS Proxy: http.docker.internal:3128 No Proxy: hubproxy.docker.internal Experimental: false Insecure Registries: hubproxy.docker.internal:5555 127.0.0.0/8 Live Restore Enabled: false WARNING: No blkio throttle.read_bps_device support WARNING: No blkio throttle.write_bps_device support WARNING: No blkio throttle.read_iops_device support WARNING: No blkio throttle.write_iops_device support WARNING: daemon is not using the default seccomp profile ```

HeinrichAD commented 10 months ago

But hey, the first issue seems to be fixed. Natually, after to first issue came the second.

Next would be to install additonally libxrender1. But I do not know how may issues will follow.

FROM plantuml/plantuml-server:jetty

USER root
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        libxext6 \
        libxrender1 \
        && \
    rm -rf /var/lib/apt/lists/*
USER jetty
Error Histroy 1. `java.lang.UnsatisfiedLinkError: /opt/java/openjdk/lib/libawt_xawt.so: libXext.so.6: cannot open shared object file: No such file or directory` Solution: install `libxext6` 3. `java.lang.UnsatisfiedLinkError: /opt/java/openjdk/lib/libawt_xawt.so: libXrender.so.1: cannot open shared object file: No such file or directory` Solution: install `libxrender1`
Pro100v commented 10 months ago

@HeinrichAD After some atempts I solved problem with libs. Dockerfile is below:

FROM plantuml/plantuml-server:jetty

USER root
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
            libxext6 \
            libxrender1 \
            libxtst6 \
            libxi6 \
            && \
    rm -rf /var/lib/apt/lists/*
USER jetty

But now i get error bellow:

 mrdef@MinisForum-M690  /drives/c/work/dev/probe/plantuml  docker logs plantuml-test | grep -i Error
java.awt.AWTError: Can't connect to X11 window server using '192.168.0.104:0.0  ' as the value of the DISPLAY variable.
java.lang.NoClassDefFoundError: Could not initialize class net.sourceforge.plantuml.FileFormat
java.lang.NoClassDefFoundError: Could not initialize class net.sourceforge.plantuml.FileFormat
java.lang.NoClassDefFoundError: Could not initialize class net.sourceforge.plantuml.FileFormat

I tried to change Doccker file like below by advise here but it doesn't solve problem

FROM plantuml/plantuml-server:jetty

USER root
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
            libxext6 \
            libxrender1 \
            libxtst6 \
            libxi6 \
            && \
    rm -rf /var/lib/apt/lists/* && \
    unset DISPLAY && \
    export DISPLAY=:0

USER jetty
HeinrichAD commented 10 months ago

@arnaudroques Do do have an idea where and why java.awt is used? Or why the server requires a X11 server?

@Pro100v Could you check if the JVM inside the docker container runs java.awt in headless mode (java.awt.headless=true)?

Example how to check java.awt.headless: ```Dockerfile FROM maven:3-eclipse-temurin-11 AS builder RUN mkdir -p /tmp/test && \ echo 'public class TmpClass{ public static void main(String[] args){System.out.println(java.awt.GraphicsEnvironment.isHeadless());}}' > /tmp/test/TmpClass.java && \ javac /tmp/test/TmpClass.java ######################################################################################## FROM plantuml/plantuml-server:jetty ENV DEBIAN_FRONTEND noninteractive USER root RUN apt-get update && \ apt-get install -y --no-install-recommends \ libxext6 \ libxrender1 \ libxtst6 \ libxi6 \ && \ rm -rf /var/lib/apt/lists/* USER jetty COPY --from=builder /tmp/test /tmp/test ``` ```bash docker build -t plantuml-test . docker run -it plantuml-test /bin/bash -c "cd /tmp/test && java TmpClass" ``` The last command should return `true`.

Edit: Note, that Windows 11 comes with new feature w.r.t. WSL and GUI applications. If they simply use X11 forwarding (like we all did in Windows 10 to solve this problem) it shouldn't be a problem, but I do not know how Microsoft solved this.

arnaudroques commented 10 months ago

@arnaudroques Do do have an idea where and why java.awt is used? Or why the server requires a X11 server?

Yes :-)

This is because when we generate PNG images, we need to access to some graphical ressources of the server. (For example, fonts information) Hope this helps!

Pro100v commented 10 months ago

@ Pro100v Could you check if the JVM inside the docker container runs java.awt in headless mode (java.awt.headless=true)?

@HeinrichAD return false

 mrdef@MinisForum-M690  /drives/c/work/dev/probe/plantuml  docker run -it plantuml-test-2 /bin/bash -c "cd /tmp/test && java TmpClass"
false
HeinrichAD commented 10 months ago

@arnaudroques Thanks for clarifying. That makes sense I should have known this :sweat_smile:.

@Pro100v Finally, a first hint to what is wrong.

Please try to set the JVM option java.awt.headless to true. This is a little bit tricky for more than one reason but I could manipulate the option this way:

  1. create a new file plantuml.properties with the following content: 
    java.awt.headless=true

  2. while starting the the docker conatiner:

    • map the plantuml.properties inside the container and
    • set the PLANTUML_PROPERTY_FILE environment accordingly.

    Example:

    docker run -d -p 8082:8080 --name plantuml -v ./plantuml.properties:/usr/local/jetty/plantuml.properties -e PLANTUML_PROPERTY_FILE=/usr/local/jetty/plantuml.properties plantuml-test-2

Please, also try this with the original plantuml/plantuml-server:jetty image from hub.docker.com.

Finally, if this really solves the problem, I will modify the PlantUML server code to set the java.awt.headless option to true by default. But it is really strange that this option/property is false in your case. I really suspect that this could be related to the "new" Windows 11 WSL GUI features. I mean they are trying to fool WSL into believing that there is a proper X11 server (or something similar) so that all GUI applications will work automatically. Unfortunately, we are currently inside a docker container.

Pro100v commented 10 months ago

@HeinrichAD Hi! The problem is solved. Thanks.

I spent a lot of time to reproduce your case because the file with parameters did bind mount into a container as a directory. Only full path to file in windows format. Variant like -v ./file or -v $(pwd)/file didn't work.
The final right variant looks like this

docker run -d -p 8082:8080 --name plantuml -v c/work/dev/probe/plantuml/plantuml.properties:/usr/local/jetty/plantuml.properties -e PLANTUML_PROPERTY_FILE=/usr/local/jetty/plantuml.properties plantuml/plantuml-server:jetty

I'v tried on custom bild and from registry both worked well

HeinrichAD commented 10 months ago

Great to hear and thanks for the Docker on Windows insides. I created a PR to prevent this from happening again.

HeinrichAD commented 10 months ago

I decided to set the default/fallback to be the headless mode. That means the user can still manipulate the property (for whatever reason) but if it is not explicitly set it will run in headless mode.

Should the next version still have the same problem, please reach out again and I will change it and force the server to use the headless mode. (This should not be the case but who knows what Windows 11 does here :sweat_smile:.)