Stand-alone FitNesse logging is mute for dynamically loaded Fixtures and plug-ins

[violinner]

FitNesseMain loads logging.properties from the stand-alone .jar file.

Calls to SLF4J log to Console or File as directed in this file.
However, The same logging methods in a Fixture loaded and imported in the wiki do not log to file.

It is clear that logging.properties from the Java JRE distribution is used to configure logging for Fixtures, and it defaults to Console. This is proven by modifying the file, but this is not wise for FitNesse run from a Jenkins CI worker.
Tested on stand-alone fitnesse, versions 20210606 & 20191229.

Requesting that the stand-alone fitnesse logger configuration be propagated by default to the code running dynamically loaded fixtures through SLIM, FIT, custom test runners, and to custom test listeners.

[fhoeben]

@violinner the fact that FitNesse configures logging is only intended for the wiki server. Ideally we would not configure the logging at all, allowing logging configuration to be fully controlled by the specific test setup (as FitNesse is then being used as a library and the test is the application that should be responsible for the logging setup).
There have actually been requests in the past to fully remove the logging implementation (#1248), to ensure configuration provided in a test setup cannot be affected (overridden) by the logging.properties content.

The logging used for the wiki server (defaults to console) should be separately configured from the logging when running tests (the latter end up in the 'Execution Log' in the wiki). Please note that test runs are done in a different process and fixture code can be a non-Java process, possibly on a different machine.
I believe you should be able to override the logging configuration for Java test runs by supplying system properties to the command to start the test process. In general this logging should always end up in standard out/error, so that the messages can be included in the execution log.

Configuring logging for a CI server should be completely separate from the logging used when running locally. When using Java fixtures I would recommend running the tests directly in a single process and not start a different process. To me the wiki logging configuration should not come into play at all, only the test-run logging configuration should be considered. Again system properties seem the most logical configuration option for a CI run, as that would allow all parameters to be controlled by the CI job setup without the need to change any code/files.

So in general I would be against forwarding wiki logging properties to test processes. But there probably is quite a bit of room to improve the logging configuration options for FitNesse (and document these).

FitNesse used as library running tests should impose as little logging constraints as possible, to give full flexibility with regards to logging to fixture writers. As far as I'm aware only using the slf4j API in FitNesse code should be a way to achieve that, but there should be some default implementation so that basic logging from the framework ends up on the console when the test run process (i.e. the set of all loaded fixtures and their libraries) do not provide any slf4j implementation.

[violinner]

CommandRunner.asynchronousStart() passes environment variables to the new Process, which I assume is executing the fixture code. However, the location of the JDK logger is passed as a JVM "-D" argument, not an environment variable. JVM arguments, or some selection including the JDK logger configuration path, should be be passed in the command executed by the CommandRunner class. Otherwise, the default jre logging.properties are used, and these do not write logs to a file.