Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Fatal problem with TreeAppendable(This is killing me...)
Fatal problem with TreeAppendable [message #1717031] Wed, 09 December 2015 16:54 Go to next message
Ingo Meyer is currently offline Ingo MeyerFriend
Messages: 162
Registered: July 2009
Senior Member
Hi,

from one model element, similar to Entity in DomainmodExample, I inferr two Java elements, one interface and one implementation class. The implementation class will not compile as the setter method parameter throws really crazy error at compile time:

java.lang.NullPointerException
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator$43.getURIForTrace(JvmModelGenerator.java:2019)
	at org.eclipse.xtext.xbase.compiler.output.TreeAppendable.createLocationData(TreeAppendable.java:296)
	at org.eclipse.xtext.xbase.compiler.output.TreeAppendable.createLocationData(TreeAppendable.java:231)
	at org.eclipse.xtext.xbase.compiler.output.TreeAppendable.createAllLocationData(TreeAppendable.java:246)
	at org.eclipse.xtext.xbase.compiler.output.TreeAppendable.createAllLocationData(TreeAppendable.java:256)
	at org.eclipse.xtext.xbase.compiler.output.TreeAppendable.trace(TreeAppendable.java:176)
	at org.eclipse.xtext.xbase.compiler.output.TreeAppendable.trace(TreeAppendable.java:171)
	at org.eclipse.xtext.xbase.compiler.output.TreeAppendable.trace(TreeAppendable.java:166)
	at org.eclipse.xtext.xbase.compiler.output.TreeAppendable.trace(TreeAppendable.java:1)
	at org.eclipse.xtext.xbase.compiler.TypeReferenceSerializer.serialize(TypeReferenceSerializer.java:91)
	at org.eclipse.xtext.xbase.compiler.TypeReferenceSerializer.serialize(TypeReferenceSerializer.java:84)
	at org.eclipse.xtext.xbase.compiler.TypeReferenceSerializer.serialize(TypeReferenceSerializer.java:81)
	at org.eclipse.xtext.xbase.compiler.ErrorSafeExtensions.serializeSafely(ErrorSafeExtensions.java:242)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateParameter(JvmModelGenerator.java:1232)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateParameters(JvmModelGenerator.java:1205)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator._generateMember(JvmModelGenerator.java:996)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateMember(JvmModelGenerator.java:2190)
	at xxx
	at org.eclipse.xtext.xbase.lib.ObjectExtensions.operator_doubleArrow(ObjectExtensions.java:139)
	at org.eclipse.xtext.xbase.compiler.LoopExtensions$1.apply(LoopExtensions.java:40)
	at org.eclipse.xtext.xbase.lib.IteratorExtensions.forEach(IteratorExtensions.java:363)
	at org.eclipse.xtext.xbase.lib.IterableExtensions.forEach(IterableExtensions.java:333)
	at org.eclipse.xtext.xbase.compiler.LoopExtensions.forEach(LoopExtensions.java:43)
	at xxx
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator._generateBody(JvmModelGenerator.java:287)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateBody(JvmModelGenerator.java:2162)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.generateType(JvmModelGenerator.java:231)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator._internalDoGenerate(JvmModelGenerator.java:217)
	at org.eclipse.xtext.xbase.compiler.JvmModelGenerator.internalDoGenerate(JvmModelGenerator.java:2145)

(The xxx stacktrace element is a own class which just delegates and do nothing with the objects.)

It is where the setter parameter will be serialized to the appendable. Its resource is null. but this is really!!! not true. As I found out, the method "createAllLocationData" of TreeAppendable will use the "jvmModelAssociations.getSourceElements(object)" to do something with the source elements:
	protected static Set<ILocationData> createAllLocationData(ITraceURIConverter converter, ILocationInFileProvider locationProvider, IJvmModelAssociations jvmModelAssociations, EObject object, ILocationInFileProviderExtension.RegionDescription query, boolean skipEmpty) {
		Set<EObject> sourceElements = jvmModelAssociations.getSourceElements(object);
		Set<ILocationData> result = Collections.emptySet();
		if (sourceElements.isEmpty()) {
			ILocationData locationData = createLocationData(converter, locationProvider, object, query, skipEmpty);
			if (locationData != null) {
				result = Collections.singleton(locationData);
			}
		} else {
			result = Sets.newHashSet();
			for(EObject sourceElement: sourceElements) {
				ILocationData locationData = createLocationData(converter, locationProvider, sourceElement, query, skipEmpty);
				if (locationData != null) {
					result.add(locationData);
				}	
			}
		}
		return result;
	}

But the source element of the setter parameter, a "JvmParameterizedTypeReference: java.util.List<JvmParameterizedTypeReference: MySetterModelObject>", is another "JvmParameterizedTypeReference: java.util.List" with a container JvmUpperBound with a container JvmWildcardTypeReference with NO container. So where the heck is that coming from???

Really bad is also that I have no chance to overwrite the TreeAppendable, right? I don't need the tracing stuff and the model is correct.
I have no idea what to do and I am lost.
Any hints are really appreciated,

Thanks Ingo
Re: Fatal problem with TreeAppendable [message #1717049 is a reply to message #1717031] Wed, 09 December 2015 17:59 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14669
Registered: July 2009
Senior Member
Hi can you share a reproduceable example?

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Fatal problem with TreeAppendable [message #1717258 is a reply to message #1717049] Fri, 11 December 2015 07:58 Go to previous message
Ingo Meyer is currently offline Ingo MeyerFriend
Messages: 162
Registered: July 2009
Senior Member
Yes I could but found the problem by myself Smile

In the getter, which is compiled just before, I have some code using "typeRefs.wildCardExtends( myAttr.type )" which will remove the typeRef and in the setter it is null. I guess that forces the serializer into a totally different code area...
So a typically beginners misktake with EMF containment...
When migrating a big project things like this are difficult to find, Before we had own helper classes for that, now we try to use as much default as possible.

Thanks for the great project,
~Ingo
Previous Topic:Sharing rules' bodies
Next Topic:Add org.eclipse.equinox.common to the class path.
Goto Forum:
  


Current Time: Sat Apr 27 03:22:19 GMT 2024

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

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

Back to the top