In this post, we will cover some more advanced logging topics in TRM, including PE logging, SQL output, user clicks, authentication attempts, and startup logging.
PE logs, due to special requirements, are handled through custom log4j objects. These objects are based on log4j appenders and loggers, but are not configured in the log4j.xml file; they are essentially hard-wired in code. As such, the logging performed in the PE is not configurable. The design of the PE logs includes two categories (general and detail level) of logs for each submitted PE job. The files are located and (usually) named with the convention:
The logpath root for the PE files defaults to different locations depending on the webserver:
• Tomcat is <tomcat install root>\webapps\trm\bin\dist
• WebSphere is <WAS root>\profiles\<AppSrv>\dist
To override this location, edit "trm.properties" (in the .\trm\WEB-INF\classes directory). The symbol trm-data specifies the root location:
Most configuration files, including the log4j.xml, are located in the application's WEB-INF\classes directory, the path to which depends on the webserver:
Due to their large size and marginal utility of archiving the PE logs in a test environment, a "purge" action was added which will automatically delete PE log files created in prior to given number of elapsed days. This elapsed time value is derived from "purgeWaitDays" which is set in the "processingEngineTemplate" Spring bean (see file "trm-modules/trm-processing-engine/config/common-pe-context.xml"). The minimum purge wait value is 1 (day). A value of 0 (or less) suppresses the purge action.
2008-12-16 07:47:08,226 DEBUG :pool-1-thread-229 [com.teradata.trm.common.qes.ioc.jdbc.advice.SqlTrace] sql(ms)=16 SQL TRACE: "insert into CR_RUN_COUNT (UPDATE_DTTM, UPDATE_USER, RUN_COUNT_ID) values (?, ?, ?)--parameters=[2008-12-16 07:47:08.163,trm-user,20003d420nmt],ver:220.127.116.11.85900.branches/stable/,
This is an example log entry. It shows a query being executed to insert a record into CR_RUN_COUNT. It’s a parameterized query, and the parameters are reported in the com-ments of the query.
2008-09-14 08:20:50,861 INFO ac210023:WebContainer : 4 [com.teradata.trm.common.web.struts.TRMRequestProcessor] --> 1 /trm/tablesAndFields.do create 
This is an example log entry. As with all log entries, it begins with the date/time, log level and the user name. These entries can be found by filtering (with logweb or similar tool) for mes-sages from the TRMRequestProcessor. You'll notice there is a --> which indicates the user has just clicked "into" this page. For each of these entries there is a corresponding <-- entry which indicates the log entry for when the server returns the page to the user. In this way you can identify all the log messages associated with each page, as the ones between these two log entries. After that, you see the url (/trm/tablesAndFields.do) and the dispatch action (create), which is to say the button that the user has clicked. So this log entry is when user ac210023 had clicked "create" on the tables and fields page.
2008-12-16 05:49:38,540 INFO kwells:WebContainer : 6 [com.teradata.trm.common.web.struts.TRMRequestProcessor] --> 1 /trm/extractFormat.do publish 
query string: &trm_currentBreadcrumb=0
novalidate = true
dispatch = publish
SAVE_FOLDERID = 20003d41rl9n
trm_currentBreadcrumb = 0
This is another example. In this log entry you can see all the parameters that were passed on the request. So, in this case the user kwells was publishing an extract format into the folder with the id 20003d41r19n.
2008-12-16 11:09:22,608 WARN :WebContainer : 2 [org.acegisecurity.event.authentication.LoggerListener] Authentication event AuthenticationFailureBadCredentialsEvent: ac210023; details: org.acegisecurity.ui.WebAuthenticationDetails@380f4: RemoteIpAddress: 18.104.22.168; SessionId: ktmh6n_F_19ZsVrkWEhcAwG; exception: Bad cre-dentials
This is an example log entry. It shows an attempt by someone at IP address 22.214.171.124 to login with the userid ac210023. It reports that the login attempt failed because the credentials provided by the user (their username/password) were not correct. The user does not see this log message. They just see the message “Your login attempt was not successful, try again.”
2008-12-16 11:09:28,140 WARN :WebContainer : 2 [org.acegisecurity.event.authentication.LoggerListener] Authentication event AuthenticationSuccessEvent: ac210023; details: org.acegisecurity.ui.WebAuthenticationDetails@380f4: RemoteIpAddress: 126.96.36.199; SessionId: ktmh6n_F_19ZsVrkWEhcAwG
This is an example of a successful login event. It shows that someone at 188.8.131.52 logged in successfully with the userid ac210023. We never log the password used for either successful or failing login attempts.
The following is an example log message captured in trm-system.log during the startup of TRM. It records all the settings from trm.properties, jdbc.properties and ldap.properties. Refer to the chapter on configuration settings to see the definition of each of these settings.
2008-12-10 09:41:07,765 -main: INFO [TRMStartup]
TRM Startup properties
dbcp.validationQuery select current_timestamp dbcp.warehouseDataSource trmDataSource jdbc.driverClassName com.teradata.trm.common.qes.ioc.jdbc.QESDriver