I have a WAR file which contains among other things a ServletContextListener, a @Singleton EJB and and @ApplicationScoped CDI bean.
The RouterContextListener injects the @Singleton EJB w/_at_EJB. The @SingletonEJB injects the @ApplicationScoped CDI bean w/_at_Inject and the EJB's @PostConstruct method uses the CDI bean to parse and XML file. Yes, I know the 'spec violation' here w/respect to the EJB code path interacting with the IO API.
If during deployment the CDI bean throws and exception during @PostConstruct it fails and the EJB's @PostConstruct fails causing a:
Exception while invoking class org.glassfish.ejb.startup.EjbApplication start method exception of javax.ejbEJBException: javax.ejb.CreateException: Initialization failed for Singleton FooBar from javax.enterprise.system.tools.admin.org.glassfish.deployment.admin
This all results in Glassfish failing to deploy the web app. Fine, that's expected. Now the cause of this stemmed from a XML file parse error. If the file is fixed so that it parses correctly and I simply try to redeploy WITHOUT restarting Glassfish I am greeted with a:
org.apache.catalina.LifecycleException: java.lang.IllegalArguementException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: com.foo.bar.MyServletContextListerner
The last exception in the stack is:
Caused by: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001324 Argument bean must not be null
If I stop the Glassfish domain and restart the domain and deploy again everything works fine. Its as if the initial deployment failure has left the domain in a bad state. I'm surprised, I would have expected GF to clear out the domain state when it fails to deploy a web app like this.
Thoughts?
-Noah