Comment 1 Ed Willink 2012-04-25 12:48:22 EDT

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)

Comment 2 Moritz Eysholdt 2012-04-25 12:52:50 EDT

Hi Ed, could you set a breakpoint on the exception and tell us what the type of the variable "context" is?

Comment 3 Ed Willink 2012-04-25 13:05:07 EDT

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

Comment 4 Moritz Eysholdt 2012-04-25 13:32:33 EDT

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?

Comment 5 Ed Willink 2012-04-25 13:39:09 EDT

(In reply to comment #4)
> Do you use the BuilderIntegrationFragment in your *.mwe2 file for that
> language?

Yes

Comment 6 Michael Vorburger 2012-06-06 13:48:08 EDT

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.

Comment 7 Sebastian Zarnekow 2012-06-06 14:35:39 EDT

(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.

Comment 8 Michael Vorburger 2012-06-08 11:29:22 EDT

> 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?

Comment 9 Michael Vorburger 2012-06-08 11:37:53 EDT

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

Comment 10 Ed Willink 2012-06-08 11:43:06 EDT

(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.

Comment 11 Sebastian Zarnekow 2012-06-08 11:45:11 EDT

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.

Comment 12 Michael Vorburger 2012-06-08 12:51:13 EDT

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.

Comment 13 Sebastian Zarnekow 2012-06-08 13:27:24 EDT

(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.

Comment 14 Michael Vorburger 2012-06-15 09:36:29 EDT

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.

Comment 15 Sven Efftinge 2012-11-14 05:35:49 EST

see comment 7

Comment 16 Ed Willink 2012-11-14 05:46:43 EST

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?

Comment 17 Michael Vorburger 2014-01-30 14:06:07 EST

> 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.