Weird traceback says "Should never happen"

Hi!
After I get rid of “Session Expired” notice that generated me 1G logs/day, now another one huge traceback frequently comes into my logs, although things generally working fine. What does that mean and how to get rid of it?

So should I worry about this, or this is just nothing serious?

[#|2010-06-20T10:06:19.293+0300|WARNING|sun-appserver2.1|javax.enterprise.system.stream.err|_ThreadID=49;_ThreadName=httpSSLWorkerThread-80-39;_RequestID=b5d02e71-c1ba-434b-8c65-8da7af4ebbc7;|
General security exception, should never happen|#]

[#|2010-06-20T10:06:19.294+0300|WARNING|sun-appserver2.1|javax.enterprise.system.stream.err|_ThreadID=49;_ThreadName=httpSSLWorkerThread-80-39;_RequestID=b5d02e71-c1ba-434b-8c65-8da7af4ebbc7;|
com.vaadin.terminal.gwt.server.AbstractCommunicationManager$InvalidUIDLSecurityKeyException: Security key mismatch
        at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.handleVariables(AbstractCommunicationManager.java:1027)
        at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.doHandleUidlRequest(AbstractCommunicationManager.java:587)
        at com.vaadin.terminal.gwt.server.PortletCommunicationManager.handleUidlRequest(PortletCommunicationManager.java:245)
        at com.vaadin.terminal.gwt.server.AbstractApplicationPortlet.handleRequest(AbstractApplicationPortlet.java:457)
        at com.vaadin.terminal.gwt.server.AbstractApplicationPortlet.serveResource(AbstractApplicationPortlet.java:725)
        at com.sun.portal.portletcontainer.appengine.filter.FilterChainImpl.doFilter(FilterChainImpl.java:177)
...




And it would be really-really helpful if someone would cleanup these tracebacks, once things are in production. Notices are OK (if production admin wants them), but entire traceback should be thrown only if there is a real crash and things are really dangerous or critical. However, putting everything to the logs and making it even not bypassable is really harmful, because one thing when you have 1-10 users in dev environment, and other deal when you have 20-50K users in production. Hence I suggest production mode not just true/false, but something like “verbose”, “errors-only”, “quiet” etc. :slight_smile:


Somebody must love print the garbage in the logs, no matter happens:

} catch (final GeneralSecurityException e) {
	                // TODO Figure out a better way to deal with
	                // GeneralSecurityExceptions
	                System.err
	                        .println("General security exception, should never happen");
	                e.printStackTrace(System.err);

JFYI: that’s just some more GB of garbage in the logs… :frowning:

We should definitely get rid of all the System.out / System.err / e.printStackTrace() in Vaadin core and use some kind of a logging framework or at least centralize logging and give the user some control over it. One issue, though, is that different projects using Vaadin use and prefer different logging frameworks.

I believe this will happen latest in Vaadin 7, not sure if before.

Look at SL4J please, pretty please.

I believe in
The Book of Vaadin
as well… :rolleyes:
But normally, if you just do a very traditional way without doing anything third-party components, like:

Logger.getLogger(YourClass.class.getName()).log(Level.INFO, null, yourExceptionInstance);

…then at least it is possible to say to appserver: “Hey, dear, please shut up on Level.INFO, but tell me stories only when Level.SEVERE”. Howevr, if you do an explicit printing to STDERR (which is log redirected), then things are getting totally out of control and really hurts. Besides, decent IDE should scream on such code (NetBeans does) offering you to do not do this.