Community
Participate
Working Groups
Currently Parser attributes are extracted from generated GLA configuration file and passed into Parser as a hashtable. There is no way to pass parameter at memory to parser. This is necessary when log file does not have all imformation to create meaningful Common Base Event. Some examples from iSeries job log conversion: 1. I want to put job ( same as "process" in world outside iSeries ) number to a field of CBE. This piece info is not written in log record but is available at runtime. It will be very convinent if there is an API to pass it to Parser and eventually set to an attribute of CBE. Right now, as a workaround, I have to put it in Sensor parameters and in my parser to access the parameter set of Sensor. This causes tightly couple releationship between sensor and parser. 2. Another example will be the location in SourceComponentID. iSeries job log conversion also supports the offline analysis, ie, the iSeries job log is generated at iSeries host but it will be downloaded to PC workstation. Then the log can be imported into LTA. In this case, the location of SourceComponentID should still be the iSeries host. By taking advantage of iSeries tooling, I can have iSeries host info around but there is no easy way I can pass it to Parser. As a result, the localtion will be the workstation IP which is misleading. To sum up, log record escipally from legacy application may miss some important informtion for a meaningful CBE but these info are available at runtime by taking advatage of third party tooling. If Parser has public API then all these valuable information got from runtime can be used together from log record.
change component to Monitor.Execution
I am making this requirement more general. I am extending it to be able to pass properties or parameters to any GLA component. The proper solution requires changing the schema of all components to extend pu:ProcessUnitType like the Sensor and Outputter schema do so that any user defined property can be passed to a compoment. However, this is a breaking API change and cannot be done until an API breaking major release (eg. 5.0). Making this a P1 but changing the verion to "future" because the change cannot be made in 4.2.
Setting target to future so it doesn't show up in 4.2 feature query.
Due to lack of resources this enhancement request is resolved as WONTFIX. Please feel free to reopen if you consider it's a required enhancement.
Closing.
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As such, TPTP is not delivering enhancements. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement is resolved as WONTFIX. For this enhancement to be considered, please re-open with an attached patch including the Description Document (see http://www.eclipse.org/tptp/home/documents/process/development/description_documents.html), code (see http://www.eclipse.org/tptp/home/documents/resources/TPTPDevGuide.htm), and test cases (see http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html).
