Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ResourceException during LibraryClasspathContainer initialization #3181

Closed
briandealwis opened this issue Jun 26, 2018 · 4 comments · May be fixed by #3180
Closed

ResourceException during LibraryClasspathContainer initialization #3181

briandealwis opened this issue Jun 26, 2018 · 4 comments · May be fixed by #3180

Comments

@briandealwis
Copy link
Member

As a follow-on to #3180, I noticed the following exception being logged.

Jun 26, 2018 1:32:02 PM com.google.cloud.tools.eclipse.appengine.libraries.repository.LibraryClasspathContainerResolverService resolveContainer
SEVERE: Could not resolve container: com.google.cloud.tools.eclipse.appengine.libraries/appengine-api
org.eclipse.core.internal.resources.ResourceException: The resource tree is locked for modifications.
	at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:119)
	at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:2188)
	at org.eclipse.core.internal.resources.Folder.create(Folder.java:90)
	at org.eclipse.core.internal.resources.Folder.create(Folder.java:121)
	at com.google.cloud.tools.eclipse.appengine.libraries.persistence.LibraryClasspathContainerSerializer$DefaultStateLocationProvider.getFile(LibraryClasspathContainerSerializer.java:215)
	at com.google.cloud.tools.eclipse.appengine.libraries.persistence.LibraryClasspathContainerSerializer$DefaultStateLocationProvider.getContainerStateFile(LibraryClasspathContainerSerializer.java:202)
	at com.google.cloud.tools.eclipse.appengine.libraries.persistence.LibraryClasspathContainerSerializer.getContainerStateFile(LibraryClasspathContainerSerializer.java:184)
	at com.google.cloud.tools.eclipse.appengine.libraries.persistence.LibraryClasspathContainerSerializer.saveContainer(LibraryClasspathContainerSerializer.java:87)
	at com.google.cloud.tools.eclipse.appengine.libraries.repository.LibraryClasspathContainerResolverService.resolveContainer(LibraryClasspathContainerResolverService.java:173)
	at com.google.cloud.tools.eclipse.appengine.libraries.LibraryClasspathContainerInitializer.initialize(LibraryClasspathContainerInitializer.java:86)
	at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:3114)
	at org.eclipse.jdt.internal.core.JavaModelManager$10.run(JavaModelManager.java:3020)
	at org.eclipse.jdt.internal.core.JavaModelManager.initializeAllContainers(JavaModelManager.java:3058)
	at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:2058)
	at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:3568)
	at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2986)
	at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:3150)
	at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2255)
	at org.eclipse.jdt.internal.core.DeltaProcessingState.getRootInfos(DeltaProcessingState.java:310)
	at org.eclipse.jdt.internal.core.DeltaProcessingState.initializeRoots(DeltaProcessingState.java:255)
	at org.eclipse.jdt.internal.core.DeltaProcessor.processResourceDelta(DeltaProcessor.java:1926)
	at org.eclipse.jdt.internal.core.DeltaProcessor.resourceChanged(DeltaProcessor.java:2128)
	at org.eclipse.jdt.internal.core.DeltaProcessingState.resourceChanged(DeltaProcessingState.java:473)
	at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:299)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:289)
	at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:152)
	at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:374)
	at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1469)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2253)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2267)
	at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:128)
	at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)

This occurs in the following code:

        JavaCore.setClasspathContainer(
            containerPath,
            new IJavaProject[] {javaProject},
            new IClasspathContainer[] {container},
            subMonitor.newChild(1));
        serializer.saveContainer(javaProject, container);
        for (Job job : sourceAttacherJobs) {
          job.schedule();
        }

We haven't noticed this problem previously because the classpath container was successfully resolved and set on the project.

@briandealwis
Copy link
Member Author

I should note that this occurred during the upgrading process as part of ImportNativeAppEngineStandardProjectTest where we coalesce our older containers into the new single master container.

I don't know that we can detect this situation. There are two solutions that I can think of:

  1. Wrap the saveContainer() within a try-catch, with the expectation that the container will be re-resolved in another situation (i.e., outside of a workspace notification) and so be able to write out the serialized container state.

  2. Punt the container state serialization to a job. The danger is that we might might modify the container definition in the meantime so that the job would write out stale data.

@briandealwis
Copy link
Member Author

Oops, wasn't finished. I should note that we've been doing (1) implicitly since we were silently swallowing the exception.

@chanseokoh
Copy link
Contributor

If the container is expected to be resolved eventually or frequently enough, I think (1) isn't a bad idea (also considering we've been doing so)?

@diegomarquezp
Copy link
Contributor

Closing as not planned since GAE with Java 8 is not supported. cc: @blakeli0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants