Community
Participate
Working Groups
I haven't been able to reproduce it so far, but I saw the following trace showed up in my log. I think it's updating the classpath of all of the projects when the resource change event may already have a conflicting rule in place. !ENTRY org.eclipse.core.resources 4 2 2005-07-20 00:40:44.587 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.resources". !STACK 0 java.lang.IllegalArgumentException: Attempted to beginRule: R/, does not match outer scope rule: MultiRule[P/84046,P/antlr,P/commons-beanutils,P/commons-digester,P/commons-fileupload,P/commons-logging,P/commons-validator,P/D,P/Design,P/docs,P/DTDs,P/EclipseWTP,P/F,P/f2,P/Flexible003,P/fresh,P/FsingleModule,P/images,P/J0000,P/J2,P/j2eeWebProject0,P/jakarta-oro,P/jakarta-tomcat-5.5.4-jsp-examples] at org.eclipse.core.internal.runtime.Assert.isLegal(Assert.java:58) at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:117) at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:211) at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:81) at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:190) at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:96) at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:1674) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1714) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:782) at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath(JavaProject.java:2834) at org.eclipse.jdt.core.JavaCore$6.run(JavaCore.java:3951) at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:718) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1719) at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:3760) at org.eclipse.jdt.core.JavaCore.setClasspathContainer(JavaCore.java:3934) at org.eclipse.jdt.internal.launching.JREContainerInitializer.initialize(JREContainerInitializer.java:54) at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:1591) at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1040) at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:1326) at org.eclipse.jst.common.jdt.internal.classpath.FlexibleProjectContainer$Listener.resourceChanged(FlexibleProjectContainer.java:330) at org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:276) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1044) at org.eclipse.core.runtime.Platform.run(Platform.java:783) at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:270) at org.eclipse.core.internal.events.NotificationManager.handleEvent(NotificationManager.java:242) at org.eclipse.core.internal.resources.Workspace.broadcastEvent(Workspace.java:195) at org.eclipse.core.internal.resources.Project.close(Project.java:171) at org.eclipse.ui.actions.CloseResourceAction.invokeOperation(CloseResourceAction.java:169) at org.eclipse.ui.actions.WorkspaceAction.execute(WorkspaceAction.java:133) at org.eclipse.ui.actions.WorkspaceAction$2.runInWorkspace(WorkspaceAction.java:424) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76)
Hi - Are you adding a Job rule with the specific projects? Looks like jdt is using the workspace root, so this rule may need to include that.
Chuck, I am not sure why you assigned this to me. Did you mean to assign it to Nitin?
Looking at the stack again... do we want to open this against jdt? The platform is in the middle of a close resource action, and the container is just calling: JavaCore.getClasspathContainer() - which gets the rule conflict. Not sure why this should be illegal. I'll move to jdt.
Moving to Platform/Resources.
Closing a project uses a project-level scheduling rule. The call to JavaCore.getClasspathContainer() can actually modify resources, and in order to do that it uses the workspace root as the scheduling rule (and it has to). One cannot try to begin a rule that is more comprehensive than the current rule. Thus, calling that method from a resource change listener is not safe. Also, doing so from a PRE_CLOSE resource change listener is not valid either.
A similar issue in PDE: bug 94435.
Looks like the jdt team will consider a fix in 3.2.... *** This bug has been marked as a duplicate of 94764 ***
Bug 94764 is in Platform/Resources, not JDT, and is only about improving error reporting, so this problem will still occur even if that bug is fixed. It is wrong to call JavaCore.getClasspathContainer() from a PRE_CLOSE resource change listener, because it may create resources, and you are not allowed to do so from this type of resource change listener.
Ok Kostantin, looks like this is back to you again... JavaCore.getClasspathContainer() can't be called on the PRE_CLOSE event, so maybe listen for this in your FlexibleProjectContainer$Listener class?
Thanks for doing the legwork to investigate this. I committed the fix. Haven't released it as there are other changes in the plugin. This may or may not be in RC1.
Can't reproduce on 1.0rc4
