Great explanation and great solution!
Without the "var" keyword, both ways worked (using "resultVariable" parameter and with "setVariable")
Allright, just to clarify: the problem is really related to the JVM behaviour, but it fires at the variable declaration using "var" keyword, not while returning the result. Am I right? This may help other in the future.
Thanks again!
M
Your understanding is correct. I would want to separate the script engine behaviour from the JVM behaviour. Effectively, Sun/Oracle only licensed and integrated an already existing open source JavaScript engine from Mozilla (Rhino) which runs "on" the JVM but should not be considered part of the JVM. Essentially it is just a reference implementation for JSR-223 that is shipped with the JRE/JDK.
Hi again! I now upgraded from JDK 1.7 to JDK 1.8 and found myself with Nashorn and the resurrection of the issue (I'm still using Activiti engine 5.17.0 for production)
The ScriptTasks do work with the precaussion of not using the var keyword neither the "resultVariable" for the implicit result. But now, ScriptExecutionListeners fail no matter what with the following exception:
org.activiti.engine.ActivitiException: couldn't find a variable type that is able to serialize [object global]
at org.activiti.engine.impl.variable.DefaultVariableTypes.findVariableType(DefaultVariableTypes.java:62)
Is there a way to deal with that? Is there a workarround other than extracting ScriptExecutionListeners into ScriptTasks? I'm evaluating the use of groovy instead of JS too, but it would be very painful for definition's designers.
Thanks!
M
Ask for and offer help to other Alfresco Process Services and Activiti Users and members of the Alfresco team.
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.