[
https://issues.apache.org/jira/browse/STORM-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947238#comment-13947238
]
Peter Klipfel commented on STORM-122:
-------------------------------------
I ended up manually excluding all log4j dependencies from included libraries
that required them and removing all log4j code from the codebase. I think that
better documenting this would be a good way to move forward. The things that I
tried before this caused very strange behavior in storm (I tried things like
munging classpaths and jars).
Here is a sample from the build.sbt
{code:title=build.sbt}
"com.datastax.cassandra" % "cassandra-driver-core" % "1.0.3"
exclude ("org.slf4j", "slf4j-api")
exclude ("org.slf4j", "slf4j-log4j12")
exclude ("log4j", "log4j"),
...
{code}
I found them with sbt dependency-graph combined with a command like
{code}
find ~/.ivy2/cache/ -exec grep -ln slf4j {} \;
{code}
I hope that helps anyone else that might hit this issue
> 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)
