Hi Servoy,
Under some “uncertain” conditions, we get the following error:
org.mozilla.javascript.EvaluatorException: Constructor for "InternalError" not found
The suspect is that this condition happens after some forms are unloaded automatically by Servoy and then reloaded.
“InternalError” does not appear anywhere in our code. What could be causing this issue?
that shouldn’t really happen. Because InternalError constructor is at the top level scope of rhino, that is created when the scriptengine is created.
having said that, we did add some extra synchronization for the next release of servoy 7.x (and 6.0) so that that shouldn’t happen.
If you still see that please report back
jcompagner:
that shouldn’t really happen. Because InternalError constructor is at the top level scope of rhino, that is created when the scriptengine is created.having said that, we did add some extra synchronization for the next release of servoy 7.x (and 6.0) so that that shouldn’t happen.
If you still see that please report back
When did you add that? The issue is happening on a server running Servoy version 7.3.0 i1- releaseNumber 2019
no its not in that release, don’t know if it is currently in the 7.3.1 "branch’, will ask, its on 7.4 for sure
jcompagner:
that shouldn’t really happen
Unfortunately it does happen…
7.3.0i2 should have the changed code.
Hi Johan,
This issue is still happening even on 7.4.2.
This is from the server log:
Server log:
2014-11-04 14:55 http-18080-4 ERROR com.servoy.j2db.util.Debug InternalError: Constructor for “InternalError” not found. (app_shell/forms/app_shell_BaseForm/processBeforeActionContext#591) at app_shell/forms/app_shell_BaseForm/processBeforeActionContext:591 (processBeforeActionContext) at app_shell/forms/app_shell_BaseForm/requestBeforeActionContext:566 (requestBeforeActionContext) at app_shell/forms/app_shell_BaseForm/performBaseFormAction:1632 (performBaseFormAction) at app_shell/forms/app_shell_BaseForm/performSaveAndCloseAction:4381 (performSaveAndCloseAction) at argos_abelisk_client/forms/BOTTOM_TOOLBAR_x77ba54b7bc79491a8cb40bb0a5d2dd59/handleToolBarButtonClick:315 (handleToolBarButtonClick)
are you using 3th party plugins like velocity plugin or something like that?
Or maybe are you trying to destroy a form that you want to alter again in the solution model, but the current execution context is on that form?
There should be safe guards in it that then the form really can’t be destroyed/removed from history. Because if that does happen then the complete state of the form or the method of that from that is running is bogus. (the parent hierarchy is destroyed)
FYI I’ve released a Velocity v3.3.7 lately that fixes any issue with the plugin’s usage of the Rhino context that could have happened before.
It has been confirmed to be working for people who had issues with previous versions.