Debugging Summary
Web Experience Factory offers multiple avenues when it comes to debugging a
bunk application. Developers often need to be able to determine what is
happening in the application and its state, just before and when a problem
occurs. WebSphere Portlet Factory provides multiple mechanisms and techniques
to help you resolve such issues, as described below. Each link provided will
offer information on how and why each technique is useful. These are not the
only techniques available, but a grouping of the most typical methods used by
Web Experience Factory Developers.
You can navigate to other forms of testing by using the links provided at
the bottom of this page.
Designer Problems View
Web Browser Debugging
log4j Logging properties/custom logging
Debug Tracing Builders
Println Variables system.out
Model Tracing
Eclipse/RAD Debugging
Designer Problems and Task View
The Problems View found within Web Experience Factory is the most basic
method used to debug an application. As you work with resources in the
workbench, various builders may automatically log problems, errors, or
warnings. When you double-click the icon for a problem, error, or warning. The
editor for the associated resource automatically opens to the relevant line of
code. This is part of the Default Web Experience Factory Perspective. If you do
not see this option in your perspective, click Window > Show View > Other... >
General > Problems.
The first column of the Problems view displays an icon that denotes the type
of line item, the category and description. These are typically produced by the
builders used within the model. Press F1 with the builder in question open to
see specific information on that builder. This can be useful in determining
what each builder, and builder input does. The builder help can also be used
to determine whether your builder has any built in capabilities that could help
in the debugging process. See for more details.Choosing Builders that use Actions and Events
You can filter the tasks or problems that are displayed in the Problems
view. You can filter problems that have been logged by the Workbench, tasks
that you have logged as reminders, and items according to resources they are
associated with. Either by text string within the description, severity, task
priority and or status. Filters can also be used to remove known or expected
API problems. For more information on API filtering, please refer to
unavailable
1. On the tool bar of the Tasks or Problems view, click Filter.
2. Select the radio buttons and checkboxes that correspond to your
filtering objectives and click ok.
You may also use the Quick Fix feature available. This feature detects the
error and offers simple quick fixes, if available.
1. Right click on the task in the problems view.
2. Select Quick Fix and choose from the options.
Quick Fix Example: A missing import statement in a Java file
will result in a Quick Fix suggestion to add the import statement or change the
type name to a name that is already imported.
For additional information or Supporting topics, please use the following link
below.
- Link 3
unavailable
Web Browser Debugging
Google Chrome, Firefox, and Safari are just a few of the browsers supported
with developer tools that can be used to help debug a Web Experience Factory
Application. Using a browser specific developer tool can aid in helping better
understand, why the UI looks the way it does. What CSS file is getting used for
a particular style element. What HTML element is effecting what features, and
when working with themes inside your project. You can also edit the pages
within the browser debugging console to achieve the desired look.
Developer Tools allow for easy inspection and step through of a
page's JavaScript code as well. You can track variables, set break points and
enable event listeners. Using built in web browser utilities can prove to be
very useful, especially when dealing with the over style and look of your
application.
For more information on browser specific Debugging Techniques, please visit:
Google Chrome - Chrome Development Tools
Firefo x- Firebug
Safar i- Safari Developer Tools
Internet Explorer –IE Developer
Tools
Opera - Opera Development Tools
Log4j.properties
Web Experience Factory uses the Apache Log4j logging services to log warnings,
errors, exceptions, statistics and debugging information to a deployed WAR's
WEB-INF/logs folder. The logs and the information they provide can prove
exceedingly useful when debugging and diagnosing a variety of issues in Web
Experience Factory Application. The log4j.properties folder can be located in
the WEB-INF/config/log4j.properties file in your deployed WAR and Project
within designer. I encourage you to read through this file carefully. It
explains the categories of system level logging, and has changeable properties
for each of the default logs and available appenders.
The Default WPF / LWF Logs can easily be enabled and are located by default in
WEB-INF/logs of your deployed application WAR. The most commonly used logs are
as follows.
event.log - Contains error messages, exceptions and stack
traces encountered during application requests
serverStats - Contains runtime statistics information, logged
every 5 mins by default, showing how long actions, DB and web service requests
are taking
debugTracing - Contains optional debug tracing information,
if enabled
general.tx Catches all log that the log4j root category uses
to combine messages from the other logging appenders
modelTracing - If enabled, lists actions that were executed,
plus how long in milliseconds each action took to complete
For most situations, the log4j.properties file in the deployed WAR should
suffice. If for some reason you must point to a log4j.properties file external
to your deployed WAR, you should be able to set the following property in your
project's WEB-INF/config/override.properties to point to a log4j.properties in
an alternate location.
Example:
bowstreet.logging.log4j.configFile=/my/alternate/log4j/configuration/path/log4j.
properties
There are many appenders included in the log4j.properties file such as
Server appenders, Server stat appenders, profile selection appenders, and
builder call appenders just to name a few. For location, level of debuging and
further information regarding PatternLayout and Regen of these files, please
read the log4j.properties file. You may want to change the logging level on one
ore more appenders in log4j.properties. You can read more about logging levels
here Logging Levels
I have an example below that takes the incoming SOAP Requests which have a
logging level of WARN, and changing it to DEBUG. This web service will now log
all incoming requests.
Get debug information from incoming web service requests by changing:
log4j.logger.bowstreet.system.webservice.incomingSOAPRequest=WARN,IncomingSOAPRe
quests
to
log4j.logger.bowstreet.system.webservice.incomingSOAPRequest=DEBUG,IncomingSOAPR
equests
You may also add your own custom appenders to this file in conjunction with
corresponding information in in the override.properties file . For more
information on custom log4j appenders and override.properties file, please
refer to the supporting information of this section. There you will find links
to resources that will aid in learning about custom appenders, customer logging
techniques, and log4j standards.
Supporting Information:
- For additional logging information see link 4
- Custom Appenders and Custom Logging please visit link 5 -
- Default logging level --- link 6
Debug Tracing builder
This builder writes trace information to a log file. You can review the logged
trace output after you run a model. By default, this log file is stored at the
following location: web_app_dir\proj_name\WEB-INF\logs\debugTracing.txt
Using a debug Tracing builder is useful for looking at the value of a variable
during model execution. You can select action to trace or trace all actions to
trace one or all methods in your project. You can select the variable or data
service parameter in the additional Debug Output to track a variable and its
value.
For example: If you enter a method to be traced in the Action to trace
input and also want a variable to be traced, enter an indirect reference to the
variable in “Additonal Debug Output" Field. This can be specified as a Java
expression as well. like so ---(${Java/Expression_to_trace}. This is an easy
way to see if the value is getting set correctly, while tracking the methods
being called throughout a model execution. You can place multiple Debug Tracing
builders in a single model to trace multiple methods/variables. You have to
enable the Debug tracing builder in the log4j.properties file first.
Enable Tracing debug tracing builder
Before you use the Debug Tracing builder, set the bowstreet.system.debugTracing
property to DEBUG. When this property is set to DEBUG, it provides more
details, such as the session ID and profile information. Refer to
Log4j.PROPERTIES section of this article or the log4j.properties file itself
for more information on the location and level of debugging available. Each
property will supply you with information that can be helpful in debugging your
application.
1. Open the WEB-INF/config/log4j.properties file in your favorite text editor.
2. Change the following property.
log4j.logger.bowstreet.system.debugTracing=INFO,DebugTracing
to the following value.
log4j.logger.bowstreet.system.debugTracing=DEBUG,Console,DebugTracing
1. Change priority value from WARN (the default value) to DEBUG for one or more
of the following properties found in the log4j.properties file.
log4j.logger.bowstreet.system.request=WARN,Console,Request
log4j.logger.bowstreet.system.profileSelection=WARN,Console,ProfileSelection
log4j.logger.bowstreet.system.regen=WARN,Console,Regen
log4j.logger.bowstreet.system.builderCalls=WARN,Console,BuilderCalls
log4j.logger.bowstreet.system.modelActions=WARN,Console,ModelActions
log4j.logger.bowstreet.system.webservice.serviceCall=WARN,Console,ServiceCalls
log4j.logger.bowstreet.system.webservice.incomingSOAPRequest=WARN,Console,Incomi
ngSOAPRequests
If you want to set further properties, please refer to log4j properties section
for more information.
On Windows systems, you can use a tool like WinTail to tail the debugTrace.txt
file as it rolls. When it comes to interpreting a debug tracing log file,
please refer to (9) for additional information.
NOTE: When your done debugging, don’t forget to set the DEBUG level back to
INFO and disable the debugTracing builder.
Supporting Information
- Interpreting a Debug tracing log file ---
http://www-10.lotus.com/ldd/pfwiki.nsf/dx/Interpreting_a_debug_log_file_wpf7
- Custom Appenders and logging
-http://www-10.lotus.com/ldd/pfwiki.nsf/dx/06122009032055PMWEBQPM.htm