The simplest way to resolve this issue is likely just to retry the JNDI lookup when you hit a failure. Insert a small delay (e.g. 200ms) between retries and after X number of retries then throw an exception. That should deal with the timing issue.
The workaround you suggest has also been in my mind, but I will not use this yet. I had hoped for another answer for this problem To me it seems odd that WildFly's ActiveMQ component in the application log writes 'Server is now live' and then later on in the log it writes 'trying to deploy a queue' or 'resource adaptor started'. I will dig deeper into the problem, and if I find an answer, I will post it here.
WildFly uses new core architecture where whole boot process is multi threaded.
So unless you have proper dependencies defined between components you could see problem like you see now.
How do you do jndi lookup? by using InitialContext.lookup? or by injection?
if you would do something like
private ConnectionFactory factory;
it should work. as server knows about relationship and it will wait till service is ready to inject it.
To me it seems odd that WildFly's ActiveMQ component in the application log writes 'Server is now live' and then later on in the log it writes 'trying to deploy a queue' or 'resource adaptor started'...
This is the expected behavior, I believe. You should establish proper dependencies like Tomaz suggested or implement a retry as I suggested if you're not using a component which support resource injection.
I do have a dependency between some components so they need to start in the right sequence.
Being an older application it uses InitialContext. I will try the use of @Resource