Hello Samuel, I've tried your configuration with logback's latest version (0.8) and it seems to work. However, I'd change a few things about it. I've included your configuration, after a few modifications, at the end of this email. The TimeBasedRollingPolicy objects that you are configuring have a "ActiveFileName" parameter. This element was removed, because there was a double information between FileAppender's <File> element and the <ActiveFileName> element. We encourage people to use the <File> element in the RollingFileAppender's configuration instead. See [1] and [2] for more information about these components. The <param> elements, although perfectly compatible with logback, can be replaced by elements whose name is the option's name. For example, instead of writing: <param name="pattern" value="%-4relative [%thread] %-5level %class - %msg%n" /> you might want to write: <Pattern>%-4relative [%thread] %-5level %class - %msg%n</Pattern> In my opinion, this makes the configuration files much easier to read. Of course, you are absolutely free to use the <param> elements anyway. Now, to the core of your issue: since the two appenders are configured in similar manners, I find it strange that only one of them creates the log file. Since the <ActiveFileName> element is not used, the files are not created in the /var/log/smartcorridors/ directory. The <FileNamePattern> is used to guess the file name and the files are created in the application's directory. That is, they are created in the directory where they would have been put if you had entered only the name of the file in the <File> or formerly <ActiveFileName> element. Moreover, the log files are created when the appender is started. So even if there is no logging events that are to be logged in these files, they should exist anyway. Could you check if the files are actually created in the application's directory instead of the /var/log/smartcorridors/ directory? Or just try the configuration that I've appended at the end of this email. If both fail, it would help to see the StatusPrinter's output. You can tell logback to output the configuration statuses by adding a debug="true" in the configuration element, like in: <configuration debug="true"> ... ... </configuration> Hope this helps, Sébastien [1] http://logback.qos.ch/manual/appenders.html#RollingFileAppender [2] http://logback.qos.ch/manual/appenders.html#TimeBasedRollingPolicy Modified configuration file: <configuration debug="true"> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%-4relative [%thread] %-5level %class - %msg%n</Pattern> </layout> </appender> <appender name="bitranlog" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>/var/log/smartcorridors/bitran.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>bitran_%d{yyyy-MM}.log.gz</FileNamePattern> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%-4relative [%thread] %-5level %class - %msg%n</Pattern> </layout> </appender> <logger name="org.accma.concentrator.services.bitran.BiTranService"> <level value="debug" /> <appender-ref ref="bitranlog" /> </logger> <appender name="soccslog" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>/var/log/smartcorridors/soccs.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>soccs_%d{yyyy-MM}.log.gz</FileNamePattern> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%-4relative [%thread] %-5level %class - %msg%n</Pattern> </layout> </appender> <logger name="org.accma.concentrator.services.soccs.SOCCSService"> <level value="debug" /> <appender-ref ref="soccslog" /> </logger> <root> <level value="debug" /> <appender-ref ref="STDOUT" /> </root> </configuration> Samuel Doyle wrote:

Hi,

In my following properties file only the first logfile (bitranlog) gets generated and output directed to that. Should the one for the soccslog be generated as well from the SOCCSService class?

Thanks, S.D.

----

-- Sébastien Pennec sebastien@qos.ch Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch/