maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juan Pablo Santos Rodríguez (JIRA) <j...@codehaus.org>
Subject [jira] (MNG-5510) Maven causing ClassCastException with container plugins when project is using other SLF4J implementation than slf4j-simple
Date Mon, 16 Jun 2014 07:28:10 GMT

     [ https://jira.codehaus.org/browse/MNG-5510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Juan Pablo Santos Rodríguez reopened MNG-5510:
----------------------------------------------


Hi Jason,

let me reopen the issue, as it seems to me it has been misunderstood. The issue is triggered
because of having speficic requirements coded against specific SLF4J implementations (btw,
f.ex., if you try to reload the log's config file you'll have to go against your specific
SLF4J implementation), but it's only an example, as the issue has a broader scope. 

We've already made the appropiate changes to bypass the affected code if not on Logback and
carried on, but it was just an example of Maven leaking its SLF4J implementation. We had problems
with the tomcat and jetty maven plugins when using a different SLF4J implementation, because
of having two different SLF4J implementations on classpath.

Another example: go to {{$MAVEN_HOME/lib}} and change the simple-slf4j jars with another SLF4J
implementation. Just because you want to colour maven output, or you want your logs on a database
or whatever strange reason you may come up to. As noted at the bottom of \[#1], it's fairly
trivial. 

Then, when doing a {{mvn sonar:sonar}} on any maven project, you'll get something like:

{code}
08:26:09.204 [main] ERROR org.apache.maven.cli.MavenCli Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.3:sonar
(default-cli) on project YOUR_PROJECT_HERE: Error setting Log implementation.  Cause: java.lang.reflect.InvocationTargetException:
org/slf4j/Marker -> [Help 1]
08:26:09.204 [main] ERROR org.apache.maven.cli.MavenCli
{code}

Forking a new VM may not always be an option, and there may be justified cases which enforce
the use of an specific slf4j implementation, leading to this issue. I'm attaching a simple
project to reproduce the issue.

\[#1] http://maven.apache.org/maven-logging.html

> Maven causing ClassCastException with container plugins when project is using other SLF4J
implementation than slf4j-simple
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: MNG-5510
>                 URL: https://jira.codehaus.org/browse/MNG-5510
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Bootstrap & Build, Logging
>    Affects Versions: 3.1.0
>            Reporter: Juan Pablo Santos Rodríguez
>         Attachments: MNG-5510-sample.zip
>
>
> On our project we're using directly logback to start up a custom mbean to be able to
change log levels dynamically, among other things. Most of these operations are Logback-specific,
they're not available via SLF4J API
> For testing we use Jetty, so when we're doing an mvn jetty:run, the mbean gets init'd
and we get an Exception stating "ClassCastException: org.slf4j.impl.SimpleLoggerFactory cannot
be cast to ch.qos.logback.classic.LoggerContext", due to slf4j-simple being on maven's lib.
This is very likely to happen with other container plugins (tomcat7 et al)



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

Mime
View raw message