1 Reply Latest reply on Jun 12, 2019 5:30 PM by jfisherdev

    EJB Access Issue From MBean During Shutdown

    jfisherdev

      I am currently migrating from JBoss AS 4.2.2 to WildFly 9.0.2.


      Some applications have MBeans that access EJB 2.x components in a stop() lifecycle method like this:


      public class AppService implements AppServiceMBean {
      
      
           @Override
           public void stop() throws Exception {
                EJBDelegate.callMethod();
           }
      }
      
      

       

      When shutting down a WildFly server, I am seeing this exception:

       

      org.jboss.as.ejb3.component.EJBComponentUnavailableException: WFLYEJB0421: Invocation cannot proceed as component is shutting down

       

      Is there a way to ensure that the EJB resources are available to the MBeans when shutting down? More specifically, can an MBean express a dependency on an EJB component? I know that in JBoss AS 4.2.2 this could be done via the jboss-service.xml descriptor by having the MBean that depends on the EJB declare a dependency on the MBean for the EJB. This is not supported in WildFly.

       

      Also, in cases where the EJB accesses a data source, this often coincides with a NameNotFoundException due to there no longer being a data source bound to the JNDI name used to lookup the data source. Is there a way for an MBean to express a dependency on a data source so that it is available during shutdown?

       

      Any information about this would be very much appreciated.

       

      Message was edited by: Josh Fisher

        • 1. Re: EJB Access Issue From MBean During Shutdown
          jfisherdev

          The solution I ultimately found was to first and foremost move away from legacy SAR deployments and instead deploy as singleton EJBs with optional JMX instrumentation.

           

          Not sure if this works for SAR deployments, but the second part was to correctly declare dependencies on the appropriate resources using @Resource and @EJB annotations as needed so they are available during PostConstruct/PreDestroy life cycle method calls.