mkurz and dwijnand Don't deprecate whole play.Logger, but only the static Logger singlet…
…on (#8813)

In RC3 `play.Logger` [is deprecated]( I get [the idea](#1669) why using that class introduces some problems. However I think we should not deprecate the class itself, but only it's `static` methods. The same for `play.api.Logger` - we should only deprecate the usage of the singleton. But for both cases it's totally OK to use its instances, there is nothing wrong with them IMHO.
The advantage of using those wrapper classes instead of SLF4J itself is that right now SLF4J [does not provide logging methods which accept lambda expression]( as parameters (for lazy evaluation). That's why I would still keep `Play.Logger` and `play.api.Logger` for now (and finally deprecate them once SLF4J introduces that lambda parameters.) See #7082 which added lazy logging via suppliers to `play.Logger`.
Latest commit 179a425 Nov 19, 2018

Play Framework - The High Velocity Web Framework

Gitter Maven

The Play Framework combines productivity and performance making it easy to build scalable web applications with Java and Scala. Play is developer friendly with a "just hit refresh" workflow and built-in testing support. With Play, applications scale predictably due to a stateless and non-blocking architecture. By being RESTful by default, including assets compilers, JSON & WebSocket support, Play is a perfect fit for modern web & mobile applications.

Learn More


Copyright (C) 2009-2018 Lightbend Inc. (

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this project except in compliance with the License. You may obtain a copy of the License at

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.