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 just before and when a problem occurs. WebSphere Portlet Factory provides multiple mechanisms and techniques to help you resolve such errors. These techniques are listed below. Each topic is covered from a beginners perspective. Each section describes the method or technique used and why it may be 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 the topics listed in the Table below. There is also a links section at the bottom of this page where you will find an array of useful information.

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, and warnings. The errors in the Problems view include any and all builders used in the model including Java Code and syntax errors. When you double-click the icon indicating either an error or warning, the editor automatically opens to that line of code. The outline view will show the associated resources for easy navigation. This feature 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.

These warnings and errors are typically produced by custom coding, builders, and builder inputs. Pressing F1 with the builder in question open will display specific information about that builder. This can be useful in determining what each builder does and how the inputs are used. The builder help can also be help determine whether your builder has any built in capabilities that could help in the debugging process. Choosing Builders that use Actions and Events can be useful in debugging a provider model within Web Experience Factory. The Problems view comes with two unique features worth mentioning here. Filtering and Quick Fix.

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.
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 offers simple quick fixes for an error, 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.

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 this 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

The value you display using SystemOut is displayed in the console and will look something like the following. To learn more about special actions please refer to the Supporting information section of this page.

*--TIME: [2004-12-25] 16:07:05, 831] __*

Category: bowstreet.system.debugTracing

Priority: INFO

Msg: SystemOut= ${Variables/varHellowWorld} =null

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 to displays a 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

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. 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
- Enabling Debug Tracing
- Debug Tracing Builder

Use the system tracing feature to store the WebApp execution path and the execution time for each action (Page or Method).

Model Tracing and System 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. There are two types of testing that should be noted here. System Tracing and Model Tracing.

System Tracing
You can enable system tracing via Run>Run Configuration>Tracing and check the "run with system tracing" checkbox. This allows you to write a debugging file, Use the system tracing feature to store the WebApp execution path and the execution time for each action (Page or Method). The stored information is written to the console upon completion of the request. It can also be written to an event log file found in the MyApp\logs directory. When you activate system tracing and run a model, system trace control records the amount of time it took to run through each of the action builders in a model.The system can only perform tracing on actions that are called through the WebAppAccess methods callMethod() and processPage(). If you call a method directly from another method, the tracing is bypassed and cannot be automatically tracked.You can add tracing manually to an internal web application method or a linked Java object method. To manually do this, use the WebAppAccess method addSystemTrace() to add the start of a trace.

{ SystemTrace trace = webAppAccess.addSystemTrace(SystemTrace.METHOD, "in My Method"); ... do some work; trace.endTrace(); }

Model Tracing
When you run any model from Web Experience Factory Designer or in Websphere Portal, a Model Actions will be logged to the modelActions.txt file. The file can be found in the deployed application's WEB-INF\logs directory instead of being written directly to the console. If you need help Interpreting a Debug log File, you can check the supporting materials below.
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.

If you would like to find additional information on setting appenders, session size logging etc. Please visit the Per formance Testing Article and select Model Tracing from there for additional information.

Supporting Information

Model tracing and results output

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 a Web Experience Factory Application. The log4j.properties folder can be located in the WEB-INF/config/log4j.properties file in your deployed WAR. I encourage you to read through this file carefully. In addition to logging, 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 visitCustom 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.

The example below that takes the incoming SOAP Requests which has a logging level of WARN, and changes it to DEBUG. Default logging levels will provide additional information on WARN, DEBUG etc..This web service will now log all incoming requests. You can find more information on custom logging, creating your own appenders, logging service calls, and SQL builders in the supporting information of this section.
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

Web Browser Debugging

Google Chrome, Firefox, and Safari are just a few of the browsers supported with developer tools that can aid in debug a Web Experience Factory Application. Web Experience Factory uses a combination of CSS, stylesheets, JavaScript and HTML to handle most UI features. Looking at HTML, CSS, and JavaScript can help a developer figure out,"Why does this page look this way?", "What CSS file is getting used for the styling of this element?". There are also a lot of JavaScript techniques like, viewing console output, finding errors, looking at variable values, and setting breakpoints. Although, this is not singular to Web Experience Factory, it is a technique worth mentioning. Especially for those UI conscious developers.

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

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 models 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 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 is running and a remote debug connection is 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

As you can see there is more than one way for a developer to debug a Web Experience Factory Application. This here is a compiled list of the most common methods of debugging your Web Experience Factory Application. You can always refer to your product help in order to learn more. I have created a list containing various other types of testing and debugging methods that could potentially be useful. I recommend searching the wiki and reading the forum for additional information.
Links Section
Deciphering error logging displayed in the command prompt window: Example-- This topic represents log output that shows a list of actions performed and the milliseconds used for those actions.

Starting System Tracing-- Use the system tracing feature to store the WebApp execution path and the execution time for each action (Page or Method).

Setting Diagnostic trace settings-- You need to set diagnostic trace properties to determine whether you have too much data in the session.

Starting Builder call timing-- To 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.

Per formance Testing--Use the statistics described in this topic to analyze the performance of your IBM Web Experience Factory application.

Trouble Shooting and Serviceability-- link to a general debugging page where you can find links for additional information.

JMX Publishing Problems in Web Experience Factory-- JMX publishing logs are produced for most servers with the exception of WebSphere Application Server Community Edition and Tomcat.
Debuggin a Web Experience Factory application-- Overview of general debugging techniques.