Form clearing out at random

We had an issue reported by a user that as he was in the process of entering data in a form, the form reset all the data, clearing out all the information he had input. Not sure if this is the cause, but the timing coincided with this error in the logs:

[2010-09-16 16:58:24.164]
com.vaadin.event.ListenerMethod$MethodException
[2010-09-16 16:58:24.164]
Cause: java.lang.NullPointerException
[2010-09-16 16:58:24.164]
at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:507)
[2010-09-16 16:58:24.164]
at com.vaadin.event.EventRouter.fireEvent(EventRouter.java:158)
[2010-09-16 16:58:24.164]
at com.vaadin.ui.AbstractComponent.fireEvent(AbstractComponent.java:995)
[2010-09-16 16:58:24.164]
at com.vaadin.ui.Window.fireClose(Window.java:1066)
[2010-09-16 16:58:24.164]
at com.vaadin.ui.Window.close(Window.java:945)
[2010-09-16 16:58:24.164]
at com.vaadin.ui.Window.changeVariables(Window.java:913)
[2010-09-16 16:58:24.164]
at com.vaadin.terminal.gwt.server.CommunicationManager.handleVariables(CommunicationManager.java:751)
[2010-09-16 16:58:24.164]
at com.vaadin.terminal.gwt.server.CommunicationManager.handleUidlRequest(CommunicationManager.java:300)
[2010-09-16 16:58:24.164]
at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:432)
[2010-09-16 16:58:24.164]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:92)
[2010-09-16 16:58:24.164]
at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:106)
[2010-09-16 16:58:24.164]
at com.caucho.server.security.SecurityFilterChain.doFilter(SecurityFilterChain.java:135)
[2010-09-16 16:58:24.164]
at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:183)
[2010-09-16 16:58:24.164]
at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:173)
[2010-09-16 16:58:24.164]
at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229)
[2010-09-16 16:58:24.164]
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:274)
[2010-09-16 16:58:24.164]
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:514)
[2010-09-16 16:58:24.164]
at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:527)
[2010-09-16 16:58:24.164]
at com.caucho.util.ThreadPool.run(ThreadPool.java:449)
[2010-09-16 16:58:24.165]
at java.lang.Thread.run(Thread.java:619)
[2010-09-16 16:58:24.165]
Caused by: java.lang.NullPointerException
[2010-09-16 16:58:24.165]
at com.cbs.madison.MadisonApplication$1.windowClose(MadisonApplication.java:66)
[2010-09-16 16:58:24.165]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[2010-09-16 16:58:24.165]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[2010-09-16 16:58:24.165]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[2010-09-16 16:58:24.165]
at java.lang.reflect.Method.invoke(Method.java:597)
[2010-09-16 16:58:24.165]
at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:487)
[2010-09-16 16:58:24.165]
… 19 more

The actual code on line 66 is:


getMainWindow().getApplication().close();

from this listener method within init() of the Application subclass:


this.getMainWindow().addListener(new Window.CloseListener() {
            public void windowClose(CloseEvent e) {
                // TODO Auto-generated method stub                
                getMainWindow().getApplication().close();
            }
});

Anyone experience this as well?

getMainWindow() seems to return null. That happens if the component your asking getMainWindow() from is not actually attached to the view (no addComponent() on “this”).

Anyhow, it don’t see why a NPE would clear a form. Doesn’t really make sense.

Gathered more info from the users who reported this, they describe it as the form clearing out while they were in the middle of entering data into it. In reality, the form is completely removed from the page. The behavior seen is as if the user hit the browser reload button, even though he didn’t. I believe this has to do with the fact that the app overrides the getWindow(String name) method in order to support bookmarking and multiple browser tabs, as previously described in some older posts.


public Window getWindow(String name) {
        Window w = super.getWindow(name);
        if (w == null) {            
            w = new CustomWindow();
            w.setName(name);
            addWindow(w);
        }
        return w;

    }	

CustomWindow(){
			HorizontalLayout nav = new HorizontalLayout();
			nav.addComponent(header);			
			nav.addComponent(uriFragmentUtility);
			/*			
			 * This seems to be the recommended approach.
			 * See also: http://vaadin.com/forum/-/message_boards/message/17226  
			 * 
			 * Supporting multiple tabs, bookmarking and back button all together
			 * See post: http://vaadin.com/forum/-/message_boards/message/18492
			 */
            uriFragmentUtility.addListener(new FragmentChangedListener() {
                public void fragmentChanged(FragmentChangedEvent source) {
                	String fullUriFrag = source.getUriFragmentUtility().getFragment();                    
                    System.out.println("++ fragmentChanged: "+fullUriFrag);
                    setModule(fullUriFrag);
                }
            });           
            
            vLayout.addComponent(nav);
            // Empty label to be replaced when uri fragment is detected.
            mainView = new Label();
            vLayout.addComponent(mainView);
            // To lighten the session storage, remove the window from the Application object when user closes a tab.
            this.addListener(new MadisonWindowCloseListener(this));
            this.addComponent(vLayout);
		}	

The behavior seen by the user is what would be expected when the setModule(fullUriFrag) line is invoked in the uriFragmentUtility listener of the CustomWindow. Something isn’t right with this setup, I suppose. It’s unclear why a new CustomWindow would be created when they are in the middle of filling out a form.