Hi!
My Vaadin stuff is running in production mode. However, I often still see this:
[#|2010-06-12T08:37:20.487+0300|WARNING|sun-appserver2.1|javax.enterprise.system.stream.err|_ThreadID=84;_ThreadName=httpSSLWorkerThread-80-35;_RequestID=71bfdeb3-4afb-4842-8a0a-7413fdba176c;|
com.vaadin.terminal.gwt.server.SessionExpiredException
at com.vaadin.terminal.gwt.server.AbstractApplicationPortlet.findApplicationInstance(AbstractApplicationPortlet.java:730)
at com.vaadin.terminal.gwt.server.AbstractApplicationPortlet.handleRequest(AbstractApplicationPortlet.java:332)
at com.vaadin.terminal.gwt.server.AbstractApplicationPortlet.serveResource(AbstractApplicationPortlet.java:652)
at com.sun.portal.portletcontainer.appengine.filter.FilterChainImpl.doFilter(FilterChainImpl.java:177)
at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:76)
at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:100)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:427)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:875)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:558)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:490)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:382)
at com.liferay.portlet.InvokerPortletImpl.invoke(InvokerPortletImpl.java:615)
at com.liferay.portlet.InvokerPortletImpl.invokeResource(InvokerPortletImpl.java:724)
at com.liferay.portlet.InvokerPortletImpl.serveResource(InvokerPortletImpl.java:498)
at com.liferay.portal.action.LayoutAction.processPortletRequest(LayoutAction.java:672)
at com.liferay.portal.action.LayoutAction.processLayout(LayoutAction.java:459)
at com.liferay.portal.action.LayoutAction.execute(LayoutAction.java:195)
....
And users often see red alert “Session Expired”. Logs are taking disk space, while this message looks not that much useful.
How to turn off that red alert (Liferay takes care about alerting by itself in more sophisticated way by giving a chance to prolong session etc) as well as how to turn off these huge tracebacks? Are there any other options in web.xml or elsewhere to suppress all of this?
To be specific, in my very humble voice here, printing out entire 10-screen traceback into the log is certainly
not any good idea :
} catch (final SessionExpiredException e) {
// TODO Figure out a better way to deal with
// SessionExpiredExceptions
System.err.println("Session has expired");
e.printStackTrace(System.err);
}
At least, production mode
should suppress the traceback completely (message can still persist, if you set “verbose production mode”).
Update: Many kind :vader: :vader: :vader: thanks to those, who did this. It rotates log 500 times and generates 1G log daily. I solved this by removing this thing :what: by recompiling entire Vaadin from the sources.
I agree that the stack trace is generally not of interest in a non-dev environment. Where you where when it occurred is not something that really can be fixed since you can be anywhere your application allows when the session expires.
And it would be really nice to have an option to get rid of the red session expired alert that requires a click before taking the action I’d like to just happen. In our case, on session expiration, we show a logoff page that explains the session expired with the ability to login again, but it would be nicer to have it just go there than give them an error they have to click through first. Or perhaps it could be just a notification that is shown briefly and doesn’t require a click to handle.
When using the Vaadin Directory or Sampler, I routinely get this error when I return since I keep them open in a tab, and it would surely be better to just have a new session started and then process the request.
For those who want this error (perhaps as the default behavior for consistency), it should be allowed, but when we set up our CustomizedSystemMessages.setSessionExpiredURL, perhaps we could set an option about whether to show the red alert and/or stack trace. For those of us who require session expiration for security reasons that force user logoffs after X amount of non-use, this is something that’s expected, not really a troubling exception.
IMO and from a usability POV, that would be awful - if the user has entered some data, e.g. written a long forum post, and then leaves the app for a while and the session expires, there would be no way for him to recover the lost data. That’s why we display the notification, so the user has even a slight change of copying the data he’s entered.
I do agree that it could be a lot more nicely designed, but I haven’t really gotten into fixing the system messages (the big red box is intimidating).
I’d suggest you take a look at the
SessionGuard add-on (if you haven’t already), which has a keep-alive option for the Vaadin session, making the whole red notification useless.
What makes Vaadin stand out is the outstanding support we get in these forums. Your posts are very abrasive. I fear that if more people take example on you the Vaadin crew will run out of patience. Your points are very valid, but your use and abuse of emoticons and emotive language is, frankly, out of place. I have been around the Internet since before it was even called the Internet (1984), sorry to be so paternalistic.
Uhm, yes. Absolutely. But I think this is not too much valid for a Liferay, that takes care of it?
Correct. As long as it is not a portlet. At the same time, as an idea, I would suggest to integrate session guard to the Form object. So you could do something like:
Form form = new Form();
form.keepSession(); // Until form.commit();
So in this case, when you call this method, Form would heart-bit the server periodically and you could explicitly prolong it. However, Vaadin lives with its own session, right?
How it works with conjunction with Liferay? AFAIK, session will be terminated anyway, as long as entire page was not refreshed?
Dear Jean,
I totally agree. But on the other hand, after I found a zillion logs filled with one single traceback that is actually not really an error of my application(s) and/or platform, saying what I think as well as thinking of what I am saying and the use of the emoticons was honest, open, truthful, sincere, candid, frank, forthright, ingenuous, straightforward, plain-speaking, matter-of-fact, informal upfront, aboveboard and on the level.
I am pretty sure Vaadin guys are actually just smiled. Well, if no, then I am sorry…
But J-F still has a good point, it’s very easy to misinterpret people’s sayings on the internet, I bet we’ve all done that a few times.
Oh, and about Liferay, sorry, I already forgot that you we’re developing for that monstrosity So forget about SessionGuard, Liferay indeed has a similar mechanism for its session. I guess it would be nice to tie the Vaadin session to Liferay’s session, no?
Yeah, that’s why it’s nice to just have an option, but what seems good to you with a forum post isn’t good if the data should be secure. In fact, in our scenario, we actually would prefer to have the app logoff when the session expires so the screen goes away and secures the page rather than leaves it open for view.
This is described in enhancement ticket #4155
SessionGuard is close, but not quite what we need. We definitely DO NOT want the session to be kept alive as that would be a security issue for our app. But I’d like it to be able to force a logoff so we can wipe the browser page and replace it with our logoff page that contains info saying it was logged off for N minutes of inactivity. We can do the logoff page just fine in Vaadin, but only after the user clicks on the red alert and the data has remained exposed for an unknown amount of time (the time between the page being displayed and the user next tries to do something after the session expired), so if SessionGuard could somehow cause the client to send a logoff event that would then cause it to redirect to the logout URL configured in Vaadin, that would be perfect.
And I’m sure the long stack trace exception should be optioned too as it’s very common for sessions to end without that being recorded as some serious abnormality. I mean, I suppose if you use SessionGuard with keep-alive, you’d be interested, but for us, we’d prefer to be able to suppress that detail.
Well, I would not say vaadin.com is that a monster…
Exactly. The thing is that if you do something like polling your portlet — Liferay still ignores it totally and then cuts the session. Hence the traceback.
To fix that, it is needed to call a JavaScript on a client-side:
Liferay.Session.extend();
Hence I am now back to my previous point: how to call a JavaScript periodically in the Vaadin after application has been reloaded [several]
times? There is eval for JavaScript, but it works only on Application init() — that means, if you leave some Liferay’s page to another and then go back — your app lost it.
But in my opinion, this traceback printout in the Vaadin release should be removed ASAP. Or, at least do this printout when it is a dev mode. But in production I even doubt we would need “Session expired” message in the logs — it is like well, expired, now what?
Also, in a Liferay you can do something like putting to -ext environment:
It would be very-very nice if Vaadin would react on that… Currently, if Liferay session is still around, Vaadin complains. So the only workaround is to drop some refresher (indicator) at app main window and poll it each N seconds + automatically extend session at Liferay.
So it will set a session to a 10 minutes, suppress warning and will autoextend the session. But at least if "
Liferay and Vaadin Announce Partnership " is true, then I expect some com.vaadin.liferay library that is wiring integration stuff or something similar. No?
Vaadin 6.5 nightlies already use Java logging APIs instead of printStackTrace() and println() - see
#5715 .
The default log levels should be more sensible, although some fine tuning might still be necessary - feedback on that would be welcome. You can adjust the log levels by category with the standard Java mechanisms in case there are problems with the defaults.
to those, who did this. It rotates log 500 times and generates 1G log daily. 
Well, if no, then I am sorry…
There is eval for JavaScript, but it works only on Application init() — that means, if you leave some Liferay’s page to another and then go back — your app lost it.