IP IVR 8.5 Logging

Version 1
    This document was generated from CDN thread

    Created by: James Heffernan on 17-09-2013 10:44:42 PM
    Hi, firstly let me say what a hellish system to try to get working.  I've spent days trying to get my axis2 based w/s client library to the point where it is ready to make calls (after having got over firstly the classpath -> required libs dilemma and then the various security policy issues) but now there is still an underlying fault which I have NO visibility of due to the fact I cannot get the engine to take any notice of my logj.properties, no matter where I put it.
    I have my own appender setup, and the usual properties there which work when I use from a standalong test client.  I have tried both putting the properties file under the /opt/cisco/uccx/Documents/User/default/classpath folder AND embedded within my main custom classes jar file, under the root.
    No joy and no logging out to my customised appender.  I even tried naming the appender "CUSTOM" as I saw errors int he stdout.log file for unknown appender.
    Any assistance would be gratefully accepted, my hair is disappearing at a remarkable rate

    Thanks

    James

    Subject: RE: IP IVR 8.5 Logging
    Replied by: James Heffernan on 17-09-2013 11:24:56 PM
    Hi me again,
    I forgot to mention I set the $LOGPATH var to /opt/cisco/uccx/Customer, which is configured as the "Customer" writable area for the engine, and then use that variable when setting up the appender.
    Again, placing the properties under the classpath itself or contained within my jar makes no difference...

    Thanks again

    log4j.rootLogger=DEBUG,stdout

    log4j.appender.stdout=org.apache.log4j.ConsoleAppender
    log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
    log4j.appender.stdout.layout.ConversionPattern=%d %p [%c] - <%m>%n

    contextRoot=xxclient
    logpath=/opt/cisco/uccx/Customer

    log4j.appender.CUSTOM=org.apache.log4j.RollingFileAppender
    log4j.appender.CUSTOM.MaxFileSize=1000KB
    log4j.appender.CUSTOM.MaxBackupIndex=2
    #log4j.appender.CUSTOM.DatePattern= '.'yyyy-MM-dd
    log4j.appender.CUSTOM.layout=org.apache.log4j.PatternLayout
    log4j.appender.CUSTOM.layout.ConversionPattern=%d %-5p - [%X{RemoteHost}] - [%X{SessionID}] - [%X{CustomerID}] - %c{2} - %m%n
    log4j.appender.CUSTOM.File=${logpath}/xxivrclient.log

    #and some package logging...
    log4j.logger.nz.co.blahblah.yada=DEBUG, CUSTOM
    log4j.additivity.nz.co.blahblah.yada=false

    Subject: RE: IP IVR 8.5 Logging
    Replied by: James Heffernan on 02-10-2013 09:55:16 PM
    Hi me again, (good fun this)
    thought I'd provide an update on my woes.  Got beyond the logging, thanks to slf4j and logback, and implementing my own customised logging source (so I didn't have to rely on the engine loading up my properties) and now I'm getting output which is great.
    I still see weird behaviour with the engine in this version, the word "flaky" springs to mind.  It seems to randomly not load up my custom jars when I restart the engine, I thought I might have got around it with the "restart db, restart engine" sequence but not really.  And it is not even consistent in the jars it doesn't load. 
    Eventually, after "a magic" number of restarts it will decide to play nicely and the scripts will run. 
    I really really hope v9.x is a better system (by far) than v8.5.
    If anyone has experience on both I'd be keen to hear confirmation on that

    Thanks

    James

    Subject: RE: IP IVR 8.5 Logging
    Replied by: Binny Mathew on 03-10-2013 02:31:26 AM
    Hi James,

    Before coming to the point i went through the start of this chain where you specified usage of Axis 2, I too had a customer where in i had to work with Axis but during the due course i found that there are several jars which are internally getting used by UCCX engine and if we are using a new version of Axis which has a higher version of the common jar there will be a conflict for which the work around is to over write these jars. [This is not proposed by Cisco].  

    I will propose Wsimport rather than Axis 2 which not only reduces the no of jars to be uploaded and also the jars which are conflicting and can create a runtime exception. [Have tested it in both 8.5 and 9.0]

    Coming to the current issue yes have faced it a lot of times when i make any changes in my custom jar i have to have restart my engine at least 2-3 times in the order of Engine and then Administration. As sometimes the call does not land and you restart it again it works fine and sometimes the application mapping becomes an issue. [The issues persists for both 8.5 and 9.0]

    P.S. Also if it’s ok with you can you share the logging mechanism that you created/customised, will be helpful for me as i also have been struggling for it for some time.

    Rgds/Binny

    Subject: RE: IP IVR 8.5 Logging
    Replied by: James Heffernan on 03-10-2013 03:35:26 PM
    Hi Binny,
    thanks for the 'reassurance' it wasn't just us.

    Firstly on the wsimport option, yes I did look at that but unfortunately the type of w/s implementation I was developing against precluded using wsimport.
    In fact the previous version of the client was old enough that I had used Axis (1.0), so when I updated that I made absolutely certain all the associated libs were the same version as were under the /opt/cisco/uccx/lib path on the platform, to try to prevent any incompatibility issues.  I did this with every third-party library I've included, that goes for the axis2, axiom, geronimo,slf4j, and so on.
    That is not good news on the v9, I was kind of hanging my hat on that being a more stable version in terms of the startup/classloader.  We're only taking this one to v8.5 in the interim until our (hosted) UCCE platform is updated.
    On the logging front I really wanted to try to use the external properties mechanism and let the logging framework take care of things.  But try as I might (as you have found) it is very hard to get the engine to take any notice of them.  So I just put the LogSource within my main package, and that acts as the provider for an slf4j Logger.  Within that static method I use the Logback lib to setup my context and appender.  So in terms of the default level, output format, filename format and so on it is hard coded.  But at least I can get logging for my custom classes.
    I also had to edit the UCCX_EngineCfg.xml file Binny to include my two logback jars (core & classic) and if you go this way make sure you use v0.9.9 of those by the way, as that works with the slf4j-api.jar in the engine (SLF4J is fussy over compatiblities).  I also needed to comment out the slf4j-log4j.jar file in that config file.

    There is NO WAY I would have got this system up at all unless I had root access.   Hat tip to Michael at UC Corner there.

    Check out the logback documentation Binny, you'll find that pretty straightforward.  You may even find a way of injecting your required config, I have taken the easy route.

    Thanks again for your response, good luck

    James