I'm taking a look at the JMS endpoint issue http://jira.jboss.org/jira/browse/JBWS-1324; here are some thoughts about it we might want to discuss:
- It's difficult to systematically reproduce this issue in a testcase; Darran, do you already have a testcase showing this behaviour?
- Apart from this, I think the most straightforward solution here is to put the described workaround (the sleep) in the abstract JMSTransportSupport class, preventing the user from doing the same in every JMS endpoints.
- Ideally it would be great to have these MDBs deployed with the message delivery disabled and enable it once the DefaultEndpoint is ready (let's say from a deployment aspect for example). However the only way I see to have a MDB deployed this way is to use the DeliveryActive attribute in the standard jboss bean configuration (invoker-proxy-binding -> proxy-factory-config -> MDBConfig).
Moreover afaik this cannot be done with EJB3s (and I think soon we'll need them too).
- Another workaround could be to have the message driven bean depend on something being deployed after it in the same sar archive (a queue for example), like in our org.jboss.test.ws.jaxrpc.samples.jmstransport sample. As far as I can see trying the sample, our endoint state goes to STARTED in the deployment start phase of the jar, when the EndpointLifecycleDeploymentAspect:Start is called. At that point the ejb service is waiting on the start of the queue specified in the sar archive, since the inner jar is deployed first.
I think the most straightforward solution here is to put the described workaround (the sleep) in the abstract JMSTransportSupport class