Hi, I struggled against this one as well (I am happy not to be alone!), it's more related to WebLogic and Spring's DefaultMessageListenerContainer than Camel. My understanding is that, in WebLogic, the security context (who is sending/receiving messages) is bound to the thread getting the ConnectionFactory, instead of being bound to the Connection/Session object itself. With Spring DMLC, the thread getting the connection factory is not the thread sending/receiving messages, as a result we are loosing user rights between threads. I ended up with a solution based a decoratorconnectionfactory (see honeybunny post http://forum.springsource.org/showthread.php?62373-weblogic-10-standalone-jms-client ) and disabling all connection caching: each thread gets his own connectionfactory. It's a catastrophe from a performance point of view because the connectionfactory/connection can not be cached and shared between listener threads, but it works.
Your Github article is very interesting (thanks for sharing), I ignored these Security/Authenticate WebLogic classes. I need to test the behaviour of the new SJMS component (not based on Spring DMLC) and see if it's better. We could put up WeblogicMQ specific component (based on JMS or SJMS) do solve this problem. I advise you to read these blogs in case you didn't http://www.jayway.com/2011/06/26/secure-jms-spring-and-weblogic-a-one-click-workaround/ http://sleeplessinslc.blogspot.fr/2009/04/weblogic-jms-standalone-multi-threaded.html Another challenge I had to face was receiving JMS message from one broker, processing it, and then sending it to another broker. I had to introduce a Thread EIP in the middle just to lose this damned thread bound security context (user are different on both ends). -- View this message in context: http://camel.465427.n5.nabble.com/Weblogic-JMS-Security-Issues-A-possible-resolution-tp5735108p5735149.html Sent from the Camel - Users mailing list archive at Nabble.com.
