84 Community-Gadgets: Guidelines for Maintaining the Application

This chapter contains the following sections:

84.1 Widget Deployment Guidelines

The deployment process can be started for the Community-Gadgets widgets as soon as the widget functionality, permissions, and appearance are configured in the Community-Gadgets web application. During widget deployment, when the site settings option is selected, configurations made in Community-Gadgets are instantly reflected on the deployed widgets, after the page containing the widget is reloaded. This option enables the deployed widget to constantly monitor configuration changes in the database. However, in the custom settings option, some of the configuration settings use custom values that are embedded into the widget deployment code snippet itself. Note that custom configuration settings are stored in the HTML/JavaScript code of the page on which the widget is deployed, and not in the database. As a result, custom configuration settings take priority over site settings.

When you deploy a widget with the custom settings option selected, the Resource ID field becomes available for customization. The resource ID enables Community-Gadgets to associate the content posted by visitors with the page on which it is deployed. Because of the lightweight integration approach, which uses JavaScript to deploy widget functionality to the web site, this ID is used to determine the type of content to be shown on a page. For example, if no resource ID is specified during deployment, md5 (a cryptographic hash function that produces a 128-bit (16-byte) hash value) is used as the resource ID automatically. In this case, when visitors visit a page repeatedly, the same content is shown to them by Community-Gadgets. Therefore, it is recommended that the resource ID be equal to the page ID (if it is managed by a content management system), so the association is straightforward and intuitive.When the same comment feed needs to be shown on two separate pages, it is sufficient to specify the same resource ID. For example, xyz can be used as the resource ID on both pages, so that the same content is rendered on these pages.

84.2 Adjusting Logging Levels

This section contains the following topics:

84.2.1 Configuring log4j Loggers

Configuration and monitoring of log files is an important aspect of product maintenance. This section describes log4j loggers that are available for troubleshooting/monitoring.

  • The log4j-cos.properties file is the main configuration file for the logging in Community-Gadgets web application. The log4j-shindig.properties file is the main configuration file for the logging in Shindig web application. These files are located in the standalone_node folders (default locations are: <cg_install_dir>/deploy/management/management_node1 and <cg_install_dir>/deploy/production/production_node1

  • To enable all logging specific to Community-Gadgets, set the following loggers to debug level:

  • To monitor all the requests that Community-Gadgets sends to the WebCenter Sites data repository, enable the following logger: log4j.logger.com.fatwire.cos.core.jpa.cmd.wem.WemCommandManager = TRACE

  • To monitor all the requests that Community-Gadgets sends to network and which network proxy is used, enable the following logger: log4j.logger.com.fatwire.cos.registry.client.local=TRACE

  • To monitor lifecycle management of CAS tickets that are used to connect to WebCenter Sites over REST, enable the following loggers: log4j.logger.com.fatwire.cos.core.jpa.session.wem.WemSessionManager = TRACE

    log4j.logger.com.fatwire.cos.core.sites.wem.WemManager = TRACE

  • To monitor inCache operations performed by Community-Gadgets, enable the following logger: log4j.logger.com.fatwire.cos.core.cache.appcache.wem.WemAppCacheFacility = TRACE

  • To monitor inCache invalidations coming from WebCenter Sites, enable the following logger: log4j.logger.com.fatwire.cos.core.cache.appcache.wem.IncacheServlet = TRACE

  • When troubleshooting data consistency issues and the synchronization functionality (locking) in the system, enable the following loggers: log4j.logger.com.fatwire.cos.cluster.CacheLockClientFacility = TRACE

    log4j.logger.com.fatwire.cos.cluster.ClusterLockImpl = TRACE

84.2.2 Enabling Logging for SEO Widget JAR Files

When deploying widgets that support search engine optimization (SEO), you need to download the cos-widget-tag.jar file containing the widget deployment and rendering logic, and place it into the classpath of your web applications. Navigate to Comments, then Deploy, then Comments, and then select Custom settings and scroll down to the Widget Tag field. To download the JAR file, click the link in the Note section.

This is a lightweight JAR file, and it is created to function independently of any external logging libraries. However, to enable log messages provided by this library (cos-widget-tag.jar), it is necessary to add the -Dcos.widget.tag.debug=true Java parameter to JVM that runs the web application. This ensures that the log messages display in the standard output stream (console).

To optimize this library for performance, it is recommended that you add the following JVM parameters:

-Dhttp.keepAlive=true, -Dhttp.maxConnections=<Number>

The <Number> value must be aligned with the concurrency rates on the application server on which the pages with the SEO deployment tag were deployed, as well as with the number of processing threads available on the application server.

84.3 Reporting Issues

Before contacting the support team, compile the information required for investigation. This will help you avoid unnecessary communication round-trips and speed up the troubleshooting process.

The following is the recommended list of items to be provided to support for quick and efficient troubleshooting:

Environment Details

  • Operating system name and version

  • System language, locale, and time zone

  • JVM name and version

  • Application server name and version

Configuration Details

Archive the contents of the product configuration directory and attach the archive to the support ticket. For example, Production_node1 or Management_Node1, configurations are saved in the <install folder>/deploy/production and <install folder>/deploy/management directories. Other required files are: the setup_*.properties files from the <cg_install_dir>/deploy/management/management_node1 and <cg_install_dir>/deploy/production/production_node1 directories.

Logging Details

  • Log files of Community-Gadgets, its CAS and Shindig

  • Log files of the WebCenter Sites application and its CAS

  • Log files of Community-Gadgets and WebCenter Sites application servers (including the standard output and standard error consoles)