Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: error (athena.apache.org: encountered temporary error during SPF
 processing of domain of gerald.quintana@gmail.com)
Date: Wed, 3 Jul 2013 05:56:31 -0700 (PDT)
From: gquintana <gerald.quintana@gmail.com>
To: users@camel.apache.org
Message-ID: <1372856191876-5735149.post@n5.nabble.com>
In-Reply-To: <1372811685745-5735108.post@n5.nabble.com>
References: <1372811685745-5735108.post@n5.nabble.com>
Subject: Re: Weblogic JMS Security Issues - A possible resolution
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.