4 ms·

I think you misunderstand the point of log4j. Logging is not free, and outputting to all three of those is quite expensive (especially in the Docker case, and i

by junon 5y ago

I think you misunderstand the point of log4j. Logging is not free, and outputting to all three of those is quite expensive (especially in the Docker case, and it can even be dangerous as Docker - at least for a long time - did not implement proper backpressure and instead dropped logs). log4j allows libraries to implement logging and allow the end user to worry about where the logs go, at the application level, usually via config on the command line (e.g. modifying classpaths).

zaphar 5y ago
I'm not entirely sure libraries logging is a good idea anyway. I think there is a strong case that logging should be entirely an application concern not a library concern.
- watwut 5y ago
  The libraries being able to log what they do helps a lot when debugging production issues. The application does not see inside cache library or hibernate or what not. They themselves being able to log what they do inside helps a lot.
- shagie 5y ago
  I've got a bug... the application that I've deployed isn't working in this configuration. It's not even hitting my controller for me to be able to log to a file. So, I kick the log level from warn to debug and I see that Spring is booting it because it failed a CORS check. This was much easier than trying to reproduce it in my local system and attach a debugger to it. There is a lot that goes on beneath and behind the code that a person writes within the libraries. I would contend that the log4j vulnerability is because people didn't realize the extent of what was going on beneath and behind. Making a developer blind to what goes on inside a library is not the answer. The "what goes on inside of a library" is indeed a concern for the application and the developer and should be made as easy to access as possible.
  - zaphar 5y ago
    Is this partly due to the fact that everyone is depending on the libraries having logs instead of throwing the correct exception? Then the application could log it.
    - shagie 5y ago
      A program working correctly with incorrect input isn't an exceptional case. "This endpoint cannot be accessed in a CORS improper way" is caught in the library/framework level and doesn't even touch my code - there's no exception for me to catch. Throwing a checked exception for no access rather than returning "false" from a library call because you passed in all upper case on case sensitive role check would be a decision that I wouldn't agree with. Another example would be "I want to see the sql generated by hibernate" - that's not exception throwing at all, its me trying to debug what the query is and why the performance is awful.
- piva00 5y ago
  Have you never had to rely on logs from some JDBC library to figure out an issue in production? There are absolutely many reasons for a library to have logging, specially in the case of libraries providing tooling for anything that deals with networking (clients to any kind of services, serving requests through the network, etc.). I think that an opaque library in terms of logging is absolutely hell to deal with, I already have my fair share of issues with libraries that don't do enough logging and require painful hours of debugging instead of reading a log...
zorr 5y ago
Also note that log4j comes from an era before everything was "cloud-native". In the Java world before cloud-native we had application servers like Tomcat and JBoss which typically used something like log4j (log4j-core package) to configure what gets logged and where the logs should be shipped to. These application servers where shared and usually hosted more than 1 application. Hence the need to do contextual lookups (jndi and others) to determine log routing or enrich log messages with contextual information. Applications or libraries running inside these application servers would only implement a logging api (log4j-api package) which is just a facade so every application can write implementation-independant logging and let the application server provide the implementation and configuration. Now in the cloud-native/12-factor world, the industry has moved away from application servers (or embeds an app-specific server in the container) so it makes sense to just log to stdout and let the container orchestration handle log shipping and filtering. The former role of log4j is now mostly handled by Fluentd, Logstash, Filebeat and friends. Log4j still has a place though: Having the ability to use ENV vars or commandline flags to influence log levels and packages is still a nice to have. And one feature that is often overlooked is the ability to set contextual information per request. For example authentication middleware can set a userId or requestId in the request context and every log message within the request handling automatically gets logged with that metadata, avoiding the need to pass all this contextual information manually in every log.info(...) statement.

by junon 5y ago

zaphar 5y ago

I'm not entirely sure libraries logging is a good idea anyway. I think there is a strong case that logging should be entirely an application concern not a library concern.

watwut 5y ago
The libraries being able to log what they do helps a lot when debugging production issues. The application does not see inside cache library or hibernate or what not. They themselves being able to log what they do inside helps a lot.
shagie 5y ago
I've got a bug... the application that I've deployed isn't working in this configuration. It's not even hitting my controller for me to be able to log to a file. So, I kick the log level from warn to debug and I see that Spring is booting it because it failed a CORS check. This was much easier than trying to reproduce it in my local system and attach a debugger to it. There is a lot that goes on beneath and behind the code that a person writes within the libraries. I would contend that the log4j vulnerability is because people didn't realize the extent of what was going on beneath and behind. Making a developer blind to what goes on inside a library is not the answer. The "what goes on inside of a library" is indeed a concern for the application and the developer and should be made as easy to access as possible.
- zaphar 5y ago
  Is this partly due to the fact that everyone is depending on the libraries having logs instead of throwing the correct exception? Then the application could log it.
  - shagie 5y ago
    A program working correctly with incorrect input isn't an exceptional case. "This endpoint cannot be accessed in a CORS improper way" is caught in the library/framework level and doesn't even touch my code - there's no exception for me to catch. Throwing a checked exception for no access rather than returning "false" from a library call because you passed in all upper case on case sensitive role check would be a decision that I wouldn't agree with. Another example would be "I want to see the sql generated by hibernate" - that's not exception throwing at all, its me trying to debug what the query is and why the performance is awful.
piva00 5y ago
Have you never had to rely on logs from some JDBC library to figure out an issue in production? There are absolutely many reasons for a library to have logging, specially in the case of libraries providing tooling for anything that deals with networking (clients to any kind of services, serving requests through the network, etc.). I think that an opaque library in terms of logging is absolutely hell to deal with, I already have my fair share of issues with libraries that don't do enough logging and require painful hours of debugging instead of reading a log...

zorr 5y ago

Also note that log4j comes from an era before everything was "cloud-native". In the Java world before cloud-native we had application servers like Tomcat and JBoss which typically used something like log4j (log4j-core package) to configure what gets logged and where the logs should be shipped to. These application servers where shared and usually hosted more than 1 application. Hence the need to do contextual lookups (jndi and others) to determine log routing or enrich log messages with contextual information. Applications or libraries running inside these application servers would only implement a logging api (log4j-api package) which is just a facade so every application can write implementation-independant logging and let the application server provide the implementation and configuration. Now in the cloud-native/12-factor world, the industry has moved away from application servers (or embeds an app-specific server in the container) so it makes sense to just log to stdout and let the container orchestration handle log shipping and filtering. The former role of log4j is now mostly handled by Fluentd, Logstash, Filebeat and friends. Log4j still has a place though: Having the ability to use ENV vars or commandline flags to influence log levels and packages is still a nice to have. And one feature that is often overlooked is the ability to set contextual information per request. For example authentication middleware can set a userId or requestId in the request context and every log message within the request handling automatically gets logged with that metadata, avoiding the need to pass all this contextual information manually in every log.info(...) statement.