[Acceleo] Bug when accessing abstract UML metaclasses [message #765194] |
Tue, 13 December 2011 15:39 |
Eclipse User |
|
|
|
Hi all,
I guess I've found a bug in Acceleo or in OCL (i'm not really certain), when
using UML in combination with a static profile implementation.
Consider the following template
[template public utp2ttcn3(model : Model, simulateSUT : Boolean) ?
(model.viewpoint = 'testModel')]
[comment @main/]
[for (testContext : TestContext | q_allTestContexts(model))]
[file (model.name.concat('.xyz'), false, 'UTF-8')]
module [testContext.base_BehavioredClassifier.name/] { //throws an
IllegalArgumentError due to the base_BehavioredClassifier property
} //TTCN-3 end
[/file]
[/for]
[/template]
UML::BehavioredClassifier is an abstract metaclass of UML, TestContext a
stereotype of UTP. In my concrete model, <<TestContext>> is applied on
UML::Component, which is in turn a concrete subclass of
UML::BehavioredClassifier
Now, I changed the code at the respective location from
[testContext.base_BehavioredClassifier.name/]
to
[testContext.base_BehavioredClassifier.oclAsType(Component).name/]
and it works as expected. I'd be happy to file a bug once it is clear
whether this is related to Acceleo or OCL.
Here is the corresponding stack trace:
!ENTRY org.eclipse.ocl 4 10 2011-12-13 16:34:09.281
!MESSAGE Evaluation failed with an exception: (no message)
!STACK 0
java.lang.IllegalArgumentException
at
org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigateProperty(EcoreEvaluationEnvironment.java:258)
at
org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigateProperty(EcoreEvaluationEnvironment.java:1)
at
org.eclipse.ocl.EvaluationVisitorImpl.visitPropertyCallExp(EvaluationVisitorImpl.java:2088)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitPropertyCallExp(AcceleoEvaluationVisitor.java:1124)
at
org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.accept(PropertyCallExpImpl.java:238)
at
org.eclipse.ocl.AbstractEvaluationVisitor.visitExpression(AbstractEvaluationVisitor.java:248)
at
org.eclipse.ocl.EvaluationVisitorDecorator.visitExpression(EvaluationVisitorDecorator.java:156)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.switchExpression(AcceleoEvaluationVisitor.java:1747)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitExpression(AcceleoEvaluationVisitor.java:1012)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitAcceleoFileBlock(AcceleoEvaluationVisitor.java:409)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.switchExpression(AcceleoEvaluationVisitor.java:1708)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitExpression(AcceleoEvaluationVisitor.java:1012)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitAcceleoForBlock(AcceleoEvaluationVisitor.java:522)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.switchExpression(AcceleoEvaluationVisitor.java:1698)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitExpression(AcceleoEvaluationVisitor.java:1012)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitAcceleoTemplate(AcceleoEvaluationVisitor.java:880)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.switchExpression(AcceleoEvaluationVisitor.java:1682)
at
org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitExpression(AcceleoEvaluationVisitor.java:1012)
at
org.eclipse.ocl.internal.evaluation.QueryImpl.evaluate(QueryImpl.java:152)
at org.eclipse.ocl.ecore.QueryImpl.evaluate(QueryImpl.java:62)
at
org.eclipse.acceleo.engine.generation.AcceleoEngine.doEvaluate(AcceleoEngine.java:360)
at
org.eclipse.acceleo.engine.generation.AcceleoEngine.evaluate(AcceleoEngine.java:141)
at
org.eclipse.acceleo.engine.service.AcceleoService.doGenerateTemplate(AcceleoService.java:869)
at
org.eclipse.acceleo.engine.service.AcceleoService.doGenerate(AcceleoService.java:585)
at
org.eclipse.acceleo.engine.service.AbstractAcceleoGenerator.generate(AbstractAcceleoGenerator.java:193)
at
org.eclipse.acceleo.engine.service.AbstractAcceleoGenerator.doGenerate(AbstractAcceleoGenerator.java:158)
at
de.fraunhofer.fokus.testing.fokusmbt.m2t.ttcn3.TTCN3pio.module.Utp2ttcn3.doGenerate(Utp2ttcn3.java:194)
at
de.fraunhofer.fokus.testing.m2t.acceleo.testing2ttcn3.serviceimpl.Testing2TTCN3ServiceImpl.transform(Testing2TTCN3ServiceImpl.java:128)
at
de.fraunhofer.fokus.testing.fokusmbt.m2t.ttcn3.ttcn3pio.testsuite.TTCN3pioTester.runMWO(TTCN3pioTester.java:49)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at
org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62)
at
org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
Marc-Florian
|
|
|
Re: [Acceleo] Bug when accessing abstract UML metaclasses [message #765626 is a reply to message #765194] |
Wed, 14 December 2011 12:12 |
|
Hi Florian,
I must admit that I don't really see what's going on behind the scene here... If you have a simple reproductible sample (Using an already existing profile or a minimal one) that you can provide, that would be great. Please fill a bug against Acceleo, we'll reassign to OCL if it comes to it, this is most likely due to the evaluation engine though.
Laurent Goubet
Obeo
|
|
|
Re: [Acceleo] Bug when accessing abstract UML metaclasses [message #765670 is a reply to message #765626] |
Wed, 14 December 2011 13:43 |
Ed Willink Messages: 7670 Registered: July 2009 |
Senior Member |
|
|
Hi Florian
I suspect this may be a more fundamental lack of specification. One of
the UML spec guys was explaining to me yesterday that Sterotypes are not
types, so it may well be that testContext.base_BehavioredClassifier.name
is traversing a non-type. It is therefore a surprise to me that
testContext.base_BehavioredClassifier.oclAsType(Component).name works;
well done for finding a workaround.
There is no mention of profiles or stereotypes in the OCL specification,
so apart from an expectation that they should work, there are no clues
as to how. There is only a single example in UML Super 2.4 in 18.3.2
where self.base_Interface.ownedAttributes->size() = 0 suggests your
usage is sensible.
The IAE suggests that either testContext.base_BehavioredClassifier was
not an EObject (unlikely) or was an EObject that had no "name" property
or that the wrong "name" property was in use. You are using
org.eclipse.ocl.ecore.EcoreEvaluationEnvironment, so your UML model has
been converted to Ecore. The OCL Ecore binding has and needs no profile
support.
The compile-time analysis of testContext.base_BehavioredClassifier.name
appears to succeed. It is the run-time that needs the oclAsType() to
help it out. I therefore suspect that the Ecore code synthesized to
create the testContext.base_BehavioredClassifier object has created an
object with an inaccurate eClass(). This points to the UML2Ecore
conversion, since that is where the profiles are applied and the
profile-free Ecore representation is synthesized.
A small example showing the steps you take and the tool versions would
be helpful.
Regards
Ed Willink
On 14/12/2011 04:12, Laurent Goubet wrote:
> Hi Florian,
>
> I must admit that I don't really see what's going on behind the scene
> here... If you have a simple reproductible sample (Using an already
> existing profile or a minimal one) that you can provide, that would be
> great. Please fill a bug against Acceleo, we'll reassign to OCL if it
> comes to it, this is most likely due to the evaluation engine though.
>
> Laurent Goubet
> Obeo
|
|
|
Powered by
FUDForum. Page generated in 0.03221 seconds