Hi David, I don't understand why you say "I avoided any threading changes because I was concerned about its affect on transactions. " because this is actually what you're doing in WeblogicSecurityBean#runPrivilegedActionAsSubject: this piece of code is pushing/poping the security context in the threadlocal.
I don't understand either why I would need DelegateProcessor, your WeblogicSecurityInterceptStrategy seems enough. To summarize you work (correct me if I'm wrong): - For Inbound JMS: you're creating a dedicated thread pool with the specialized WeblogicSecureThreadFactory, as result each listener thread has his security context properly set on creation. I would just fear this security context gets dirty with time. Ideally we should intercept inside the message polling loop and wrap the MessageConsumer#receive in a runPrivilegedAction, but the DMLC is not very configurable here. - For Outbound JMS: you're intercepting the JMS Producer Endpoint to set the security context. -- View this message in context: http://camel.465427.n5.nabble.com/Weblogic-JMS-Security-Issues-A-possible-resolution-tp5735108p5735175.html Sent from the Camel - Users mailing list archive at Nabble.com.
