cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gueugaie <>
Subject Re: SOAP over JMS using secured Weblogic JMS Module
Date Fri, 08 Jan 2016 11:23:53 GMT

Propagating the JNDI properties of the endpoint would be great!
One could make that a config option on the JMSConfig object, something
along the lines of what Spring does with the "exposeAccessContext" option,
although we would have to use it both while accessing the JNDI directory,
and while polling (see

I have just cloned the repo and started hacking.
My first quick&dirty test to see if this could work was to modify
PollingMessageListenerContainer$Poller#run() to create an InitialContext
before the createSession call, and close it in the finally.
The core of the hack is :

@@ -49,10 +52,18 @@ public class PollingMessageListenerContainer extends
         public void run() {
             while (running) {
+                Properties jndiProps = new Properties();
                 MessageConsumer consumer = null;
                 Session session = null;
+                InitialContext ic = null;
                 try {
                     // Create session early to optimize performance
+                    jndiProps.put(Context.INITIAL_CONTEXT_FACTORY,
+                    jndiProps.put(Context.PROVIDER_URL,
+                    jndiProps.put(Context.SECURITY_PRINCIPAL, "jmsuser");
+                    jndiProps.put(Context.SECURITY_CREDENTIALS, "jmspwd");
+                    ic = new InitialContext(jndiProps);
                     session = connection.createSession(transacted,
                     consumer = createConsumer(session);

I can confirm that this actually solves the secured resource issue. I'll
try the "cleaner" solution you suggested with the ExecutorService, but it
looks like we're on the right path.


2016-01-07 19:39 GMT+01:00 Christian Schneider <>:

> Can you try to get it working with the cxf code from the master branch and
> a custom executor. If that works I will try to adapt the implementation so
> it works by default.
> I think we can make this work using the jndi properties of the endpoint. So
> it is possible to have different jms setups in the same process.
> Christian

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message