Bugzilla – Full Text Bug Listing
| Summary: | WorkspaceSynchronizer.getFile(Resource) leads to CoreException | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF Services | Reporter: | Martin Fluegge <martin.fluegge> | ||||||
| Component: | Transaction | Assignee: | EMF Services Transaction inbox <emfservices.transaction-inbox> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | ahunter.eclipse, bjoern.sundin, cedric.dumoulin, christoph, kofeka, orgler, sebastien.gerard, stepper | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Martin Fluegge
Created attachment 186221 [details]
Patch v1
I attached a patch which could solve the problem. At least it does this for my case.
;)
Cheers,
Martin
Created attachment 193355 [details]
Patch v2
I noticed that in my previous patch I forget to include the dependency changes in the Manifest.MF. The new patch now contains the corrected version. Sorry for that.
Since the topic is open for a while I would like the draw the attention to it again. It would be nice if someone from the EMF Transaction could comment on this bug.
Thx :)
Hi Anthony, I added you to this bug in the hope that you are the right one to have a look at it (saw that you are the last active committer on EMF Transaction). The bug is around for a while without any reaction. It would be nice if you could have a look at the attached patch and make some comments about it, or even accept it :) Thanks in advance. Cheers, Martin What is Dawn’s GMF extension? Is this blocking something or is it just an annoying error in the log 100s of times? Hi Anthony, Thanks for your response. (In reply to comment #4) > What is Dawn’s GMF extension? Dawn is the UI integration part of CDO (http://wiki.eclipse.org/Dawn). It provides an integration layer between CDO and EMF based framework such as GMF to make the collaborative. >Is this blocking something or is it just an annoying error in the log 100s of times? It is not blocking anything but leads to a blown up log file and slows down the performance of the editor. Hi, here is Sebastien the project lead of Papyrus, the UML graphical editor of Modelling MDT. It is exactly the same thing for us, and the result is feezing Papyrus some time that will be not accepted by users... I do thank you in advance if this bug may be solved quite soon for RC4 it would be perfect. Cheers... Sébastien. Hi Sebastien, just out of curiosity: Does the attched patch solve your problem, too? The Papyrus team has tried the patch, and it works. But, personally I don't think it is a good idea to return an empty array when the URI is not found. If the URI is not found, this means there is an error, and this error should be reported with an exception. The problem with the actual implementation is that a silent exception (not declared in the method signature) is thrown, so callers of the method are not obliged to catch this error. A better solution should be to throw a not silent exception, and let the callers deal with the exception. If you return an empty array, you can't detect easily if the returned values are corrects, partially correct (a file is missing), or bad. This could lead to problems that will be propagated to other part of your code, and will be difficult to understand. As far as I remember to actual problem (unbelievable amount of traces in the log file) comes from the FileSystemResourceManager.allPathsForLocationNonCanonical() method which simply catches the CoreException, writes it to the log file and than returns an empty list. So what is returned to the the WorkSpaceSynchronizer.getFile() is this empty list. This leads to returning null to the caller. My proposed patch just checks whether the call of WorkspaceRoot.findFilesForLocationURI() is necessary (if not it would trace the exception due to the catch in FileSystemResourceManager) and if not it just avoids the call and thus the exception is not written to the log file.The contract of the method WorkSpaceSynchronizer.getFile()) stays the same. I chose this way because we cannot declare an additional exception to this method, because this would break any caller of this method, which for example would mean any generated GMF editor. So in addition GMF codegen must be changed to generate code which handles this exception and any existing GMF editor must be changed accordingly. I think this is not solution. I am not sure whether I got what the problem for Papyrus is, because currently you also do not have a way to track that an error occurred, because getFile() simply returns null on an unregistered files system. My patch does not change this behaviour but just suppresses the print out of the exception. But I have to admit that it has been a while since I last looked at this problem. Since I am no EMF Transaction committer I am not that familiar with the code. Anthony, do you have a better solution to solve this problem? Hello, we have the same issue on our Business Process Modeling Tool Horus. We're loading/saving our models through our custom resourceManager. For us - as for the CDO-users - we're getting tons of errors in our log complaining about an unknown filesystem-scheme. The patch provided by Martin solves this issue. I would propose to bring this into the mainline as soon as possible. Maybe there are better solutions (it seems a bit weird to me to have a direct dependency from EMF to EFS), but the provided patch is in my opinion better than the errors we have at the moment :-( - Johannes Hi all, did the patch find its way into the Indigo release? Because we're also getting our error log clogged with this core exception. It doesn't seem to have any other negative effects, just as described here. Regards, chris > did the patch find its way into the Indigo release?
Unfortunatelly not. :(
+1 for having this one in Indigo SR1
I encounter the same problem attempting to upgrade my application to Indigo using EMF/GMF and a HibernateResource (Teneo). Resource URI: hibernate://dsname=mydatabase org.eclipse.core.runtime.CoreException: No file system is defined for scheme: hibernate at org.eclipse.core.internal.filesystem.Policy.error(Policy.java:55) at org.eclipse.core.internal.filesystem.Policy.error(Policy.java:50) at org.eclipse.core.internal.filesystem.InternalFileSystemCore.getFileSystem(InternalFileSystemCore.java:65) at org.eclipse.core.internal.filesystem.InternalFileSystemCore.getStore(InternalFileSystemCore.java:107) at org.eclipse.core.filesystem.EFS.getStore(EFS.java:470) at org.eclipse.core.internal.localstore.FileSystemResourceManager.findLinkedResourcesPaths(FileSystemResourceManager.java:142) at org.eclipse.core.internal.localstore.FileSystemResourceManager.allPathsForLocationNonCanonical(FileSystemResourceManager.java:124) at org.eclipse.core.internal.localstore.FileSystemResourceManager.allPathsForLocation(FileSystemResourceManager.java:62) at org.eclipse.core.internal.localstore.FileSystemResourceManager.allResourcesFor(FileSystemResourceManager.java:216) at org.eclipse.core.internal.resources.WorkspaceRoot.findFilesForLocationURI(WorkspaceRoot.java:113) at org.eclipse.core.internal.resources.WorkspaceRoot.findFilesForLocationURI(WorkspaceRoot.java:104) at org.eclipse.emf.workspace.util.WorkspaceSynchronizer.getFile(WorkspaceSynchronizer.java:357) at org.eclipse.emf.workspace.util.WorkspaceSynchronizer.getFile(WorkspaceSynchronizer.java:270) at org.eclipse.gmf.runtime.emf.type.core.commands.EditElementCommand.getAffectedFiles(EditElementCommand.java:86) at org.eclipse.gmf.runtime.emf.type.core.commands.EditElementCommand.<init>(EditElementCommand.java:67) at org.eclipse.gmf.runtime.emf.type.core.commands.CreateElementCommand.<init>(CreateElementCommand.java:69) at ch.bergauer.rcp.amset.project.data.nodes.amset.diagram.edit.commands.GateLsaCreateCommand.<init>(GateLsaCreateCommand.java:22) at ch.bergauer.rcp.amset.project.data.nodes.amset.diagram.edit.policies.EnvironmentItemSemanticEditPolicy.getCreateCommand(EnvironmentItemSemanticEditPolicy.java:61) at ch.bergauer.rcp.amset.project.data.nodes.amset.diagram.edit.policies.NodeprojectdataBaseItemSemanticEditPolicy.getSemanticCommandSwitch(NodeprojectdataBaseItemSemanticEditPolicy.java:183) at ch.bergauer.rcp.amset.project.data.nodes.amset.diagram.edit.policies.NodeprojectdataBaseItemSemanticEditPolicy.getSemanticCommand(NodeprojectdataBaseItemSemanticEditPolicy.java:136) at org.eclipse.gmf.runtime.diagram.ui.editpolicies.SemanticEditPolicy.getCommand(SemanticEditPolicy.java:69) at ch.bergauer.rcp.amset.project.data.nodes.amset.diagram.edit.policies.NodeprojectdataBaseItemSemanticEditPolicy.getCommand(NodeprojectdataBaseItemSemanticEditPolicy.java:101) at org.eclipse.gef.editparts.AbstractEditPart.getCommand(AbstractEditPart.java:502) at org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPart.access$1(GraphicalEditPart.java:1) at org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPart$1.run(GraphicalEditPart.java:482) at org.eclipse.emf.transaction.impl.TransactionalEditingDomainImpl.runExclusive(TransactionalEditingDomainImpl.java:328) at org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPart.getCommand(GraphicalEditPart.java:477) at org.eclipse.gmf.runtime.diagram.ui.editpolicies.CreationEditPolicy.getCreateElementAndViewCommand(CreationEditPolicy.java:340) at org.eclipse.gmf.runtime.diagram.ui.editpolicies.CreationEditPolicy.getCommand(CreationEditPolicy.java:87) at org.eclipse.gef.editparts.AbstractEditPart.getCommand(AbstractEditPart.java:502) at org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPart.access$1(GraphicalEditPart.java:1) at org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPart$1.run(GraphicalEditPart.java:482) at org.eclipse.emf.transaction.impl.TransactionalEditingDomainImpl.runExclusive(TransactionalEditingDomainImpl.java:328) at org.eclipse.gmf.runtime.diagram.ui.editparts.GraphicalEditPart.getCommand(GraphicalEditPart.java:477) at org.eclipse.gmf.runtime.diagram.ui.tools.PopupBarTool.getCommand(PopupBarTool.java:107) at org.eclipse.gmf.runtime.diagram.ui.tools.AbstractPopupBarTool.isCommandEnabled(AbstractPopupBarTool.java:96) at org.eclipse.gmf.runtime.diagram.ui.editpolicies.PopupBarEditPolicy$PopupBarLabelHandle.calculateEnabled(PopupBarEditPolicy.java:263) at org.eclipse.gmf.runtime.diagram.ui.editpolicies.PopupBarEditPolicy$PopupBarLabelHandle.<init>(PopupBarEditPolicy.java:170) at org.eclipse.gmf.runtime.diagram.ui.editpolicies.PopupBarEditPolicy.initPopupBars(PopupBarEditPolicy.java:780) at org.eclipse.gmf.runtime.diagram.ui.editpolicies.PopupBarEditPolicy.showDiagramAssistant(PopupBarEditPolicy.java:842) at org.eclipse.gmf.runtime.diagram.ui.editpolicies.DiagramAssistantEditPolicy$FocusListener.selectedStateChanged(DiagramAssistantEditPolicy.java:150) at org.eclipse.gef.editparts.AbstractEditPart.fireSelectionChanged(AbstractEditPart.java:436) at org.eclipse.gef.editparts.AbstractEditPart.setFocus(AbstractEditPart.java:1012) at org.eclipse.gef.ui.parts.GraphicalViewerImpl.handleFocusGained(GraphicalViewerImpl.java:123) at org.eclipse.gef.ui.parts.GraphicalViewerImpl$2.focusGained(GraphicalViewerImpl.java:276) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:139) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1058) at org.eclipse.swt.widgets.Control.sendFocusEvent(Control.java:2822) at org.eclipse.swt.widgets.Widget.wmSetFocus(Widget.java:2403) at org.eclipse.swt.widgets.Control.WM_SETFOCUS(Control.java:5152) at org.eclipse.swt.widgets.Canvas.WM_SETFOCUS(Canvas.java:448) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4598) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4972) at org.eclipse.swt.internal.win32.OS.SetFocus(Native Method) at org.eclipse.swt.widgets.Control.forceFocus(Control.java:1098) at org.eclipse.swt.widgets.Control.setSavedFocus(Control.java:3599) at org.eclipse.swt.widgets.Decorations.restoreFocus(Decorations.java:821) at org.eclipse.swt.widgets.Decorations.WM_ACTIVATE(Decorations.java:1651) at org.eclipse.swt.widgets.Shell.WM_ACTIVATE(Shell.java:2137) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4525) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341) at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1610) at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2061) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4972) at org.eclipse.swt.internal.win32.OS.PeekMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.PeekMessage(OS.java:3095) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3749) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at ch.bergauer.rcp.amset.Application.start(Application.java:31) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) at org.eclipse.equinox.launcher.Main.main(Main.java:1386) With the FileSystemResourceManager being the root of the problem here, shouldn't this be reassigned to core? I guess that would also increase the chance of getting this included in SR1 :) +1 This patch saved us time. And I agree with comment #9 of Martin Fluegge I have committed to R1_5_maintenance Will do a build over the next few days and get a build in Indigo SR1. (In reply to comment #16) > I have committed to R1_5_maintenance > > Will do a build over the next few days and get a build in Indigo SR1. This fix is in the indigo repository for SR1. |