tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brendan Le Ny (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MTOMCAT-257) Classpathes separation between plugin and application is broken (can't use slf4j-jcl in app)
Date Mon, 20 Jan 2014 17:32:20 GMT

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

Brendan Le Ny commented on MTOMCAT-257:
---------------------------------------

<useSeparateTomcatClassLoader>true</useSeparateTomcatClassLoader> doesn't solve
the issue.

It seems that the classpaths are not separated.

I've created a project to show the whole issue. The problem appeared when i added shiro as
a dependency to my project. Shiro depends on slf4j-api. I also use commons-codec 1.8. My project
use log4j to log and slf4j-jcl to gather slf4j logs (so i will get Shiro's log). Log4j and
slf4j-jcl are in scope runtime.

Here is the whole thing:

    if I do a tomcat:run, the application breaks, because tomcat-plugin put jcl-over-slf4j
in classpath and slf4j initialization fail because you can't have both jcl-over-slf4j and
slf4j-jcl in the same classpath. The application works when deployed in a tomcat, but it doesn't
work in tomcat:run. That's the exact problem Tony raised.
    If I add <useSeparateTomcatClassLoader>true</useSeparateTomcatClassLoader>
in plugin config, it solve the issue because jcl-over-slf4j and slf4j-jcl
    But ! it raise another issue: in my application, I use commons-codec 1.8 and when the
time come when the class is loaded, I get a linkage error saying that DigestUtils#sha1hex
method doesn't exists. It exists in commons-codec 1.8 but not in commons-codec version declared
in tomcat-plugin. So it seems that even with useSeparateTomcatClassLoader=true, the actual
classpath of the application running in tomcat7:run is not the same that the one given by
mvn package, ie with the exact dependencies and exact version defined in the project's pom.

For now, the only workaround i've found is to leave useSeparateTomcatClassLoader = false and
add a maven profile to put slf4j-jcl in scope runtime, I use the profile only when doing a
tomcat7:run. I don't know if useSeparateTomcatClassLoader = true is buggy or what occurs actually
but it's sure that the application's classpath is not sane.

> Classpathes separation between plugin and application is broken (can't use slf4j-jcl
in app)
> --------------------------------------------------------------------------------------------
>
>                 Key: MTOMCAT-257
>                 URL: https://issues.apache.org/jira/browse/MTOMCAT-257
>             Project: Apache Tomcat Maven Plugin
>          Issue Type: Bug
>          Components: tomcat7
>    Affects Versions: 2.1
>            Reporter: Brendan Le Ny
>            Assignee: Olivier Lamy (*$^¨%`£)
>         Attachments: MTOMCAT-227-2.zip, MTOMCAT-227.tgz
>
>
> I use in my war the slf4j-jcl, which is not compatible with the jcl-over-slf4j used in
the plugin dependencies.
> I give you a little project that show the problem.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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


Mime
View raw message