ether
Log4js is stale due to upstream change
Mheh it turns out log4js made loads of breaking changes over the years and now I gotta support old settings/configs to pass to their now broken API. FML
- [ ] Write mechanism to see if this is pre v2 config (appenders.out !== 'undefined')
- [ ] Write mechanism to see if this is pre v2 install of log4js (version)
- [ ] Write mechanism to port v1 config to v2.
- [ ] Update settings.json.template with new config style
- [ ] Make changes to logic handlers IE reload of config [ a8ec242d0047e501b410d44108d7a70a1d7cb705 ]
I'm not gonna work on this, just don't feel like it :)
I'd be surprised if anyone feels like working on this. :smile:
Unless there is an existing library that can convert a v0.6.35 config to something compatible with v2.0 and later, I think the only feasible option is to break backward compatibility and force users to re-write their logging settings. (Also: log4js seems to have gone out of favor, so we may want to switch to winston or something else.)
To make it possible for us to change the logging library again in the future without breaking user configs, I suggest we simplify the logging settings by replacing them with the following:
-
settings.loglevel: Unchanged. -
settings.logfile: If set, also write log messages to this file. Defaults to unset.
And if we switch to a logging library that supports syslog, add the following
-
settings.syslog: If true, also write log messages to syslog (LOG_USERfacility). Defaults to false.
Most users aren't going to want anything more sophisticated than the above. For exotic configurations, we can either tell users to patch their local copy of Etherpad or we can have a (hidden?) advancedLoggingConfig object in settings.json that is not guaranteed to remain compatible across Etherpad versions.
This is a configuration breaking change to bump log4js we have in our deployed version running at zumpad.zum.de. Even with subsequent merges of upstream into our codebase we did not experience much changes necessary. The bump so far only affected configuration and usage of console.* (needed some additional initialization).
https://github.com/ZUMTeam/etherpad-lite/tree/log4js-upgrade
This is a configuration breaking change
I don't understand what you mean by "this".
Note that PR #5178 deprecated the logconfig setting, which will make it possible for us to upgrade log4js once users have been given enough time to remove logconfig from their settings.json.
This is a configuration breaking change
I don't understand what you mean by "this".
The "this" is referencing my linked branch where i did a log4js upgrade even before the existing logconfig setting got deprecated. I posted it for anyone who also needed to upgrade until etherpad has an official way to move forward (which it now has).
i think this issue can now be closed. With v1.9.4 log4js was bumped a few major versions. https://github.com/ether/etherpad-lite/releases/tag/v1.9.4
