Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 108958

Summary: Importing Windows Event log with a filter fails
Product: z_Archived Reporter: Dave Smith <smith>
Component: TPTP.monitoringAssignee: Dave Smith <smith>
Status: CLOSED FIXED QA Contact:
Severity: major    
Priority: P1 CC: amehrega, apnan, zung
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows 2000   
Whiteboard: closed460
Bug Depends on: 106497    
Bug Blocks:    

Description Dave Smith CLA 2005-09-07 12:25:15 EDT
Importing any Windows event log (Application, Security, System) with a filter 
fails with the following error messages:

IWAT0027E Error importing the specified log file(s).
  IWAT0412E Errors occurred parsing the log file null.
  java.lang.Exception: IWAT0239E Converter command failed: java.io.IOException: 
CreateProcess: eventlogreader.exe application error.log error=2
java.lang.Exception: IWAT0239E Converter command failed: java.io.IOException: 
CreateProcess: eventlogreader.exe application error.log error=2

The failure occurs on both a local and a remote import.  The failure occurs on 
using any filter.

I used TPTP 4.0 20050718_1519 build but the problem also occurs in TPTP 3.3 and 
4.1.
Comment 1 Dave Smith CLA 2005-09-07 12:56:08 EDT
This problem is caused by the Log Import Wizard creating a new adapter file 
with the filter component added and passing the name of that new file to the 
ParserWrapper object via the hash table in place of the original adapter file 
name.  The ParserWrapper.modifyConverter() method parsers and uses the 
configuration file directory passed in and assumes it is the directory where 
the original adapter file is located.  However, the directory where the new 
temporary adapter file is passed to modifyConverter() so that code fails to 
modify the converter command correctly and the resulting converter command 
cannot be executed.

This problem affects any parser that requires a converter command that must be 
modified by a ParserWrapper extension class and whose modification depends on 
the original adapter file location or directory name.  Some ParserWrapper 
extension classes support multiple log types and they use the directory name 
where the adapter is located to determine which log type is being parsed in 
order to do the correct processing on the converter command.
Comment 2 Dave Smith CLA 2005-09-07 13:04:36 EDT
The fix for this problem involves the Log Import Wizard passing the original 
adapter file name as specified in a parserParameter element of the logParser 
exension point to the ParserWrapper class and then the ParserWrapper class 
parses out the directory of that original adapter file and passes that to 
modifyConverter() method.

The Log Import Wizard can pass the original adapter file name as an element of 
the HashTable in the local case and as a parameter of the RemoteLogParserLoader 
program in the remote case, with key "originalAdapter"
Comment 3 Alex Nan CLA 2005-09-21 15:15:24 EDT
*** Bug 110230 has been marked as a duplicate of this bug. ***
Comment 4 Dave Smith CLA 2005-09-29 11:37:20 EDT
The fix for this defect will be affected by the work done for bugzilla 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=106497 so I'll wait until that 
defect is completed before doing this one.
Comment 5 Dave Smith CLA 2005-10-06 10:02:43 EDT
The fix for this problem was included with the changes made for bugzilla 106497.
The fix is to use the originalAdapter hash entry from the Log Import wizard to 
find the original adapter location to pass to the modifyConverter method.
Comment 6 Paul Slauenwhite CLA 2009-06-30 08:05:51 EDT
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.