Community
Participate
Working Groups
Import -> Log File Select "IBM Websphere Application Server activity log" Select a valid server with a working RAC and a valid connection, enter the correct websphere server installation directory, but enter an _incorrect_ file path for the log (a non-existent log file). Click Ok, Finish. The log view comes up with an empty log, the profiling monitor view says the agent has terminated. But, there is no indication to the user that the operation failed. The user is left guessing why the log is empty.
Are you trying to import a remote log file ?
Yes. I'm using: Host: zeta:10002 Websphere: /opt/WebSphere/AppServer
cannot be contained in M10
Mewa, For LOCAL host file import, file existence should be checked before the import action started. Start from org.eclipse.hyades.log.ui plugin and follow the import log wizard, when user select a localhost, validation on any file path in the detail tab should be done before OK button is enabled to let user continue on.
*** Bug 50067 has been marked as a duplicate of this bug. ***
For LOCAL host file import, it worked fine. I didn't face this problem. When I entered non-existent log file or non-existent path for log file, then a "Logging Message" dialog popup "File or directory:c:\**\**.log doesn't exist.Please ensure the provided name is correct and try again" So it didn't allow user to go further in profile monitor view. Please confirm!
Please read Eugene's previous comment more carefully; the idea was to check before hitting Ok and tell the user beforehand that the file doesn't exist.
Once the local scenario validates the existance of the file, please open a defect against the RAC components to work on the remote case. When the file is imported remotely, the RAC should sent an exception when the file location is invalid.
Updating defect owner.
[in the new build eclipse platform] For log file import on LOCAL host : Validation on the existence of log file and path has done for UI component (Import Log File wizard > Edit Log File > Details tab) and it works well. For log file import on REMOTE host : Validation on the existence of log file and path has NOT done for UI component. When the log file is imported remotely, the RAC/GLA should acknowledge workbench about the validity of the log file location. The problem is not a UI problem. GLA adapter should extend this function.
Defect discussed in Hyades committers call and approved to move to a higher release
part of the redesign of the extension point should include support on display name on defaultValues, so the dafaultValues send to remote machine is always English. AC 35363
I increased the priority to P2 because there is additional downstream dependency on this now as per Eugene's previous comment.
This feature is also related to Bugzilla 74900 where import muliple logs will be splitted as separate jobs.
Support for throwing exceptions and returning messages was added to the GLA runtime in fix for bugzilla 61256 (https://bugs.eclipse.org/bugs/show_bug.cgi? id=61256). Here is what need to be done in the Local Log Import wizard UI code: 1)create a Log 2)pass the Log to the Parser class via the setParserLogger() method 3)if an exception is caught from the parse(Log) method, receive any messages from the Log 4)open an error dialog to show the message from the exception and give the user the option to show the messages from the Log for more details. We also need to handle the remote import case, in the Log Import wizard and on the remote machine. I can change org.eclipse.hyades.logging.parsers.RemoteLogParserLoader to create a logging agent logger that the GLA will use to log its messages. The remote Log Import wizard needs to attach to the logging agent and monitor the GLA messages. Once the GLA is finished, it will throw and exception which will be caught in RemoteLogParserLoader and sent back to the UI via an error logging agent that exists in the current code base. Once the UI receives the error it will display any GLA messages it received from the first logging agent if the user asks for them. necessary logger and give it to StaticParserWrapper.
See Hyades defect #82162 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=82162) for infrastructure changes to the org.eclipse.hyades.logging.parsers.logParser extension point.
retarget bug to 4.0 and it is a P2.
This is P1 for downstream product.
separate UI works of bug 61256 (see Additional Comment #16 From Dave Smith 2004-12-09 15:20) from this bug and opened bug 82781 to track it as P1 there.
The bug is to capture the following problems/requirements: - include support on display name on defaultValues, so the dafaultValues send to remote machine is always English. AC 35363 - validation framework support on parser entry fields in import wizard detail pane (eg. validation on file path/name) - parser configuration support on vendor,product,name grouping bug that is related to this bug and should be considered in the restructuring: - bug 74900 split multiple log import into jobs with stop import job support - bug 82162 log file grouping in import wizard log table
CVS decrsiption: The Log Parser extension point should be reviewed so that it allows field validation. For example, a field can be used to identify a file path and install location and the input should be validated before the information is send back to the parser. The extension point should allow more generic type of entry fields, such as password entry fields. Also, provide a way to separate strings that are used to populate the UI widgets from strings that are actually used as parser options and versions and send to the RAC. This will solve the problem of having the options and versions translated in the UI without affecting functionality. The parsers should always use english versions and options and the UI should display the translated strings. A new attribute different from but corresponding to the current defaultValue field (possibly named displayValue) will be added to logParser fields to supply the display value for a field. DisplayValue will consist of a comma-separated list of strings corresponding to the comma-separated list of strings in defaultValue. DisplayValue strings will be displayed but the corresponding defaultValue string will be taken as the value of the choice made by the user. DisplayValue is optional and defaultValue will be used for it when displayValue is omitted. In the case of the pull-down choices from the log import wizard, the displayValues must be present and localized and the defaultValues must be present and not localized.
The extension point should allow the import of log file using different protocols, for example FTP. Scenario : the user has a file on a remote machine where the RAc is not available. The file will be copied to the local machine using ftp/http ( if avaialble ) and next the file is imported generating CBE events. Some updates at the intersection between GLA UI and GLA runtime might be required ( the ParserWrapper class should be able to allow the copy action before starting the actual import )
Upgrate priority to P1
The restructuring should support localization of log file. This is the scenario : Currenty, in the log import scenario, a user selects a log file version and based on the version a specific adapter configuration file is run by the GLA. However, parser writers can provide adapter files for logs created under different locales and character sets. Therefore, to support importing log files that are generated in different locales and character sets, a mechanism for selecting the correct adapter configuration file based on log version plus locale and character set specified by the user in the import wizard, is required. The extension point should allow the user to provide a locale and/or character set for the adapter file. This should be available as a user option in the import wizard. Based on the user selection, the right file path is passed to the parser. Adapter files will be stored in different subdirectory relatively to the main file path; for example, if x:\myPath\myFile.adapter is selected in the import wizard and the user selects german as the locale, the parser wrapper should receive the file path as x:\myPath\de\myFile_de.adapter. This should be documented and a sample should be provided.
Changing to P1 as per the 4.1 official plan.
As part of the restructure, also consider support to allow extension point contributer to specify time zone selection field in import wizard, where when enable, an extra field listing all the available time zone should be shown and user selection will be passed to GLA for CBEs generation. This is depend on feature bug 74918. Also see feature bug 79560 on how time zone preference is used in log related view display.
I am working on creating an adapter to convert IBM iSeries server job log to Log analyzer. The import log UI I currently use ( TPTP3.3 ) need to be more extensible. Not sure if this feature will cover my following request. If not, please point me the feature which contains it. Problem: iSeries job log does not exist as a physical file. This is difference with log in most other platforms. Some iSeries host API must be called so that job log can dump to a file. When importing iSeries job log, customer specifies job name because log file does not exist until adapter calls host API. I'd like to override browse button so that it browses remote iSeries job number. I think current browse button is only a file dialog. I also like to contribute iSeries friendly widget to the tab ( an example is to use three widget to represent a full qualified iSeries job name ). Suggestion: The details tab should be an extension point so that third party can contribute the whole tab. This provides flexibility to add customized widget, widget event handling and arrage widget layout. Something likes Eclipse workbench launch configuration tab machianism.
The new extension point will provide the option to specify in your parser contribution a control that will be displayed on the details tab of the Add Log dialog. You will have to provide a so called custom field, maybe the name is a bit misleading, which requires to implement the following interface: public interface ICustomField { /** * Creates the contents of this custom field. */ public Control createContents(Composite parent); /** * The returned map contains key/value pairs where key is the widget id and value the widget value for each widget that occurs in the field. * @return the user input for this custom field. */ public Map getUserInput(); } You will control the widgets created inside this control, the layout and handling of any type of events. I think this design is sufficiently flexible and will solve your problem.
Work will be done by the end of i2
A comment for the "Path" coulmn in table of import log file wizard: For iSeries job log, there is no file_path defined in logParser extension point because file does not exist yet. As a result, the path column shows empty. In iSeries job log case, iSeries job name / message queue name ( and others will come in future release ) makes more sense. I am wondering if it is possible to add an attribute in logParser extension point to indicate the string used to represent the target to be convert ? The field should be a calculated field so it can potentially combine the values from multiple fields. For example, iSeries job name is divided as three widgets for usability reason. Each one represents one part of job name information.
Regarding comment https://bugs.eclipse.org/bugs/show_bug.cgi?id=50681#c31 I have added a method to the custom control interface that allows the log parser contributor to return the label displayed in the import log wizard's log elements table. By default the file path attribute will be used. In order to customize this return value, the contributor has to implement a custom control. This customization is not supported by old style field contributions.
completed
Using: TPTP-4.1.0-200510140100 I tried importing an invalid log file again (apache access log), and verified that it does complain when the log file path is invalid. However, there are a few problems here: 1. I get a rather cryptic error dialog saying something about the initialization parameters of the parser being invalid. Only when I click on details does it tell me that it couldn't find the log file. Shouldn't it just tell me straight up that it couldn't find the file? i.e. no need for a details section or the cryptic messages. 2. I still see a new log in the log navigator, and the log view still opens (it is empty). These things shouldn't happen if the log import failed completely.. although I can see it would still be valid if , say, only some of the log files couldn't be imported (i.e. it should still show the other ones and open the log view). In my case I only had one log file in the set.
Curtis, although you opened this request as a defect some time ago, the defect ended up as a feature to restructure the log parser extension point. This work is done and I believe it works as designed. You are right, the error handling is not the best for the log import but it was not the purpose of this feature to improve error handling. Could you please open a defect for the problem you are mentioning or just add comments to a defect opened for a similar scenario 112530 which we could use to improve error handling in the log import.
Done.
Closing.
*** Bug 113667 has been marked as a duplicate of this bug. ***
