Community
Participate
Working Groups
Created attachment 239224 [details] Bundle showing the issue Step to reproduce: 1- create a very basic viewpoint specification project 2- create inside a Java service class with a public method using as parameters or returning values with a type which is not a type from a metamodel or a type of the OCL standard library. 3- use the Java service (you can use another method of this service) and try to validate the odesign. 4- NPE! In my attachment, you can see a bundle showing the issue (click on validate to see it create the NPE) with the following Java service class: package unknown.type.design.services; import java.math.BigDecimal; import java.net.URI; import java.util.Map; public class UnknownTypes { public URI useUnknownTypes(Map<String, BigDecimal> parameters) { return null; } } URI and Map are two types that cannot be "translated" in OCL therefore it crashes. Stack trace: java.lang.NullPointerException at org.eclipse.sirius.common.acceleo.mtl.business.api.extension.DynamicJavaModuleCreator.inferOCLType(DynamicJavaModuleCreator.java:346) at org.eclipse.sirius.common.acceleo.mtl.business.api.extension.DynamicJavaModuleCreator.extractArgumentSignatureString(DynamicJavaModuleCreator.java:173) at org.eclipse.sirius.common.acceleo.mtl.business.api.extension.DynamicJavaModuleCreator.createModule(DynamicJavaModuleCreator.java:121) at org.eclipse.sirius.common.acceleo.mtl.ide.WorkspaceJavaImportHandler$WorkspaceJavaModuleDescriptor.getModuleContent(WorkspaceJavaImportHandler.java:433) at org.eclipse.acceleo.parser.interpreter.ModuleDescriptor.hashCode(ModuleDescriptor.java:105) at java.util.HashMap.hash(Unknown Source) at java.util.HashMap.put(Unknown Source) at java.util.HashSet.add(Unknown Source) at org.eclipse.sirius.common.acceleo.mtl.business.internal.interpreter.AcceleoMTLInterpreter.addExtendedImport(AcceleoMTLInterpreter.java:1011) at org.eclipse.sirius.common.acceleo.mtl.business.internal.interpreter.AcceleoMTLInterpreter.addImport(AcceleoMTLInterpreter.java:451) at org.eclipse.sirius.common.acceleo.mtl.business.internal.interpreter.AcceleoMTLInterpreter.addContextImports(AcceleoMTLInterpreter.java:979) at org.eclipse.sirius.common.acceleo.mtl.business.internal.interpreter.AcceleoMTLInterpreter.createCompilationContext(AcceleoMTLInterpreter.java:561) at org.eclipse.sirius.common.acceleo.mtl.business.internal.interpreter.AcceleoMTLInterpreter.validateExpression(AcceleoMTLInterpreter.java:945) at org.eclipse.sirius.tools.internal.validation.description.constraints.ValidInterpretedExpressionConstraint.checkExpression(ValidInterpretedExpressionConstraint.java:84) at org.eclipse.sirius.tools.internal.validation.description.constraints.ValidInterpretedExpressionConstraint.validate(ValidInterpretedExpressionConstraint.java:57) at org.eclipse.emf.validation.internal.util.JavaConstraintParser$ConstraintAdapter.validate(JavaConstraintParser.java:80) at org.eclipse.emf.validation.internal.service.AbstractValidator.evaluateConstraints(AbstractValidator.java:241) at org.eclipse.emf.validation.internal.service.BatchValidator.validate(BatchValidator.java:264) at org.eclipse.emf.validation.internal.service.BatchValidator.validate(BatchValidator.java:211) at org.eclipse.emf.validation.internal.service.BatchValidator.doValidate(BatchValidator.java:149) at org.eclipse.emf.validation.internal.service.AbstractValidator.validate(AbstractValidator.java:147) at org.eclipse.emf.validation.internal.service.AbstractValidator.validate(AbstractValidator.java:126) at org.eclipse.emf.validation.internal.service.BatchValidator.validate(BatchValidator.java:117) at org.eclipse.sirius.tools.internal.validation.EValidatorAdapter.validate(EValidatorAdapter.java:80) at org.eclipse.emf.ecore.util.Diagnostician.doValidate(Diagnostician.java:171) at org.eclipse.emf.edit.ui.action.ValidateAction$3.doValidate(ValidateAction.java:296) 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.edit.ui.action.ValidateAction.validate(ValidateAction.java:264) at org.eclipse.emf.edit.ui.action.ValidateAction$1.run(ValidateAction.java:176) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
I failed to add that Acceleo and OCL will never be able to handle a Java operation with this signature, the Sirius-Acceleo bridge will not be able to create a valid Acceleo "invoke" for this operation. It should just fail nicely with an error message detailing the issue for the end user and ignore this Java method from the creation of the in-memory Acceleo module representing this Java class. Right now, it stops with a NPE and it deactivates the Acceleo validation until a restart of Eclipse.
Stéphane : do we have something in the Acceleo code/API so that we can filter methods which are not going to be supported because of the return type ?
(In reply to Cedric Brun from comment #2) > Stéphane : do we have something in the Acceleo code/API so that we can > filter methods which are not going to be supported because of the return > type ? From a private exchange with Stéphane, it seems that there is no way to do this currently (although it could probably be added).
