| Summary: | Importing Windows Event log with a filter fails | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Dave Smith <smith> |
| Component: | TPTP.monitoring | Assignee: | 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
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. 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" *** Bug 110230 has been marked as a duplicate of this bug. *** 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. 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. 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. |