Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: jerry_jeremiah on March 07, 2015, 11:35:56 PM
-
I have a Composer VXML IVR app that uses the web request block to make back end calls. Composer writes a log file in the tomcat/logs directory called default_composer.log to store the details of sending the request and parsing the response.
According to the manual:
"Java Composer Projects exported as WAR files will have the log4j.xml bundled inside the WEB-INF\lib folder. If the log4j.xml configuration format is not working, you can add a log4j.properties in the tomcat/webapps/<application name>/WEB-INF/classes folder. "
So it should be controlled by a log4j.xml file but the log4j.xml file specifies a RollingFileAppender and a base file name of composer.log so the file should NOT be called default_composer.log
I have tried putting my own log4j.properties file in WEB-INF/classes and it does not specify a file called default_composer.log either. I have searched the box for files that mention default_composer and have found nothing so I can't figure out where it is coming from.
So why is Composer ignoring the log4j.xml and log4j.properties file and instead making a log file called default_composer.log ?
Thanks for the help,
Jerry
-
Is the jar for lo4 installed?
-
Yes. It also adds log4j-1.2.14.jar to the WEB-INF/lib directory along with the log4j.xml when the war is created. So all my Composer apps have both a log4j.xml and a log4j-1.2.14.jar automatically added but they aren't used.
I am assuming that not everyone else ends up with everything in default_composer.log but I don't know what I am doing differently to make it not work.
-
Ok, in case it helps someone else, I have fixed this the hard way.
The gvpbackend.jar that is put into the WEB-INF/lib directory has a class called com.genesyslab.studio.backendlogic.BackendLogManager that first checks for a log4j.xml configuration in the global Tomcat lib directory and then uses that if it finds it - but that doesn't solve the problem because then all the Composer apps share the configuration which means that they all still log to the same place. If it doesn't find that log4j.xml file it runs the following code:
[code]
localStringBuilder.append("log4j.rootCategory=DEBUG, R\n");
localStringBuilder.append("log4j.logger.com.dappit.Dapper.parser=ERROR\n");
localStringBuilder.append("log4j.logger.org.w3c.tidy=FATAL\n");
localStringBuilder.append("log4j.appender.R = org.apache.log4j.RollingFileAppender\n");
localStringBuilder.append("log4j.appender.R.File = ${catalina.home}/logs/default_composer.log\n");
localStringBuilder.append("log4j.appender.R.Append = true\n");
localStringBuilder.append("log4j.appender.R.layout = org.apache.log4j.PatternLayout\n");
localStringBuilder.append("log4j.appender.R.layout.ConversionPattern = %d %c{1} [%p] - %m%n\n");
[/code]
So what that means is that log4j works PERFECTLY fine and uses the the webapp's WEB-INF/lib/log4j.xml file (which is placed there by Composer) until the first Backend block in the IVR executes. From them on the rootCategory is changed to point to default_composer.log or wherever the global log4j.xml files says and all the logging for every Composer app ends up in the same file.
In order to make it continue to read from the webapp's WEB-INF/lib/log4j.xml or WEB-INF/classes/log4j.properties you need to delete the code in gvpbackend.jar that changes the log4j configuration and then recompile the jar file. After that it all works fine...