by David Wade, Davalen
Webster’s Dictionary defines mastery as
“knowledge and skill that allows you to do, use, or understand something very well”.
Mastery is also defined as
“possession or display of great skill or technique”.
For most people mastering a tool like Web Experience Factory (WEF) comes from study and experience in developing solutions using WEF. It also comes from recognizing the fact that WEF is not just a generation tool. WEF’s strength is that the WEF developer determines how much of a WEF application is generated and how much is customized based on the needs of the task at hand and the environment.
“How does WEF handle a specific functional requirement?”
My answer is usually
What WEF doesn’t do is replace the need for you to develop your techniques in analyzing the application and building your knowledge on what goes into developing a superior application.
For “Web Experience Factory in Practice” articles our goal is to share experiences from the field. One thing that seems to be common for all the projects I’ve been a part of is that there is a need to debug the application. For example you may be getting an exception and you are not certain where it is occurring so the exception to be traced or you are creating a complex XML to submit to a service or getting back a complex XML. There are many different aspects of debugging. For this article we are focusing on debugging the application at various points in the flow to see what values are being set. The first and sometimes only choice of some WEF developers is to place SystemOut’s or log4j statements all through the action lists and methods trying to solve an issue.
On a WEF project several years ago Carl Domingue showed me another way of accomplishing this same goal that provides a more robust view of the variables. The method I am going to be documenting in this article is one that using Java Debug to set breakpoints, step thru code, see the variables, and even change variables at certain points. In this article we will show you how to set up you server and project for debugging.
In future blogs we will describe some approaches to setting up you action lists to use this technique. My personal preference is to move all Method builders to a utility class accessed by a LJO builder. This allows debugging and use of the Java editor. For the case of debugging alone we would recommend moving a Method builder to a utility class accessed by a LJO builder.
Step 1 is to enable debug on your server.
My preference is to use a WAS server with Portal. The WAS/Portal combination is what I’ve used on almost all of my projects. Please email me if you need information on other servers.
Open your WAS console.
My local portal WAS console is https://localhost:10032/ibm/console/logon.jsp .
- Sign on using your WAS admin password
- Navigate to Servers -> Server Types -> Application Servers -> WebSphere Portal -> Debugging service.
Debugging service is on the right hand side under “Additional Properties”.
- Check the “Enable service at server startup”.
- Choose a “JVM debug port”
Note: You can leave this at the default of “7777” as long as this doesn’t conflict with other ports in use on your server. This is the port you will reference when you start your Debug Configuration in your workspace
- Click “Apply” and then “Save directly to the master configuration.”
- Close your console
- Important: Restart your server
- Navigate to the Java class you want to debug
- Set your breakpoints by double-clicking on the left of the line
A blue dot will appear
- Click Run -> Debug Configurations. You should see the dialog to the left
- At the bottom of the list click “Remote Java Application”
- Select the project you want to debug
- Enter the port that you selected when you set up your WAS server
- Click “Debug”
- If all went well, then nothing should happen. Sometimes you get a dialog that you can’t attach to the JVM. This can happen if the ports don’t match or sometimes it’s necessary to restart the workspace.
Now whenever you run the model that contains LJO’s either thru Run Configurations or in your Local Portal you should get a message in your workspace to switch to the Debug Perspective. When you do you will be at the first breakpoint that you set. At this point you can:
- Check the value of any variables in this method.
Note: if WebAppAccess is part of this method, you can open it up and find a lot of instance information.
- Change the value of any variable
- Step thru the next steps using the debug menu
So at this point you are ready to start debugging your application. In future blogs we will look at how we can arrange our action lists and LJO’s so that we begin an application with a plan for debugging. Another interesting thing we can do is to add an open source decompile tool and be able to look into what is happening with the generated WEF java. Ultimately we want to promote the mastery of WEF so that we can deliver superior solutions.
About the author: David Wade is a Portal / Web Experience Factory Consultant with expertise as a developer, team lead, and architect. Before joining Davalen, David was an employee of IBM as a Senior Specialist and as the Portlet Factory Lead for GBS and recently an independent consultant. He has worked on major Portal projects across the United States. David’s Portal / Portlet Factory background began as a consultant at a manufacturing company in SC. After IBM purchased Portlet Factory from Bowstreet in 2005, he developed and implemented a complete production line system using Portlet Factory on WebSphere Portal connecting with the iSeries. Prior to his Portal experience David spent 20+ years as an iSeries Applications consultant delivering solutions in the manufacturing, education, and media industries.