It seems your user doesn’t have enough permissions to that folder (C:\Servoy). This is why the database is not initialized. The previous command only initializes, does not create any database (more commands like that are executed during install). So, please try to give more rights to your user or install to a different folder .
Hi Laurian,
That is not likely, for I am running the installation process as an Administrator without any restrictions. The files and sub-folders in the "\application_server\database’’ only get created after running ```
postgres_db\bin\initdb.exe -D database -E UNICODE -U DBA
After running the ```
postgres_db\bin\initdb.exe -D database -E UNICODE -U DBA
``` command, the files/sub-folders get created alright, but as I wrote earlier, none of the default dbs is able to start with the Developer.
We have never had such a situation with previous installers, they have also worked out-of-the-box.
I suppose you'd agree with me that there appears to be a problem with the current installer on Windows Server 2003 OS.bobpee:
Hi Laurian,That is not likely, for I am running the installation process as an Administrator without any restrictions. The files and sub-folders in the "\application_server\database’’ only get created after running ```
postgres_db\bin\initdb.exe -D database -E UNICODE -U DBAAfter running the ``` postgres_db\bin\initdb.exe -D database -E UNICODE -U DBA ``` command, the files/sub-folders get created alright, but as I wrote earlier, none of the default dbs is able to start with the Developer. We have never had such a situation with previous installers, they have also worked out-of-the-box. I suppose you'd agree with me that there appears to be a problem with the current installer on Windows Server 2003 OS.
The Servoy installer doesn’t touch user rights. If the user doesn’t have enough rights the installer will fail. The command was just a test to see what is going on, as I said it doesn’t create the databases. You should install Servoy in a folder or with user where you have enough rights.
Just to clarify:
PostgreSQL doesn’t ‘start’ databases like Sybase does. PostgreSQL works with a database cluster where all databases are located. When the cluster is up (i.e. PostgreSQL is running) then all databases in that cluster are available.
For this same reason you can create a database and don’t have to add it to some config file and restart your database services like with Sybase. Any newly created databases are ‘live’ right after you create them.
As for the absence of the default/demo databases. The initdb command ONLY creates an empty database cluster. After this PostgreSQL can be started with this cluster and you can create new databases in there.
Since the installer couldn’t create the cluster to begin with you won’t have any default/demo databases either.
Hope this makes things more clear.
@Robert n @Laurian,
Thnx for the clarifications. thnx very much.
The issue with the install on Windows Server 2003 not working has been resolved. This is how we got it working (The approach listed below may be crude, but never mind, it saved the situation):
1. Do a normal Servoy install into a folder like “C:\Servoy” and corresponding workspace into a folder like “C:\servoy_workspace”;
2. Servoy will create a “C:\Servoy\application_server\database” folder which maybe empty. If it is, proceed to step (3). If this folder is not empty, you installation may have completed successfully. Proceed to step (6).
3. On your “C:\Servoy” folder , even if you are logged in as an Administrator, still make sure that there is an “Everyone” user to the folder “C:\Servoy” security settings with full/unrestricted access/previleges.
4. Get to the directory "C:\Servoy\application_server" on the command line and execute the command “postgres_db\bin\initdb.exe -D database -E UNICODE -U DBA”. This will create the files/sub-folders that didn’t get created in in step (2).
5. Run the Servoy installer once again, pointing it to the same directory as in step (1) - this will overwrite the files/sub-folders under step (2). By this time also, the folder “C:\Servoy\application_server\database” would definitely have files/sub-folders that at least the “servoy_repository” server will need to start.
6. You’re done.
Hope nobody is angry with us
Thanks
can’t you create first the c:\Servoy dir with all the “Everyone” rights and then install?
You are right, Johan, that works too - If only we had thought that necessary from the onset.
As I wrote earlier, we normally install Servoy on our Windows Server 2003s as Administrators (with no restrictions) and we allow Servoy to create the install folder during the installation.
We have never had to create an “Everyone” security access on a pre-existing install folder before an install. However, with the latest installers on Windows Server 2003s, it is necessary to do that, and give it an “Everyone” security access, before proceeding with the installation.
Thanks for the tips, thank you.
I will later post our findings on the “Logout” stuff that necessitated the installation of Servoy 5.2.2 - I have this version now running and will post a feedback later.
10q.
Hi Johan,
I have done some more testing, using Servoy 5.2.2 (and same code) on a Windows Vista and Windows Server 2003. In both cases, a call to :
if (application.getApplicationType() == APPLICATION_TYPES.WEB_CLIENT) {
application.showURL('http://www.mydomain.nl', "_self");
application.exit();
}
to logout of our solution still seems to throw error on “application.exit()” and a redirection to an URL like “http://www.mydomain.nl” does not work anymore in a webclient. Note the following strange behavior though :
-
When our solution is started using an ip-addressing like http://10.0.0.12/servoy-webclient/solut … mysolution
, a logout attempt redirect to any URL that I put in the (), although the Server still throw the error as listed below on the ‘admin’ page; -
When our solution is started using a public-domain like http://www.mydomain.nl/servoy-webclient … mysolution
, a logout attempt throws an “error calling server” shows on top-right corner of the webclient, the user is kept on the solution, the “application.showURL()” does not work, and the Server still throw the error as listed below on the ‘admin’ page;
These are the Server logs on the admin pages of both machines when calls to logouts were made:
Windows Server 2003:
2010-11-09 11:43 http-8088-4 INFO com.servoy.j2db.util.Debug shutDown
2010-11-09 11:43 http-8088-4 WARN com.servoy.j2db.util.Debug Solution already closed, ignoring exception
org.mozilla.javascript.WrappedException: Wrapped com.servoy.j2db.ExitScriptException: Application exit (myappl_exit_method#377)
at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1828)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:199)
at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:353)
at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3666)
at script.myappl_exit_method(myappl_exit_method:377)
at script.onClose(onClose:10)
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:3127)
at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:165)
at com.servoy.j2db.scripting.ScriptEngine.executeFunction(ScriptEngine.java:458)
at com.servoy.j2db.FormController.executeFunction(FormController.java:3972)
at com.servoy.j2db.FormController.executeFunction(FormController.java:3860)
at com.servoy.j2db.FormController.executeFunction(FormController.java:3782)
at com.servoy.j2db.FormController$ScriptExecuter.executeFunction(FormController.java:3637)
at com.servoy.j2db.ui.BaseEventExecutor.fireEventCommand(BaseEventExecutor.java:270)
at com.servoy.j2db.ui.BaseEventExecutor.fireActionCommand(BaseEventExecutor.java:217)
at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor.onEvent(WebEventExecutor.java:348)
at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor$2.onEvent(WebEventExecutor.java:152)
at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:286)
at org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:119)
at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
at com.servoy.j2db.server.servlets.Zl.doGet(Zl.java:15)
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:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
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:849)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Unknown Source)
Caused by: com.servoy.j2db.ExitScriptException: Application exit
at com.servoy.j2db.scripting.JSApplication.js_exit(JSApplication.java:1222)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:179)
… 42 more
2010-11-09 11:43 http-8088-4 INFO com.servoy.j2db.util.Debug Unregistering client: EC965722-8142-473B-9741-51D98B84004C
2010-11-09 11:43 http-8088-4 INFO com.servoy.j2db.util.Debug shutDown
2010-11-09 11:43 http-8088-1 INFO com.servoy.j2db.util.Debug questiondata[1] = 2 ,type: java.lang.Integer
2010-11-09 11:43 http-8088-1 INFO com.servoy.j2db.util.Debug questiondata[0] = ‘Administrators’ ,type: java.lang.String
2010-11-09 11:43 http-8088-1 INFO com.servoy.j2db.util.Debug used sql select user_uid from servoy_users su, servoy_user_groups sug, servoy_groups sg where sg.group_name = ? and sg.group_id = sug.group_id and sug.user_id = su.user_id limit ? questiondata.length 2
2010-11-09 11:43 http-8088-1 INFO com.servoy.j2db.util.Debug QuerySet { updates = , select = select user_uid from servoy_users su, servoy_user_groups sug, servoy_groups sg where sg.group_name = ? and sg.group_id = sug.group_id and sug.user_id = su.user_id limit ? [[Administrators,2]] <0^2>, cleanups = }
2010-11-09 11:43 http-8088-1 INFO com.servoy.j2db.util.Debug CUSTOM ELEMENT select user_uid from servoy_users su, servoy_user_groups sug, servoy_groups sg where sg.group_name = ? and sg.group_id = sug.group_id and sug.user_id = su.user_id ([Administrators]) FILTER null
2010-11-09 11:43 http-8088-1 INFO com.servoy.j2db.util.Debug Analysing filters null
2010-11-09 11:43 http-8088-1 INFO com.servoy.j2db.util.Debug sql select CUSTOM ELEMENT select user_uid from servoy_users su, servoy_user_groups sug, servoy_groups sg where sg.group_name = ? and sg.group_id = sug.group_id and sug.user_id = su.user_id ([Administrators])
Windows Vista:
2010-11-09 11:57 http-8080-3 INFO com.servoy.j2db.util.Debug shutDown
2010-11-09 11:57 http-8080-3 WARN com.servoy.j2db.util.Debug Solution already closed, ignoring exception
org.mozilla.javascript.WrappedException: Wrapped com.servoy.j2db.ExitScriptException: Application exit (myappl_exit_method#377)
at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1828)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:199)
at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:353)
at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3666)
at script.myappl_exit_method(myappl_exit_method:377)
at script.onClose(onClose:10)
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:3127)
at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:165)
at com.servoy.j2db.scripting.ScriptEngine.executeFunction(ScriptEngine.java:458)
at com.servoy.j2db.FormController.executeFunction(FormController.java:3972)
at com.servoy.j2db.FormController.executeFunction(FormController.java:3860)
at com.servoy.j2db.FormController.executeFunction(FormController.java:3782)
at com.servoy.j2db.FormController$ScriptExecuter.executeFunction(FormController.java:3637)
at com.servoy.j2db.ui.BaseEventExecutor.fireEventCommand(BaseEventExecutor.java:270)
at com.servoy.j2db.ui.BaseEventExecutor.fireActionCommand(BaseEventExecutor.java:217)
at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor.onEvent(WebEventExecutor.java:348)
at com.servoy.j2db.server.headlessclient.dataui.WebEventExecutor$2.onEvent(WebEventExecutor.java:152)
at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:286)
at org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:119)
at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
at com.servoy.j2db.server.servlets.Zl.doGet(Zl.java:15)
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:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
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:849)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Unknown Source)
Caused by: com.servoy.j2db.ExitScriptException: Application exit
at com.servoy.j2db.scripting.JSApplication.js_exit(JSApplication.java:1222)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:179)
… 42 more
2010-11-09 11:57 http-8080-3 INFO com.servoy.j2db.util.Debug Unregistering client: F6853D6F-F774-4BFB-B883-76A8C00FBC0B
2010-11-09 11:57 http-8080-3 INFO com.servoy.j2db.util.Debug shutDown
Does the above tell something? Is/Are there a/ workaround?
As indicated earlier on, we have been using this very code over and over again and it had worked fine. I don’t suppose that it is an OS or a Servoy version issue (this behavior started showing up recently in our Servoy 5.1.4 and it is still showing in Servoy 5.2.2), at least this time around - that is why I did testing on 2 different Windows OSs - must be due to something else.
If the redirection were to happen and server still threw an error in the server log or admin page, I would say that we’d have managed with that, however, keeping the user still in the solution when the intention is to log out of the solution is what is disturbing.
you have tracing enabled thats why you see that stacktrace
That error can be ignored completely that is irrelevant. (its a exception that should happen)
i will try to reproduce that showURL doesnt work if you call right after that exit()
you have tracing enabled thats why you see that stacktrace
Yes, I had to enable tracing because I wanted to know what was happening - why the sudden “error calling server” on logout in the webclient.
Has the “showURL” in combination to “application.exit()” reproduced anything/something?
Is there any “Prognosis http://bit.ly/9gFHXn” and or workaround this situation?
10q.
i just made a simple solution with a button doing this:
application.showURL(‘http://www.nu.nl’, “_self”);
application.exit();
and it works fine for me.
i just made a simple solution with a button doing this:
application.showURL(‘http://www.nu.nl’, “_self”);
application.exit();and it works fine for me.
That’s right, that’s what we have been doing all the time too and it had always worked fine for us,alas, until recently.
By the way, Johan, have you run your sample solution on a Window Server 2003? This is the OS that we’ve have been doing our staging/testing on and it appears to be giving unpredictable results, at least lately.
We want to be sure that it is nothing like a “Win Server 2003” bug. We test code locally on our Win XPs and Vistas and Win 7 and we get positive results, But on Window Server 2003 with same code, this behavior is showing up.
Are we talking here about the server or a browser (so a client) on Win2003?
it really shouldnt matter if win2003 is the server and the browser is XP or Win7… compared to another server machine and the browsers are XP or Win7
The response that is generated by a serer should be exactly the same.
So maybe it is the location that is different? (where the server is?)
The response that is generated by a serer should be exactly the same.
So maybe it is the location that is different? (where the server is?)
I think I am missing this one - can you elaborate a bit more? - you mean the location of our test server? The one in question is on site,that is, where we do our dev work.
I am not concluding, but are you ruling-out that the issue may also not be a-larry-ellison-effect on Win2003Ser? We’aint able to reproduce this behavior on Win Vista/Xp/7 .
win2003 is only the server right? Its not the client (where the browser runs in?)
so that same solution running on Vista/Xp/7 is that on the same network as the win2003 server and the client where you test that redirect on is on the same client (so that is the same browser connecting now to a vista server compared to the win2003 server)??
Hi Johan,
You know what? There’s good news.
Now this is what is happening, we managed to get a workaround for our logout issue:
1. To get our solution centralize a webclient, we have had to embed the call to start Servoy webclient in an