WebCenter Sites provides several options for logging error messages and debugging source code. This chapter gives you information about general error logging and debugging techniques that apply throughout the WebCenter Sites development environment.
WebCenter Sites can log its activity in a log file, which in a new installation, is named sites.log, located in the logs folder. The type and volume of information that is written to the log file is controlled by the loggers that you choose to enable or define. See Section 10.1, "Logging to the WebCenter Sites Log File" for information about loggers.
WebCenter Sites also has a reserved variable that is used by JSP and XML tags for returning an error code if the tag did not successfully complete its task. See Section 10.2, "Using Error Codes with Tags" for more information.
This chapter contains the following sections:
Logging is based on either the commons-logging framework (using the commons-logging.properties file) or the Apache log4j framework.
In new WebCenter Sites installations, log4j is the WebCenter Sites logging system. When log4j is set up, the log4j.properties file is created to specify how information must be logged and which information will be logged. In addition, the WebCenter Sites Admin interface provides the Configure log4j tool in the System Tools node, on the Admin tab. Using Configure log4j, you can view current loggers directly from the Admin interface. You can also dynamically add new loggers and change logger levels. Changes will persist upon system restart if you copy the text version of the loggers from the interface to the log4j.properties file. For more information about the Configure log4j tool, see the Oracle Fusion Middleware WebCenter Sites Administrator's Guide.
For information about the log4j.properties and commons-logging.properties files, see the Oracle Fusion Middleware WebCenter Sites Property Files Reference
To define your own loggers or write your own messages to WebCenter Sites's log file, use the ics:logmsg tag. The following example writes a warning message to WebCenter Sites's log file.
<ics:logmsg msg="This is a warning message" name="com.fatwire.logging.cs.jsp" severity="warn"/>
For more information about ics:logmsg, see the Oracle Fusion Middleware WebCenter Sites Tag Reference.
Note:
It is recommended that you set loggers to a level that agrees with the type of system on which logging is implemented. On development and content management systems, logging levels can be set to a greater severity (such as INFO or DEBUG), which provides a large amount of information. On delivery systems, loggers can be either disabled or set to low severity (WARN or ERROR) to avoid performance setbacks and making system information available on a publicly accessed environment.
WebCenter Sites has a reserved variable named Variables.errno which most JSP and XML tags use for returning an error code (generally referred to as an errno) if the tag did not successfully complete its task.
For example, the <CALLELEMENT> XML tag sets Variables.errno as follows:
-10 if you specified a nonexistent element.
-12 if you specified an existing element that WebCenter Sites could not evaluate.
On success, <CALLELEMENT> does not modify the value of Variables.errno.
Note:
For revision tracking operations, the reserved variable named Variable.errdetails provides additional information about the error.
You typically use the following strategy with tags that use Variables.errno:
Initialize Variables.errno to 0 before calling the tag.
Call the tag.
Evaluate Variables.errno.
Tag Examples Using Error Codes
For example, the following code performs all three steps:
<SETVAR NAME="errno" VALUE="0"/>
<SETCOUNTER NAME="pi" VALUE="3.14159"/>
<IF COND="Variables.errno=-501">
<THEN>
<p>Bad value of pi</p>
</THEN>
</IF>
Running this code yields the following HTML because SETCOUNTER cannot handle floating-point values:
<p>Bad value of pi</p>
The ASSET, RENDER, and SITEPLAN tags clear errno before they execute. You do not need to set errno to 0 when you use these tags. For example, after you use an ASSET tag, just check the value of errno to determine whether it has changed:
<ASSET.LOAD NAME="topArticle" TYPE="Article"
OBJECTID="Variables.cid"/>
<IF COND="IsError.Variables.errno=false">
<THEN>
<ASSET.CHILDREN NAME="topArticle" LIST="listOfChildren"/>
</THEN>
</IF>
At the end of template elements, you can include error checking code such as this:
<IF rendermode="preview">
<THEN>
<IF COND="IsError.Variable.errno=true">
<THEN>
<FONT COLOR="#FF0000">
Error <CSVAR NAME="Variables.errno"/>
while rendering <CSVAR NAME="pagename"/>
with asset ID <CSVAR NAME ="Variables.cid"/>.
</FONT>
</THEN>
</IF>
</THEN>
</IF>
After making calls to WebCenter Sites, the String variable errno can be retrieved and tested for success or failure. Here's an example:
cs.clearErrno();
IList rslt = cs.SelectTo(SYSTEMUSERS_TABLE, ALL_FIELDS, USERNAME,
null, NO_LIMIT, null, CACHE_RESULTS, errstr);
errno = cs.GetVar("errno");
if (errno.compareTo(ERRNO_SUCCESS) == 0)
{
...
Error numbers are always integers. The following table briefly summarizes error numbering rules for Variables.errno.
See the Oracle Fusion Middleware WebCenter Sites Tag Reference for specific error numbers for each tag.