A big difference in production environments is the logging aspect. When testing your application locally, you start it via play start or play test and check the console output every now and then. On production system the application is started with play run and forked into the background from then on. Log output is written to the logs directory inside the application.
As the default log4j configuration in Play logs to the console, you should always go with a custom log4j file in production deployments.
There are several possibilities to do log rotation because it is being built into log4j. However, the most common ones are either rotating if the file has reached a certain limit, or does daily log rotation. This example works for file size based rotation:
log4j.rootLogger=ERROR, Rolling
log4j.logger.play=INFO # default log level
log4j.appender.Rolling=org.apache.log4j.RollingFileAppender
log4j.appender.Rolling.File=logs/application.log
log4j.appender.Rolling.MaxFileSize=1MB
log4j.appender.Rolling.MaxBackupIndex=100
log4j.appender.Rolling.layout=org.apache.log4j.PatternLayout
log4j.appender.Rolling.layout.ConversionPattern=%d{ABSOLUTE} %-5p ~ %m%nYou can change it to daily (or even hourly rotation) by writing the following:
log4j.appender.Rolling=org.apache.log4j.DailyRollingFileAppender log4j.appender.Rolling.DatePattern=yyyy-MM-dd
If you need hourly rotation due to heavy log writing, use .yyyy-MM-dd.HH as DatePattern.
In case you need class based logging, you may not use the play.logger.Logger class, but you have to implement your own logger in your class like the following code:
private static final Logger log = LoggerFactory.getLogger(YourClass.class);
Use the logger now as every normal log4j logger in your source code. This means you will lose the varargs style logging, which comes with the nice Play logger, as it is wrapped around log4j.
Then add this to your log4j.properties:
log4j.logger.yourPackage.YourClass=DEBUG
Logging is simple, as long as you keep it simple. You can possibly have arbitrary complex log4j configurations with different rotation and log levels per class. You should never have more than a few log files. Otherwise, you will lose overview pretty quick. A good rule of thumb is to talk to the system engineers, what kind of logging they want and need, as they are more likely to wade through these files instead of the developers.
If you really wish to (as you might be used to or you have old configurations lying around) you can also put a log4j.xml file into the conf/ directory of your application. It will work as well as the log4j.properties file.
It is important to mention that the log4j configuration does not get reloaded on each change, especially if you are in production mode. You might be used to that, if you are using JBoss or other application servers. If you really need to change this, you can recompile the Play framework and change the play.logger.Logger class from:
PropertyConfigurator.configure(log4jConf);
To:
PropertyConfigurator.configureAndWatch(log4jPath);
This checks every 60 seconds whether the log4j configuration file has changed and reloads it. Not all changes are reflected though. You should check play.logger.Logger.setUp() for more information.
As there is almost no Play specific part in logging, there is not much extra information to be listed.
You can read a whole lot more about log4j at http://logging.apache.org/log4j/.
Inside of the Play source a log4j configuration has already been defined. It defines several log levels by default, for example for Hibernate, Spring, Quartz, DataNucleus, Apache HttpClient, or OVAL. If you experience problems with one of these in logging, you should check this exact log4j configuration in the source code. You can grab the configuration file from framework/src/log4j.properties in your Play framework folder.