[
https://issues.apache.org/jira/browse/STORM-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13943140#comment-13943140
]
Robert Joseph Evans commented on STORM-122:
-------------------------------------------
By default the packaging we suggest groups to use is the maven-assembly-plugin
with jar-with-dependencies
http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#jar-with-dependencies
You can manually exclude the slf4j-log4j12 in your pom under all of the
dependencies, or you can create your own assembly config that excludes them
there. The main difference here is that logging may cause some problems in
your unit tests (NOTE: I just threw this together and have not tested it}
{code:xml}
<assembly
xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
<id>jar-with-dependencies-but-no-log4j</id>
<formats>
<format>jar</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<dependencySets>
<dependencySet>
<outputDirectory>/</outputDirectory>
<useProjectArtifact>true</useProjectArtifact>
<unpack>true</unpack>
<scope>runtime</scope>
<excludes>
<exclude>org.slf4j:slf4j-log4j12</exclude>
<exclude>log4j:log4j</exclude>
</excludes>
</dependencySet>
</dependencySets>
</assembly>
{code}
The other thing to be aware of is that running
{code}
mvn dependency:tree
{code}
Will print out exactly which dependencies are being pulled in and where they
are coming from. Be aware that once you squash one version of a dependency
with an exclude, you need to run the command again, because it only prints out
a dependency once, and if multiple things are pulling it in, the next one will
bubble up to the top.
> log4j-over-slf4j in 0.9.0-rc2 breaks existing topologies
> --------------------------------------------------------
>
> Key: STORM-122
> URL: https://issues.apache.org/jira/browse/STORM-122
> Project: Apache Storm (Incubating)
> Issue Type: Bug
> Reporter: James Xu
> Priority: Minor
>
> https://github.com/nathanmarz/storm/issues/745
> Apologies if this ticket is off-base, I'm not an expert in this area. We've
> been testing an existing topology we ran on Storm 0.8.1 on a deployment of
> Storm 0.9.0-rc2. The only roadblock we've encountered so far is the presence
> of the log4j-over-slf4j jar in the newer version. It turns out that
> log4j-over-slf4j is incompatible with slf4j-log4j12.
> Basically our topology uses slf4j as the the logging facade and log4j as the
> backend, which I've heard is a common pattern. It seems that in order to
> migrate to the new Storm version we must either move our code off of log4j or
> delete the log4j-over-slf4j jar from the storm classpath.
> Are we doing something crazy here? I'm open to alternate solutions, but it
> seems like an issue to break legacy topologies over logging. My understanding
> based on #144 was that Storm was migrating completely to slf4j, is this no
> longer true? Any insight, advice, or fixes would be helpful.
> --------
> jmlogan: You're going to have to exclude log4j and log4j-over-slf4j. Storm
> calls mostly seem to be slf4j, but it is not logger-agonistic. In 0.9.0, it
> will force logback onto your classpath at runtime, and will crash if it has
> multiple adapters.
> If you see a job failing to launch, right after updating, it's probably this
> issue. We ended up just excluding log4j from the offending dependencies.
> ---------
> bakks: Hey, thanks for your response. The issue is that log4j-over-slf4j is
> now a Storm dependency, so its loaded into the topology classpath by default.
> This wasn't true in earlier Storm versions, so perhaps this is intentional,
> but our topology which used to work now doesn't. It seems like there is now
> no way to use log4j as an slf4j backend. If that is the new state of the
> world, its fine, but it seems like an issue and I'm hoping for a workaround.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
