New builds throws exception in ubuntu

[arbuilder]

using below command on ubuntu 20.04 (WSL2) gives Exception in thread "main" java.io.IOException: Current OS and desktop configuration does not support browsing for a URL

java -jar Tachidesk-v0.2.0-r184.jar

Earlier non windows specific build were working on ubuntu

[arbuilder]

new windows jar build don't work in docker so we should remove the docker info for now

[AriaMoradi]

This bug most likely comes from drokbox.util and should be fixed upstream.

[AriaMoradi]

does the program crash after running under wsl or does it continue working?

[arbuilder]

it hangs in extensions i.e. wait , so web ui works but we cant do anything. i have rebuild jar (Tachidesk-v0.2.2-r222.jar) it still show the above error Exception in thread "main" java.io.IOException: Current OS and desktop configuration does not support browsing for a URL but it works on docker (Tachidesk-v0.2.2-r222.jar still hangs on wsl2).

Summary

S.No.	jar	Win 10	Docker Win 10	WSL2 Ubuntu 20.04
1	Tachidesk-v0.2.2-r214.jar (latest release github)	works	hangs	hangs
2	Tachidesk-v0.2.2-r222.jar (rebuild on my pc)	works	works	hangs

[univeous]

This also happens on my CentOS Linux server. Can SystemTray be disabled in a system that has no GUI?

[AriaMoradi]

Release v0.2.3 should prevent from crashing on headless systems

[univeous]

Release v0.2.3 should prevent from crashing on headless systems

I'm using V0.2.3, it seems it will still crash:

Also, it hangs in extensions i.e. wait.

[arbuilder]

Release v0.2.3 should prevent from crashing on headless systems

I'm using V0.2.3, it seems it will still crash:

check if http://localhost:4567/extensions works and shows extensions if it does then u can ignore this error

[univeous]

Release v0.2.3 should prevent from crashing on headless systems

I'm using V0.2.3, it seems it will still crash:

check if http://localhost:4567/extensions works and shows extensions if it does then u can ignore this error

Library hangs on 'loading...', extensions and sources hang on 'wait'

[arbuilder]

Library hangs on 'loading...', extensions and sources hang on 'wait'

i see i have the same error in wsl2 , can u run java -version and paste the output meanwhile if u have docker u can run docker run -p 127.0.0.1:4567:4567 docker.io/arbuild/tachidesk-docker as docker build works with v0.2.3

[univeous]

Library hangs on 'loading...', extensions and sources hang on 'wait'

i see i have the same error in wsl2 , can u run java -version and paste the output meanwhile if u have docker u can run docker run -p 127.0.0.1:4567:4567 docker.io/arbuild/tachidesk-docker as docker build works with v0.2.3

Here is my java version:

I tried to run it in docker but still no luck. I will check if it's my network problem.

[AriaMoradi]

I tried the app with my archlinux in headless mode and it worked, I can load the webUI from my phone but none of the api works because it's trying to connect to the server at http://127.0.0.1:4567 but my phone sees the server from http://192.168.1.115
Maybe @univeous is facing the same issue?

Mind you that the app crashing means it getting terminated not printing java exceptions...

[univeous]

@AriaMoradi
Yes, I have the same problem, I just found it.

[AriaMoradi]

I can load the webUI from my phone but none of the api works because it's trying to connect to the server at http://127.0.0.1:4567 but my phone sees the server from http://192.168.1.115

If you are accessing the server from a remote client, To fix this issue you have to map the server's port to your local port with a tunneling program.(One easy to use solution is ssh port forwarding.)

This issue is not a bug, but is so by design, and is to prevent you from running on a remote client.
Reason being It's a bad idea to run Tachidesk remotely, because it has zero security and the app might break if api calls take a long time to resolve, but if you want to circumvent this limitation you are free to do so.

If you think this limitation should be removed, react to this comment with the rocket emoji, if it gets enough reactions I'll consider doing something about it.

[arbuilder]

tried the app with my archlinux in headless mode and it worked, I can load the webUI from my phone but none of the api works because it's trying to connect to the server at http://127.0.0.1:4567 but my phone sees the server from http://192.168.1.115
Maybe @univeous is facing the same issue?

yes and that's why it failed on wsl2 also and works on docker because i am exposing docker container port on localhost.

If you are accessing the server from a remote client, To fix this issue you have to map the server's port to your local port with a tunneling program.
This issue is not a bug, but is so by design, and is to prevent you from running on a remote client.
Reason being It's a bad idea to run Tachidesk remotely, because it has zero security and the app might break if api calls take a long time to resolve, but if you want to circumvent this limitation you are free to do so.(One easy to use solution is ssh port forwarding.)

i see it also means that using docker will also cause the same issue when using lan ips http://192.168.1.115:4567 and the docker will also not work without port forwarding on headless servers. I will check if i can add forwarding in docker container without breaking the app.

[arbuilder]

closing the issues as it is not a bug