Bugzilla – Full Text Bug Listing
| Summary: | import filters are not exported when export the logset | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Jane Fang <janefang> |
| Component: | TPTP.monitoring | Assignee: | vrushali satpute <vsatpute> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P1 | CC: | apnan, ewchan, labadie, nelliec, rohit.shetty, smith |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Attachments: | |||
Deferring this to 4.4 because it is not critical/stop ship for 4.3. Eugene, please open a defect to add a 4.3 readme item for this problem. As a workaround, You can export and import the filter via the 'Export...'/'Import...' > 'Profiling Filters' menu action. Add sizing from Eugene. Target to future. Cannot be contained in 4.4 due to limitation of resource. Move target back to 4.4. Monitor defects are mistakenly targeted in bulk move. Targetting to iteration 3 and increasing priority to indicate it is planned for 4.4. Re-assigning to Vrushali. Hello Eugene, Attached the patch to fix the problems described here. Patch is added to export and import the 'Import Filter Definitions' while exporting and importing the the log sets. If filter already exists while import of logsets , old filter definition will be replaced by new filter definition. Modules: org.eclipse.tptp.monitoring.logui org.eclipse.tptp.platform.common.ui Please review the patch and let me know if you have any further changes. Created attachment 64924 [details]
Patch for the problems described in this defect is attached.
I reviewed the patch and have a few concerns here: 1). I see you reuse the FilterResourceFileHandler to save and load the query model. This results in a 'hybrid' log set file, where log file elements and filter queries are in totally different models. The resulting log set file looks a bit weird. 2). Step 1 is a quick fix for the problem. A more proper approach would be to either (A) move log file element to EMF model and persist with EMF resource, or (B) have a DTD mapping for the existing query model. Neither of them are not simple changes and risky to be contain by 4.4 release. The current workaround of the problem is to export filter and export log set in 2 different steps and also import the 2 files in 2 different steps. It's not user-friendly but I don't think it's a good idea to have a weird logset file which looks very unprofessional. Eric, Dave. Since the suggested changes (A or B) in 2) above takes longer time to be implements and the impact is big on the import log wizard structure, I suggest to push this out from 4.4, and have a more formal change in the code base to instead. Please advise. Created attachment 64947 [details]
sample logset file with the patch
I have also taken a look over the patch and I agree that this is not a solution we want to go with. Until we have a complete solution for this issue I would say we shouldn't commit the changes. (In reply to comment #11) > I reviewed the patch and have a few concerns here: > > 1). I see you reuse the FilterResourceFileHandler to save and load the query > model. This results in a 'hybrid' log set file, where log file elements and > filter queries are in totally different models. The resulting log set file > looks a bit weird. > > 2). Step 1 is a quick fix for the problem. A more proper approach would be to > either (A) move log file element to EMF model and persist with EMF resource, or > (B) have a DTD mapping for the existing query model. Neither of them are not > simple changes and risky to be contain by 4.4 release. The current workaround > of the problem is to export filter and export log set in 2 different steps and > also import the 2 files in 2 different steps. It's not user-friendly but I > don't think it's a good idea to have a weird logset file which looks very > unprofessional. > > Eric, Dave. Since the suggested changes (A or B) in 2) above takes longer time > to be implements and the impact is big on the import log wizard structure, I > suggest to push this out from 4.4, and have a more formal change in the code > base to instead. Please advise. > Hi Eugege, On 1) i agree that it does look weird, but that i guess is a limitation. i think the 'hybrid' logset file does not have anyother alternative .i.e. it would not make much sense to have duplicate filter definitions (multiple logs or logsets might use the same filter, what do you do in this case? Do you duplicate the filters? The XMI filter we have today are not necessarily the best representation of filters that we can duplicate with each log or logset). In order to avoid any duplication in the filter definitions in the logset file this approach has been adopted .i.e. only one instance of each of the filters used by the logs in all the logsets are exported into a filter dump available with each logset file. Im not sure if moving the logset to EMF or having a DTD mapping of the existing query model would actually solve the problem that i describe above. Also im not sure if moving the logset itself to EMF is the right thing to do. Also, isnt there a requirement to move to xpath based filters? I think this would open up a third option for a possible fix to this problem. xapth based filters are easier to represent. And, i believe we should be taking some inputs from the effort on the common launch by Eric. (i remember we have some solution for this type of a problem) Eric, Can you please add your comments on this. In common launch in context, user can define filters using FilterDeclaration element, and reference the filters in their logs using FilterReference element. For SimpleSearchQuery filters, what we do in common launch in context is to serialize them all as a parameter. Later on when user uses the context file to launch LTA in a different workspace, the parameter is deserialized back to SimpleSearchQuery filters. Jane, please send the code to Rohit to see how we are doing this on the IBM side. I am OK to contribute this code. Rohit, Jane has code to serialize/deserialize the FilterList in pure XML (not XMI). You will need to update the LogSet dtd to add this new ParameterList as an optional element. We might be able to meet the deadline to fix the problem on time using Jane's code. As per the discussion between Eric,Me and Eugene it was concluded that the only change that is required over the patch attached is to obfuscate the XMI related information from the Filter XML snippet attached by Eugene. Created attachment 65218 [details]
Patch for the defect
This patch over and above the previous patch does transformation to and from the XMI and obfuscated XML Filter representation.
Created attachment 65219 [details]
Sample logset after the transformation ....
Please ignore the previous patch and use the latest one attached by me. Thank you!!! (In reply to comment #18) Hi Rohit, you patch does not compile with the latest code. Would you please make sure it syncs with the latest CVS code? Created attachment 65283 [details]
Please apply this patch to the common UI package
Please appy this patch too. Sorry for missing it out previously.
Patches are reviewed and submitted to CVS. Thanks a lot Vrushali and Rohit 1. launch in a clean workspace 2. open log import wizard 3. add an apache access log, also add an error only import filter 4. export the logset 5. launch in another workspace 6. use the logset to import the apacch access log 7. all events get imported. in .log, the following exception is logged !ENTRY org.eclipse.tptp.platform.common 1 0 2007-05-08 16:13:07.816 !MESSAGE org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Package with uri 'null' not found. (file:/D:/test.logsxml, 2, 10) !STACK 0 org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Package with uri 'null' not found. (file:/D:/test.logsxml, 2, 10) at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:80) at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:190) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:179) at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1094) at org.eclipse.hyades.ui.filters.internal.util.FilterResourceFileHandler.load(FilterResourceFileHandler.java:151) at org.eclipse.tptp.monitoring.logui.internal.wizards.ImportLogSetsUI.populateLogSetFilterXML(ImportLogSetsUI.java:151) at org.eclipse.tptp.monitoring.logui.internal.wizards.ImportLogSetsUI.finish(ImportLogSetsUI.java:61) at org.eclipse.tptp.monitoring.logui.internal.wizards.ImportExportLogSetsDialog.okPressed(ImportExportLogSetsDialog.java:403) at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:464) at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:616) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:227) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3673) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3284) at org.eclipse.jface.window.Window.runEventLoop(Window.java:820) at org.eclipse.jface.window.Window.open(Window.java:796) at org.eclipse.tptp.monitoring.logui.internal.wizards.ImportLogWizardPage.importExportLogSets(ImportLogWizardPage.java:932) at org.eclipse.tptp.monitoring.logui.internal.wizards.ImportLogWizardPage.widgetSelected(ImportLogWizardPage.java:900) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:227) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3673) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3284) at org.eclipse.jface.window.Window.runEventLoop(Window.java:820) at org.eclipse.jface.window.Window.open(Window.java:796) at org.eclipse.tptp.monitoring.logui.internal.actions.ImportLogAction.run(ImportLogAction.java:53) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:545) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:490) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:402) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3673) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3284) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2365) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2329) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2204) at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:497) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:436) at org.eclipse.equinox.launcher.Main.run(Main.java:1162) at org.eclipse.equinox.launcher.Main.main(Main.java:1137) Caused by: org.eclipse.emf.ecore.xmi.PackageNotFoundException: Package with uri 'null' not found. (file:/D:/test.logsxml, 2, 10) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectByType(XMLHandler.java:1150) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createTopObject(XMLHandler.java:1244) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XMLHandler.java:880) at org.eclipse.emf.ecore.xmi.impl.XMIHandler.processElement(XMIHandler.java:80) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:863) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:627) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source) at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:180) ... 54 more Created attachment 66473 [details] Attached the patch for comment #24. Hello Eugene, I resolved the issue and attached the patch for the problem in comment #24. Modules: org.eclipse.tptp.monitoring.logui Please review the patch and let me know if you have any further changes. Target i4, as it does not block i3 test pass. (In reply to comment #24) > 1. launch in a clean workspace > 2. open log import wizard > 3. add an apache access log, also add an error only import filter > 4. export the logset > 5. launch in another workspace > 6. use the logset to import the apacch access log > 7. all events get imported. > If user select edit on log file to be imported (stpe 6), the filter will be applied and only error logs are imported. approved by project lead and patch submitted to CVS. verified |
When export the logset, import filters are exported as elements shown below ...... <filter name="error_filter" type="org.eclipse.hyades.log.ui.ImportLogFilterType" /> Only the name of the filter above is exported. The filter itself stays in the workspace. The filter is useless if user uses this logset in another workspace.