Serialization bug in scripts with JDK >= 1.6.0_43

cancel
Showing results for 
Search instead for 
Did you mean: 
matutano6
Member II

Re: Serialization bug in scripts with JDK >= 1.6.0_43

Jump to solution

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

afaust
Master

Re: Serialization bug in scripts with JDK >= 1.6.0_43

Jump to solution

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.

matutano6
Member II

Re: Serialization bug in scripts with JDK >= 1.6.0_43

Jump to solution

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