Community
Participate
Working Groups
Is it possible that the problem for Bug 4239 affects other things in addition to the outline view. Here's my set up: File A has a function, and a class definition as follows: void foo() => comment this out { } class A { } file B has a function as follows: void fooB() { foo(); } When I comment out the function, foo, in file A, I get a series of ClassCast exception, as Xtext tries to validate and resolve all references in the DefaultResourceDescription for File B. If I comment out the call to foo() in File B, the resolve all references works fine without exception. It looks to me that the model and the document has gone out of sync, and when resolving references for foo() in File B, it's returning the wrong object type. In my example here, it's resolving to the class definition in File A. This causes a dialog to pop up every time I save the file B. I am not sure if it's my customization causing this problem, or some timing issue causing the model to go out of sync. Can you provide some insight as to why something like this would happen? !ENTRY org.eclipse.xtext.validation.CompositeEValidator 4 40000 2011-01-24 18:21:49.452 !MESSAGE Error executing EValidator !STACK 0 java.lang.ClassCastException: com.ibm.streams.studio.spleditor.core.spl.impl.CompositeDefImpl incompatible with com.ibm.streams.studio.toolkit.core.basetoolkit.ToolkitFunctionOrTypeRef at com.ibm.streams.studio.spleditor.core.spl.impl.LocalLiteralImpl.getRef(LocalLiteralImpl.java:117) at com.ibm.streams.studio.spleditor.core.spl.impl.LocalLiteralImpl.eGet(LocalLiteralImpl.java:158) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1021) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1013) at org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImpl.hasNext(EContentsEList.java:409) at org.eclipse.emf.ecore.util.EObjectValidator.validate_EveryReferenceIsContained(EObjectValidator.java:788) at org.eclipse.emf.ecore.util.EObjectValidator.validate_EveryDefaultConstraint(EObjectValidator.java:361) at org.eclipse.emf.ecore.util.EObjectValidator$DynamicEClassValidator.validate(EObjectValidator.java:1426) at org.eclipse.emf.ecore.util.EObjectValidator$DynamicEClassValidator.validate(EObjectValidator.java:1429) at org.eclipse.emf.ecore.util.EObjectValidator$DynamicEClassValidator.validate(EObjectValidator.java:1429) at org.eclipse.emf.ecore.util.EObjectValidator$DynamicEClassValidator.validate(EObjectValidator.java:1429) at org.eclipse.emf.ecore.util.EObjectValidator.validate(EObjectValidator.java:339) at org.eclipse.xtext.validation.CompositeEValidator.validate(CompositeEValidator.java:119) at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:165) at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:143) at org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:36) at org.eclipse.emf.ecore.util.Diagnostician.doValidateContents(Diagnostician.java:180) at org.eclipse.xtext.validation.CancelableDiagnostician.doValidateContents(CancelableDiagnostician.java:48) at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:168) at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:143) at org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:36) at org.eclipse.emf.ecore.util.Diagnostician.doValidateContents(Diagnostician.java:180) at org.eclipse.xtext.validation.CancelableDiagnostician.doValidateContents(CancelableDiagnostician.java:48) at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:168) at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:143) at org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:36) at org.eclipse.emf.ecore.util.Diagnostician.doValidateContents(Diagnostician.java:184) at org.eclipse.xtext.validation.CancelableDiagnostician.doValidateContents(CancelableDiagnostician.java:48) at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:168) at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:143) at org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:36) at org.eclipse.emf.ecore.util.Diagnostician.doValidateContents(Diagnostician.java:184) at org.eclipse.xtext.validation.CancelableDiagnostician.doValidateContents(CancelableDiagnostician.java:48) at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:168) at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:143) at org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:36) at org.eclipse.emf.ecore.util.Diagnostician.doValidateContents(Diagnostician.java:180) at org.eclipse.xtext.validation.CancelableDiagnostician.doValidateContents(CancelableDiagnostician.java:48) at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:168) at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:143) at org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:36) at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:126) at org.eclipse.xtext.validation.ResourceValidatorImpl.validate(ResourceValidatorImpl.java:103) at com.ibm.streams.studio.spleditor.ui.SPLResourceValidator.validate(SPLResourceValidator.java:31) at org.eclipse.xtext.ui.editor.validation.ValidationJob$1.exec(ValidationJob.java:79) at org.eclipse.xtext.ui.editor.validation.ValidationJob$1.exec(ValidationJob.java:1) at org.eclipse.xtext.util.concurrent.IStateAccess$AbstractImpl.readOnly(IStateAccess.java:40) at org.eclipse.xtext.ui.editor.model.XtextDocument.readOnly(XtextDocument.java:70) at org.eclipse.xtext.ui.editor.validation.ValidationJob.createIssues(ValidationJob.java:75) at org.eclipse.xtext.ui.editor.validation.ValidationJob.run(ValidationJob.java:64) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) java.lang.ClassCastException: com.ibm.streams.studio.spleditor.core.spl.impl.CompositeDefImpl incompatible with com.ibm.streams.studio.toolkit.core.basetoolkit.ToolkitFunctionOrTypeRef at com.ibm.streams.studio.spleditor.core.spl.impl.LocalLiteralImpl.getRef(LocalLiteralImpl.java:117) at com.ibm.streams.studio.spleditor.core.spl.impl.LocalLiteralImpl.eGet(LocalLiteralImpl.java:158) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1021) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1013) at org.eclipse.emf.ecore.util.EContentsEList$FeatureIteratorImpl.hasNext(EContentsEList.java:409) at org.eclipse.emf.ecore.util.EcoreUtil.resolveCrossReferences(EcoreUtil.java:307) at org.eclipse.emf.ecore.util.EcoreUtil.resolveAll(EcoreUtil.java:287) at org.eclipse.xtext.resource.impl.DefaultResourceDescription.getImportedNames(DefaultResourceDescription.java:97) at org.eclipse.xtext.resource.impl.DefaultResourceDescriptionManager.getImportedNames(DefaultResourceDescriptionManager.java:97) at org.eclipse.xtext.resource.impl.DefaultResourceDescriptionManager.isAffected(DefaultResourceDescriptionManager.java:93) at org.eclipse.xtext.ui.editor.DirtyStateEditorSupport.isReparseRequired(DirtyStateEditorSupport.java:354) at org.eclipse.xtext.ui.editor.DirtyStateEditorSupport$UpdateEditorStateJob$1.exec(DirtyStateEditorSupport.java:120) at org.eclipse.xtext.ui.editor.DirtyStateEditorSupport$UpdateEditorStateJob$1.exec(DirtyStateEditorSupport.java:1) at org.eclipse.xtext.util.concurrent.IStateAccess$AbstractImpl.readOnly(IStateAccess.java:40) at org.eclipse.xtext.ui.editor.model.XtextDocument.readOnly(XtextDocument.java:70) at org.eclipse.xtext.ui.editor.DirtyStateEditorSupport$UpdateEditorStateJob.run(DirtyStateEditorSupport.java:113) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
I think this is a race condition. When the exception happens, the validator / builder state tries to resolve all references. It was able to resolve references successfully to the correct EObjectDescription. When I look at the EObjectDescription, its fragment field is linked to the old location in the file. After this processing is done, the following happens to update the fragments in the EObjectDescription: Thread [Worker-21] (Suspended (breakpoint at line 160 in EObjectDescriptionImpl)) owns: PersistableResourceDescriptionsImpl (id=4897) EObjectDescriptionImpl.setFragment(String) line: 160 BuilderStateUtil.create(IEObjectDescription) line: 61 BuilderStateUtil.create(IResourceDescription) line: 31 PersistableResourceDescriptionsImpl.createNew(Delta, Set<URI>) line: 84 PersistableResourceDescriptionsImpl.doUpdate(ResourceSet, Set<URI>, Set<URI>, Map<URI,IResourceDescription>, IProgressMonitor) line: 60 PersistableResourceDescriptionsImpl.doUpdate(ResourceSet, Set, Set, Map, IProgressMonitor) line: 1 PersistableResourceDescriptionsImpl(AbstractBuilderState).update(ResourceSet, Set<URI>, Set<URI>, IProgressMonitor) line: 111 XtextBuilder.doBuild(ToBeBuilt, IProgressMonitor, IXtextBuilderParticipant$BuildType) line: 148 XtextBuilder.incrementalBuild(IResourceDelta, IProgressMonitor) line: 133 XtextBuilder.build(int, Map, IProgressMonitor) line: 86 BuildManager$2.run() line: 629 SafeRunner.run(ISafeRunnable) line: 42 BuildManager.basicBuild(int, IncrementalProjectBuilder, Map, MultiStatus, IProgressMonitor) line: 172 BuildManager.basicBuild(IProject, int, ICommand[], MultiStatus, IProgressMonitor) line: 203 BuildManager$1.run() line: 255 SafeRunner.run(ISafeRunnable) line: 42 BuildManager.basicBuild(IProject, int, MultiStatus, IProgressMonitor) line: 258 BuildManager.basicBuildLoop(IProject[], IProject[], int, MultiStatus, IProgressMonitor) line: 311 BuildManager.build(int, IProgressMonitor) line: 343 AutoBuildJob.doBuild(IProgressMonitor) line: 144 AutoBuildJob.run(IProgressMonitor) line: 242 Worker.run() line: 54 It seems to me that the order of this is incorrect. Shouldn't the builder be run first, update the fragment, and then do the validation ? Please let me know if you need additional information to debug this.
Perhaps I am wrong... I am also seeing that all these things can be run at the same time, or the fragement can get updated before the validation jobs. But I still get into this class cast exception because the fragment is pointing to the old location.
What kind of customizations have you done?
(In reply to comment #3) > What kind of customizations have you done? I have customized the local scope provider, where I have caching implemented. I commented out my caching code, and still saw this exception. I also have a custom global scope provider. In there, I have customized the #createContainerScopeWithContext... where I provided my own FilterUriContainer to get around a NPE that I previously reported. In the global scope provider, I have also customized it such that it will look for content from an external index if the element is not found in in the resource descriptions.
Hi Samantha, please make sure that your FilterUriContainer works as expected. Its original implementation was introduced to avoid these CCEs.
(In reply to comment #5) > Hi Samantha, > > please make sure that your FilterUriContainer works as expected. Its original > implementation was introduced to avoid these CCEs. Hello, I backed out the changed for the customized FilterUriContainer, and still experienced the same problem with the default implementation. I am not sure I understand the use of the FilterUriContainer very well, to determine if that is causing problems... or how to look for things that may cause problems. Can you provide some insight as to go about debugging this? Thanks... Samantha
Samantha, is this one still an issue for you?
Ping (and lowering the severity)
closing this, because there was no feedback.
