Community
Participate
Working Groups
Build ID: M20070212-1330 Steps To Reproduce: 1. Delete or refactor a resource Problem: "Resouce does not exist" message is printed in Error log. Here's the comments added by Hiroshi Tsuji from the original defect: --------------------------- We need to have Eclipse add a check that the resource being decorated exists before passing it to decorators This fix would involve adding a call to IResource.exists() in org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(). This would avoid individual decorators from causing the exception in most cases when the resource no longer exists. This case can apparently occur when the user deletes resources while the decorator thread is running. More information: If you need more information please contact mandylh@ca.ibm.com or htsuji@ca.ibm.com.
I am appending the original problem description. Although the steps to reproduce are specific to our adopting product, you can see that a file is being deleted (and possibly other associated files, as well) in step 3. The exception stack trace is also below. I realize that the ResourceException is caused by a decorator that is not supplied by Eclipse, and could be fixed in the decorator code by checking if the file exists. However, that decorator also is not provided by our product. It could become difficult for us to track down all providers of all decorators that are causing a similar exception, when it appears that a check for the existence of the file in the decorator thread would prevent it for all decorators. Is there a reason why a decorator might want to receive a recently deleted file, and if so, are all deleted files passed to a decorator? - - - - - Steps to reproduce: 1) Add a new BSM; 2) Add a new state to the BSM, Save the changes and close the edtior; 3) Wait until the "Building workspace" process completed, delete the BSM from the BI view; Problem: Exception is reported in the Error log: org.eclipse.core.internal.resources.ResourceException: Resource /Module1/gg.sacl does not exist. at org.eclipse.core.internal.resources.Resource.checkExists(Resource.java:311) at org.eclipse.core.internal.resources.Resource.checkAccessible(Resource.java:187) at org.eclipse.core.internal.resources.Resource.getPersistentProperty(Resource.java:997) at com.ibm.correlation.rulemodeler.act.presentation.ACTLResourceState.decorate(Unknown Source) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:253) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:71) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:843) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:336) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:322) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:338) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:308) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
You can work around this yourself by checking if the resource exists. I am reluctant to consider this change as adding arbitrary filtering may be breaking another decorator that does want to work in that case. ACTLResourceState should do this check.
As I mentioned, we do not own the decorator. I also suspect that files are not passed to decorators when they are deleted. If this is true, it would be rather arbitrary what deleted files a decorator could expect to see (e.g. only those that are deleted while the decorator thread is running). As a result, any code that a decorator provides specifically to run on deleted files, such as clean-up code, would not run predictably anyway. So unless my premise of not receiving all deleted files is false, I can't see that any decorator could be doing anything useful with deleted files, except to ignore them. However, I understand your reluctance to change code that is not causing any real breakage.
I realize that it is a bit of a wild cse but say someone chose not to removed deleted files from a view but had a "deleted" decorator? I don;t expect that this is the case but every time I assert that something would never happen I find someone who does. I think the best we can do is log a bug to the owner of the decorator.
Oleg is now responsible for watching the [Decorators] category.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
