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

Robert Joseph Evans commented on STORM-122:
-------------------------------------------

Do you think it would be enough to document this so it is simpler to fix 
topologies? Or are you looking for us to switch back to log4j? Or do you want 
something radical/scary like munge with submitted topology jars and try to 
strip out problematic classes? 

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

Reply via email to