search

allanbank / mongodb-async-driver

The MongoDB Asynchronous Java Driver.
Apache License 2.0
22 stars 14 forks source link

Using "org.slf4j.Logger" instead of "org.slf4j.spi.LocationAwareLogger" #20

Open igreenfield opened 9 years ago

igreenfield commented 9 years ago

Why are you using "org.slf4j.spi.LocationAwareLogger" as base logger and not the "org.slf4j.Logger" as base? I am using an LoggerFactory that create it own logger and it only extends the "org.slf4j.Logger" ?

allanbank commented 9 years ago

Since the driver does not directly bind to the logger and instead use reflection the LocationAwareLogger allows us to pass the entry class for the logger. That makes sure that the source/line/method in the log records is the call site for the logging and not the internal logging class itself.

igreenfield commented 9 years ago

The problem with this is, I am using this: https://github.com/foundation-runtime/logging and it create logger that does not extends this logger. how I can over come this?

allanbank commented 8 years ago

Looks like the log4j2 version does implement the LocationAwareLogger:

https://github.com/foundation-runtime/logging/blob/master/logging-log4j2/src/main/java/com/cisco/oss/foundation/logging/slf4j/Log4jLogger.java

yairogen commented 8 years ago

doesn't the location aware have a big impact on performance (if used to print the class name and line that originated the log?) Also, why are you using your own interface and not regular slf4j logger interface?

allanbank commented 8 years ago

doesn't the location aware have a big impact on performance (if used to print the class name and line that originated the log?)

There is a penalty only if you ask to log the location. SLF4J (and most other frameworks) won't try to determine the location if it is not needed. Using the location aware logger makes not difference on if you incur that overhead. The only method on the interface is a "log(...)" that takes as an argument the class that is the logging facade. Using the interface just makes sure that the result of the location lookups is correct.

Also, why are you using your own interface and not regular slf4j logger interface?

This is a philosophical issue.

The driver is just a driver. It should avoid making as many non-driver decisions for the users of the driver as possible. In my opinion forcing a project that is using log4j (for historical or other reasons) to include two jars from SLF4J (one of which they have to know to include) is just plain wrong.

We work very hard to keep the dependencies for the driver at zero so that projects can make there own decisions on what logger, I/O support library (like Netty) or current hot framework they want to work with. Our thin logging shim is one example of that work. We have some work in progress to make injecting other frameworks into appropriate locations in the driver. Some of those will require dependent jars but those will be isolated into adapter projects so users can pick and choose which support/framework libraries work for them.