Using logging framework in LT

Development
1

I am currently developing quite complicated Java rules in LT and often need to print some debugging information from different places in the code. It looks like we don’t have currently any logging framework set up (we have slf4j-api dependency but no implementation) so I have to do System.err.println() wrapped in if statement.
Would it make sense to add some logging implementation framework to LT?

2

I think it would be useful in some cases. We should just agree that this will be used for debugging, not for logging internal errors (i.e. Exceptions), as Exceptions should simply be thrown. This makes sure internal errors get noticed. In a log, they might be ignored.

I only know log4j, and I’d be okay with using it.

3

I am also most familiar with log4j, but it looks that most of the modern projects use logging facade, namely slf4j. The API is close to log4j but allows to switch implementation without changing the code.
For the backend logback or log4j are mostly used. I am fine with either as the choice of the implementation would not affect the API we use.
Please let me know if you want to make the final decision and add the dependency or shall I do that.

Thanks
Andriy

4

Feel free to add slf4j.

5

Ok, here’s the approximate plan:

  1. we’ll add explicit dependency for slf4j-api in languagetool-core (btw we already have slf4j-api.jar as a transient dependency)
  2. we’ll add logging implementation dependency (most probably log4j or logback - I’ll do a bit more reading on that)
  3. we currently have slf4j-nop as a dependency in languagetool-server, languagetool-standalone, and languagetool-commandline to prevent “Failed to load class org.slf4j.impl.StaticLoggerBinder” message - as I understand we can remove slf4j-nop as we’ll have real implementation

This logging support will be primarily for development purposes and if there’s some default logging backend configuration needed I’ll provide that. If we later to decide to use it for production we’ll have to look at it separately.

Please let me know if you have any questions or suggestions,
Andriy

6

I’ve got the changes working but I’d like to test it a bit more and I am traveling next two weeks so I’ll finish this change after 3.6 released.

7

Sorry for the delay - it took a while to get enough free time to make it work and test all parts of LT.
We now have slf4j api for logging in LanguageTool.
I am using it in few rules in Ukrainian, by default the debug logging is off and there’s a small logback config file with debug turned on and example on how to activate it here: languagetool/languagetool-language-modules/uk/src/main/resources/org/languagetool/rules/uk/src at master · languagetool-org/languagetool · GitHub

Please let me know if you see any issues,
Thanks
Andriy

8

Thanks for working on this. I guess we can then have a global logback configuration file, i.e. one in languagetool-core instead of a uk-specific one?

9

Does mvn clean package work for you? I get this in LanguageTool RPM:

[ERROR] Failed to execute goal de.dentrassi.maven:rpm:0.10.0:rpm (default) on project languagetool: Execution default of goal de.dentrassi.maven:rpm:0.10.0:rpm failed: '/home/dnaber/lt/git/languagetool/languagetool-standalone/target/LanguageTool-4.1-SNAPSHOT/LanguageTool-4.1-SNAPSHOT/libs/slf4j-nop.jar' is not a regular file -> [Help 1]

Also see my recent commit about downgrading a dependency that doesn’t seem to be on Maven Central yet.

10

There’s logback.xml in the languagetool-core (and logback-test.xml in tests).
I just created one for my tests as it’s easy to to switch the whole file with -D property than to modify the config file in -core.

11

My bad - I’ve left out slf4j-nop jar reference, I’ve removed it now.