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
Filtering
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.
QuickFix
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 changes it to DEBUG. This web service will now log
all incoming requests.
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 in 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:
-
Additional logging
Information
-
Custom Appenders and Custom Logging
-
Default Logging Levels
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 models 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. < br>
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
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
-
Custom Appenders and logging
System.out.println
A common way to debug in Java is to use the System.out.println method. This is
a useful method when showing any variable during the execution of a model. This
is also a good method when Java builders such as the Link Java Objects Builder.
You can use the feature by adding an Action List builder to your project. Add
a new entry to your action list by clicking to the right of the text box at the
position you wish to add a debugging statement. In the Select an Action box,
expand the "Special" folder and select SystemOut. In the Set Argument box use
the picker to drill down to the value you want to output, select it and click
OK. .
Output
{code:}The value you display using SystemOut is displayed in the console
and will look something like the following:
*--TIME: [2004-12-25] 16:07:05, 831] __*
Category: bowstreet.system.debugTracing
Priority: INFO
Msg: SystemOut= ${Variables/varHellowWorld} =null {code}
The varHellowWorld is currently set to null for it has no value. To learn more
about the "Special Actions" found within the action list. Please refer to the
supporting information of this section.
Supporing information
-
About Special Actions
Model Tracing
This is a way for a developer to trace what actions are being called during
execution. Are your methods being called twice? Is a model container or method
main being called out of order? You may also use this method for performance
testing as well. There is more information regarding performance testing at the
bottom of this page.
How to configure Model Actions logging:
1. Open the WEB-INF/config/log4j.properties file.
2. Find the line:
log4j.logger.bowstreet.system.modelActions=WARN,ModelActions
3. Set the modelActions property to DEBUG.
4. The line should now be:
log4j.logger.bowstreet.system.modelActions=DEBUG,ModelActions
5. Restart the server.
When you run any model from Web Experience Factory Designer or any portlet in
the Portal, Model Actions will be logged to the modelActions.txt file. The file
can be found in the deployed application's WEB-INF\logs directory. If you need
help interpreting the out put of this file, you can check the supporting links
of this section. There you will be able to find more information regarding
Model Tracing and it's potential.
Supporting Information
Model tracing and results output
ECLIPSE/RAD
This can be used for debugging your hand coded LJO's and other various Java
code. The Factory model execution debugger support enables model developers to
easily leverage the Eclipse and Rational Application Developer integrated
debugger. Debugger support includes the following features.
- Simplified server start and application launch in debug mode.
- Enable breakpoints in generated code.
- Easier inspection of web application runtime objects such as
variables.
Here are some general debugging features offered to debug your model Java™ and
JSP code with the Eclipse and Rational Application Developer integrated
debugger.
- Set breakpoints - You can set breakpoints on the following web
application tree objects.
- Method - Select a method in the web application, and break on the
first line during method execution.
- Page -Select a page in the web application, and break on the first
line during the page execution.
- Event Handlers- Select an Event Handler action in the web
application, and break on the first line during the event handler method
execution.
- Data Services - Select a data services operation as the breakpoint
target. This has the same affect of setting the breakpoint on the method, but
allows you to locate the method more easily.
Note: Once a breakpoint is set, you can also use the Eclipse and Rational
Application Developer Debugger Breakpoints view to manage the breakpoints
(Window -> Show View -> Debug -> Breakpoints).
If you are using WebSphere Application Server Community Edition (CE), when
you start the server through IBM® Web Experience Factory, there is an option to
start your server in debug mode. The Web Experience Factory Designer prompts
you to start the WebSphere Application Server CE server when you either deploy
your project or run a model. In the Start WAS CE server dialog, set Start WAS
CE in debug mode and click Yes. If you are manually starting the WebSphere
Application Server CE server, add Java options to start the server in debug
mode.
1. Stop the server.
2. Restart using the following start options, either from the command
line or as a script.
Set JAVA_OPTS=-Xdebug -Xnoagent -Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000
If you have already deployed an application, the file startdebug.bat or
startdebug.sh is automatically generated. You can use this file to manually
start your server in debug mode.
Start a remote debug connection.
Once your server is started in debug mode, start a remote debug connection to
the server to begin debugging. To assist with the connection, Web Experience
Factory creates a Remote Java Application configuration for each project. The
debug configuration enables the debugger to locate source code that is related
to the target project.
In Web Experience Factory Designer.
1. click Run -> Debug Configurations to open the Debug
Configurations dialog.
2. From the dialog, expand Remote Java Application, select your
project, and then click Debug.
3. Run the model.
With your server running and a remote debug connection active, run the target
model to be debugged. In the Confirmed Perspective, to switch dialog, click yes
when prompted. The Debug perspective opens.
If you are running on Websphere Portal, you you can use the supporting links of
this sections to set up a remote connection to your Portal Server as well as
server side debugging techniques not covered here.
Supporing information
Remote Debug Connection for WebSphere portal
Rational Application Developer
Eclipse
Conclusion
These are the most common methods of debugging your Web Experience Factory
Application. If you are interested in performance testing, JMX Debugging, or
any other type of testing methods available. Please refer to the links below
for a list of available resources.
Performance “Best Practice” asdf
Performance Testing asdfasdfasdf
General Debugging
Trouble Shooting and servicability -
http://www-10.lotus.com/ldd/pfwiki.nsf/dx/04012009105336PMWEB5EK.htm
JMX Debugging
- Diagnosing JMX publishing problems -
http://www-10.lotus.com/ldd/pfwiki.nsf/dx/Diagnosing_JMX_publishing_problems_wit
h_WebSphere_Portlet_Factory