There's a few places this needs to go into, in my customisation of it I've added it to the following methods, although it may be done in a more centralized manner.

refreshConnectionUntilSuccessful()

AsyncMessageListenerInvoker.initResourcesIfNecessary()

handleListenerSetupFailure(Throwable ex, boolean alreadyRecovered)

Good point! The JMS API's JMSException class is unfortunately not implemented in a way that would be compatible with the JDK 1.4 exception changing mechanism...

I've revised the log messages in refreshConnectionUntilSuccessful and handleListenerSetupFailure accordingly; to be released in Spring 2.5.6.

What exactly did you do to initResourcesIfNecessary - there is no logging code there, at least not in the most recent version of the code?

Juergen

I've wrapped the whole method in a try catch, that rewrites any JMSException to include destination name and the linked exception. This is mainly because we use MQ Series, and it's default exception messages are more or less useless Not naming queue name, and putting the actual error code in the link exception rather than the thrown exception. Can't rememeber now why I had to stick this in this method too, but it may me a different code path when the thing tries to initialise or recover.

Here's the code I've added, it's not ideal, but it meets my requirements.

private void initResourcesIfNecessary() throws JMSException
{
try{ ... Original code goes here..... }
catch(JMSException jms)

}

Hmm, as far as I can see (and as far as the original intention was), any exception thrown from initResourcesIfNecessary ends up in handleListenerSetupFailure anyway... So the handleListenerSetupFailure revision should already cover those. The only difference that I can see is that your JMSException wrapper would get exposed to a specific ExceptionListener as well (when configured through the "exceptionListener" property). There shouldn't be a difference beyond that, in particular not in terms of logging...

BTW, I had to fine-tune this quite a bit in order to not end up as repetitive message on providers that do include the linked exception message in their original JMSException message already. This is for example the case with ActiveMQ. We're now checking whether the original JMSException message already contains the linked exception message in the first place, and only append the latter explicitly when not contained already (like when running against MQSeries).

Juergen

I've added this to CVS HEAD as discussed above; to be available in the next 2.5.6 snapshot (http://static.springframework.org/downloads/nightly/snapshot-download.php?project=SPR). Please give that implementation a try and let me know about any gaps...

Juergen