Maven 2 & 3

Remove log4j configuration warning

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Trivial Trivial
  • Resolution: Fixed
  • Affects Version/s: 2.2.0
  • Fix Version/s: 2.2.0
  • Component/s: Logging
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

Running mvn help:active-profiles -U on a (minimal) POM delivers

[INFO] artifact org.apache.maven.plugins:maven-help-plugin: checking for updates from central
log4j:WARN No appenders could be found for logger (hidden.org.apache.commons.httpclient.params.DefaultHttpParams).
log4j:WARN Please initialize the log4j system properly.

We probably need to ship with a log4j.properties to silence this harmless noise.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
John Casey added a comment -

I'm adding a log4j.properties file to $maven.home/conf so users can configure this to tune the output for the httpclient-based http wagon (possibly among other things). Likewise, embedders won't have to deal with collisions on this file, since they're likely to use the jars directly instead of the distro...and users with a different config file can always remove this file from their distro if it's in the way.

I've already made these changes on my localhost, just need to run the ITs to verify them.

Show
John Casey added a comment - I'm adding a log4j.properties file to $maven.home/conf so users can configure this to tune the output for the httpclient-based http wagon (possibly among other things). Likewise, embedders won't have to deal with collisions on this file, since they're likely to use the jars directly instead of the distro...and users with a different config file can always remove this file from their distro if it's in the way. I've already made these changes on my localhost, just need to run the ITs to verify them.
Hide
Permalink
John Casey added a comment -

still not quite fixed. Need to revisit.

Show
John Casey added a comment - still not quite fixed. Need to revisit.
Hide
Permalink
Mark Hobson added a comment -

Can you clarify why log4j is being shipped with Maven? Does HttpClient have a hard dependency on log4j and not go via commons-logging?

Show
Mark Hobson added a comment - Can you clarify why log4j is being shipped with Maven? Does HttpClient have a hard dependency on log4j and not go via commons-logging?
Hide
Permalink
John Casey added a comment -

I'm planning to include - but shade, making it inaccessible to plugins and the outside world - log4j 1.2.14. It seems that httpclient actually depends on clogging 1.0.4 (which is also shaded in to avoid classloader conflicts with plugins), but that the logging strategy employed by clogging actually looks for log4j classes by name on the classpath and will try to load them if they exist. If a plugin depends on log4j and happens to be the trigger that causes the http wagon, httpclient, and clogging to load, then clogging gets confused and tries to use the log4j included with the plugin. This is causing quite a bit of trouble in these cases, basically resulting in a stacktrace.

By including log4j in the core classpath, we can work around this strategy and make plugins that depend on log4j safe to use. I'm still working on this issue, and if I can supply a configuration for commons-logging that will allow us to leave out log4j, I'll do that instead.

Show
John Casey added a comment - I'm planning to include - but shade, making it inaccessible to plugins and the outside world - log4j 1.2.14. It seems that httpclient actually depends on clogging 1.0.4 (which is also shaded in to avoid classloader conflicts with plugins), but that the logging strategy employed by clogging actually looks for log4j classes by name on the classpath and will try to load them if they exist. If a plugin depends on log4j and happens to be the trigger that causes the http wagon, httpclient, and clogging to load, then clogging gets confused and tries to use the log4j included with the plugin. This is causing quite a bit of trouble in these cases, basically resulting in a stacktrace. By including log4j in the core classpath, we can work around this strategy and make plugins that depend on log4j safe to use. I'm still working on this issue, and if I can supply a configuration for commons-logging that will allow us to leave out log4j, I'll do that instead.
Hide
Permalink
John Casey added a comment -

I've moved Maven to use jcl-over-slf4j and slf4j-jdk14 in place of commons-logging and log4j. This solves the classloading exceptions from MNG-4207 and cleans up the log4j configuration warnings from this issue simultaneously.

Show
John Casey added a comment - I've moved Maven to use jcl-over-slf4j and slf4j-jdk14 in place of commons-logging and log4j. This solves the classloading exceptions from MNG-4207 and cleans up the log4j configuration warnings from this issue simultaneously.
Hide
Permalink
John Casey added a comment -

BTW, slf4j is shaded into the maven distribution now, so plugins using slf4j will get their own versions loaded into their classloaders.

Show
John Casey added a comment - BTW, slf4j is shaded into the maven distribution now, so plugins using slf4j will get their own versions loaded into their classloaders.
Hide
Permalink
Mark Hobson added a comment -

Sounds good to me, thanks for the summary.

Show
Mark Hobson added a comment - Sounds good to me, thanks for the summary.

People

  • Assignee:
    John Casey
    Reporter:
    Benjamin Bentmann
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: