> I would question the choice to use any logging implementation at all This is a fair point, and we could go that route. It would be a bigger change and would change the way storm would be deployed. Right now, the scope of the change I was focusing on was just to add a proper way to handle syslog while changing as little of the functionality as possible.
If we want make the logging implementation up to the user, we would probably want to handle that it its own JIRA issue. -- Derek ________________________________ From: Tim Molter <[email protected]> To: [email protected] Sent: Saturday, February 21, 2015 5:18 AM Subject: Re: Seeking opinions on moving storm from logback to log4j 2.x I always thought the point of using slf4j was to give final control to the end user of a library to pick and configure the specific logging implementation. I would question the choice to use any logging implementation at all, but then again, I'm not an expert in Storm at all, just an outside observer. However, if you need a specific functionality for syslogging that logback doesn't support, it seems to me to be an issue with the way Storm handles logging. I've seen this problem in Dropwizard too. They hard code an implementation of logback and don't let the end user configure logging themselves. I think their thinking is that they don't want to "inconvenience" the end user to have to figure out logging for themselves. The tradeoff, however, is that the end user is forced to accept and work within that hard coded logging framework. That's just my two cents from an observer's point of view. I have no idea why Storm's logging is how it is or whether it's "good" or "bad". ~Tim On 2015_02_20 8:45 PM, Derek Dagit wrote: > Hi all, > > Following up, do any users on the list have thoughts about the switch? > > Good/Bad/Indifferent? > > >
