1

We are running SDL 2013 SP1 with Java 7 on the delivery side. We are trying to upgrade from an earlier release of DXA Java to DXA 1.4.1. While upgrading we noticed that none of Tridion CD libraries are generating any log information even though we have everything defined in the logback.xml file. Not having any log info makes troubleshooting impossible.

Below is the logback.xml we are using.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<property name="log.pattern" value="%date %-5level %logger{0} - %message%n"/>
<property name="log.history" value="7"/>
<property name="log.folder" value="D:/Apache/tomcat-sh-web13/logs"/>
<property name="log.level" value="WARN"/>
<property name="log.encoding" value="UTF-8"/>
<!-- Appenders -->
<appender name="rollingTransportLog" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <fileNamePattern>${log.folder}/tridion/cd_transport.%d{yyyy-MM-dd}.log</fileNamePattern>
        <maxHistory>${log.history}</maxHistory>
    </rollingPolicy>
    <encoder>
        <charset>${log.encoding}</charset>
        <pattern>${log.pattern}</pattern>
    </encoder>
    <prudent>true</prudent>
</appender>
<appender name="rollingDeployerLog" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <fileNamePattern>${log.folder}/tridion/cd_deployer.%d{yyyy-MM-dd}.log</fileNamePattern>
        <maxHistory>${log.history}</maxHistory>
    </rollingPolicy>
    <encoder>
        <charset>${log.encoding}</charset>
        <pattern>${log.pattern}</pattern>
    </encoder>
    <prudent>true</prudent>
</appender>
<appender name="rollingMonitorLog" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <fileNamePattern>${log.folder}/tridion/cd_monitor.%d{yyyy-MM-dd}.log</fileNamePattern>
        <maxHistory>${log.history}</maxHistory>
    </rollingPolicy>
    <encoder>
        <charset>${log.encoding}</charset>
        <pattern>${log.pattern}</pattern>
    </encoder>
    <prudent>true</prudent>
</appender>
<appender name="rollingCoreLog" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <fileNamePattern>${log.folder}/tridion/cd_core.%d{yyyy-MM-dd}.log</fileNamePattern>
        <maxHistory>${log.history}</maxHistory>
    </rollingPolicy>
    <encoder>
        <charset>${log.encoding}</charset>
        <pattern>${log.pattern}</pattern>
    </encoder>
    <prudent>true</prudent>
</appender>
<appender name="rollingSessionPreviewLog" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <fileNamePattern>${log.folder}/tridion/cd_preview.%d{yyyy-MM-dd}.log</fileNamePattern>
        <maxHistory>${log.history}</maxHistory>
    </rollingPolicy>
    <encoder>
        <charset>${log.encoding}</charset>
        <pattern>${log.pattern}</pattern>
    </encoder>
    <prudent>true</prudent>
</appender>
<appender name="rollingHibernateLog" class="ch.qos.logback.core.rolling.RollingFileAppender">
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    <fileNamePattern>${log.folder}/tridion/cd_hibernate.%d{yyyy-MM-dd}.log</fileNamePattern>
    <maxHistory>${log.history}</maxHistory>
</rollingPolicy>
<encoder>
        <charset>${log.encoding}</charset>
    <pattern>${log.pattern}</pattern>
</encoder>
<prudent>true</prudent>
</appender>  


<!-- Loggers -->
<logger name="com.tridion" level="${log.level}"/>
<logger name="com.tridion.transport">
    <appender-ref ref="rollingTransportLog"/>
</logger>
<logger name="com.tridion.transport.HTTPSReceiverServlet">
    <appender-ref ref="rollingDeployerLog"/>
</logger>
<logger name="com.tridion.transport.transportpackage">
    <appender-ref ref="rollingDeployerLog"/>
</logger>
<logger name="com.tridion.transformer">
    <appender-ref ref="rollingDeployerLog"/>
</logger>
<logger name="com.tridion.deployer">
    <appender-ref ref="rollingDeployerLog"/>
</logger>
<logger name="com.tridion.tcdl">
    <appender-ref ref="rollingDeployerLog"/>
</logger>
<logger name="com.tridion.event">
    <appender-ref ref="rollingDeployerLog"/>
</logger>
<logger name="com.tridion.monitor">
    <appender-ref ref="rollingMonitorLog"/>
</logger>
<logger name="Tridion.ContentDelivery" level="${log.level}">
    <appender-ref ref="rollingCoreLog"/>
</logger>
<logger name="com.tridion.preview">
    <appender-ref ref="rollingSessionPreviewLog"/>
</logger>
<logger name="com.tridion.storage.persistence.session">
    <appender-ref ref="rollingSessionPreviewLog"/>
</logger>
<logger name="org.hibernate.SQL">
    <appender-ref ref="rollingHibernateLog"/>
</logger>
<logger name="org.hibernate.type">
    <appender-ref ref="rollingHibernateLog"/>
</logger>

<root level="OFF">
    <!-- <level value="${log.level}" /> -->
    <appender-ref ref="rollingCoreLog"/>
</root>

<logger name="org.springframework"/>
<logger name="org.springframework.web"/>
<logger name="org.dd4t"/>
<logger name="com.sdl.webapp"/>
</configuration>

EDIT:

I noticed that Tomcat is not picking up the logback.xml from my web-inf/classes folder and instead it is taking a logback.xml from Tomcat/lib. I found that tomcat-juli.jar was replaced to use logback's version of tomcat-juli.jar and Tomcat/lib folder contained tomcat-juli-adapters.jar. After removing tomcat-juli-adapters.jar and replacing tomcat-juli.jar with the original one and deleting logback.xml from Tomcat/lib now even the blank files defined in my logback.xml are not being created.

  • I also noticed <configuration> tag is not closed? – Julián Hernández Jun 20 '16 at 11:18
  • It is actually closed in the xml file. Somehow got removed when copy/pasting the config here. – Husain Zahid Jun 20 '16 at 11:59
  • Does the user under which you are running the windows service have access to the log location? – Hiren Kaku Jun 20 '16 at 18:57
  • @Hiren The service is running under "Local System Account" which has full access to the log location. If files are being created I doubt this is a permissions issue. – Husain Zahid Jun 21 '16 at 7:02
  • You can rule out a permission problem by using Process Monitor (technet.microsoft.com/en-us/sysinternals/processmonitor.aspx); any file system related problems would be highlighted. Have you tried manually setting the <root level> logging to any other value than off? – RjE Jun 22 '16 at 12:00
2

Try to set this value:

<property name="log.level" value="WARN"/>

to DEBUG

<property name="log.level" value="DEBUG"/>

And restart the deployer service.

  • Setting log.level to DEBUG made no difference at all. All Tridion log files are created in the specified location but they are all blank. – Husain Zahid Jun 20 '16 at 11:35
  • If you restart tomcat and Tridion services, the creation date of the log files changes acording to the restart time? – Julián Hernández Jun 20 '16 at 12:40
  • Yes the creation date does change. In fact if I delete all log files from the specified folder and restart tomcat service, I can see new log files being created. But all blank. – Husain Zahid Jun 20 '16 at 13:48
  • You could try with the reference logback.xml sample file, wich comes with the installation CD of tridion 2013sp1 (Content Delivery\roles\context\configuration\samples) changing only the log folder route. Just to ensure there are no errors in your logback.xml – Julián Hernández Jun 20 '16 at 15:22
  • Already tried the sample logback file from 2013sp1 installation CD. Didn't work either. – Husain Zahid Jun 20 '16 at 18:07
1

We did some research and found that Apache Apache ActiveMQ causes a conflict because it has a dependency on slf4j-log4j and thus logback is not initialized properly (multiple slf4j bindings). We were able to get the CD logging working after removing activemq-all.jar and instead using only the required jar files.

0

I have not tried the solution, but maybe the problem is in the 4 logger elements, that must be before de root node. Have you tried changing this?

As the problem seems to be lying in the logback configuration, the console of the application must be showing some traces of the loading of the logback configuration. Have you seen the console logs?

  • This is running under Tomcat which is run as a Windows Service in our case. Console shows same basic info as in STDOUT file which is not very informative. – Husain Zahid Jun 20 '16 at 12:02
0

Check on the permission of the D:/Apache/tomcat-sh-web13/logs folder. It's possible there's no write permission

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.