Using log.properties file

By default the Websphere Portal Server writes debugging trace message in same file as that of WebSphere Application Server. But if you want you can change it so that the debugging trace information generated by WebSphere Portal Server goes to separate file.
In order to enable this feature you will have edit /shared/app/config/log.properties file which looks like this by default

#
# Specifies if WebSphere Portal Server writes to the WebSphere Application
# Server log files or uses its own log file.
#
# Default: true
useAppServerLog = true
#
# The name of the WebSphere Portal Server's log file.
# This setting is ignored if the WebSphere Application Server's log files are
# used.
#
# The following tokens are replaced by the corresponding values:
# $APPSERVER_NAME The name of the WAS node, this should be used for vertical
# clusters to enforce that the different nodes write into
# different files or directories
# $CREATE_TIME The time a file was created
#
# Default: log/wps_$CREATE_TIME.log
logFileName = log/wps_$CREATE_TIME.log

In this file value of useAppServerLog property defines if you want portal to use different log file. By default it is set to true so portal server writes to trace.log file. If you set it to false(Means use differnet log file) then portal server will read value of logFileName property to find the location of log file where the trace messages should be written.

Once you make changes in log.properties file you will have to restart the server for these changes to take affect. After you restar the server the log generated by portal component such as PUMA log will go to seperate file.

Using Enable Trace portlet

You can enable trace for portal server component temporarily by going to WebSphere Portal -> Administration -> Enable Trace Portlet.
For example you want to enable trace for PUMA then you can go to enable tracing portlet and add these strings

com.ibm.wps.puma.*=all
com.ibm.wps.services.puma.*=all

Note one very important thing that whatever changes you make in Enable tracing portlet will take effect immediately and will be lost when you restart the server. It is same as making changes using the runtime configuration tab in WAS Admin Console

Now your enable tracing portlet should look like this


Once your done debugging your problem you can disable the tracing by deleting all the trace string except *=INFO

Utilizing log for troubleshootin

The WebSphere Portal Server uses System Event logging facility as logging framework Ex. Portal Server components such as Portal Aggregation engine, Personalization engine,, etc write to the System Event log. This facility is based on top of WebSPhere Application Server Trace facility. If your administrator then the System Event logging can provide you with information on abnormal events such as errors that occured during the operation of portal.

When you open a support request with IBM normally they will ask you to collect trace generated by system event logging from your system and send it to them. Ex. If your facing some problem in say registering new user or in the edit profile of existing user then they will ask you to collect trace for User Registry related PUMA component

The System Event log messages can be divided into two types

1. Message Logging:WebSphere Portal Server provides the logging of messages that report errors and status information. The messages can be divided into ERROR, WARNING and INFO type


2. Trace Logging:WebSphere Portal Express provides the logging of debugging messages called traces. These traces are useful for fixing problems. However, to save system resources, they are switched off by default.

The messages logging is enabled by default and it writes messages in the SystemOut.log and SystemErr.log. Ex if you go to enable tracing portlet and add additional trace string then it will write these messages to SystemOut.log

[/WEB-INF/jsp/ManageLogView.jsp]: Initialization successful.
[10/10/08 13:54:13:732 EDT] 0000008e ManagerAdmin I TRAS0018I: The trace state has changed. The new trace state is *=info: com.ibm.websphere.wmm.*=all:com.ibm.ws.wmm.*=all:WSMM=all:com.ibm.wps.services.puma.*=all.
[10/10/08 13:54:30:106 EDT] 0000008d ManagerAdmin I TRAS0018I: The trace state has changed. The new trace state is *=info: com.ibm.websphere.wmm.*=all:com.ibm.ws.wmm.*=all:WSMM=all:com.ibm.wps.services.puma.*=all:com.ibm.wps.puma.*=all.
[10/10/08 13:55:05:402 EDT] 0000007b ServletWrappe A SRVE0242I: [wps] [/wps] [/themes/html/IBM/mainMenu.jsp]: Initialization successful.


Enabling trace logging causes a performance impact so it is disabled by default. You can able the trace logging using the WAS Admin Console or Portla Admin Console. Normally when you enable trace logging you will enable it for particular java package or class. For example you want to debug problems related to User Profile creation and update so you can go to Portal Infocenter and find out name of the authentication related java packages in Portal Server and you will get these trace string.

com.ibm.wps.engine.*=all:   
com.ibm.wps.services.puma.*=all:   
com.ibm.wps.puma.*=all:  
com.ibm.wps.sso.*=all:  
com.ibm.wps.services.authentication.*=all

Once you have the trace string you can enable using one of the two methods

1. Using WAS Admin Console


2. Using Enable trace portlet