You're right that I might as well be talking about all third party libraries. In fact, I've said exactly that elsewhere, most recently at ApacheCon a month ago and also here:
https://jlbp.dev/JLBP-1 The difference is only that we really, really don't need to take the risk for logging libraries when the JDK provides a perfectly good option with reliable maintainers (i.e. Oracle and the OpenJDK project). But of course I'm happy to get rid of other third party dependencies wherever feasible. On Sat, Nov 5, 2022 at 6:04 PM Gary Gregory <garydgreg...@gmail.com> wrote: > > On Sat, Nov 5, 2022, 09:09 Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > > > After log4shell last year, I no longer have any patience for third > > party logging libraries, full stop. > > > > Uh? CVEs have occurred in all types of libraries, there is nothing about > logging that makes it more CVE-prone. You might as well be talking about > all third party libraries. > > Gary > > > > IMO logging should be done through java.util.logging, nothing else. > > This is fully functional since Java 1.4 twenty years ago. Log4j, > > slf4j, plexus-logging, etc. are all efforts to solve a problem we > > don't have any more. They are not needed and they introduce dependency > > problems and security issues. > > > > For one example, Google has used java.util.logging exclusively in all > > its internal Java code since at least 2008 and never needed anything > > more. This is a matter of policy inside Google, and as a result of > > this log4shell was close to a non-event for one of the largest Java > > shops on the planet. It wasn't a complete non-event only because of > > third party libraries that depended on log4j and open source projects > > that weren't quite as strict about following Google rules. > > > > To the extent Maven and its plugins are currently dependent on SLF4J > > and others, this should be fixed. We should not continue down this > > path in any new or updated code. To be clear: > > > > 1. I am willing to do some of the work of ripping out old logging > > calls and replacing them with j.u.l. > > > > 2. It is OK to have mixed logging during a transition period. > > > > 3. It is OK if some log messages are lost or appear when they're not > > expected during a transition period. Logging is never critical > > functionality. > > > > What I am not willing to accept are dependency management problems and > > major security holes like log4shell due to optional, convenience > > functionality. > > > > On Fri, Nov 4, 2022 at 10:57 AM Slawomir Jaranowski > > <s.jaranow...@gmail.com> wrote: > > > > > > Hi, > > > > > > I want to start ( again :-) ) a discussion about logging in Maven > > plugins. > > > > > > First I agree that plugin developers should use logging methods provided > > by > > > Plugin api. > > > > > > But we can not expect plugin developers to write everything from scratch. > > > In many cases they may want to use an external library to do tasks needed > > > by the plugin. > > > > > > We don't have any control over what logging framework is used in the > > > external library used by plugin developers. > > > > > > We also maintain some libraries which can be used by plugin and also as > > > standalone in another project. > > > In such a case the question is - what logging we should use [1]? > > > > > > Last time I did a test, I use Java util logging from JDK in the Maven > > > plugin. > > > I see that Java util logging use default configuration, eg. we will have > > > two lines for one log event. > > > Even more options -q and -X have no effect for such a logger. > > > > > > One of the solution for such problem is using "Bridging" methods > > supported > > > by slf4j [2] > > > Probably all of existing and future logging frameworks can not be > > covered - > > > but most of common using will be. > > > > > > I hope that, even if we will want to change the logging framework used > > > internally in Maven, we can also use the same method. > > > > > > [1] https://github.com/apache/maven-dependency-analyzer/pull/71 > > > [2] https://www.slf4j.org/legacy.html > > > > > > > > > -- > > > Sławomir Jaranowski > > > > > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
