Skip to main content


Eclipse Community Forums

      Home
Home » Modeling » TMF (Xtext) » Exception when accessing xtext index
Exception when accessing xtext index [message #1760763] Tue, 02 May 2017 12:38 Go to next message
Eclipse UserFriend
My validator uses the reference index in order to omit parsing each recourse in the workspace:

@Inject
IContainer.Manager containerManager;
@Inject
ResourceDescriptionsProvider resourceDescriptionsProvider;

private def Iterable<IReferenceDescription> getReferenceDescriptionsOfType(EObject object, EReference eReference) {
		return object.getReferenceDescriptions().filter[it.EReference == eReference]
}

private def Iterable<IReferenceDescription> getReferenceDescriptions(EObject object) {
		return object.getResourceDescriptions().map[referenceDescriptions].flatten()
}

private def Iterable<IResourceDescription> getResourceDescriptions(EObject object) {
		return object.visibleContainers.map[resourceDescriptions].flatten()
	}

private def List<IContainer> getVisibleContainers(EObject object) {
		val index = resourceDescriptionsProvider.getResourceDescriptions(object.eResource())
		val resourceDescription = index.getResourceDescription(object.eResource().URI)
		return containerManager.getVisibleContainers(resourceDescription, index)
}


It works fine when applied to individual model elements. But when I trigger the workspace rebuild, I get a lot of these weird exceptions, yield when accessing to referenceDescriptions:

1661339 [Worker-1] ERROR org.eclipse.xtext.builder.clustering.CopiedResourceDescription  - java.lang.IllegalStateException: getReferenceDescriptions platform:/resource/test/onboardnet/ASP_R.fbdl
java.lang.IllegalStateException: getReferenceDescriptions platform:/resource/test/onboardnet/ASP_R.fbdl
	at org.eclipse.xtext.builder.clustering.CopiedResourceDescription.getReferenceDescriptions(CopiedResourceDescription.java:84)
	at MyValidator.lambda$2(MyValidator.java:77)
	at org.eclipse.xtext.xbase.lib.internal.FunctionDelegate.apply(FunctionDelegate.java:42)
	at com.google.common.collect.Iterators$8.transform(Iterators.java:794)
	at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
	at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
	at com.google.common.collect.Iterators$5.hasNext(Iterators.java:543)
	at com.google.common.collect.Iterators$7.computeNext(Iterators.java:645)
	at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
	at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
	at com.google.common.collect.Iterators$7.computeNext(Iterators.java:645)
	at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
	at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
	at com.google.common.collect.Iterators.size(Iterators.java:186)
	at com.google.common.collect.Iterables.size(Iterables.java:108)
	at org.eclipse.xtext.xbase.lib.IterableExtensions.size(IterableExtensions.java:471)
	at MyValidator.lambda$0(MyValidator.java:56)
	at java.lang.Iterable.forEach(Iterable.java:75)
	at MyValidator.validateModel(MyValidator.java:62)
	at MyValidator.checkNormalExtensionValidators(MyValidator.java:133)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.eclipse.xtext.validation.AbstractDeclarativeValidator$MethodWrapper.invoke(AbstractDeclarativeValidator.java:118)
	at org.eclipse.xtext.validation.AbstractDeclarativeValidator.internalValidate(AbstractDeclarativeValidator.java:312)
	at org.eclipse.xtext.validation.AbstractInjectableValidator.validate(AbstractInjectableValidator.java:71)
	at org.eclipse.xtext.validation.CompositeEValidator.validate(CompositeEValidator.java:151)
	at org.eclipse.emf.ecore.util.Diagnostician.doValidate(Diagnostician.java:171)
	at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:158)
	at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:137)
	at org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:39)
	at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:120)
	at org.eclipse.xtext.validation.ResourceValidatorImpl.validate(ResourceValidatorImpl.java:146)
	at org.eclipse.xtext.validation.ResourceValidatorImpl.validate(ResourceValidatorImpl.java:124)
	at org.eclipse.xtext.validation.ResourceValidatorImpl.validate(ResourceValidatorImpl.java:90)
	at org.eclipse.xtext.ui.validation.DefaultResourceUIValidatorExtension.addMarkers(DefaultResourceUIValidatorExtension.java:60)
	at org.eclipse.xtext.ui.validation.DefaultResourceUIValidatorExtension.updateValidationMarkers(DefaultResourceUIValidatorExtension.java:46)
	at org.eclipse.xtext.builder.builderState.MarkerUpdaterImpl.processDelta(MarkerUpdaterImpl.java:93)
	at org.eclipse.xtext.builder.builderState.MarkerUpdaterImpl.updateMarkers(MarkerUpdaterImpl.java:63)
	at org.eclipse.xtext.builder.builderState.AbstractBuilderState.updateMarkers(AbstractBuilderState.java:82)
	at org.eclipse.xtext.builder.clustering.ClusteringBuilderState.doUpdate(ClusteringBuilderState.java:283)
	at org.eclipse.xtext.builder.builderState.AbstractBuilderState.update(AbstractBuilderState.java:116)
	at org.eclipse.xtext.builder.impl.XtextBuilder.doBuild(XtextBuilder.java:287)
	at org.eclipse.xtext.builder.impl.XtextBuilder.fullBuild(XtextBuilder.java:319)
	at org.eclipse.xtext.builder.impl.XtextBuilder.build(XtextBuilder.java:155)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)


Why does this happen and how could I fix it?

PS: The Xtext version is 2.10.
Re: Exception when accessing xtext index [message #1760851 is a reply to message #1760763] Wed, 03 May 2017 11:40 Go to previous messageGo to next message
Eclipse UserFriend
The validation may run in a phase that not all reference descriptions are build
Thus you cannot do that


If you want to use validation based on reference descriptions
You should move validation to the builder participant

Depending on what you do you can
Alternatively store some bits in the index entries (ieobjectdescription)
And use these bits inside the validator

(Depends on what you actually validate and how your naming conventions and scoping look like)
Re: Exception when accessing xtext index [message #1760858 is a reply to message #1760851] Wed, 03 May 2017 12:35 Go to previous messageGo to next message
Eclipse UserFriend
Thanks for reply, Christian!

My settings is: There are elements of type A which may reference to elements of type B. The instances of A'S and B's are wildy distributed over files in the workspace, but one file may not contain both, A and B, because they are defined in separate grammars.

Now the requirement is that at most one A may reference any B. So a naive approach would be to parse all files with A's for each B. I considered this being not really efficient.

My scope is based on imports of resources, but again, a file with A's imports files with B's, not other way around. So I do not know where B is referenced.

You propose to extend ieobjectdescriptions with the references A->B, is that right?

I did not quite got your other proposal to move the validation to the builder participant. Could you explain this in more detail? And will it be still usable as the "normal", FAST validation?

Thanks!
Re: Exception when accessing xtext index [message #1760859 is a reply to message #1760851] Wed, 03 May 2017 12:35 Go to previous messageGo to next message
Eclipse UserFriend
Thanks for reply, Christian!

My settings is: There are elements of type A which may reference to elements of type B. The instances of A'S and B's are wildy distributed over files in the workspace, but one file may not contain both, A and B, because they are defined in separate grammars.

Now the requirement is that at most one A may reference any B. So a naive approach would be to parse all files with A's for each B. I considered this being not really efficient.

My scope is based on imports of resources, but again, a file with A's imports files with B's, not other way around. So I do not know where B is referenced.

You propose to extend ieobjectdescriptions with the references A->B, is that right?

I did not quite got your other proposal to move the validation to the builder participant. Could you explain this in more detail? And will it be still usable as the "normal", FAST validation?

Thanks!
Re: Exception when accessing xtext index [message #1760860 is a reply to message #1760851] Wed, 03 May 2017 12:36 Go to previous messageGo to next message
Eclipse UserFriend
Thanks for reply, Christian!

My settings is: There are elements of type A which may reference to elements of type B. The instances of A'S and B's are wildy distributed over files in the workspace, but one file may not contain both, A and B, because they are defined in separate grammars.

Now the requirement is that at most one A may reference any B. So a naive approach would be to parse all files with A's for each B. I considered this being not really efficient.

My scope is based on imports of resources, but again, a file with A's imports files with B's, not other way around. So I do not know where B is referenced.

You propose to extend ieobjectdescriptions with the references A->B, is that right?

I did not quite got your other proposal to move the validation to the builder participant. Could you explain this in more detail? And will it be still usable as the "normal", FAST validation?

Thanks!
Re: Exception when accessing xtext index [message #1760861 is a reply to message #1760860] Wed, 03 May 2017 12:45 Go to previous messageGo to next message
Eclipse UserFriend
No I suppose to put
The names (actually the text from the node Modell) of the references to b to the index entries of a

But this won't work if you have imports and thus there can be multiple As

Thus you have to move the validation to a later phase e.g. In builderparticipant
Unfortunately there is no infrastructure you can use for this out of the box
Re: Exception when accessing xtext index [message #1760862 is a reply to message #1760861] Wed, 03 May 2017 12:47 Go to previous messageGo to next message
Eclipse UserFriend
And with moving I mean

Customize builder participant (or quick and dirty the generator ) and do the validation there manually (create error marks etc)
But as I said this needs alll to be done manually since there is no infrastructure
Re: Exception when accessing xtext index [message #1760863 is a reply to message #1760862] Wed, 03 May 2017 12:57 Go to previous message
Eclipse UserFriend
Another thing that comes tommy mind is that you sort the files in the Xtext builder in a way that all A files are built first and the b files second
But that needs patching / subclassing the ClusteringBuilderState
(Please note this is a Xtext global singleton)
Previous Topic:Strange conflict on xtext grammar
Next Topic:Xtext -Xtend deployment
Goto Forum:
  


Current Time: Thu May 15 10:14:19 EDT 2025

Powered by FUDForum. Page generated in 0.03753 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly