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.
Related
I have a page which will send some ajax request to my Jetty7.6.9 server. All of them containing a COOKIE named JSESSIONID so that the server knows the request is logged in.
But sometimes, the method org.eclipse.jetty.server.Request.getCookies() returns an empty Cookie[]. I set a breakpoint and checked the _connection._requestFields and I found the Cookie right there, but Request.getCookies() cannot fetch it or parse it.
The situation can happen in any one or more ajax request in that page, can happen in any time, can happen in both windows and linux. It seems that it's a random case, and even when I dropped the frame at the breakpoint to the pre line, it would run correctly when it ran to the same place, so I think it's an issue about synchronize/concurrent.
I didn't find the same case in jetty bug list.
Is it a bug? What can I do to verify or repeat it? How to fix it?
(For some reason,maybe I cannot update the Jetty version for our system.)
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 am getting a 'session state not available in this context' error.
The error is nested in the sender parameter of a number of methods within the Global.asax file:
Application_BeginRequest
Application_AuthenticateRequest
Session_Start
Application_Error
The error happens on the very first page load (and all page loads thereafter).
I've added a completely new and empty page, WebForm1.aspx, to the project and made it my start page.
You'd think nothing could go wrong on an empty page. No code of mine is executed, as far as I can see, when loading an empty page. But I'm still getting the session state error.
My project works totally fine. No error pages are shown. There is no incorrect behavior at any time.
But the fact that this session error shows up in the sender parameter of my current project bugs me. This error is not generated in a blank, new project.
What can possibly be the cause of this error in my current project?
How can I trace where the error occurs? I can't set breakpoints in ASP.NET code that's under the hood. Or can I?
Here's my session configuration:
<pages enableSessionState="true" />
<sessionState mode="InProc" cookieless="false" timeout="20" />
Update:
I just found out that a brand new blank project also has this error in the sender object. It's visible in the Application_BeginRequest and Application_AuthenticateRequest methods. But the blank project isn't generating the Application_Error event, like my other project is.
You are requesting for session state too early in the cycle. you need to do it in Application_AcquireRequestState
"If a tree falls in a forest and no one is around to hear it, does it make a sound?"
Don't watch the Session property at the point where it is not available yet.
We are experiencing issues with sudden logouts. It came with a version switch, previous application ran JSF 1.2 while this one runs JSF 2.1. Since this was a major refactoring any specific code changes are impossible to track. But a major update to code has taken place (all though mostly views and not beans).
We have control over every place were we invalidate sessions, they are logged and are not the cause.
We use a session-bean for authentication, it implements HttpSessionBindingListener.
We log valueUnbound and can tell that the logout was caused by end of life for the session. We are struggling to find the cause.
Tomcat 6.0.26 has been profiled and everything seems normal. This also occurs for small customers with little load.
<session-timeout>
Is appropriately set to 30 minutes.
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
Not sure this has any impact but they all use client.
We tried bypassing load balance but the problem still occurs.
How could randomly my session is null?
We tried the suggested flag, emptySessionPath but it didnt help.
Further we are not sure how to proceed with logging the request headers as suggested.
In our application I tried to kill the session-cookie for debugging reasons:
HttpServletResponse response = (HttpServletResponse) getFacesContext().getExternalContext().getResponse();
Map<String, Object> cookies = getFacesContext().getExternalContext().getRequestCookieMap();
Cookie cookie = (Cookie) cookies.get("JSESSIONID");
cookie.setValue("");
cookie.setPath("/");
cookie.setMaxAge(0);
response.addCookie(cookie);
Seems like it's either not destroyed or recreated. I also tried delete cookies in the browser while logged in, still no problem.
Would appreciate some concrete tips on how to debug this further? Basically now all we know is valueUnbound is called all of the sudden.
Tomcat 6.0.26
JSF 2.1.10
Cheers
Was embarrassingly enough one of the Filters after all. I guess that's what can happen when everyone assumes everyone else checked something
I have an application that supports multiple types of login using username+password, using open id, etc.
Technology used : GWT.
Login url = Login.html and Login Failure url = Login.html?error=true
as shown above, the login page (made in GWT) can determine that whether its just opened for first time or whether its opened after an error.
However, i am not able to determine the type of error
a similar post here: Post link shows how to set the message to a custom one,
But i require a programming approach:
eg if open id login fails, I must show user a panel to enter his name, etc.
Is there any way to achieve this ?
For those not knowing GWT:
Let me change the problem a bit, suppose that my login page is not a JSP but a servlet, how do i write code in my servlet that is able to access the type of error occured during login? (Actually this does not solve the GWT issue, but it may give me a 'heads up' of what is needed to be done.)
Well you don't have to redirect your failed login to a jsp - it can be any URI. For instance you can redirect them to the URI http:/www.myserver.com/failed which is a completely different servlet (could be a servlet that does nothing but sends a redirect to a new URL even).