Orientdb: Improve internal logging api and implementation

[tglman]

The current logging implementation is based on https://github.com/orientechnologies/orientdb/blob/master/core/src/main/java/com/orientechnologies/common/log/OLogManager.java

that support this features:

• Log message formatting
• Runtime detection and log of the current db
• global flags for enable and disable level
• runtime configuration of the logging

the limits of this implementation are:

• runtime log lookup(in a map) and level check on every log call
• only global level flags ( as soon as is enabled debug on a corner feature i get all debug code executed)

feature we should include:

• static log reference that remove maps lookup
• for package/class level flags ( can be implemented with log.isLoggable(iLevel))

one solution could be rely more on the underling implementation and use it directly in a standard way with static loggers(to check the support of runtime reconfiguration).

[PhantomYdn]

Guys, might be you can switch to slf4j to allow clients to use their own logger implementation?
java.util.logging is slowest from implementations.
https://www.loggly.com/blog/benchmarking-java-logging-frameworks/
Personally, I didn't see any reasons to keep OLogManager. It provide a little bitbetter performance (measured by me) in respect to JUL, but it's still beyond log4j and log4j2.

Btw, I can transform codebase to slf4j + log4j2 and then we can compare performance. What do you think?

And one more point: there are loggers which allow to build much more complex logging infrastracture - for example sending logs by tcp.

[lvca]

+1

[smolinari]

Also please take into account this: https://github.com/orientechnologies/orientdb/issues/5141

Scott

[zerovian]

Please please please switch to slf4j and abandon the custom log formatter and use of JUL.

And I second the vote...ditch OLogManager class completely, it is trying to do things better handled by a proper logging implementation.

[ygyg70]

Another problem with OLogManager is that shutdownFlag is set to false only on class load, making it impossible to shut down embedded server and start again.