Adding logging to portlet code is usually an afterthought during the development cycle. The issue of logging usually only comes up after a portlet has been deployed in production and an error occurs. Then you hear, "Well, the problem didn't happen during testing."

This paper steps you through the three different logging mechanisms available for portlets. The first demonstrates the WebSphere Portal's built-in logging mechanism. The second is a roll-your-own version of the base WebSphere Portal logging. The third shows you how to add Log4j to your portlet.

Add WebSphere PortletLog to a Basic Portlet
Start by creating a basic portlet using the IBM Rational Software Development Platform. All of the examples in this article should be run in the J2EE perspective. Using the navigation bar, go to File=>New=>Other=>Portlet Project. Click Next. Enter the project name Test Log. Press the Next button. Select Basic Portlet. Press the Finish button.

Using the native WebSphere PortletLog logging for your portlet development has a few drawbacks. So you understand both its strengths and weaknesses, you can try this logging feature with the Test Log project.

Open TestLogPortlet.java and add the declaration for the PortletLog and sClassName. Replace the init() [A], doView() [B] and actionPerformed() [C] methods with the code shown in Listing 1 at the end of this article. Remove the annotations [...] from the listing before you compile.

Besides instantiating a reference to the PortletLog [D] in init(), the logging methods info() [E] and error() [F] are added to both doView() and actionPerformed(). To prevent a negative impact on performance always check to see if logging is enabled using

if (logger.isInfoEnabled()) ...

before invoking info(). Also limit the number of info() calls to significant events such as method entry and exit to prevent the portlet from spending more time tracing than actually performing its function. Since error() is only invoked under extraordinary circumstances, you don't need to check if error logging is enabled before invoking this method.

Logging in the WebSphere Portal Server consists of three distinct levels and one all-encompassing level (all):

• low
• medium
• high
• all

Each level can be assigned the value enabled or disabled to determine which logging method calls are written to the log. The first three levels map to common logging methods. If the low level is enabled then logging from all the logging methods will display. The medium level means that logging from the warn() and error() methods will be displayed. Only the error() method will display messages if the high level is activated.

Although PortletLog supports different logging levels, the best rule for the PortletLog tracing is to keep the assignments simple. Limit your level assignments to all=enabled or all=disabled.

Enabling PortletLog Tracing Using the Rational Software Development Platform
Test the Test Log portlet in IBM Rational Software Development Platform. Right click on Test Log and choose Run=>Run on Server. Choose Manually define a server and WebSphere Portal v5.0 Test Environment. Select the Set server as project default checkbox. Press Next.

Notice the port number. The portal login page for this test environment will have the address http://localhost:9081/wps/myportal. Click Next.

Add Test LogEAR to the list of Configured projects.

The WebSphere Portal Server test environment will display the portlet. In the Servers view, right click on the WebSphere Portal v5.0 Test Environment. Press Stop. After the server stops, right click on the server and select Open. Choose the Portal Options tab. Select the Enable base portlets for portal administration and customization and Enable console logging checkboxes. Press Ctrl-S to save your configuration changes and close the server configuration panel.

Right click on the Test Log portlet project again and choose Run=>Run on server.

Due to the design of PortletLog tracing, you need the administration console to enable portlet logging. Once the portlet renders, navigate to Administration=>Portal Analysis=>Enable Tracing. You enable tracing by adding the line org.apache.jetspeed.portlet.PortletLog=all=enabled to the Append these trace settings field. Press the plus (+) button. Log out of the portal and then logon. After the page with the Test Log portlet displays, press the Submit button and select the Console tab. You should see messages similar to those shown in Figure 5.

Results of Using PortletLog Logging
Notice that in Figure 5 all log entries generated by the PortletLog are prefaced with org.apache.jetspeed.portlet.PortletLog. It's important that any log messages include a unique string. In the example above, the logging text for both the info() [E] and error() [F] methods include the sClassName variable in addition to the method name. Also, if all your portlets use the PortletLog methods, then logging for all the portlets in your portal will be enabled. This can be a nuisance if you're just trying to solve a problem in a single portlet.

The benefit of using the PortletLog is that it's simple. It's included in the base portlet class. You can get a reference to the PortletLog using:

• portletConfig.getContext().getLog(), or
• getPortletLog(), which is available in the PortletAdapter.

Adding the PortletLog methods are better than not having any logging in the portlet but it's definitely not the best method.

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Figure 5
• Figure 6
• Figure 7
• Table 1
• Table 2