There was a short discussion in the NeoForged discord about ways that configuring logging could be made easier for mod developers and users, and this is roughly what came from that discussion.
It's not the cleanest code, but the main goal is to get feedback on the basic idea of configuring logging in this way.
For modders and users, general logging configuration should be done by the system properties under logging.*:
logging.loglevel.* configures the log levels for the logger with the given name.
logging.loglevel.default configures the root logger level. Loggers will default to this level unless otherwise specified.
Currently, this affects both debug.log and latest.log. I know this isn't ideal, but I couldn't figure out a way to do it and I didn't want to block opening this PR forever. Perfection being the enemy of the good, and all.
logging.loglevel.mypackage configures all loggers in the mypackage package.
Further packages can be specified to refine the logging, such as logging.loglevel.mypackage.mysubpackage.
Per-type loggers can also be specified by passing their fully-qualified-class-name. For example, logging.loglevel.mypackage.mysubpackage.MyLoggedClass.
logging.marker.* configures the minimum log level for a given marker. For example, if you wanted to turn on trace logging for launch plugins, you could specify logging.marker.LAUNCHPLUGIN=TRACE.
This (I believe) overrides the log levels specified via logging.loglevel.*, so you can specify logging.loglevel.default=WARN and logging.marker.COOLMARKER=TRACE to turn on trace logging for any log message using the COOLMARKER marker.
Configuring the nitty-gritty of logging consists of specifying one or more --loggingConfig parameters, which is a URI to a valid log4j configuration file. These are aggregated by ModLauncher and used to populate the logging configuration fairly early on in the startup path. I imagine NeoForge/FancyModLoader would want to specify a --loggingConfig parameter to configure their marker filter defaults, or to add their custom log appenders for the server console.
As for why I decided to put these changes into ModLauncher, I felt that centralising all configuration in a single place would be ideal, and doing it early on in the startup process means that we can ensure a reliable foundation for the entire lifecycle of a launched game.
There was a short discussion in the NeoForged discord about ways that configuring logging could be made easier for mod developers and users, and this is roughly what came from that discussion.
It's not the cleanest code, but the main goal is to get feedback on the basic idea of configuring logging in this way.
For modders and users, general logging configuration should be done by the system properties under
logging.*:logging.loglevel.*configures the log levels for the logger with the given name.logging.loglevel.defaultconfigures the root logger level. Loggers will default to this level unless otherwise specified.logging.loglevel.mypackageconfigures all loggers in themypackagepackage.logging.loglevel.mypackage.mysubpackage.logging.loglevel.mypackage.mysubpackage.MyLoggedClass.logging.marker.*configures the minimum log level for a given marker. For example, if you wanted to turn on trace logging for launch plugins, you could specifylogging.marker.LAUNCHPLUGIN=TRACE.logging.loglevel.*, so you can specifylogging.loglevel.default=WARNandlogging.marker.COOLMARKER=TRACEto turn on trace logging for any log message using theCOOLMARKERmarker.Configuring the nitty-gritty of logging consists of specifying one or more
--loggingConfigparameters, which is a URI to a valid log4j configuration file. These are aggregated by ModLauncher and used to populate the logging configuration fairly early on in the startup path. I imagine NeoForge/FancyModLoader would want to specify a--loggingConfigparameter to configure their marker filter defaults, or to add their custom log appenders for the server console.As for why I decided to put these changes into ModLauncher, I felt that centralising all configuration in a single place would be ideal, and doing it early on in the startup process means that we can ensure a reliable foundation for the entire lifecycle of a launched game.