[ 
https://issues.apache.org/jira/browse/MNG-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17831770#comment-17831770
 ] 

Iurii Ignatko commented on MNG-8086:
------------------------------------

Just for the record, the full command is any Maven command where one wants to 
specify the logging config file via -D.
For example:
{code:bash}
mvn clean package -Djava.util.logging.config.file=logging.properties
{code}
I understand, that the original intention in Maven 3.x might have been not to 
have this supported in the first place. And I'm also not arguing about bringing 
it back. 

However, it does seem odd that -D for any Java process can pass a system 
property, whereas it's not the case for Maven. 

I also understand there might have been a discussion about this somewhere else, 
so if the decision has been made, I can close the issue and rely on the 
MAVEN_OPTS moving forward.

> Maven no longer initializes logging configuration based on java.util.logging 
> config file
> ----------------------------------------------------------------------------------------
>
>                 Key: MNG-8086
>                 URL: https://issues.apache.org/jira/browse/MNG-8086
>             Project: Maven
>          Issue Type: Bug
>    Affects Versions: 4.0.0-alpha-12
>            Reporter: Iurii Ignatko
>            Priority: Major
>
> h3. Bug description and the root cause
> When supplying the logging configuration to the Maven build using 
> {{{}-Djava.util.logging.config.file{}}}, it is no longer propagated to the 
> logger.
> This started when the [following 
> PR|https://github.com/apache/maven/pull/1279] was merged. The reason is [this 
> line 
> |https://github.com/apache/maven/blob/003a5bc06daa6e74c98e4d8ab45c6643a6844975/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L191]
>  in the constructor and as a connected change, [this  
> initialization|https://github.com/apache/maven/blob/a5ea944c993d8c087b3d38fdaea55815e668e550/maven-jline/src/main/java/org/apache/maven/jline/MessageUtils.java#L37]
>  in {{org.apache.maven.jline.MessageUtils}}. 
> The root cause of the issue lies in the fact that any instance of 
> {{org.jline.utils.StyleResolver}} 
> [triggers|https://github.com/jline/jline3/blob/19c031c0bccaeea6a4346bc82c04c7bd3ec18888/terminal/src/main/java/org/jline/utils/StyleResolver.java#L27]
>  the {{java.util.logging.Logger}} initialization. This process happens before 
> MavenCli's 
> [doMain|https://github.com/apache/maven/blob/003a5bc06daa6e74c98e4d8ab45c6643a6844975/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L273]
>  method is invoked, which 
> [populates|https://github.com/apache/maven/blob/003a5bc06daa6e74c98e4d8ab45c6643a6844975/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L614]
>  the system properties the logging initializer uses.
> Before the migration to JLine, Jansi's JansiMessageBuilderFactory didn't have 
> any logger initialization logic (neither by itself nor by any auxiliary 
> components created when that library was used). Hence, the system properties 
> were all set by the time any logger was found, as that used to happen 
> somewhere later in the lifecycle.
> h3. Reproducer
> The issue can be easily reproduced by supplying the following logging 
> configuration to any Maven build:
> {code:java}
> handlers=java.util.logging.ConsoleHandler
> .level=FINE
> java.util.logging.ConsoleHandler.level=FINE
> java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter{code}
> When built with Maven version 4.0.0-alpha-10 (or any prior version), note the 
> amount of FINE level logs that are being printed.
> Starting from 4.0.0-alpha-12, those log entries are not printed anymore.
> h3. Solution
> The issue can be fixed in multiple ways:
>  # Reorganize object creation in Maven such that the logger initialization 
> happens after system properties are set.
>  # Change in JLine's {{org.jline.utils.StyleResolver}} 
>  # Some combination of both.
> I was able to do a quick fix using Option (1) as a PoC solution. A proper 
> fix, however, is something to decide upon.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to