Closed SergioK29 closed 1 month ago
I'm not sure that l4j is really causing enough issues for us to deal with diverging away from the rest of the ecosystem, and if we did, it would be a long ways away
I'm not sure that l4j is really causing enough issues for us to deal with diverging away from the rest of the ecosystem, and if we did, it would be a long ways away
If I made a single class minimal logger that writes lines to a file and zips old ones, would velocity implement it? is there some kind of fancy other functionality that velocity uses loggers for or anything?
No, because people rely on L4J, and so we can't just break it without a strong reason to do so at an appropriate time to do so
Our terminal itself is also a Log4J appender; I've never really seen any issues with Log4J other than it having a metric ton of functionality which doesn't get enabled, and the fact that appenders are blocking by default, but, that is easy to mitigate once I can/do get around to it
We would need a really strong reason to migrate away from one of the most popular logging frameworks in use within the wider java ecosystem, not only pretty much the defacto option within our space, over fairly abstract complaints about the framework.
If there is an issue that you've actually seen with Log4J, i'd be interested to hear about it, but, as it stands, it would take something pretty large for me to consider migrating away from this, and is definitely not something we can just do on a whim with all of the ecosystem generally being tied to this.
Requested Feature
Log4j is very inefficient, bloated and has had security issues in the past. For velocity's use case (which is very simple, just writing lines to log file and zipping old logs), something simpler such as tinylog or more modern such as logback would be an improvement.
Why is this needed?
Log4j is bloated, has security issues, and has bad performance
Alternative Solutions
🤷
Additional Information
No response