Closed damienflament closed 4 years ago
Hi! Can you tell me what version of ArchLinux you're using? I'll spin up a VM and tinker with it.
In the instructions on the wiki, I recommend installing LanguageTool on Linux using LinuxBrew and not the native package manager. This provides a consistent install across distributions and is typically more current. That said, I'm happy to look into accommodating installs via native package managers. I had problems managing the service when started by a wrapper script, but I can look at it again. It may take some time to figure it out, thought.
ArchLinux is a rolling release distribution. I can't tell you which version I'm using, but can I tell you the versions of some packages:
CPU architecture: x86_64 Linux kernel: 5.3.6 Java Runtime Environment enabled: JRE OpendJDK 13.u33 LanguageTool: 4.7 VSCode OSS: 1.39.1 LanguageTool Linter extension: 0.3.2
To launch the LanguageTool server on ArchLinux, I use the command provided. It's pointing to the script I shown you before:
$ languagetool --http --port 8000
Picked up JAVA_TOOL_OPTIONS: -Djdk.gtk.version=3
2019-11-09 09:14:33 +0000 Not setting up database access, dbDriver is not configured
2019-11-09 09:14:33 +0000 WARNING: running in HTTP mode, consider using org.languagetool.server.HTTPSServer for encrypted connections
2019-11-09 09:14:34 +0000 Setting up thread pool with 10 threads
2019-11-09 09:14:34 +0000 Starting LanguageTool 4.7 (build date: 2019-09-28 10:09, 64f87c1) server on http://localhost:8000...
2019-11-09 09:14:34 +0000 Server started
That script launch the following command:
/bin/java \
-cp /usr/share/languagetool:/usr/share/java/languagetool/aho-corasick-double-array-trie.jar:/usr/share/java/languagetool/akka-actor_2.11.jar:/usr/share/java/languagetool/annotations.jar:/usr/share/java/languagetool/asm.jar:/usr/share/java/languagetool/berkeleylm.jar:/usr/share/java/languagetool/catalan-pos-dict.jar:/usr/share/java/languagetool/cjftransform.jar:/usr/share/java/languagetool/commons-cli.jar:/usr/share/java/languagetool/commons-codec.jar:/usr/share/java/languagetool/commons-collections4.jar:/usr/share/java/languagetool/commons-csv.jar:/usr/share/java/languagetool/commons-io.jar:/usr/share/java/languagetool/commons-lang3.jar:/usr/share/java/languagetool/commons-logging.jar:/usr/share/java/languagetool/commons-pool2.jar:/usr/share/java/languagetool/commons-text.jar:/usr/share/java/languagetool/config.jar:/usr/share/java/languagetool/FastInfoset.jar:/usr/share/java/languagetool/german-pos-dict.jar:/usr/share/java/languagetool/guava.jar:/usr/share/java/languagetool/hamcrest-core.jar:/usr/share/java/languagetool/hppc.jar:/usr/share/java/languagetool/hunspell-native-libs.jar:/usr/share/java/languagetool/ictclas4j.jar:/usr/share/java/languagetool/icu4j.jar:/usr/share/java/languagetool/indriya.jar:/usr/share/java/languagetool/istack-commons-runtime.jar:/usr/share/java/languagetool/jackson-annotations.jar:/usr/share/java/languagetool/jackson-core.jar:/usr/share/java/languagetool/jackson-databind.jar:/usr/share/java/languagetool/jafama.jar:/usr/share/java/languagetool/java-jwt.jar:/usr/share/java/languagetool/javax.activation-api.jar:/usr/share/java/languagetool/jaxb-api.jar:/usr/share/java/languagetool/jaxb-core.jar:/usr/share/java/languagetool/jaxb-runtime.jar:/usr/share/java/languagetool/jcommander.jar:/usr/share/java/languagetool/jna.jar:/usr/share/java/languagetool/jsonic.jar:/usr/share/java/languagetool/junit.jar:/usr/share/java/languagetool/jwordsplitter.jar:/usr/share/java/languagetool/kryo.jar:/usr/share/java/languagetool/language-detector.jar:/usr/share/java/languagetool/languagetool-commandline.jar:/usr/share/java/languagetool/languagetool-core.jar:/usr/share/java/languagetool/languagetool-core-tests.jar:/usr/share/java/languagetool/languagetool-gui-commons.jar:/usr/share/java/languagetool/languagetool.jar:/usr/share/java/languagetool/languagetool-server.jar:/usr/share/java/languagetool/languagetool-tools.jar:/usr/share/java/languagetool/logback-classic.jar:/usr/share/java/languagetool/logback-core.jar:/usr/share/java/languagetool/lucene-backward-codecs.jar:/usr/share/java/languagetool/lucene-core.jar:/usr/share/java/languagetool/lucene-gosen-ipadic.jar:/usr/share/java/languagetool/mariadb-java-client.jar:/usr/share/java/languagetool/minlog.jar:/usr/share/java/languagetool/morfologik-fsa-builders.jar:/usr/share/java/languagetool/morfologik-fsa.jar:/usr/share/java/languagetool/morfologik-speller.jar:/usr/share/java/languagetool/morfologik-stemming.jar:/usr/share/java/languagetool/morfologik-tools.jar:/usr/share/java/languagetool/morfologik-ukrainian-lt.jar:/usr/share/java/languagetool/morphology-el.jar:/usr/share/java/languagetool/mybatis.jar:/usr/share/java/languagetool/objenesis.jar:/usr/share/java/languagetool/opennlp-chunk-models.jar:/usr/share/java/languagetool/opennlp-postag-models.jar:/usr/share/java/languagetool/opennlp-tokenize-models.jar:/usr/share/java/languagetool/opennlp-tools.jar:/usr/share/java/languagetool/openregex.jar:/usr/share/java/languagetool/reflectasm-shaded.jar:/usr/share/java/languagetool/scala-compiler.jar:/usr/share/java/languagetool/scala-parser-combinators_2.11.jar:/usr/share/java/languagetool/scala-reflect.jar:/usr/share/java/languagetool/scala-xml_2.11.jar:/usr/share/java/languagetool/segment.jar:/usr/share/java/languagetool/simpleclient_common.jar:/usr/share/java/languagetool/simpleclient_guava.jar:/usr/share/java/languagetool/simpleclient_hotspot.jar:/usr/share/java/languagetool/simpleclient_httpserver.jar:/usr/share/java/languagetool/simpleclient.jar:/usr/share/java/languagetool/slf4j-api.jar:/usr/share/java/languagetool/stax-ex.jar:/usr/share/java/languagetool/txw2.jar:/usr/share/java/languagetool/unit-api.jar:/usr/share/java/languagetool/uom-lib-common.jar:/usr/share/java/languagetool/xgboost4j.jar:/usr/share/java/languagetool/xgboost-predictor.jar \
org.languagetool.server.HTTPServer \
--port 8000
As you can see, the paths of all the JAR files located in the /usr/share/java/languagetool
directory are appended to the classpath. Putting this list in the languageToolLinter.managed.jarFile
setting works. But it might break if the package change.
I've decided to treat this as an enhancement. If the path is a directory, add all the jars in the directory to the classpath when starting. If the path is a jar, use current behavior. If it's something else, throw an error.
@damienflament - I'm still going to pursue adding this as an enhancement, but there's an alternative on ArchLinux. The package provides a systemd service file so LanguageTool can be run as a service. If you have root access on the machine, you can enable it by:
sudo systemctl enable languagetool
And you can start it by:
sudo systemctl start languagetool
It starts on the default port, and the extension works with the default configuration. Would this be an option for you?
Running a LanguageTool server system wide is the workaround actually.
Just a note about that, if someone looks at this issue and use ArchLinux:
The provided service is running a LanguageTool server which accept connections from the network. It launches the command
/usr/bin/languagetool --http --allow-origin "*"
. So, by using it, its usage is NOT restricted to your machine.
I posted this issue ticket because the managed behavior of your extension seems to not work on my configuration.
I understand that relying on a portable package manager (Brew) makes your work easier because the package files location is expectable regardless of the operating system. But I can't use the package manager recommended by every software maintainer on my system, there are so many.
Thanks for your efforts.
I'm glad you pointed this out. I was using the Jar File setting as a classpath anyhow. I think what I'll do is deprecate the Jar File setting and replace it with Class Path. That would provide better support across different ways of installing LanguageTool.
Version 0.4.0 broke when published. Reverted to 0.3.2 and will implement when I figure out what happened.
Feature added in 0.6.0.
Broke on publication again.
So embarrassed. I had the node-glob module as a dev dependency. I've built and installed locally to test. Will publish an updated version soon.
@damienflament: Thanks for reporting this!
@davidlday: Thanks for creating this project!
Regarding:
The provided service is running a LanguageTool server which accept connections from the network. It launches the command /usr/bin/languagetool --http --allow-origin "*". So, by using it, its usage is NOT restricted to your machine.
That doesn't seem to be correct, see output of languagetool --help
:
[...]
--public allow this server process to be connected from anywhere; if not set,
it can only be connected from the computer it was started on
--allow-origin ORIGIN set the Access-Control-Allow-Origin header in the HTTP response,
used for direct (non-proxy) JavaScript-based access from browsers;
example: --allow-origin "*"
[...]
Hi!
I just installed the LanguageTool Linter extension for VSCode on ArchLinux. I choose to let the extension manage the LanguageTool server.
I use the following configuration in
settings.json
:The extension output in VSCode is shown below:
After looking at the LanguageTool launch script available on ArchLinux, I think the classpath is not well defined when this extension run the server:
Each JAR file located in the
/usr/share/java/languagetool
directory is appended to the classpath. As your extension only include the thelanguagetool-server.jar
file to the classpath, some classes are not found.I don't know how LanguageTool is packaged on other Linux distribution, but it seems your extension does not work well with the ArchLinux package.
I think about another solution: it may be useful to specify a command to launch instead of a path to the JAR file.