One of them is Document ID : TEC435611[left][left] Tech Document[left] Title: Debugging in Clarity[left]
Generally speaking, if you are getting an error and it's in a category code that isn't giving you enough detail, then log that category at a deeper level (ERROR -> INFO -> DEBUG).Timeslicing, for example, will fail in category code 'niku.blobcrack', so you can put INFO level logging on ' com.niku.blobcrack ' (add it in the 'Other Name' column then save, even though it's not in the default list), and try again to reproduce the problem after saving this config and restarting the services.Putting the same thing on 'com.niku' would give you too much data probably, as it will capture everything 'com.niku', 'com.niku.blobcrack' and so effectively 'com.niku.*'. This can be as detrimental as it can be beneficial, as you'll flood yourself with irrelevant data. Sometimes this is true even if you filter down to a single category on DEBUG, so try INFO first to see if it gives what you need.You may also need to adjust (by hand) the $NIKU_HOME/config/logger.xml file as 3x 5MB isn't enough to prevent the information you want from being flooded out too quickly. Re-deploy and restart the services following a direct change to the logger.xml (see
http://wiki.apache.org/logging-log4j/Log4jXmlFormat for some info on the format and capability). com.niku.security - can give information related to login/logout problems, including ldap connectivity problems. com.niku.union.* - part of the app's inner engine, touches on a lot of the framework that holds the different technologies together: rarely needed when logging IMO though as failings tend to occur at the higher level (you'll almost always see references to com.niku.union in stack traces of error messages, but nearer the top of the function call stack, it usually moves into a more specific product area that you can focus on, in my experience). org.logicalcobwebs.proxool - is the 'connection pool' library we use for Orion/Tomcat app servers to both Oracle and SQL Server (proxool = "proxy pool", or how to implement a connection pool by proxy, so your code is written without needing to know that a pool exists). org.jgroups - used for multicasting. Consider using it if any reference to jgroups or multicast was mentioned to try and glean more data, though it would be guess work. com.niku.bpm - for process engine related stuff. In some older versions of the product (Clarity 7.5.3 certainly, if not also some newer releases), you need to also enable the JVM 'asserts' parameter on your bg and app as follows (including the '...' elipsis at the end) specifically and only for this category: -ea:com.niku...If you don't enable this, check your logs after enabling it, and it will probably tell you if it needs this parameter or not anyway. com.niku.njs - deserves a mention, this is for the 'background' jobs scheduler, if you experience problems in that area. com.niku.schedulers - this is for the server-side interactions with the OWB/MSP project scheduler apps and their area of functionalities.It is almost always suggested to add to the default config rather than change the existing lines/entries. You may want DEBUG detail on a specific category, but probably not at the cost of losing WARN detail level on 'com.niku' itself. You go to NSA and Logs to Edit Configuration.Make a note what you already have.Click addSelect com.niku.bpmSet the level at what you need. Martti K.[left][left][left][left] [left]