Description of problem: If an application contains i.e. resource references and the resource is not available the deploy or start process will wait for the timeout (300sec) before any other log output. But regardless of different error messages the server will not continue nor it it possible to shutdown it. The process must be killed. How reproducible: use the quickstart cluster-ha-singleton, there are two EJB's SchedulerBean, this Singleton is called from the HATimerService and initialize the scheduled timers. ServiceAccessBean, this is a normal SLSB which is not involved during starup it does not matter which of both contain this code_ @Resource(mappedName = "java:/jms/topic/testTopic") private Topic testTopic; Another way is to add the @Resource annotation to any EJB3 SLSB, this will have the same result. Note: the server must be started with "standalone.sh -c standalone-full-ha.xml" Actual results: Server start/deploy hung Expected results: Error message that the resource is not available, the application deployment fail, but the server operate normal. Additional info: Everything work correct if the resource (here the topic) is added to stanalone-full-ha. Inside of the application the testTopic is not NULL and useable. <jms-topic name="testTopic"> <entry name="java:/jms/topic/testTopic"/> <entry name="java:jboss/exported/jms/topic/testTopic"/> </jms-topic>
Having something like: @Resource(mappedName = "java:/jms/topic/testTopic") private Topic testTopic; creates a hard dependency of your EJB onto the JMS topic. This is against the nature of JMS which is to decouple dependencies and allow for asynchronous operation. It's not uncommon for an application server and a JMS provider to be starting in different order and timeframe. To allow for such scenarios an EJB needs to be coded such it can handle the non-existence of JMS destinations. The easiest way to do this is doing a JNDI lookup in the post-construct (/ create) and throwing an (application) exception when the resource can not be located. The bean caller can will get the appropriate exception and should deal with it accordingly. Note that we could file for a RFE that basically makes the dependency optional, thus creating the scenario that throws the appropriate exception whenever the EJB is instantiated.