suggestion for all libraries: implement a logging facade instead of the logger

[BradleyScrim]

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

[lcottret]

I completely agree ! It's very difficult to tune log4j when we use jsbml with other libraries using also log4j.

[draeger]

Would it help to replace the log4j dependency by Java's on-board logging mechanism?

[niko-rodrigue]

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]

Would it help to replace the log4j dependency by Java's on-board logging mechanism?

Sorry, "logging facade" seems to be the right word for what I mean. A nice short explanation can be found here.

[niko-rodrigue]

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.