ResourceException during LibraryClasspathContainer initialization

[briandealwis]

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]

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]

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

[chanseokoh]

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]

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