Consult the example logging configuration file below for guidance when working with other configurable options. You can also consult the logback documentation at http://logback.qos.ch/manual/ 
<!-- Scan/scan period mean that as the application is running, logback will check the file every 30 seconds for changes and re-load the configuration as needed -->
<configuration scan="true" scanPeriod="30 seconds"> 
<!-- This creates an appender (a place for log messages to go), names it "STDOUT" and says that this appender uses the built-in ConsoleAppender, which writes to the standard output stream. It can also be configured to write to standard error. -->
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> 
<!-- This filter prevents logging messages below the given level from being written to the appender. -->
<filter class="ch.qos.logback.classic.filter.ThresholdFilter"> 
<!-- By default, the console appender is OFF. Change as needed. --> 
<level>OFF</level> 
</filter> 
<!-- Encoders determine what the output looks like. Here we have each log message start with a date/time stamp that just shows the time, down to the millisecond.
The thread name and log level are shown, and then the name of the logger (limited to 36 characters). Finally, the message itself, followed by a newline --> 
<encoder> 
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender> 
<!-- This creates a second appender, names it "FILE" and says that it WILL be using the built-in RollingFileAppender. That appender writes to a file, and then periodically archives old logs. The rolling strategy is completely configurable --> 
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> 
<!-- The name of the 'base' log file. No path is given, so the file will be located in the 'current' directory. For the GUI, that means that the file will be in the installation directory. For the CLI, this will be whatever directory the CLI was started from. Note that this means there may be many daticaldb.log files scattered around the user's disk. We may want to do this differently. --> 
<file>daticaldb.log</file> 
<!-- As with the console appender above, this filters out messages below the given level. That means that DEBUG messages will be shown, but not TRACE messages. -->
<filter class="ch.qos.logback.classic.filter.ThresholdFilter"> 
<level>DEBUG</level>
</filter> 
<!-- This configures the rolling policy to create a new log file each day, naming the 'rolled' file 'daticaldb-2016-01-23.log' or similar, and to keep at most 30 days worth of log files. -->
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> 
<!-- daily rollover -->
<fileNamePattern>daticaldb.%d{yyyy-MM-dd}.log</fileNamePattern> 
<!-- keep 30 days' worth of history -->
<maxHistory>30</maxHistory>
</rollingPolicy> 
<!-- This encoder is identical to the one used above by the console appender -->
<encoder> 
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender> 
<!-- This configures what is called the 'root' logger. Logback allows for a hierarchy of loggers, making it possible for different loggers in the code to send output to zero, one, or many different destinations. We set the default log level to 'DEBUG', and then reference both of the named appenders. It is possible to refer to named loggers here, so that, for instance, all the messages from the com.datical.hammer.core package (and sub-packages) went to a specific appender, and all the messages from another package went to a different appender. -->
<root level="debug"> 
<appender-ref ref="STDOUT" />
<appender-ref ref="FILE" />
</root>
</configuration>