Le dim. 3 mars 2024 à 19:18, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit :
> Le 2024-03-03 à 18 h 48, Romain Manni-Bucau a écrit : > > >> (snip) Nothing force us to use System.getLogger() for getting an > >> instance of that interface. (snip) > >> > > Yes but you make something well specified misbehaving so while > > technically true I think it would deserve us on the long run. > > > I do not understand this argument. The proposal is to replace a custom > interface by a standard one doing the same thing. How to get an instance > of that interface does not need to change. This is currently done that > way in Maven Mojos: > > @Inject > protected Log logger > > It would stay as before, except that Log would become System.Logger. > Where do you see a misbehaviour? > Ok, then the idea of maven-api was to abstract anything from the implementation to be able to change, as you can see if you use System.Logger you can't until you don't respect the contract which implies LoggerFinder is used which would be a misbehavior of the JVM for any user - and as overriding JUL it is used. > > > >> I did not talked about performance, but about misleading information > >> filled in log record (snip). > > > > For me it means a bug in the implementation > > > It is not a bug. When a logger uses stackwalker for determining who is > logging, it stops at the first stack frame which is not a method > internal to the logger implementation. It has no way to know that it > should continue a few more frames further. There is no API for saying > "please ignore stack frames that are inside the Maven Log class". > So you mean reusing existing impl? this would be handled by maven bridge so not an issue to me, same as today there. > > When using java.util.logging, we can override the automatic detection by > our own. But this is more work, e.g. we have to replace all calls to a > Logger.log(…) method by a call to our custom method which will override > the LogRecord default values. However 1) we cannot do that with > System.Logger, and 2) we don't need this complication at all if we just > use the logger directly, without passing through a Maven custom interface. > I'm not sure what you plan to do but it is the same amount of work (normalized by the capacity of the API, indeed JUL has more API than current System.Logger). Long story short it is a matter of using https://github.com/apache/cxf/blob/main/core/src/main/java/org/apache/cxf/common/logging/AbstractDelegatingLogger.java . > > > > So overall I'm not sure the goal, > > > For example when Maven is run with the --debug flag, it could use the > logger provided by System.getLogger() instead of the Maven default > "println-like" logger. We may lost coloration, but each log message > would be preceded by a line telling which method in which class emitted > that log. This is very useful when there is no exception stack trace but > we still want to look in the code what is going on. > Hmm, I see so you mean if we change everything we could get the same than what we have today? You can already switch slf4j binding - I use JUL for ex but logback is another common one - and get these info. So if it is your goal I guess we can work on the documentation only? > > Martin > >
