Back to LanguageTool Homepage - Privacy - Imprint

LanguageTool integration error with self-hosted app

I’ve configured the HTTP server to run automatically on my server using systemd, on port 8042. As far as I know, there is no need to open port 8042 but I have done anyway just to see if it was causing issues.

Here is the systemd script:

Description=Manage LanguageTool Service

ExecStart=/usr/bin/java -cp /usr/local/LangAnalysisApp/LangTool/LanguageTool-4.9/languagetool-server.jar org.languagetool.server.HTTPServer --port 8042 --allow-origin="*"


The server runs fine in the background when I start the system. I get results when I run the following in the command line, without any need to start anything manually:

 curl --data "language=en-US&text=a simple test" http://localhost:8042/v2/check

The server responds with the expected result:

{"software":{"name":"LanguageTool","version":"4.9","buildDate":"2020-03-24 14:19","apiVersion":1,"premium":false,"premiumHint":"You might be missing errors only the Premium version can find. Contact us at support<at>","status":""},"warnings":{"incompleteResults":false},"language":{"name":"English (US)","code":"en-US","detectedLanguage":{"name":"French","code":"fr","confidence":0.815771}},"matches":[{"message":"This sentence does not start with an uppercase letter","shortMessage":"","replacements":[{"value":"A"}],"offset":0,"length":1,"context":{"text":"a simple test","offset":0,"length":1},"sentence":"a simple test","type":{"typeName":"Other"},"rule":{"id":"UPPERCASE_SENTENCE_START","description":"Checks that a sentence starts with an uppercase letter","issueType":"typographical","category":{"id":"CASING","name":"Capitalization"}},"ignoreForIncompleteSentence":true,"contextForSureMatch":-1}]}

Now I have followed the ‘integration on websites’ instructions. I had tested this using languagetool’s own API and the search is executed properly. When I change the value of languagetool_rpc_url to http://localhost:8042/v2/check, there is a long wait after clicking the ‘Check Text’ button and then the following error message is displayed:

Error: Did not get response from service. Please try again in one minute.

Does anybody know what causes this error or how to fix it?

Perhaps the docs are missing details when it comes to self-hosting.

Thanks in advance!

Do you see any request arriving in the LT server logs? Does the browser console (F12, then “Network” tab) show anything helpful?

1 Like

Where are the server logs kept?.. I can’t find any.

I already checked the browser console but nothing useful there. No request or response data and no interesting headers.

LT prints to STDOUT, but I’m not sure where systemd puts that.

1 Like

These are the only logs I have:

Mar 25 21:16:20 languagetest systemd[1]: Stopped Manage LanguageTool Service.
Mar 25 21:16:20 languagetest systemd[1]: Started Manage LanguageTool Service.
Mar 25 21:16:21 languagetest java[2150]: 2020-03-25 21:16:21 +0100 INFO org.languagetool.server.DatabaseAccess Not setting up database access, dbDriver is not configured
Mar 25 21:16:21 languagetest java[2150]: 2020-03-25 20:16:21 +0000 WARNING: running in HTTP mode, consider running LanguageTool behind a reverse proxy that takes care of encryption (HTTPS)
Mar 25 21:16:23 languagetest java[2150]: 2020-03-25 20:16:23 +0000 Setting up thread pool with 10 threads
Mar 25 21:16:23 languagetest java[2150]: 2020-03-25 20:16:23 +0000 Starting LanguageTool 4.9 (build date: 2020-03-24 14:19, d6a675b) server on http://localhost:8042...
Mar 25 21:16:23 languagetest java[2150]: 2020-03-25 20:16:23 +0000 Server started
Mar 25 21:16:32 languagetest kernel: [  381.159595] [UFW BLOCK] IN=eth0 OUT= MAC=96:00:00:30:96:2c:d2:74:7f:6e:37:e3:08:00 SRC= DST= LEN=40 TOS=0x00 PREC=0x00 TTL=240 ID=61235 PROTO=TCP SPT=50760 DPT=18011 WINDOW=1024 RES=0x00 SYN URGP=0
Mar 25 21:16:33 languagetest kernel: [  382.551928] [UFW BLOCK] IN=eth0 OUT= MAC=96:00:00:30:96:2c:d2:74:7f:6e:37:e3:08:00 SRC= DST= LEN=40 TOS=0x00 PREC=0x00 TTL=241 ID=54321 PROTO=TCP SPT=55411 DPT=5431 WINDOW=65535 RES=0x00 SYN URGP=0

Looks as if a firewall is blocking the request maybe?

Oh that just means ‘a block of information regarding the firewall’ … I think.

I have the same issues when it is disabled. Can I ask how you would usually run LT as a server?

I can run the jar file and do it like that no problem, but I want to run it in the background and I don’t know if there is any standard practice for doing this.

We run it on the default port with an nginx server in front of it, taking care of https. Maybe @fabrichter has an idea about your issue.

Hmm… I’m not actually sure how to get it running on nginx in the first place, without just creating some arbitrary service or cronjob. I don’t use java normally, so perhaps I am looking for a more obvious answer.

I just don’t know how I’m supposed to get the server running, without just issuing the console command from the docs inside a shell and keeping the shell open.

Try --allow-origin '*', it doesn’t parse command line parameters with equal signs. When I tested it, I received a warning:

WARNING: unknown option: --allow-origin=* - please note that parameters are given as ‘–arg param’, i.e. without ‘=’ between argument and parameter

If you don’t see that warning, there may be another issue with your systemd service definition, though it looks like it should be working to me. I would assume that the browser just blocked the request because of the cross-origin policy, since your command line setting didn’t go through.

Still no luck. I have tried disabling the firewall and correcting the allow-origin option.

I was getting that error previously, yeah. Now I’ve fixed things I can’t find any problem.

My mistake though… my firewall does block the connection but it still doesn’t work with the firewall disabled.

Is there any chance I can see your nginx configuration?

I still think that the issue is on the browser side. Could you open the web development tools on the site where you want to integrate LanguageTool (Ctrl+Shift+C) and look into the console and the network tab?
There might be error messages there, or you can look for the /check requests and see if/why they fail.

Ok, never mind.

I’m not sure what fixed the issue exactly but I just deleted and re-wrote my nginx configuration and it worked. Possibly just a typo :see_no_evil:

Here it is, in case anyone else has mysterious nginx errors:

server {
    listen 80;
    root /var/www/;

    index index.html;

    charset utf-8;

    access_log off;
    error_log  /var/log/nginx/ error;

    location /v2/check {
        proxy_pass http://localhost:8081/v2/check;