I had spent the whole morning finding out what caused an error in a so simple class of a module. It turned out to be a defect of Glassfish Server. I would like to describe the defect here as my own reference.

Since I can’t show you the real production code so I will use this example to describe the defect 

public class AppContextListener implements ServletContextListener{
    public static final String AUTHEN_ENABLED = "AUTHEN_ENABLED";

    private volatile AuthenProcessor authenProsessor;

    public void contextInitialized(ServletContextEvent sce) {
        authenProsessor = createAuthenProcessor();

        if( readConfigBoolean(AUTHEN_ENABLED) ){
            sce.getServletContext().setAttribute(AUTHEN_ENABLED, new Boolean(true) );
            authenProsessor.startup();
        }
    }

public void contextDestroyed(ServletContextEvent sce) {
        Boolean authenEnabled = (Boolean)sce.getServletContext().getAttribute(AUTHEN_ENABLED);

        if( authenEnabled.booleanValue() ){
            authenProsessor.shutdown();
        }
    }
}

I think I don’t need to explain what the class does because it’s easy enough to read. The default value for AUTHEN_ENABLED configuration is true. Once you get the web application running and then tries to undeploy it you will get NullPointerException at the line authenEnabled.booleanValue().

We don’t have any Servlet or JSP yet so it’s impossible that there will be any module that removes AUTHEN_ENABLED attribute from the ServletContext. I have googled it out and found that this is a defect of Glassfish 2.1 that all attributes of ServletContext will be cleared before the contextDestroyed() method gets to be called.

You may find the detail at defect log Issue6594. Actually, the Issue of the defect is 6442 but I found the summary in Issue6594 contains more information.

This defect has been fixed in Glassfish V3. I have deploy the web application on V3 and problem has gone.