AlanBourke:
I have a solution that exposes a few web services (via the rest_ws.plugin). Since 6.0.6 they are throwing the following, to do with licensing (??) - any clues ?:edit: Doesn’t seem to be the plugin per se, as the sample solution works.
Alan,
Does the solution have the property mustauthenticate set to true?
Rob
jcompagner:
rossent:
Most of the time is spent on the step “Invoking ‘Servoy Project Builder’ on /some_module_name” - Servoy Developer will just sit there a long time seemingly doing nothing. This happens upon save operation and when launching a client for debugging (see the attached screen shot)and what happens if you dump the stack a few times through the admin pages when it is in that state for a while?
Can you send a few of them (5 seconds or so apart)
The attached file contains a few memory dumps.
mem_dumps_waiting_on_invoking_servoy_project_builder.txt (89.6 KB)
rgansevles:
AlanBourke:
I have a solution that exposes a few web services (via the rest_ws.plugin). Since 6.0.6 they are throwing the following, to do with licensing (??) - any clues ?:edit: Doesn’t seem to be the plugin per se, as the sample solution works.
Alan,
Does the solution have the property mustauthenticate set to true?
Rob
Rob
Yes it does - there is a main solution, which has login/authenticate modules attached and mustauthenticate = true. The web services are part of the main solution.
:edit: I have turned mustauthenticate off and it appears to be working again. I was under the impression that it needed to be ON for login/authenticate functionality to work.
Thanks
rossent:
jcompagner:
rossent:
Most of the time is spent on the step “Invoking ‘Servoy Project Builder’ on /some_module_name” - Servoy Developer will just sit there a long time seemingly doing nothing. This happens upon save operation and when launching a client for debugging (see the attached screen shot)and what happens if you dump the stack a few times through the admin pages when it is in that state for a while?
Can you send a few of them (5 seconds or so apart)The attached file contains a few memory dumps.
thx, now i get why it is slow, its not scripting, its our own builder checking for duplicates (thats added in 6.0.6, a check for duplicate fields over the form hierarchy)
At least thats why i did see in the 3 dumps, its 30 seconds busy doing that, and i know you have quite a lot form hierarchies if i remember correctly.
rossent:
jcompagner:
rossent:
Most of the time is spent on the step “Invoking ‘Servoy Project Builder’ on /some_module_name” - Servoy Developer will just sit there a long time seemingly doing nothing. This happens upon save operation and when launching a client for debugging (see the attached screen shot)and what happens if you dump the stack a few times through the admin pages when it is in that state for a while?
Can you send a few of them (5 seconds or so apart)The attached file contains a few memory dumps.
i fixed the issue that we see in the stack dumps
I also could reproduce it in the workspace i still had from you.
A save of a file and then the complete build could take up to 25 seconds or so, but now it is sub second.
jcompagner:
i fixed the issue that we see in the stack dumps
I also could reproduce it in the workspace i still had from you.
A save of a file and then the complete build could take up to 25 seconds or so, but now it is sub second.
This is great news! When can we expect to get the fix?
Hello Servoy,
We found another issue which appears only when the solution runs in Servoy Application Server (in Servoy Developer everything is fine)
Basically, we have on form variable referencing another variable from the same form like this:
var SomeNumber = 1;
var OtherFormVar = {prop: SomeNumer, otherProp: 'asdfa'};
The code above is in the same form. When running in Servoy Developer everything is fine. However when we run this in Application Server, we are getting the following errors:
This is from the Server Log
org.mozilla.javascript.EcmaError: ReferenceError: "SomeNumber" is not defined.
at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3662)
at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3656)
at org.mozilla.javascript.ScriptRuntime.notFoundError(ScriptRuntime.java:3718)
at org.mozilla.javascript.ScriptRuntime.nameOrFunction(ScriptRuntime.java:1753)
at org.mozilla.javascript.ScriptRuntime.name(ScriptRuntime.java:1678)
at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3752)
at script(OtherFormVar)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2680)
at org.mozilla.javascript.InterpretedFunction.exec(InterpretedFunction.java:181)
at org.mozilla.javascript.Context.evaluateString(Context.java:1233)
at com.servoy.j2db.scripting.ScriptVariableScope.evalValue(ScriptVariableScope.java:163)
at com.servoy.j2db.scripting.ScriptVariableScope.put(ScriptVariableScope.java:130)
at com.servoy.j2db.scripting.ScriptVariableScope.put(ScriptVariableScope.java:75)
at com.servoy.j2db.scripting.FormScope.createVars(FormScope.java:75)
at com.servoy.j2db.FormController.initForJSUsage(FormController.java:3829)
at com.servoy.j2db.FormController.initForJSUsage(FormController.java:4209)
at com.servoy.j2db.FormController.getFormScope(FormController.java:4565)
at com.servoy.j2db.dataprocessing.DataAdapterList.<init>(DataAdapterList.java:288)
at com.servoy.j2db.server.headlessclient.dataui.WebDataRenderer.createDataAdapter(WebDataRenderer.java:137)
at com.servoy.j2db.server.headlessclient.dataui.WebDataRendererFactory.placeElements(WebDataRendererFactory.java:306)
at com.servoy.j2db.server.headlessclient.dataui.WebDataRendererFactory.completeRenderers(WebDataRendererFactory.java:114)
at com.servoy.j2db.FormController.createDataRenderers(FormController.java:1705)
at com.servoy.j2db.FormController.init(FormController.java:1545)
at com.servoy.j2db.FormManager.leaseFormPanel(FormManager.java:938)
at com.servoy.j2db.scripting.CreationalPrototype.get(CreationalPrototype.java:172)
at org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1641)
at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1428)
at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1417)
at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3343)
at script.handleOnEditRootNode(handleOnEditRootNode:76)
at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2680)
at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:166)
at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:387)
at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3134)
at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:165)
at com.servoy.j2db.scripting.ScriptEngine.executeFunction(ScriptEngine.java:528)
at com.servoy.j2db.FormController.executeFunction(FormController.java:4063)
at com.servoy.j2db.FormController.executeFunction(FormController.java:3942)
at com.servoy.j2db.FormController.executeFunction(FormController.java:3864)
at com.servoy.j2db.FormController$ScriptExecuter.executeFunction(FormController.java:3719)
at com.servoy.j2db.ui.BaseEventExecutor.fireEventCommand(BaseEventExecutor.java:271)
at com.servoy.j2db.ui.BaseEventExecutor.fireActionCommand(BaseEventExecutor.java:217)
at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor.onEvent(WebEventExecutor.java:404)
at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor$2.onEvent(WebEventExecutor.java:174)
at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:312)
at org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:157)
at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1279)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1358)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1465)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:486)
at com.servoy.j2db.server.servlets.Zl.doGet(Zl.java:7)
at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:138)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:554)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Unknown Source)
Basically, as if the server is trying to initialize first the second variable while the first one is not yet available?
After the first error, there is a second one:
[ERROR] Caught unhandled exception: org.mozilla.javascript.EcmaError: TypeError: Cannot read property "prop" from (someMethodName#580)
The second error is a fall off from the first one - basically the form variable OtherFormVar failed to initialize and is null.
As far as we can tell, we did not have this issue prior to 6.0.6
My question is, why the same code works in Servoy Developer and fails in Servoy App Server? Is our code correct (can we reference one form variable in the initialization of another - seems like this was OK before 6.0.6)
rossent:
Basically, we have on form variable referencing another variable from the same form like this:
looking at the code i don’t think we explicitly support variables pointing to other variables
Because currently the script variables are just created but especially on the server side we don’t really explicitly order it based on the line number (we don’t have that property when its in the repository)
The thing we make sure is that when the variables are created all the functions are there.
jcompagner:
rossent:
Basically, we have on form variable referencing another variable from the same form like this:looking at the code i don’t think we explicitly support variables pointing to other variables
Because currently the script variables are just created but especially on the server side we don’t really explicitly order it based on the line number (we don’t have that property when its in the repository)The thing we make sure is that when the variables are created all the functions are there.
If you are saying that referencing one form variable in the initialization of another is not supported, then there should be a warning/error in the source code and the code should not work in Servoy Developer.
However, we definitely would like to be able to use the code above - it is a perfectly valid JavaScript code and works as expected in Servoy Developer. What would it take to make that happen? You mentioned that on the Server the only thing which you make sure is the functions are available when variables are initialized. What will happen if we use something like this:
var firstVar = 1;
var secondVar = getDefaultValue();
function getDefaultValue()
{
return firstVar;
}
Is this supported?
no that can lead to the same problem because if somehow the second variable is initialized before the first then the first will not be there.
and you have here a sample that already shows that this is very hard to catch (and make an error in the developer)
jcompagner:
no that can lead to the same problem because if somehow the second variable is initialized before the first then the first will not be there.and you have here a sample that already shows that this is very hard to catch (and make an error in the developer)
In that case the only safe option for now is to not allow any references to functions or other variables in the initialization of Servoy form/global variables. It should be possible to create a warning for that.
As a side note, I would like to stress the fact that this different solution behavior between the Servoy Developer and Servoy App Server is very bad. Developers write code which does not have any warnings, works as expected in Servoy Developer, all unit tests pass and yet when the code is deployed things break. It would be extremely valuable if developers can run from within the Servoy Developer the code exactly as it would run on a live server (even without debugging support).
Anyone noticed that the property: servoy.branding.windowicon: is not working anymore in a REAL 6.0.6 smart-client??
Can’t set the icon to own anymore…
We have created a case: https://support.servoy.com/browse/SVY-1938
but wanted to know, if others have the same problem.
Harjo:
but wanted to know, if others have the same problem.
Yepp, me too! Don’t get the own set icon.
jcompagner:
mateuServoy2:
ERROR - Debug - calling getFormScope on a destroyed DataAdapterList, formcontroller: FormController[form: [NAME_FORM], fs size:1, selected record: Record[DATA:Row(db:/ivi_gc/tb_pro_tto)[DATA:[…DATABASE_FIELDS ,rollbackChanges,getDataSource,save,getPKs,setFoundset,deleteRecord,getChangedData,setException,getFoundset,getException,isEditing,destroyed], currentRecord: nullthose are just added logging and some checks, so you can ignore it for you solution, i will check this exception out to see if it should or shouldn’t happen.
johan
We are also getting tons of those errors. Any update on them?
you are talking about this stack?
at com.servoy.j2db.dataprocessing.DataAdapterList.getFormScope(DataAdapterList.java:569)
at com.servoy.j2db.dataprocessing.DataAdapterList.valueChanged(DataAdapterList.java:444)
at com.servoy.j2db.scripting.ScriptVariableScope.fireModificationEvent(ScriptVariableScope.java:438)
that one is fixed for 6.0.7
It is a debug log that is in this build. Its not a problem that was introduced in 6.0.6 just a extra information log.
It happens when you show a form, alter it through solution model and call recreateUI() on it, then set a form variable of that form.
If that is the case then the above log happens and that is fixed for the next build.
jcompagner:
It happens when you show a form, alter it through solution model and call recreateUI() on it, then set a form variable of that form.
If that is the case then the above log happens and that is fixed for the next build.
Yes, this is the exact scenario which we have - good to know that this will go away in the next build.
As a side note, I filed two bug cases (SVY-1958 and SVY-1959) related to serious security issues which we see in 6.0.6 (perhaps other versions are affected as well) It will be great if they can be addressed in the next build as well.
We are getting a very strange issue in a solution deployed on a server.
The error which we are getting is:
com.servoy.j2db.persistence.RepositoryException: Cannot work without primaryKey on table xxxxxxxxxx
The problem is that this is not a table, but a database view and in its dbi settings a unique column is set with the row_ident option (see the attached screen shot) and everything works as expected in Servoy Developer and there are no warnings or errors in the source code. This is the first time we are seeing this error and suspect that this could be some sort of bug introduced in 6.0.6
The server log does not say any more about this:
[ERROR] Caught unhandled exception: com.servoy.j2db.persistence.RepositoryException: Cannot work without primaryKey on table 'vw_ac_fiscal_year_period'
Any help resolving this will be greatly appreciated!
rossent:
We are getting a very strange issue in a solution deployed on a server.The error which we are getting is:
com.servoy.j2db.persistence.RepositoryException: Cannot work without primaryKey on table xxxxxxxxxxThe problem is that this is not a table, but a database view and in its dbi settings a unique column is set with the row_ident option (see the attached screen shot) and everything works as expected in Servoy Developer and there are no warnings or errors in the source code. This is the first time we are seeing this error and suspect that this could be some sort of bug introduced in 6.0.6
Turns out there is a bug in the Servoy solution export - information for database views is not included in the export (even if the option “Export all tables from referenced servers” is used) unless there is a form based on the view. A case has been created for this (SVY-1973) and hopefully the issue will be fixed soon. Until this is done, you can use as a workaround dummy forms based on the database views.
Updating from 6.0.0 to 6.0.6 using ‘check for updates’ in the help menu, I get
An error occurred while collecting items to be installed
session context was:(profile=Servoy, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
No repository found containing: osgi.bundle,org.eclipse.equinox.concurrent,1.0.1.R35x_v20100209
what update sites are all enabled? you could try to enable also the eclipse default onces.
