Bug 76734 - [classpath] Attemp to lock workspace during container initialization
Summary: [classpath] Attemp to lock workspace during container initialization
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.3 M1   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-21 06:26 EDT by Gunnar Wagenknecht CLA
Modified: 2006-08-07 04:58 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gunnar Wagenknecht CLA 2004-10-21 06:26:15 EDT
We have a job that looks through a project to find all types inheriting from a 
specific class to build a model. For this purpose it uses 
IJavaProject#isOnClasspath. This job is executed with our own rule to prevent 
concurrency issues.

Sometimes we get an IllegalArgumentException "Attempted to beginRule: R/, does 
not match outer scope rule: My Loading Model Rule" while calling 
IJavaProject#isOnClasspath. The problem turns out to be a container 
initialization. JavaCore#setClasspathContainer wants to lock the complete 
workspace.

The problem we have now is what to do? We can't include the COMPLETE workspace 
rule into our own rule. Furthermore are API clients of 
IJavaProject#isOnClasspath expected to lock the whole workspace?

This is the detailed stack trace:

java.lang.IllegalArgumentException: Attempted to beginRule: R/, does not match 
outer scope rule: My Loading Model Rule
 at org.eclipse.core.internal.runtime.Assert.isLegal(Assert.java:58)
 at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:106)
 at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:200)
 at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:80)
 at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:170)
 at org.eclipse.core.internal.resources.WorkManager.checkIn
(WorkManager.java:95)
 at org.eclipse.core.internal.resources.Workspace.prepareOperation
(Workspace.java:1628)
 at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1668)
 at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation
(JavaModelOperation.java:744)
 at org.eclipse.jdt.internal.core.JavaProject.setRawClasspath
(JavaProject.java:2650)
 at org.eclipse.jdt.core.JavaCore$3.run(JavaCore.java:3433)
 at org.eclipse.jdt.internal.core.BatchOperation.executeOperation
(BatchOperation.java:34)
 at org.eclipse.jdt.internal.core.JavaModelOperation.run
(JavaModelOperation.java:700)
 at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1673)
 at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:3246)
 at org.eclipse.jdt.core.JavaCore.setClasspathContainer(JavaCore.java:3416)
 at org.eclipse.jdt.internal.launching.JREContainerInitializer.initialize
(JREContainerInitializer.java:51)
 at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer
(JavaModelManager.java:1261)
 at org.eclipse.jdt.internal.core.JavaModelManager.initializeAllContainers
(JavaModelManager.java:1226)
 at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer
(JavaModelManager.java:833)
 at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:1184)
 at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath
(JavaProject.java:1888)
 at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath
(JavaProject.java:1798)
 at org.eclipse.jdt.internal.core.JavaProject.isOnClasspath
(JavaProject.java:2130)
 at my.custom.code.MyRegistry.findMySpecialClassesInFolder()
Comment 1 Jerome Lanneluc CLA 2006-06-13 09:05:24 EDT
Classpath related operations now don't take any lock (see ChangeClasspathOperation#getSchedulingRule()).

Released for 3.3M1 in HEAD.
Comment 2 Frederic Fusier CLA 2006-08-07 04:58:02 EDT
Verified for 3.3 M1 using build I20060807-0010