Le sam. 5 nov. 2022 à 19:03, Gary Gregory <garydgreg...@gmail.com> a écrit :
> 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. > Gale is different is cve comes from the jre or a lib. Jre is a must upgrade anyway, a lib is additional work so JUL wins there by design. Guess it was the point. > 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 > > > > >
