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

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

Hi Neale (Tony coworker speaking), 

<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.

> Can't use slf4j-jcl with tomcat7:run
> ------------------------------------
>
>                 Key: MTOMCAT-227
>                 URL: https://issues.apache.org/jira/browse/MTOMCAT-227
>             Project: Apache Tomcat Maven Plugin
>          Issue Type: Bug
>          Components: tomcat7
>    Affects Versions: 2.1
>            Reporter: Tony Chemit
>            Assignee: Olivier Lamy (*$^¨%`£)
>         Attachments: 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to