Java error in application server log, no problem in dev. env

Hi,

In have these lines showing in the application server log but everything works fine in the dev. environment. The problem arises when trying to access the form ‘consultations_frat’.

Application server is 6.1.4 running in a Mac mini 10.6.8 with Java 1.6.

2013-03-17 17:11:15,274 ERROR [http-8080-5] com.servoy.j2db.util.Debug - Impossible d'initialiser le scope du formulaire ou de créer JSForm: consultations_frat [1ABD47B0-8D80-4E28-A85D-282F9AEFF0DC pax]
java.lang.NullPointerException
	at com.servoy.j2db.util.Utils.mapRemoveByValue(Utils.java:2641)
	at com.servoy.j2db.scripting.LazyCompilationScope.remove(LazyCompilationScope.java:272)
	at com.servoy.j2db.scripting.LazyCompilationScope.put(LazyCompilationScope.java:108)
	at com.servoy.j2db.scripting.LazyCompilationScope.createScriptProviders(LazyCompilationScope.java:66)
	at com.servoy.j2db.scripting.LazyCompilationScope.<init>(LazyCompilationScope.java:56)
	at com.servoy.j2db.scripting.ScriptVariableScope.<init>(ScriptVariableScope.java:71)
	at com.servoy.j2db.scripting.FormScope.<init>(FormScope.java:56)
	at com.servoy.j2db.FormController.initForJSUsage(FormController.java:4622)
	at com.servoy.j2db.scripting.CreationalPrototype.get(CreationalPrototype.java:166)
	at org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:2141)
	at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1518)
	at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1505)
	at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:1408)
	at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:837)
	at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:158)
	at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:406)
	at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3192)
	at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:156)
	at com.servoy.j2db.scripting.ScriptEngine.executeFunction(ScriptEngine.java:574)
	at com.servoy.j2db.FormController.executeFunction(FormController.java:4933)
	at com.servoy.j2db.FormController.executeFunction(FormController.java:4814)
	at com.servoy.j2db.FormController.executeFunction(FormController.java:4681)
	at com.servoy.j2db.FormController$ScriptExecuter.executeFunction(FormController.java:4526)
	at com.servoy.j2db.ui.BaseEventExecutor.fireEventCommand(BaseEventExecutor.java:276)
	at com.servoy.j2db.ui.BaseEventExecutor.fireActionCommand(BaseEventExecutor.java:218)
	at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor.handleEvent(WebEventExecutor.java:459)
	at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor.onEvent(WebEventExecutor.java:400)
	at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor$2.onEvent(WebEventExecutor.java:180)
	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.Zt.doGet(Zt.java:16)
	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:103)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:615)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:861)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:606)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
	at java.lang.Thread.run(Thread.java:680)
2013-03-17 17:11:15,309 ERROR [http-8080-5] com.servoy.j2db.util.Debug - TypeError: Cannot read property "controller" from undefined (btn_show_consultation#50) [1ABD47B0-8D80-4E28-A85D-282F9AEFF0DC pax]
org.mozilla.javascript.EcmaError: TypeError: Cannot read property "controller" from undefined (btn_show_consultation#50)
	at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3760)
	at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3744)
	at org.mozilla.javascript.ScriptRuntime.typeError(ScriptRuntime.java:3765)
	at org.mozilla.javascript.ScriptRuntime.typeError2(ScriptRuntime.java:3781)
	at org.mozilla.javascript.ScriptRuntime.undefReadError(ScriptRuntime.java:3792)
	at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1503)
	at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:1408)
	at script.btn_show_consultation(btn_show_consultation:50)
	at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:837)
	at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:158)
	at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:406)
	at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3192)
	at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:156)
	at com.servoy.j2db.scripting.ScriptEngine.executeFunction(ScriptEngine.java:574)
	at com.servoy.j2db.FormController.executeFunction(FormController.java:4933)
	at com.servoy.j2db.FormController.executeFunction(FormController.java:4814)
	at com.servoy.j2db.FormController.executeFunction(FormController.java:4681)
	at com.servoy.j2db.FormController$ScriptExecuter.executeFunction(FormController.java:4526)
	at com.servoy.j2db.ui.BaseEventExecutor.fireEventCommand(BaseEventExecutor.java:276)
	at com.servoy.j2db.ui.BaseEventExecutor.fireActionCommand(BaseEventExecutor.java:218)
	at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor.handleEvent(WebEventExecutor.java:459)
	at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor.onEvent(WebEventExecutor.java:400)
	at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor$2.onEvent(WebEventExecutor.java:180)
	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.Zt.doGet(Zt.java:16)
	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:103)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:615)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:861)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:606)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
	at java.lang.Thread.run(Thread.java:680)

Many thanks for any help.

Please create a case for this.
There is something strange here - it seems that you have a form method with no name… which shouldn’t be possible. A sample solution would be needed to see what’s going on.

You could also check the workspace and app. server log files after exporting / importing your solution to see if something unexpected happened.

viewtopic.php?f=8&t=19464

that’s seems to be the same.
Somehow your repository is not correct, you could delete the current solution and do a clean import again.

Thanks for the follow-up. It worked !

Hi,

We get the same problem after importing a solution on the server (without deleting the current solution). We delete the solution every time and re-import the solution which is not a nice solution for this issue. Is there a proper fix for this issue or do we know what exactly is not right in the repository database?
btw, We are running Servoy 7.4.1.

Thanks,

there is already a case for this, but we really need 2 things:

1> repository dump that is just before the solution import (so the repo that is correct)
2> the solution that will be imported

and then the steps where to see it in the solution.

so that we can do the import a few times to see what really happens.

Thanks for the reply Johan. I didn’t know there is already a case for this issue (although the case is closed and i assume no one is working on it any more).

I need to make a sample solution to reproduce it (it’s not an easy case to make a simple sample solution for it). I’ll post the sample solution here when it’s ready.

Now I have just had the same problem (on a production server, duh).
It doesn’t just happen every time and I don’t think I can dedicate enough time to reproduce the issue with a sample solution - it may well be specific to our particular solution and I can’t really share that code.
So how do we deal with it?
We also have a similar issue that stuffs up a particular form in our solution.
It would be nice if we could further discuss our options with Servoy.

the only option is that we have a repository database dump before you do an import
and then the solution file that is imported. And then the steps to show it in the solution

There is not really another way for use to proceed with this. This just happens for some customers now and then.

The only direct fix for now is to delete the solution first and do then the import (so that no merge of stuff happens)

jcompagner:
the only option is that we have a repository database dump before you do an import
and then the solution file that is imported. And then the steps to show it in the solution

There is not really another way for use to proceed with this. This just happens for some customers now and then.

The only direct fix for now is to delete the solution first and do then the import (so that no merge of stuff happens)

Does it go under a non-disclosure agreement of some sort? You know, commercial application code is what we’re talking about.

yes, thats fine, we get more of these solutions from customers.
We just use it for fixing the bug and then everything is deleted again.

But for this we really need to have a db dump before you do an import of the one that does go wrong.
So if you want to test this, always make a backup of your db just before doing an import, and if it goes wrong send us that db dump and the thing that you imported. (and hopefully when you do that the exact same error happens again)

jcompagner:
yes, thats fine, we get more of these solutions from customers.
We just use it for fixing the bug and then everything is deleted again.

But for this we really need to have a db dump before you do an import of the one that does go wrong.
So if you want to test this, always make a backup of your db just before doing an import, and if it goes wrong send us that db dump and the thing that you imported. (and hopefully when you do that the exact same error happens again)

Thanks, Johan.
Will do.