Bug 319708

Comment 1 Dimitris Kolovos 2010-07-15 18:16:11 EDT

I believe that this NPE can be thrown only if "diagnostics" in 

public boolean validate(EClass eClass, EObject eObject,DiagnosticChain diagnostics, Map<Object, Object> context) 

is null. Are you perhaps calling this method from within the EMFText integration code with a null parameter?

Comment 2 Mirko Seifert 2010-07-16 02:55:41 EDT

I call:

org.eclipse.emf.common.util.Diagnostic diagnostics = org.eclipse.emf.ecore.util.Diagnostician.INSTANCE.validate(root);

(root is my root EObject).

So 'diagnostics' seems to be set/created by EMF itself.

Is my call incorrect?

Comment 3 Dimitris Kolovos 2010-07-20 14:29:00 EDT

Hi Mirko. Have you perhaps resolved this? If not, would it be possible to attach a minimal test case that I can use to reproduce this and investigate further?

Comment 4 Mirko Seifert 2010-07-20 15:34:54 EDT

No, I did not resolve this.

I'll attach a JUnit Plug-in test, which reproduces the bug.

Comment 5 Mirko Seifert 2010-07-20 15:35:24 EDT

Created attachment 174784 [details]
Plug-in project containing a test case

Comment 6 Dimitris Kolovos 2010-07-21 04:42:04 EDT

Thanks Mirko. I'll investigate and get back to you.

Comment 7 Dimitris Kolovos 2010-09-09 06:55:21 EDT

Apologies for the late reply. I've modified the testNPE method slightly (look for lines with "dkolovos") and now the test passes:

	public void testNPE() throws URISyntaxException {
		// create dynamic EPackage
		String namespaceURI = "http://www.epsilon.org/test";
		EPackage ePackage = EcoreFactory.eINSTANCE.createEPackage();
		ePackage.setName("TestPackage");
		ePackage.setNsURI(namespaceURI);
		EClass eClass = EcoreFactory.eINSTANCE.createEClass();
		eClass.setName("A");
		ePackage.getEClassifiers().add(eClass);
		EAttribute nameAttribute = EcoreFactory.eINSTANCE.createEAttribute();
		nameAttribute.setName("name");
		nameAttribute.setEType(EcorePackage.eINSTANCE.getEString());
		eClass.getEStructuralFeatures().add(nameAttribute); // dkolovos: Added name attribute to the structural features of the class
		EPackage.Registry.INSTANCE.put(ePackage.getNsURI(), ePackage); // dkolovos: ++ Register EPackage
		
		// register EVL file
		String modelName = EvlValidator.DEFAULT_MODEL_NAME;
		// TODO I'm not sure whether the URI is correct
		// dkolovos: It was not :) It should be an absolute URI like the following
		EValidator evlValidator = new EvlValidator(new URI("platform:/plugin/org.epsilon.evl.test/constraints/constraints.evl"), modelName, namespaceURI);
		EValidator.Registry.INSTANCE.put(ePackage, evlValidator); 
		
		// create dynamic model instance
		EObject root = ePackage.getEFactoryInstance().create(eClass);
		Resource resource = new ResourceSetImpl().createResource(org.eclipse.emf.common.util.URI.createURI("temp.xmi"));
		resource.getContents().add(root);
		
		// now call validation (this throws the NPE)
		org.eclipse.emf.common.util.Diagnostic diagnostics =
			org.eclipse.emf.ecore.util.Diagnostician.INSTANCE.validate(root);
		// TODO check whether the result of the validation is correct
		
	}

Please let us know if you come across any other issues while integrating EMFText with EVL.

Comment 8 Mirko Seifert 2010-09-14 11:14:37 EDT

Hi Dimitrios,

the test case does succeed now, but my problem remains. I experiences the NPE when using EVL from plug-ins generated by EMFText. The modifications you've made to the test case are most probably causing my NPE. The generated plug-ins run within Eclipse. Therefore the EPackage is registered. I did not check this, but since EMFText used the generated EMF code, the package is registered whenever the first metaclass is instantiated. This is of course way before EVL comes into play. Also my metamodel has the element that are used by the EVL constraints. I only forgot to do this correctly in the test case. This leaves the wrong URI when creating the EvlValidator. However, I do register my constraint via extension point. This creation is therefore handled by Epsilon.

All in all, I think the test case produced the same symptoms, but the underlying problem is a different one in my case. I think the easiest way to figure out what's going on it to attach the generated plug-ins to this report, so you can have a look at it.

The plug-ins compile without having EMFText installed. After importing them you should be able to use them.

Comment 9 Mirko Seifert 2010-09-14 11:15:45 EDT

(In reply to comment #8)
> Hi Dimitrios,
> 
> The modifications you've
> made to the test case are most probably causing my NPE.

I meant: "are most probably NOT causing my NPE."

Comment 10 Mirko Seifert 2010-09-14 11:17:46 EDT

Created attachment 178844 [details]
Plug-ins to reproduce the NPE

Comment 11 Mirko Seifert 2010-09-14 11:20:13 EDT

To reproduce the problem start a new Eclipse instance, create a .rules files with the following content:

shapes circ "a" rect "b" circ "c"

When saving the file, the NPE gets thrown.

Comment 12 Mirko Seifert 2010-10-18 10:08:26 EDT

I tried again with the current version from the interim update site (0.8.9.201010171057) and the NPE exception is gone. However, problems remain with the quick fixes provided by EVL. I've already made the suggested changes to EMFText, but I still face some problems:

1. The error markers for constraints are not shown right after starting up a fresh Eclipe when the model files is already open. When I close the file and open it again, the errors are shown.

2. When selecting a problem in the problems view an exception is thown by the GmfMarkerResolver. I'll attach a stack trace.

3. When selecting "Quick Fix" on one of the problem markers, only the "Ignore" fix is shown in the list, but not the fix defined in the .evl file. I'll attach a new version of the example plug-ins where the code is generated with the current trunk version of EMFText.

Comment 13 Mirko Seifert 2010-10-18 10:11:24 EDT

Created attachment 181096 [details]
New set of test plug-ins

Comment 14 Mirko Seifert 2010-10-18 10:12:10 EDT

Created attachment 181097 [details]
Stack trace for NPE in GmfMarkerResolver