logout to expire page on webclient

[lvostinar]

Yes,i have access right to the 'database' folder. This is the message in the "\application_server\postgres_db\postgres_log.txt" file after the install

postgres cannot access the server configuration file "C:/Servoy/application_server/database/postgresql.conf": No such file or directory

Don't you get any error during install ? Or maybe a firewall is blocking the initialization of the postgres database ?

[bobpee]

Hi Laurian,
I have just done yet another install on a 2nd Windows Server 2003, using the latest Servoy 5.2.2 installers that I have - the results is as before, the installation completes leaving the ''C:\Servoy\application_server\database'' folder empty.

Don't you get any error during install ?

No

Or maybe a firewall is blocking the initialization of the postgres database ?

There are no firewalls on the machines being used for these installs.

Maybe Servoy should try that too on a Win Server 2003, for we cannot tell what's going on.

10q 4 the support,

[bobpee]

Hi Laurian,

It looks like the install issue that we having on Windows Server 2003, is somewhat related to this posting :

http://www.servoy.com/forum/viewtopic.p ... 003#p79679

Tell me, is a case already filed on that, that is, on the above issue or should we open one?

10q,

[lvostinar]

Can you try to run from command line (application_server folder as current folder):

postgres_db\bin\initdb.exe -D database -E UNICODE -U DBA

Does this work ? This is the initialization done to the database folder (so is not empty).

[bobpee]

Does this work ? This is the initialization done to the database folder (so is not empty).

Not completely, I have to give full access to user "Everyone" on the folder "\application_server\database'' to get

Code: Select all

postgres_db\bin\initdb.exe -D database -E UNICODE -U DBA

on the command line working, although I am logged in as an admin with unrestricted access - Have also given user "Everyone" permission on the top-level folder "C:\Servoy\".

Now, the files and sub-folders in "\application_server\database'' have been created, but I am unable to even checkout any of the default solutions that shipped with Servoy 5.2.2.

When I click on the "Database Server" node and further click on the "Refresh view (F5)" button in Servoy eclipse, the db nodes which appeared active when Developer was started, change from active to inactive, which is an indication that the default db connections, like "bug_db", "example_data", "log_server" etc. and very importantly "repository_server" never got started successfully.

Does this tell you anything?

[lvostinar]

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 .

[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

Code: Select all

postgres_db\bin\initdb.exe -D database -E UNICODE -U DBA

on the command line with full administrative privileges and not only that, I have to additionally create an "Everyone" use account just before executing the this command line command for it (that is the command "postgres_db\bin\initdb.exe -D database -E UNICODE -U DBA") to work.

After running the

Code: Select all

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.

[lvostinar]

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

Code: Select all

postgres_db\bin\initdb.exe -D database -E UNICODE -U DBA

on the command line with full administrative privileges and not only that, I have to additionally create an "Everyone" use account just before executing the this command line command for it (that is the command "postgres_db\bin\initdb.exe -D database -E UNICODE -U DBA") to work.

After running the

Code: Select all

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.

[ROCLASI]

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.

[bobpee]

@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

[jcompagner]

can't you create first the c:\Servoy dir with all the "Everyone" rights and then install?

[bobpee]

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.

[bobpee]

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 :

Code: Select all

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 :

1. 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;

2. 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 = <null>, 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 = <null> }
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.

[jcompagner]

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()

[bobpee]

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.