Github user pwendell closed the pull request at:
https://github.com/apache/incubator-spark/pull/573
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. To do so, please top-post your response.
If your project does not have this feat
Github user srowen commented on the pull request:
https://github.com/apache/incubator-spark/pull/573#issuecomment-35619639
@aarondav They are actually separate issues, although concerning the same
specific aspect of the code. @pwendell has a good handle on this particular
problem I th
Github user aarondav commented on the pull request:
https://github.com/apache/incubator-spark/pull/573#issuecomment-35221813
I'm not 100% caught up on the state of this issue. Is #570 a "complete fix"
for this issue, or is this PR still the best fix we have in the pipeline? Is it
in a
Github user prb commented on the pull request:
https://github.com/apache/incubator-spark/pull/573#issuecomment-34715973
The infinite loop was caused by the fact that the list of appenders is
*always* empty when the slf4j mock implementation of log4j is in place.
Github user srowen commented on the pull request:
https://github.com/apache/incubator-spark/pull/573#issuecomment-34701207
I think I misunderstood the nature of the infinite loop and thought it had
to do with querying for the appenders. If not, yeah, removing the guard does
not affect
Github user pwendell commented on the pull request:
https://github.com/apache/incubator-spark/pull/573#issuecomment-34698102
The issue is a user reported problems when they were writing from slf4j to
Logback, they had log4j-over-slf4j on the classpath, and this initialization
code kic
Github user srowen commented on the pull request:
https://github.com/apache/incubator-spark/pull/573#issuecomment-34666426
Sorry, my meaning was: how about solving this by removing the guard? The
guard is the problem. It's there to prevent executing the log4j config when
log4j is not
Github user pwendell commented on the pull request:
https://github.com/apache/incubator-spark/pull/573#issuecomment-34665107
@srowen There is a guard in the form of checking that slf4j is bound to
log4j... is there any other guard you can think of? I think this means this
should only
Github user srowen commented on the pull request:
https://github.com/apache/incubator-spark/pull/573#issuecomment-34623406
A few thoughts on this issue -- I don't know if these lead to a solution --
Is it necessary to guard this block of code with a check to see if log4j is
be
Github user AmplabJenkins commented on the pull request:
https://github.com/apache/incubator-spark/pull/573#issuecomment-34608470
All automated tests passed.
Refer to this link for build results:
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/12658/
Github user AmplabJenkins commented on the pull request:
https://github.com/apache/incubator-spark/pull/573#issuecomment-34608468
Merged build finished.
Github user AmplabJenkins commented on the pull request:
https://github.com/apache/incubator-spark/pull/573#issuecomment-34607127
Merged build triggered.
Github user AmplabJenkins commented on the pull request:
https://github.com/apache/incubator-spark/pull/573#issuecomment-34607128
Merged build started.
GitHub user pwendell opened a pull request:
https://github.com/apache/incubator-spark/pull/573
Default log4j initialization causes errors for those not using log4j
This is a re-do of #560 which got merged too soon. There are some maven
build issues we need to fix before merging this
14 matches
Mail list logo
