Is it safe to disable "play" logger?

53 views
Skip to first unread message

Aleksandar Stojadinovic

unread,
Feb 4, 2016, 11:40:51 AM2/4/16
to play-framework
Hello,

Is it considered safe to disable the play logger (<logger name="play" level="OFF"/>), in production? The thing is I have a feeling there is a kind of duplication, since the PlayDefaultUpstreamHandler logs everything as an error, even though I handle some things in a custom ErrorHandler and log it a INFO or WARN or ignor eit. I can disable this by just disabling the play logger and it does not show up anymore. After all, server errors not handled by me are generally sent up to the DefaultHttpErrorHandler, which logs them as error by default, also. My fear is, will I miss some important messages from this logger?

Best regards

René Grüner Vangsgaard

unread,
Feb 9, 2016, 2:24:28 AM2/9/16
to play-framework
Hi

I am also annoyed that errors handled in a custom ErrorHandler are logged. I hacked around it by overriding onServerError(), here is a snippet of my code:
  override def onServerError(request: RequestHeader, exception: Throwable): Future[Result] = {
   
try {
      val usefulException
= HttpErrorHandlerExceptions.throwableToUsefulException(sourceMapper.sourceMapper,
        environment
.mode == Mode.Prod, exception)

      onServerErrorCommon
(request, usefulException).getOrElse{
       
// If we haven't handled the exception ourselves, use default error handling.
        logServerError
(request, usefulException)

        environment
.mode match {
         
case Mode.Prod => super.onProdServerError(request, usefulException)
         
case _ => super.onDevServerError(request, usefulException)
       
}
     
}
   
} catch {
     
case NonFatal(e) =>
       
Logger.error("Error while handling error", e)
       
Future.successful(InternalServerError)
   
}
 
}

 
def onServerErrorCommon(request: RequestHeader, exception: UsefulException): Option[Future[Result]] = {
   
...
 
}

It is almost a copy of the default onServerError() with the logging removed for errors that I have handled.

Regards,
René
Reply all
Reply to author
Forward
0 new messages