You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The jsbml-core library implements a logger with log4j. In v1.5 the log4j version is 2.3
Using this in a library in another project with another log-framework or other versions leads to conflicts. Especially if other libraries also bring their own logger.
Implementing a logging facade or a simple abstract LogListener could solve the problem. Everyone using the library has to register the concrete logger or implements the concrete Listener to connect it to the used logger framework.
Benefits
simplify code
keep dependency tree small
keep maintainability
The text was updated successfully, but these errors were encountered:
We are staying on log4j 2.3 at the moment as we have not moved yet to required java 1.8. That 's probably something we should do for next release(s) as it prevent us to upgrade several libraries to their latest versions.
BradleyScrim
changed the title
suggestion for all libraries: implement a log-listener and delete the logger
suggestion for all libraries: implement a logging facade instead of the logger
Jun 4, 2020
It was already my intention to move to the slf4j api and I just noticed they have a migration tool that would help to modify all the log4j call and import.
The
jsbml-core
library implements a logger with log4j. In v1.5 the log4j version is 2.3Using this in a library in another project with another log-framework or other versions leads to conflicts. Especially if other libraries also bring their own logger.
Implementing a logging facade or a simple abstract LogListener could solve the problem. Everyone using the library has to register the concrete logger or implements the concrete Listener to connect it to the used logger framework.
Benefits
The text was updated successfully, but these errors were encountered: