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. The errors in the Problems view include any builder, syntax or Java
code error. When you double-click the icon for your warning or error. 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.
Problems view displays an icon that denotes the type of line item, with
category, description, location and resource associated with it. These warnings
and errors are typically produced by custom coding, builders, and builder
inputs. Press F1 with the builder in question open to see specific information
on that builder. This can be useful in determining what each builder does along
with it's associated inputs. 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 EventsThere are
two useful configuration listed below that can aid in helping deal with errors
in Web Experience Factory.
Filtering
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,
priority or status. Filters can also be used to remove known or expected API
problems. For more information on API filtering, please refer to your product
documentation and search for "API filtering."
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. You can also set QuickFix to
resolve API issues as well. Please refer to your product documentation's help
section for further information
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.
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
Firefox- Firebug
Safar i- Safari Developer Tools
Internet Explorer –IE Developer
Tools
Opera - Opera Developer 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. In
addition, you can specify your own log4j calls using builders to create log4j
methods, and calling those methods to an output log file or system console. For
more information on custom logging please visit
Custom Logging Resources
The log4j.properties file should be located in your
project..WEB-INF\Config\log4j.properties directory. Open this file and set the
log4j.category.bowstree.system.debugTracing property. When you republish the
project, the new setting is saved on the server. Any setting for this property
more lenient than INFO als allows debug tracing messages to be logged. Any
setting stricter than INFO prevents messages from being logged. Read more about
default logging levelsHERE
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, Server stat, profile selection, and builder call appenders. For
location, level of debuging and further information regarding PatternLayout and
Regen of these files, please read the log4j.properties file or visit
Using Logging in debugging.
I have an example below that takes the incoming SOAP Requests which has a
logging level of WARN, and changes it to DEBUG. This web service will now log
all incoming requests. You can find more information on custom logging,
creating your own appenders and logging service calls or SQL builders in the
supporting information.
log4j.logger.bowstreet.system.webservice.incomingSOAPRequest=WARN,IncomingSOAPRe
quests
to
log4j.logger.bowstreet.system.webservice.incomingSOAPRequest=DEBUG,IncomingSOAPR
equests
You may add your own (Custom Logging with log4j)
appenders to your project utilizing
the
override.properties file
Supporting Information:
-
Setting up loggoing in Service Calls and SQL
builders.
-
Logging
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 working with Java builders such as the Link Java
Objects. 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. .
There are
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.
NOTE: You can view the console messages generated by your IDE including
System.out Statements by modifying the command property for the menu item or
short cut used to launch Web Experience Factory. To modify Web Experience
Factory Designer run command, so that it displays the console:
1.Right-click on Designer (shortcut) and Select Properties
2.In Web Experience Factory Designer (shortcut) properties dialog, add
the "-debug -console". Than click ok.
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
Websphere 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 a Debug log File, you can check supporting materials.
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.
Other forms of debugging, performance tuning, and best
practices.
Starting System TracingUse the system tracing feature to store the WebApp
execution path and the execution time for each action (Page or Method).
Setting Diagnostic trace settingsYou need to set diagnostic trace
properties to determine whether you have too much data in the session
Starting Builder call timingTo analyze the time that builder
calls take during regeneration, you can start builder call timing tracing
Performance “Best Practice” Applications created using IBM® Web Experience
Factory need to be architected for performance
Performance TestingUse the statistics described in this topic to analyze
the performance of your IBM® Web Experience Factory application
Trouble Shooting and ServiceabilityThis is a link to a general debugging
page where you can find links for further information
JMX Publishing Problems in Web Experience
FactoryJMX publishing logs are produced for most servers, except for
WebSphere Application Server Community Edition server and Tomcat. If you have
any problems publishing, consult the following