Eclipse Community Forums: Sirius » Validate diagram throws exception

Home » Eclipse Projects » Sirius » Validate diagram throws exception(... but not when using OCL delegates...)

Validate diagram throws exception [message #1693332]

Thu, 23 April 2015 05:56

Eclipse User

Hi,

I've created a meta model that contains a number of invariants (expressed directly in the OclInEcore editor).

From the OclInEcore documention I learned that it it possible to generate a java implementation of the invariants or to delegate evaluation of the invariant to the OCL interpreter at runtime.

For sake of speed I choose for the first one, use the java generated code. Validating a model from a Sirius based diagram editor results in throwing an exception. I changed the evaluation of the invariant to runtime delegation and then it works perfect.

Should I consider this to be a Sirius bug? (I think I should because the way the OCL is evaulated should not affect the outcome of the verification I think.)

Validating the model in the sample reflective editor works correctly in both cases.

Debugging the generated java code for the invariant seems to indicate that it can not resolve the metamodel for my language (however, I'm not an expert in this area so I might easily have misinterpreted the code that I saw in the debugger). I ended up in the Pivot based metamodel resolver (or something like that).

I might be capable of creating a small reproducable testcase...

Greetings,
Wilbert.

Re: Validate diagram throws exception [message #1693430 is a reply to message #1693332]

Fri, 24 April 2015 04:08

Eclipse User

Le 23/04/2015 11:56, Wilbert Alberts a écrit :
> Hi,

Hi.

> I've created a meta model that contains a number of invariants
> (expressed directly in the OclInEcore editor).
>
> From the OclInEcore documention I learned that it it possible to
> generate a java implementation of the invariants or to delegate
> evaluation of the invariant to the OCL interpreter at runtime.
>
> For sake of speed I choose for the first one, use the java generated
> code. Validating a model from a Sirius based diagram editor results in
> throwing an exception.

Can you provide the detailed stack trace? (maybe on a bugzilla instead
of here if you open one).

> I changed the evaluation of the invariant to
> runtime delegation and then it works perfect.
> Should I consider this to be a Sirius bug?

Maybe in part, but probably not only: is the exception thrown by the
OCL-generated code or by Sirius itself? If by the generated code, is it
part of its normal way of signaling a constraint violation (would be
strange) or is it because OCL produced code that crashes?

AFAIK, Sirius itself simply invokes EMF's standard validation API
(Diagnostician.validate()).

> (I think I should because the
> way the OCL is evaulated should not affect the outcome of the
> verification I think.)

Yes, Sirius should probably handle broken/buggy validation rules more
gracefully than exposing an exception to the user.

> Validating the model in the sample reflective editor works correctly in
> both cases.
>
> Debugging the generated java code for the invariant seems to indicate
> that it can not resolve the metamodel for my language (however, I'm not
> an expert in this area so I might easily have misinterpreted the code
> that I saw in the debugger). I ended up in the Pivot based metamodel
> resolver (or something like that).

It *sounds* like the code produced by OCL makes some assumptions about
the context in which it is run which do not hold when called from a
Sirius diagram. If the same OCL constraint works in Sirius when using
interpreted mode, it sounds like a possible bug in OCL: I would expect
code generation to be functionally equivalent to runtime interpretation,
including in the assumptions it make on the context. But its just a
guess on my part, I don't know enough about OCL to be sure.

So there could be 2 bugs:
1. Possibly one in OCL, if the generated-code version of a constraint
makes different assumptions the the runtime-evaluated one. Unless the
difference is expected/documented.
2. One in Sirius, where we should be ready to handle more gracefully
exceptions/errors thrown by validation rules.

> I might be capable of creating a small reproducable testcase...

Please open a bugzilla if you do.

Thanks.

--
Pierre-Charles David - Obeo

Need professional services for Sirius?
http://www.obeodesigner.com/sirius

Re: Validate diagram throws exception [message #1693759 is a reply to message #1693430]

Tue, 28 April 2015 04:13

Eclipse User

Hi,

Sorry for not getting back to you immediately, some dutch holidays Wink

As I'm not sure right now whose to blame I've not yet raised a bugzilla but copied the stack trace below.

java.lang.NullPointerException
	at org.eclipse.ocl.examples.pivot.manager.PackageManager.getPackageServer(PackageManager.java:428)
	at org.eclipse.ocl.examples.pivot.manager.MetaModelManager.getPackageServer(MetaModelManager.java:2001)
	at org.eclipse.ocl.examples.pivot.manager.MetaModelManager.getNestedType(MetaModelManager.java:1950)
	at org.eclipse.ocl.examples.library.executor.AbstractIdResolver.visitClassId(AbstractIdResolver.java:1057)
	at org.eclipse.ocl.examples.library.executor.AbstractIdResolver.visitClassId(AbstractIdResolver.java:1)
	at org.eclipse.ocl.examples.domain.ids.impl.GeneralizedClassIdImpl.accept(GeneralizedClassIdImpl.java:27)
	at org.eclipse.ocl.examples.pivot.manager.PivotIdResolver.getType(PivotIdResolver.java:283)
	at org.eclipse.ocl.examples.pivot.manager.PivotIdResolver.getType(PivotIdResolver.java:1)
	at dca.impl.NamedElementImpl.getFqn(NamedElementImpl.java:166)
	at dca.impl.NamedElementImpl.eGet(NamedElementImpl.java:203)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1011)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1003)
	at org.eclipse.emf.ecore.util.EObjectValidator.validate_MultiplicityConforms(EObjectValidator.java:721)
	at org.eclipse.emf.ecore.util.EObjectValidator.validate_EveryMultiplicityConforms(EObjectValidator.java:579)
	at org.eclipse.emf.ecore.util.EObjectValidator.validate_EveryDefaultConstraint(EObjectValidator.java:348)
	at dca.util.DcaValidator.validateType(DcaValidator.java:321)
	at dca.util.DcaValidator.validate(DcaValidator.java:189)
	at org.eclipse.emf.ecore.util.EObjectValidator.validate(EObjectValidator.java:324)
	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.emf.ecore.util.Diagnostician.doValidateContents(Diagnostician.java:181)
	at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:161)
	at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:137)
	at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:108)
	at org.eclipse.sirius.diagram.ui.part.ValidateAction.runEMFValidator(ValidateAction.java:158)
	at org.eclipse.sirius.diagram.ui.part.ValidateAction.validate(ValidateAction.java:187)
	at org.eclipse.sirius.diagram.ui.part.ValidateAction.access$0(ValidateAction.java:167)
	at org.eclipse.sirius.diagram.ui.part.ValidateAction$2.run(ValidateAction.java:147)

I think I copied the relevant part. You see that it is not simply a constraint that is violated. Actually, a property of a class is retrieved by invoking NamedElementImpl.getFqn (which holds for 'get fully qualified name'). The Fqn is a derived attribute that normally works perfectly, even with generated java implementation. It just breaks when invoked from 'valdiate diagram'.

I tried to create a smaller testcase that reproduces this behavior but so far I haven't been succesfull.

Hope that already this shines a little light on the case.

Greetings,
Wilbert

Re: Validate diagram throws exception [message #1693797 is a reply to message #1693759]

Tue, 28 April 2015 07:45

Eclipse User

Hi,

I've investigated the situation a little bit further. I couldn't reproduce the situation, but at least I got one environment that works and one that doesn't. So I started debugging both environments.

Somewhere in the evaluation of the FQN property I get the following stack:

Thread [main] (Suspended)	
	PivotUtil.findMetaModelManager(ResourceSet) line: 326	
	PivotUtil.findMetaModelManager(Resource) line: 322	
	PivotUtil.getEvaluator(EObject) line: 753	
	CompositeImpl(NamedElementImpl).getFqn() line: 162

So I include that it is looking for an instance of the MetaModelManager; first by inspecting the model (e.g. the Resource), then by inspecting the ResourceSet. This is the first occasion where the two dbugging instances start to differ. Let me copy a fragment of the code of the PivotUtil class.

	public static MetaModelManager findMetaModelManager(@NonNull ResourceSet resourceSet) {
		MetaModelManager metaModelManager = MetaModelManager.findAdapter(resourceSet);
		if (metaModelManager != null) {
			return metaModelManager;
		}
		MetaModelManagerResourceSetAdapter adapter = MetaModelManagerResourceSetAdapter.findAdapter(resourceSet);
		if (adapter != null) {
			return adapter.getMetaModelManager();
		}
		return null;
	}

Inspecting the resourceSet given as argument to this method shows that for the working environment, a plain ResourceSetImpl instance is provided. The one that does not work receives an XtextResourceSet instance. The ResourceSetImpl does not provide an adapter that results into a MetaModelManager so in the end PivotUtil::getEvaluator constructs an ExoreExecutorManager and then evaluation of the derived attributes and constraints succeeds.

The XtextResourceSet does provide an adapter and PivotUtil::getEvaluator eventually returns an instance of PivotExecutorManager. This one does have problems evaluating the derived attributes and constraints.

However, I don't have any clue why an XtextResourceSet is used neither do I know whether this is a bug for OCL or Sirious.

Additional suggestions are welcome,

Greetings,
Wilbert.

Re: Validate diagram throws exception [message #1694448 is a reply to message #1693797]

Tue, 05 May 2015 07:42

Eclipse User

Le 28/04/2015 13:45, Wilbert Alberts a écrit :
> Hi,

Hi.

[snip]
> Inspecting the resourceSet given as argument to this method shows that
> for the working environment, a plain ResourceSetImpl instance is
> provided. The one that does not work receives an XtextResourceSet
> instance. The ResourceSetImpl does not provide an adapter that results
> into a MetaModelManager so in the end PivotUtil::getEvaluator constructs
> an ExoreExecutorManager and then evaluation of the derived attributes
> and constraints succeeds.
> The XtextResourceSet does provide an adapter and PivotUtil::getEvaluator
> eventually returns an instance of PivotExecutorManager. This one does
> have problems evaluating the derived attributes and constraints.
>
> However, I don't have any clue why an XtextResourceSet is used neither
> do I know whether this is a bug for OCL or Sirious.

XtextResourceSet extends the standard ResourceSetImpl to add features
needed by Xtext resources (regarding classpath resolution) and optimize
some use cases which are more common when using Xtext (in particular the
presence of a large number of Resources).

Using an XtextResourceSet is needed for Sirius to work correctly with
Xtext resources, but we can not know beforehand when opening a Sirius
session if such resources will be added later, so if the Sirius/Xtext
bridge plug-in is installed (org.eclipse.sirius.common.xtext), all
Sirius session default to using an XtextResourceSet instead of a plain
ResourceSetImpl. Normally this has no impact if you don't actually use
Xtext resources (except maybe performance gains in some situations), but
maybe you/OCL hit a corner case we have not seen before.

If you don't need Xtext support specifically, simply uninstalling the
org.eclipse.sirius.common.xtext plug-in (from the
org.eclipse.sirius.runtime.ide.xtext feature) should work around the issue.

As for the difference in behavior, from a quick look at the source of
XtextResourceSet it does not seem to do anything special regarding
adapters, so I don't know why the OCL-specific adapter is present in one
case and not the other.

--
Pierre-Charles David - Obeo

Need professional services for Sirius?
http://www.obeodesigner.com/sirius

Previous Topic:	EditionTableDescription: Accessability of semantic elements in context of FeatureParentExpression
Next Topic:	Predicate expression in Conditional Edge Style Description

Goto Forum:

-=] Back to Top [=-

Current Time: Thu May 15 06:22:46 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter