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