Logs

ViewsFlash keeps a log of activities and errors. This log will be either in the database or on the filesystem (in the viewsflash data directory) depending on the type of installation and the setting of the dbstores servlet parameter.

Enable verbose logging by setting the ViewsFlash servlet parameter: logrequests=2 in the /etc/cogix/viewsflash.properties file and restart the application or server.

If possible, repeat the problem with verbose logging enabled, then examine the ViewsFlash log for evidence of the error and its cause.

Also, examine the Application Server's log files at the time that error occurred for evidence of the error and its cause. Some application servers have separate logs for events and errors, be sure to examine both. These files are sometimes called System.out.

Diagnose

Start with the Diagnose command to verify installation integrity. If any errors appear, they should be corrected immediately. Next, the examine the ViewsFlash and application server logs for evidence of trouble. If the logs reveal the source of the problem, then take corrective steps. If the logs don't reveal the source of the problem, you may contact Cogix for help.

Use the Diagnose command to verify that the application is correctly installed. If using application server security then the format of the Diagnose command is:

http://yourserver.com/ViewsFlash/servlet/vfadmin?Diagnose=1

If not using application server security then the format is:

http://yourserver.com/ViewsFlash/servlet/viewsflash?Diagnose=1

The report will confirm details of the installation like servlet parameters, whether the required filesystem directories and resources are present and have the right permissions, and whether the database tables are available.

Common Errors

  • Permissions: the user that runs the application server process mush have full permissions in the <webapps>/ViewsFlash directory, the <webapps>/ViewsFlash/viewsflash/styles2 directory, and in the data directory specified in /etc/cogix/viewsflash.properties
  • Attempting to load 2nd instance: this indicates a failure at startup. Examine the ViewsFlash and application server logs for detailed evidence of why the application failed. Some common causes of this error include missing JDBC driver classes and a missing /etc/cogix/viewsflash.properties file. The application server log usually contains more specific information about the cause of this problem.

Tomcat logs Depending on the tomcat version, whether it's on windows or linux, and how the logging is configured you may find evidence of the ViewsFlash startup failure in some of the following logs:
<tomcat-home>/logs/catalina.out - this contains the console output, when running on a Linux server.
<tomcat-home>/logs/catalina.<date>.log - this file contains console messages on the given date.
<tomcat-home>/logs/localhost.<date>.log - this file contains host specific messages for the given date.

The may be other hosts that write logs in format of <hostname>.<date>.log - If ViewsFlash is installed in a host other than localhost, then look in the log for that specific host. It's also possible that the error message was written to the console but not logged in any of the above files, so watch the actual console output for the ViewsFlash startup failure, if possible.

Contact Cogix

In the case when the error, logs, and diagnostic report don't enable you to solve the problem on your own, you may contact Cogix for help. Be sure to include the following information when contacting Cogix:

  • the viewsflash log
  • the application server log, if it contains relevant information.
  • the viewsflash.properties file ( located by default in /etc/cogix/viewsflash.properties )
  • the ViewsFlash web.xml file from <webapps>/ViewsFlash/WEB-INF/web.xml where <webapps> is the directory in which your application server has installed ViewsFlash.
  • output from the ?Diagnose=1 command.
  • a complete, step-by-step description of how to reproduce the problem. If the problem generates messages or symptoms visible in the browser, then describe them completely or send screenshots.
  • completely describe the symptoms of the problem.

Clean Up

After the problem has been resolved, be sure to return the logrequests servlet parameter to its original value (or remove it) and restart the application or server. Running in production mode with logrequests set to 1 or 2 can quickly generate very large log files and is not recommended.