Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Maven Developers List" <dev@maven.apache.org>
Subject: Re: MNG-5916: Allow filtering out certain loggers from within a
 plugin
References: <CAKnbemVq8rMH=1n40HoF8h7rAM8UGqYet=v22JtAqaRDQeCiAA@mail.gmail.com>
Date: Fri, 10 Jun 2016 20:26:58 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Robert Scholte" <rfscholte@apache.org>
Organization: Apache Software Foundation
Message-ID: <op.yiuti8xakdkhrr@desktop-2khsk44>
In-Reply-To: <CAKnbemVq8rMH=1n40HoF8h7rAM8UGqYet=v22JtAqaRDQeCiAA@mail.gmail.com>
User-Agent: Opera Mail/12.17 (Win64)
archived-at: Fri, 10 Jun 2016 18:26:48 -0000

Hi Petar,

I don't think that it should be the *plugin* who decides what the loglevel  
should be, but the user.
One of my big wishes is to be able to specify for which plugin or goal you  
want to change the loglevel.
For example: mvn verify -X makes *everything* log on debug level. Instead  
I would to see something like -X install:install, meaning I would see  
normal (info) logging for all but the install goal of the  
maven-install-plugin.
The problem is that you expect to see debug messages from Maven (and other  
used libraries) as well, just like it is done right now. Dynamically  
switching loglevel for these shared core-classes is a challenge,  
especially in when running with multiple threads!

Based on MNG-5916 it states that this is regression, so the problem seems  
to be a bit different. However I don't like the idea that the plugin  
controls the loglevels.

thanks,
Robert

On Fri, 10 Jun 2016 14:41:09 +0200, Petar Tahchiev <paranoiabla@gmail.com>  
wrote:

> Hello,
>
> I recently got into a problem with my custom plugin. I want to filter out
> some loggers, only for my plugin execution and I realized this is not
> possible at the moment. I found out this issue which states exactly the
> same:
>
> https://issues.apache.org/jira/browse/MNG-5916
>
> The bottleneck for me seems to be the slf4j. SLF4J does not allow you to
> change at runtime the log levels, as stated here:
>
> http://stackoverflow.com/questions/14544991/how-to-configure-slf4j-simple
>
> I actually tried putting this in my Mojo:
>
> System.setProperty(org.slf4j.impl.SimpleLogger.DEFAULT_LOG_LEVEL_KEY,  
> "WARN");
>
> but it had no effect because the logger had already been created.
>
> If, on the other hand, they did allow the runtime switch of the log  
> levels
> then we could have a method (for example reconfigure()) in the
> AbstractMojo's log object, like this:
>
> @Override
> public void execute() throws MojoExecutionException,  
> MojoFailureException {
>
>    Map<String, String> config = new HashMap<>();
>
>    config.put("org.slf4j.simpleLogger.defaultLogLevel", "WARN");
>
>    getLog().reconfigure(config);
>
> }
>
> and so each Mojo could reconfigure the log before it's own execution.  
> This
> is very rough, but I hope you get it. I'm also far from the idea to  
> switch
> the log level API, but is there any particular reason we're sticking with
> SLF4J's SimpleLogger? I know Log4J2 and Logback provide the ability to
> change the log levels at runtime. And I also don't think performance-wise
> they are a lot worse than SLF4J (considering the amount of log a typical
> maven execution produces).
>
> I would be interested to hear your opinion.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org