NullpointerException in getDirtyVisibleComponents

I keep encountering the following exception:
java.lang.NullPointerException
at com.vaadin.terminal.gwt.server.CommunicationManager.getDirtyVisibleComponents(CommunicationManager.java:1232)
at com.vaadin.terminal.gwt.server.CommunicationManager.paintAfterVariablechanges(CommunicationManager.java:401)
at com.vaadin.terminal.gwt.server.CommunicationManager.handleUidlRequest(CommunicationManager.java:314)
at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:425)
at com.ibm.rtc.application.WebPortalApplicationServlet.service(WebPortalApplicationServlet.java:21)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:735)

When I trace through the code, starting at getDirtyVisibleComponents, I noticed a piece of code that seems to be an unchecked null object condition. It is red bold in the code below. According to the docs, component.getWindow() can return a null when the component does not yet have a parent window. I’m using Vaddin 6.1.3.

private ArrayList<Paintable> getDirtyVisibleComponents(Window w) {
        final ArrayList<Paintable> resultset = new ArrayList<Paintable>(
                dirtyPaintabletSet);

        // The following algorithm removes any components that would be painted
        // as a direct descendant of other components from the dirty components
        // list. The result is that each component should be painted exactly
        // once and any unmodified components will be painted as "cached=true".

        for (final Iterator i = dirtyPaintabletSet.iterator(); i.hasNext();) {
            final Paintable p = (Paintable) i.next();
            if (p instanceof Component) {
                final Component component = (Component) p;
                if (component.getApplication() == null) {
                    // component is detached after requestRepaint is called
                    resultset.remove(p);
                    i.remove();
                } else {
                    [color=#FF0000]
[b]
Window componentsRoot = component.getWindow();
                    if (componentsRoot.getParent() != null) {
                        // this is a subwindow
                        componentsRoot = (Window) componentsRoot.getParent();
                    }
[/b]
[/color]
                    if (componentsRoot != w) {
                        resultset.remove(p);
                    } else if (component.getParent() != null
                            && !component.getParent().isVisible()) {
                        /*
                         * Do not return components in an invisible subtree.
                         * 
                         * Components that are invisible in visible subree, must
                         * be rendered (to let client know that they need to be
                         * hidden).
                         */
                        resultset.remove(p);
                    }
                }
            }
        }

        return resultset;
    }

I see this occur when I do something like this:

            ... add the component to the page
	[code]

mainLayoutArea.addComponent(new AdminUI((MainApplication)getApplication()));
[/code]

    // button click on the page calls this method
[code]

public void buttonClick_Admin(ClickEvent event) {
mainLayoutArea.removeAllComponents();
mainLayoutArea.addComponent(new AdminUI((MainApplication)getApplication()));
}
[/code]

Seems like a bug, maybe someone more familiar with the internals of Vaadin could help you there.

I just wanted to point out that you don’t have to pass the Application instance along in the constructors. You can call getApplication() inside AdminUI, when you actually need it, as long as the AdminUI instance is added to the applicaiton, but you do that with mainLayoutArea.addComponent(new AdminUI())

You could also implement the ThreadLocal pattern to get the Application instance from anywhere, without restrictions. After that you’d just have to call MainApplication.get() or something like that. Here’s the
instructions
.

The problem I had with getting the application was that when I construct the object, in some cases, I needed data from the application. I couldn’t use getApplication() because the object is not added until after the constructor is run. In that case, getApplication() would return null. As a workaround, I simply passed in the application object when necessary. It isn’t the best solution but it worked in my case.

Hi Terry,
I seem to be having the very same problem… because I need the application instance in the child Component’s constructor… did you manage to solve this problem… Kindly assist me.

The most frequently used pattern is to do such initialization in the attach() method, not in the constructor. That way, the application instance is available.

If you cannot do that, you have two alternatives: pass the application through the constructor invocation chain as a parameter, or use the ThreadLocal pattern. If you choose the latter, do make sure you reset the ThreadLocal at the end of each request (the thread will be reused for other requests by the server), and that you only set it for requests concerning the correct application instance. You can look for information about this elsewhere on the forum, or someone can point you to a good implementation (it is easy to get slightly wrong, leading to hard to debug problems that often do not appear in simple tests). InheritableThreadLocal can also be useful.

Hi Henri,
Once I override the attach method… would I need to explicitly call that method or does Vaadin handle that for me, and at what stage would I need to call it …

It is automatically called when the component is added to a layout in a window that is visible, including when the component is shown for the first time.

Greatest lesson learnt…Never override getApplication… as highlighted
Here