Our vaadin 6 application runs in a browser pop up window provided by another web app. However, that web app is not aware of when our application is completed so the responsibility to close the browser pop up is on us. We did that in the vaadin 6 by using setLogoutURL method to redirect to another servlet after vaadin application is closed and run JS command window.close() from that servlet. I didn't find similar concept of setLogoutURL in vaadin 8. What is the replacement for that in the same scenario? Basically, I am looking for a hook that can run a JS command to close the browser pop up after vaadin UI is properly closed. I am assuming the following code will not work.
myUI.close();
JavaScript.getCurrent().execute("window.close()");
// let this thread go back to vaadin framework here
Because the close() and execute() may be in a race.
In Vaadin 8 the best practice for logout procedure is indeed different. You should invalidate http session via Vaadin session and after use set location with logout url.
vaadinSession.getSession().invalidate();
ui.getPage().setLocation("");
I found that the solution given in Answer 1 is not completely correct. When running the code given in the solution, an internal error occurs. The following code will work, basically not invalidate the session but only setLocation.
ui.getPage().setLocation("page1");
ui.close();
So the replacement of vaadin 6 setLogoutURL() is ui.getPage().setLocation("page1") in vaadin 8.
Related
I have deployed my application and it seems to be stuck in an infinite loop showing the 'insecure websocket' message in the screenshot.
I read on another post that ws:// needs to be set to wss:// but I've no idea where this JS code in the other screen shot exists in the project..
This is a .Net core MVC application
I am on an update from vaadin 6 to vaadin 7 and I am trying to find a way to debug the project on the client side. I have tried to launch the debug procedure , but with no effect. I am using Windows 8 and when trying to install the gwt-plugin I see the message:
"The installation of this software is not allowed on this machine".
Therefore I want at least to be able to send messages in the debug window, as with VConsole in vaadin 6. Strangely this deprecated in vaadin 7 class does not respond in vaadin 7 project in my working environment, namely I cannot see the messages anywhere. Any possible reason of that?
It is proposed though to use Logger instead, but I still cannot understand two things:
1) How should the logging.properties look like?
2) Where I see the output of logging messages?
Any other sugesstions would be appreciated.
VConsole.log - whilst deprecated in Vaadin 7- still works. Two things to bear in mind
1) The webapp cannot be in "production" mode - i.e. the productionMode in web.xml must be set to false
2) Typically, you need to be in Debug mode - i.e. add the debug parameter to the request URL in the browser e.g. http://localhost:8080/my-application?debug
See this page in Vaadin Book for more details.
The debug logging will appear in the debug window that appears inside your application. It should also appear in the javascript console of the browser.
I'm developing an Ajax Web Application with Grails 2.2.3 Backend on a Tomcat 7 Servlet Container. As I ran the application with grails run from my IDE everything worked like a charm (i use the tomcat-grails-plugin which is providing a Tomcat 7 implementation).
Now if I deploy my Application to a standalone Tomcat 7 I'm not able to work with the HttpSession anymore as Tomcat is creating a completely new session on every single Ajax request which makes it impossible for me to work with the session object anymore. As I guess that I'm not the only one who deploys an Ajax Application at a Tomcat 7 I wanted to ask here if anybody could give me some advice on how to solve this problem?
Is the great invention of preventing Session Fixation by making it impossible to work with Session at all?
I still want to be able to use HttpSession in the way it was meant to be, with this behaviour the idea of a Session gets ad absurdum (in my opinion) if I can't save session related data to it...
Am I seeing something wrong? Am I doing something wrong?
UPDATE
After some research I found out that only a POST request triggers the creation of a new session in Tomcat... can anybody explain this behaviour?
After some more research (even through the source code of the authenticator classes (http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/java/org/apache/catalina/authenticator/)) I realized that it has to do something with the Realm declared in the server.xml file which affects all other webapps in the same [engine]/[host] and is there by default to be used with the Tomcat Manager.
As long as I only send GET request everything works well, but if I send a POST request a new Session is created but as I'm not changing the page I'm on (since it's a so called "single page application" I'm always on the same index.gsp page) Tomcat treats it as a failed login attempt and keeps on creating new Session objects for every POST request - and there are a lot of POSTs on my page ;)
So, as a quick fix I removed the manager from the webapps directory and removed the Realm declaration from the server.xml as I'm already creating a new Session on a successful login attempt at my Grails backend myself.
I got few doubts on sessions in JSF and/or in general.
First up, does session gets created on load of an web app in AS/servlet container? Meaning, after I do right click- run as - run on server and the app is started and synchornised?
Or does it get created after the web app is loaded and the defined welcome page is displayed and then the client makes a request?
Second: I was looking into the issue of "Cannot create a session after the response has been committed" in jsf.
I was trying to reproduce the issue by doing this given in the following site,
http://java.net/jira/browse/JAVASERVERFACES-2215
But, I didnt get any error as mentioned above. I tried with all bean scope.
Was the session created?
This is the code.
<h:body>
<h:form id="test">
<p:growl id="msg"></p:growl>
<h:outputText value="#{myTestBean.exceedBuffer}" />
</h:form>
</h:body>
bean code is.
public String getExceedBuffer() {
int size = FacesContext.getCurrentInstance().getExternalContext().getResponseBufferSize();
char[] chars = new char[size];
Arrays.fill(chars, 'x');
return new String(chars);
}
My understanding is the following,
First when the app is loaded the servlet container or an AS creates a session and a sessionID(JSESSIONID) and puts it in server memory. So the initial page gets loaded up anyhow, meaning even if the response buffer is overflowed or not but the session wont be created. Now, when the client makes a request on this page, since the session was not created, the error occurs. But, I tried even doing this by
<p:commandButton actionListener="#{myTestBean.onSelect}" update=":test"></p:commandButton>
and in onSelect method just entered a dummy code. Even now the page displayed as usual.
Well, that was when I was completely lost. Can someone pls help me on this? Thanks in advance.
First up, does session gets created on load of an web app in AS/servlet container? Meaning, after I do right click- run as - run on server and the app is started and synchornised?
Or does it get created after the web app is loaded and the defined welcome page is displayed and then the client makes a request?
It's created on start of the HTTP session, not on webapp's startup (that's the application scope). Basically, when request.getSession() is called for the first time and the HttpSession hasn't been created yet. This all is handled by the Servlet API which JSF is using under the covers. So the following answer should help in understanding how it works: How do servlets work? Instantiation, sessions, shared variables and multithreading
Second: I was looking into the issue of "Cannot create a session after the response has been committed" in jsf.
I was trying to reproduce the issue by doing this given in the following site, http://java.net/jira/browse/JAVASERVERFACES-2215
But, I didnt get any error as mentioned above. I tried with all bean scope. Was the session created?
You will get this error when the HttpSession isn't created yet at the moment the response is committed. That you didn't get this error can only mean that the session has already been created beforehand. You need to test it on a freshly started webapp and the session shouldn't be created yet. Note that some servers by default stores sessions on shutown/restart. You'd need to disable this or to remove the JSESSIONID cookie in your browser before sending the first request on this test page. Restarting the webbrowser or using a different one should also force a fresh new session.
If I try to implement this simple-as-possible example:
Update Content with AJAXRefreshRequest
it does not work with Websphere Portal 6.1.0.3 on Application Server 6.1.0.27. The content is updated only the first time. In every further request the Bean is not updated from the inputText.
Oh no.
I found out that it's working fine with IE 8 in compatibility mode. The AJAX-Components are obviously not compatible to IE 8 (native).