Bugzilla – Full Text Bug Listing
| Summary: | IllegalStateException after saving programatically-modified Resource | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | mario <mario.wuendsch> | ||||
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> | ||||
| Status: | CLOSED WORKSFORME | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | ed, mike, moritz.eysholdt, ralf.heilek, sebastian.zarnekow | ||||
| Version: | 1.0.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | Macintosh | ||||||
| OS: | Mac OS X | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
mario
I'm seeing a rather similar exception on Juno M6+ (tmf-xtext-Update-N201204031826.zip) java.lang.IllegalStateException: Passed org.eclipse.xtext.resource.IResourceDescriptions not of type org.eclipse.xtext.resource.impl.ResourceSetBasedResourceDescriptions at org.eclipse.xtext.resource.containers.ResourceSetBasedAllContainersStateProvider.get(ResourceSetBasedAllContainersStateProvider.java:42) at org.eclipse.xtext.resource.containers.StateBasedContainerManager.getState(StateBasedContainerManager.java:67) at org.eclipse.xtext.resource.containers.StateBasedContainerManager.internalGetContainerHandle(StateBasedContainerManager.java:89) at org.eclipse.xtext.resource.containers.StateBasedContainerManager.getVisibleContainers(StateBasedContainerManager.java:48) at org.eclipse.xtext.resource.impl.DefaultResourceDescriptionManager.isAffected(DefaultResourceDescriptionManager.java:133) at org.eclipse.xtext.builder.clustering.ClusteringBuilderState.queueAffectedResources(ClusteringBuilderState.java:440) at org.eclipse.xtext.builder.clustering.ClusteringBuilderState.doUpdate(ClusteringBuilderState.java:257) at org.eclipse.xtext.builder.builderState.AbstractBuilderState.update(AbstractBuilderState.java:105) at org.eclipse.xtext.builder.impl.XtextBuilder.doBuild(XtextBuilder.java:158) at org.eclipse.xtext.builder.impl.XtextBuilder.incrementalBuild(XtextBuilder.java:141) at org.eclipse.xtext.builder.impl.XtextBuilder.build(XtextBuilder.java:91) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Hi Ed, could you set a breakpoint on the exception and tell us what the type of the variable "context" is? Created attachment 214547 [details] Variables at Breakpoint (In reply to comment #2) > Hi Ed, could you set a breakpoint on the exception and tell us what the type of > the variable "context" is? It's CurrentDescriptions as in the attached PNG Thx for the screen shot. I've improved the error message for that exception: http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/commit/?id=c999edc10408922645f1ff10cf7191efc1089adb Do you use the BuilderIntegrationFragment in your *.mwe2 file for that language? (In reply to comment #4) > Do you use the BuilderIntegrationFragment in your *.mwe2 file for that > language? Yes I've also just hit this one. IResourceDescriptions context is a CurrentDescriptions as well. Don't have a clear step-by-step scenario, but clearly this can happen and you might want to handle it somehow - just thought to let you know. (In reply to comment #6) > I've also just hit this one. IResourceDescriptions context is a > CurrentDescriptions as well. Don't have a clear step-by-step scenario, but > clearly this can happen and you might want to handle it somehow - just thought > to let you know. This happens if someone invokes a standalone setup in an equinox driven environment. > This happens if someone invokes a standalone setup in an equinox driven
Is that the only possibility, 100% sure? I'm still seeing it, when manually creating a new Xtext resource as soon as the Builder picks it up, in the Console of a "full blown IDE" (not test), even after having double check for any calls to *StandaloneSetup in the main plugin (which indeed we had earlier by mistake through a helper, now that's all in the tests plugin which is NOT ACTIVE in the launch config for the test IDE).
Let me know if there is any particular debugging we could do which would help nail this?
Not sure if this is of any help, but the CurrentDescriptions which you don't like in the ResourceSetBasedAllContainersStateProvider.java:42) has been created at org.eclipse.xtext.builder.clustering.ClusteringBuilderState.doUpdate(ClusteringBuilderState.java:260) : final CurrentDescriptions newState = new CurrentDescriptions(resourceSet, newData); here is the stack: Thread [Worker-2] (Suspended (breakpoint at line 42 in ResourceSetBasedAllContainersStateProvider)) ResourceSetBasedAllContainersStateProvider.get(IResourceDescriptions) line: 42 StateBasedContainerManager.getState(IResourceDescriptions) line: 67 StateBasedContainerManager.internalGetContainerHandle(IResourceDescription, IResourceDescriptions) line: 89 StateBasedContainerManager.getVisibleContainers(IResourceDescription, IResourceDescriptions) line: 48 DefaultResourceDescriptionManager.isAffected(Collection<Delta>, IResourceDescription, IResourceDescriptions) line: 133 ClusteringBuilderState.queueAffectedResources(Set<URI>, IResourceDescriptions, CurrentDescriptions, Collection<Delta>, BuildData, IProgressMonitor) line: 448 ClusteringBuilderState.doUpdate(BuildData, ResourceDescriptionsData, IProgressMonitor) line: 260 ClusteringBuilderState(AbstractBuilderState).update(BuildData, IProgressMonitor) line: 107 XtextBuilder.doBuild(ToBeBuilt, IProgressMonitor, IXtextBuilderParticipant$BuildType) line: 158 XtextBuilder.incrementalBuild(IResourceDelta, IProgressMonitor) line: 141 XtextBuilder.build(int, Map, IProgressMonitor) line: 91 BuildManager$2.run() line: 728 SafeRunner.run(ISafeRunnable) line: 42 BuildManager.basicBuild(int, IncrementalProjectBuilder, Map<String,String>, MultiStatus, IProgressMonitor) line: 199 BuildManager.basicBuild(IBuildConfiguration, int, IBuildContext, ICommand[], MultiStatus, IProgressMonitor) line: 239 BuildManager$1.run() line: 292 SafeRunner.run(ISafeRunnable) line: 42 BuildManager.basicBuild(IBuildConfiguration, int, IBuildContext, MultiStatus, IProgressMonitor) line: 295 BuildManager.basicBuildLoop(IBuildConfiguration[], IBuildConfiguration[], int, MultiStatus, IProgressMonitor) line: 351 BuildManager.build(IBuildConfiguration[], IBuildConfiguration[], int, IProgressMonitor) line: 374 AutoBuildJob.doBuild(IProgressMonitor) line: 143 AutoBuildJob.run(IProgressMonitor) line: 241 Worker.run() line: 54 (In reply to comment #8) > I'm still seeing it, ... even after having double check for > any calls to *StandaloneSetup in the main plugin You were not the only project at fault. OCL (Bug 381901) editors were also wrong. These are fixed in the latest builds that you can pick up from https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-tools-3.2-master/lastSuccessfulBuild/artifact/. You may indirectly have OCL editors via Papyrus. Check for any org.eclipse.ocl.examples.xtext.* plugins. Michael, the CurrentDescriptions are the expected ones. You may want to find the root cause if you can locate the code that creates an instance of the ResourceSetBasedAllContainersStateProvider within your eclipse. Ed, I've just removed OCL from launch config, and can still reproduce it.
Sebastian, not sure I understand you correctly, do you mean CurrentDescriptions are right, but ResourceSetBasedAllContainersStateProvider is wrong and it should be a ContainerStateProvider? I had a hard time debugging what @Inject private IAllContainersState.Provider stateProvider; into the StateBasedContainerManager, as setStateProvider() never gets called, Guice probably does the privateStringField.setAccessible(true) trick to inject it? Any tips how to debug this? BUT then I saw that all our grammar's model/src-gen/Abstract*RuntimeModule have this:
// contributed by org.eclipse.xtext.generator.builder.BuilderIntegrationFragment
public Class<? extends org.eclipse.xtext.resource.containers.IAllContainersState.Provider> bindIAllContainersState$Provider() {
return org.eclipse.xtext.resource.containers.ResourceSetBasedAllContainersStateProvider.class;
}
with just one of our model/src/*RuntimeModule also had this (done by a colleague not me) :
@Override
public Class<? extends Provider> bindIAllContainersState$Provider() {
return ContainerStateProvider.class;
}
but... ContainerStateProvider is in xtext.ui, which is normally not available in model?
If the ResourceSetBasedAllContainersStateProvider is the problem, how come Xtext generates that in model/src-gen/Abstract*RuntimeModule ?!
BTW: Is this Xtext Index persisted / saved / cached, or purely in-memory? I'm asking because I was wondering whether between workspace restarts anything could by "lying around" from previous problems.
(In reply to comment #12) > Sebastian, not sure I understand you correctly, do you mean CurrentDescriptions > are right, but ResourceSetBasedAllContainersStateProvider is wrong and it > should be a ContainerStateProvider? Yes > Any tips how to debug this? BUT then I saw that all our grammar's > model/src-gen/Abstract*RuntimeModule have this: That binding will and has to be overwritten by the ui module. Do you create an injector manually somewhere that uses only the runtime module? > > but... ContainerStateProvider is in xtext.ui, which is normally not available > in model? Not sure what you mean by 'model'. > BTW: Is this Xtext Index persisted / saved / cached, or purely in-memory? I'm > asking because I was wondering whether between workspace restarts anything > could by "lying around" from previous problems. The index is persistent in the workspace metadata on shutdown, otherwise exists only in memory. A clean build discards the complete index state. Sebastian - just a quick comment to say thank you for bearing with me through this above here... FYI we've meanwhile found (through setting a "Class level" breakpoint) that indeed we actually do *StandaloneSetup from Bundle-Activators... not sure why a colleague of mine did this but, it could be related to Bug 323572 for using Xtext in a Headless Eclipse Product we build. We'll look into how to change this, and find a better way. Thanks again. see comment 7 Since at least two teams have inadvertently invoked StandaloneSetup in an Equinox context, is it worth an EMFPlugin.IS_ECLIPSE_RUNNING test and a Console message to help developers abide by the API? > is it worth an EMFPlugin.IS_ECLIPSE_RUNNING test and a Console message to help developers abide by the API? +1 ... FYI I've just created https://bugs.eclipse.org/bugs/show_bug.cgi?id=427034 about that. |