FWD » Core Development » Runtime Infrastructure

Implement more flexible formatter for log records, configurable in directory.xml.

Currently one and the same formatter is used to generate the logs in the p2j.jar in /opt/spawn, and then to parse them on the server. To have this working with changeable formatting configs the spawner should be receiving directory.xml configs, which is an effort we can spare ourselves, if the whole process is to be reworked soon.

Be aware that the separate spawner process can be removed with the work related to enhancing authentication methods.

As requested in #4065-104 support optional (configurable) shorter versions of package names. Check how other logging libs provide it.

Full flexibility in log formats can be achieved by using a well-established slf4j implementation. Many customers already use such libraries in their own projects or as parts of their FWD deployments, for example the project affected by #7589 (using Spring logging), or #8248 (using log4j), or #8023 (using logback). Changing the logging provider is a matter of adding the library .jar file to the server and clients classpaths and the necessary formatting config file (usually parsed automatically from the launch dir), something customers are usually well familiar with, especially those requesting advanced customizations.

CentralLogger currently uses java.util.logging.FileHandler. A directory config can be added to make it switch writing to slf4-api instead. FWD's own slf4j impl CentralSlf4jProvider will have to be aborted on load, currently supported by the JVM arg disableCentralSlf4jProvider.

CentralLogger currently prepares for the logs some data flat (to survive serialization and ultimately comply to java.util.logging.LogRecord api). So this may pose an issue to the fully flexible formatting, if this flat data can't be easily transformed into separate fields, consumable by the logging provider. But that is an issue deriving from the complexity of the logging lifecycle in FWD in general and applies to any work on the formatting, it's not directly related to the use of an external lib.

This task does not include discussion on how to feed LOG-MANAGER logs to a new consumer.

It is possible that a customer's slf4j implementation will cause dependency conflicts with FWD. This will be an issue that the customer must handle. If a functional or performance bug in FWD can only be recreated with the customer's added logging customizations/dependencies, then this is not a real FWD bug to resolve.

Galya: Please ensure there is some documentation to this effect when you write the docs for this.