Claus Ibsen-2 wrote: > > I think we can fix the issue with a custom exceptionListener which > fixes the null message. > > Can you test it by creating a custom javax.jms.ExceptionListener class > and then set the message to a non null value. > > And in Camel you can register the listener using the > exceptionListener=#myListener configuration in the endpoint uri. > > If it fixes it we can create a listener to be shipped out of the box. > > Hi Claus,
I can expend the effort to do this however I've now moved and tested my application in UAT based on Spring 3 (I had to move quickly). In addition an exception listener sounds like a hack. Can we not move to Spring 3 and provide a Spring 2 profile (swap the profile situation around?). That way any AMQ and SMX dependency issue is resolved as they can build their own distributions from source. BTW: I don't see much value in shipping Camel with AMQ nowadays; I appreciate the history, but they're really two very independent things. I can't imagine why someone would prefer to use an AMQ bundled Camel vs. the one generally available. Also, given SMX's relationship to OSGi and thus its great handling at dependencies I'm not sure I get why Camel needs to be strongly coupled there either. Let's not have other projects constrain what we do here. -- View this message in context: http://camel.465427.n5.nabble.com/Problem-with-maintaining-a-JMS-subscription-after-waking-from-sleep-tp510193p511190.html Sent from the Camel - Users mailing list archive at Nabble.com.
