Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Exception when accessing xtext index
Exception when accessing xtext index [message #1760763] Tue, 02 May 2017 16:38 Go to next message
I.M. Wiesel is currently offline I.M. WieselFriend
Messages: 4
Registered: May 2017
Junior Member
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 15:40 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
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)


Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Exception when accessing xtext index [message #1760858 is a reply to message #1760851] Wed, 03 May 2017 16:35 Go to previous messageGo to next message
I.M. Wiesel is currently offline I.M. WieselFriend
Messages: 4
Registered: May 2017
Junior Member
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 16:35 Go to previous messageGo to next message
I.M. Wiesel is currently offline I.M. WieselFriend
Messages: 4
Registered: May 2017
Junior Member
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 16:36 Go to previous messageGo to next message
I.M. Wiesel is currently offline I.M. WieselFriend
Messages: 4
Registered: May 2017
Junior Member
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 16:45 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
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


Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Exception when accessing xtext index [message #1760862 is a reply to message #1760861] Wed, 03 May 2017 16:47 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
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


Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Exception when accessing xtext index [message #1760863 is a reply to message #1760862] Wed, 03 May 2017 16:57 Go to previous message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
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)


Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Previous Topic:Strange conflict on xtext grammar
Next Topic:Xtext -Xtend deployment
Goto Forum:
  


Current Time: Thu Apr 18 03:53:00 GMT 2024

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

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

Back to the top