I’m currently facing a limitation of log4j where I cannot really easily specify a maximum number of files for daily rotating logs. In log4j2 this seems easier, additionally log4j is stuck at 1.2.17 since 2 years or so.
If and when we move depends if log4j2 suites all needs, I already know:
- simple to use in Java and simple to configure
- async, file appender logging is supported
To be investigated:
- small size? (important for mobile)
- working on Android somehow?
- iOS is using is own logging stuff so this should just be adapted to the new interfaces I think
Something else important here? Should we get rid of slf4j completely or use log4j2 behind it?
Hmmh, it seems that log4j2 does not have a ‘delete old logs’ functionality implemented or did I overlooked something?
Also it looks like bigger Java projects like hibernate and elasticsearch still have slf4j (+X) logging.
(for reference we had discussed logging dependencies here)
Speaking from user’s perspective, forcing a library’s users to have in their classpath (BTW Android has limits) a specific logging framework, is not something desirable. Imagine if an app’s libraries all need specific loggers.
So using a logging facade (like SLF4J) can usually overcome that annoyance and many can also choose to activate its NOP binding.
Emux
Okay this speaks against using log4j2 only(?), but slf4j+log4j2 could be still of an advantage
@karussell I have read also your concerns in the aforementioned issue.
But still my suggestion would be to modularize GH in a way that we have a compact library with minimal dependencies (no log, no osm read, etc) just for the core functionality.
i.e. opening a ready graph and perform routing.
On top there could be a module with osm reading and graph creation capabilities (with the more advanced dependencies).
Emux
Yes, sure. Still import, android and web needs logging 
From my experience, I agree with @devemux86 that a logging facade (and especially SLF4J) is a good choice! Would be great if the graphhopper artifact has no runtime dependency to a specific log implementation. Makes it easier to use GH as library without any logging bridges.
For the actual logging output library we’re very happy with logback. It is compatible with SLF4J.
Jan
Due to https://github.com/graphhopper/graphhopper/issues/250 we have no runtime dependency since 0.4 in the core. Just for slf4j.
Heard nothing bad with logback, but log4j2 seems another newer candidate for switching.
To conclude: switching from slf4j to log4j2 should not be done and we should investigate if we switch log4j to logback or to log4j2 but all behind slf4j. We’ll wait a bit for this decision as log4j2 is too young but looks promising.
