Hi Christian, I just submitted https://issues.apache.org/jira/browse/CXF-6742 with a base patch to track this.
Thanks for your time and see you there hopefully. 2016-01-08 23:36 GMT+01:00 Christian Schneider <[email protected]>: > It would be great if you could open an issue and attach the patch. > > Christian > > 2016-01-08 17:44 GMT+01:00 Gueugaie <[email protected]>: > > > Christian, > > > > Working on it part of the day, I can confirm that both our suggested > > approaches are OK. > > Solution 1 customize the thread pool and override the pool's before/after > > execute methods > > Solution 2 propagate the JNDI Environment to worker threads > > > > Solution 1, though, has some limitations. For example, we focused our > > discussion on the server side of things, for which it works, but on the > > client side, when sending SOAP/JMS messages, we face the same issue. And > > from my reading of JMS Conduit / MessageListenerContainer classes, the > > configurable pool is actually never used. > > This is not usually as bad as it sounds on the client side, because one > can > > always manually create a JNDI context before calling CXF, usually. > > Still, this is an issue. > > > > I drafted a patch for solution 2 by adding a boolean > > "exposeJNDIEnvironment" boolean to JMS Config, allowing its configuration > > through the JMSEndpoint and then the JMSConfigFactory, and finally > > propagating it to the PollingMessageListenerContainer (for the server > > side), and the JMSConduit (for the client side). > > The PollingMessageListenerContainer is given a "JNDIPollerDecorator" > > Runnable instance, that wraps either the actual Poller / XAPoller > instance. > > The JMSConduit "sendExchange" message is modified to open the JNDI > Context > > the same way. > > > > I do not consider this patch as a final work; but please tell me if you > > feel that it would help submitting it through any mean (open a JIRA, > > continue this topic on the dev list, ...). > > > > Thanks, > > Guillaume. > > > > > > > > > > > > > > > > > > 2016-01-08 12:20 GMT+01:00 Guillaume Pichenot < > > [email protected]> > > : > > > > > Hi, > > > > > > 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, > > > (see > > > > > > > > > http://docs.spring.io/spring-framework/docs/2.5.6/api/org/springframework/jndi/JndiObjectFactoryBean.html#setExposeAccessContext%28boolean%29 > > > ), > > > although we would have to use it both while accessing the JNDI objets, > > AND > > > while polling (see https://jira.spring.io/browse/SPR-5869). > > > > > > > > > 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 > > > AbstractMessageListenerCont > > > @Override > > > 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, > > > "weblogic.jndi.WLInitialContextFactory"); > > > + jndiProps.put(Context.PROVIDER_URL, > > > "t3://localhost:7001"); > > > + jndiProps.put(Context.SECURITY_PRINCIPAL, > > "jmsuser"); > > > + jndiProps.put(Context.SECURITY_CREDENTIALS, > > "jmspwd"); > > > + ic = new InitialContext(jndiProps); > > > + > > > session = connection.createSession(transacted, > > > acknowledgeMode); > > > 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. > > > > > > Guillaume > > > > > > > > > On Thu, Jan 7, 2016 at 7:39 PM, Christian Schneider < > > > [email protected] > > > > wrote: > > > > > > > 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 > > > > > > > > 2016-01-07 19:07 GMT+01:00 Gueugaie <[email protected]>: > > > > > > > > > Hi Christian, > > > > > > > > > > Well, my sample app is really trivial, I'm using the > > "helloWorld.wsdl" > > > > from > > > > > the unit tests as a sample, and deploying it very basically, > through > > a > > > > > cxf-servlet.xml (I'm breaking lines here for readability). > > > > > > > > > > > > > > > <jaxws:endpoint id="testJMS" > > > > > address="jms:jndi:MySoapQueue? > > > > > username=jmsuser > > > > > &password=jmspassword > > > > > &jndi-java.naming.security.principal=jmsuser > > > > > &jndi-java.naming.security.credentials=jmspassword > > > > > > > > &jndiInitialContextFactory=weblogic.jndi.WLInitialContextFactory > > > > > &jndiConnectionFactoryName=MySoapConnectionFactory > > > > > &jndiURL=t3://localhost:7001" > > > > > implementor="com.MyService" > > > > > > > wsdlLocation="classpath:package/stub/HelloWorld.wsdl"> > > > > > </jaxws:endpoint> > > > > > > > > > > I'm using jndi-java.naming stuff AND username stuff to be sure to > > > provide > > > > > both JNDI level credentials and > > connectionFactory.createSession(login, > > > > > password) level credentials. > > > > > As I mentionned, this works as long as the weblogic JMS module is > > > > > unsecured, so I guess there is nothing wrong with, say, the jndiURL > > and > > > > so > > > > > on. > > > > > I package this as a WAR and deploy to a dev-mode weblogic. > > > > > > > > > > I could make a github out of this, but that would not really help > > > > building > > > > > the weblogic setup... Weblogic setup is simple too : create/reuse a > > > > realm, > > > > > create a jmsgroup, create a jmsuser inside this group, then go to > the > > > > > JMSModule pannel, and activate a security strategy that says "group > > is > > > > > [whatever you created earlier]". > > > > > > > > > > You mention : "One problem might be that we close the jndi context > > > after > > > > > the connection is created. > > > > > From what I read in the oracle docs this removes the authentication > > > from > > > > > the thread again." > > > > > > > > > > Indeed ! But then again, it's not really that the context is closed > > too > > > > > early, it's that the threads that initiate the actual > > MessageConsumers > > > > > never had a context in the first place. > > > > > > > > > > > > > > > You mention too the use of the > > > > > "org.apache.cxf.extensions.jms.destination.executor" property. If > I'm > > > not > > > > > mistaken, this is an unreleased feature (upcoming 3.2). This sounds > > > like > > > > a > > > > > plan : you'd create a ThreadPoolExecutor, and override it's > > > > > beforeExecute/afterExecute to provide contexte creation. > > > > > > > > > > It's OK, as long as you have a single credentials set for each CXF > > > Bus... > > > > > which is a constraint of sorts. But this has a reasonnably good > > chance > > > of > > > > > success. > > > > > > > > > > > > > > > Goolging aroung, I found this too : > > > > > https://docs.oracle.com/cd/E13222_01/wls/docs90/jms/j2ee.html, > where > > > > > Oracle > > > > > docs mentions that, declaring the JMS resources in a web.xml > > > > <resource-ref> > > > > > can have the following effect : > > > > > > > > > > > When you declare a JMS connection factory via a resource-ref > > element > > > in > > > > > the weblogic-ejb-jar.xml or web.xml file, there is an optional > > > > sub-element > > > > > called res-auth. This element may have one of two settings: > > > > > > > > > > *> Application* — When you set the res-auth element to Application, > > any > > > > > user name or password on the MBean is ignored. Instead, the > > application > > > > > code must specify a user name and password to the > createConnection() > > > > method > > > > > of the JMS connection factory, or use the version of > > createConnection() > > > > > with no user name or password if none are required. > > > > > ... > > > > > > > > > > > > > > > But I have not been able to make it work at this point. > > > > > > > > > > Guillaume. > > > > > > > > > > 2016-01-07 17:37 GMT+01:00 Christian Schneider < > > > [email protected] > > > > >: > > > > > > > > > > > Can you give a full example for your problem? > > > > > > How do you set up your endpoint and especially the jndi > parameters? > > > > > > > > > > > > One problem might be that we close the jndi context after the > > > > connection > > > > > > is created. > > > > > > From what I read in the oracle docs this removes the > authentication > > > > from > > > > > > the thread again. > > > > > > > > > > > > One thing you might be able to do is create a custom Executor and > > set > > > > it > > > > > > as a bus property > > > > > > "org.apache.cxf.extensions.jms.destination.executor". This > executor > > > > will > > > > > > then be used to execute the Runnable. > > > > > > You should be able to set the authentication details this way. > Can > > > you > > > > > try > > > > > > this to see if this approach can fix the problem. > > > > > > If yes we can provide an executor by default that creates the > jndi > > > > > context > > > > > > before executing the poller and destroys it afterwards. > > > > > > > > > > > > I hope if we work together closely we can still solve this. > > > > > > > > > > > > Christian > > > > > > > > > > > > > > > > > > > > > > > > On 07.01.2016 15:15, Gueugaie wrote: > > > > > > > > > > > >> Hi List, > > > > > >> > > > > > >> I'm upgrading to CXF3, and facing an issue with the deployment > of > > > > > SOAP/JMS > > > > > >> services in a weblogic container. > > > > > >> > > > > > >> We use weblogic's JMS module and everything's fine untill we > > > activate > > > > a > > > > > >> weblogic security strategy on the JMS Module. > > > > > >> > > > > > >> When doing so (see this for documentation > > > > > >> > > > https://docs.oracle.com/cd/E13222_01/wls/docs81/jndi/jndi.html#467275 > > > > > ), > > > > > >> one can retreive the ConnectionFactory inside the JNDI withtout > a > > > > > problem, > > > > > >> but when the message polling actually starts, it fails with a > > > security > > > > > >> exception : > > > > > >> > > > > > >> Caused by: weblogic.jms.common.JMSSecurityException: Access > denied > > > to > > > > > >> resource: type=<jms>, application=... > > > > > >> at > > > > > >> > > > > > >> > > > > > > > > > > > > > > > weblogic.jms.common.JMSSecurityHelper.checkPermission(JMSSecurityHelper.java:160) > > > > > >> ... > > > > > >> at > > > > > >> > > > > > >> > > > > > > > > > > > > > > > org.apache.cxf.transport.jms.util.PollingMessageListenerContainer.createConsumer > > > > > >> > > > > > >> We get the same result for Weblogic 11 or 12, with CXF 2.7.x or > > 3.x. > > > > > >> > > > > > >> The diagnostic is "simple" : we can not use weblogic secured > > > > ressources > > > > > >> from threads that do not hold a valid weblogic security context > > > (those > > > > > >> contexts are indeed are ThreadLocal). > > > > > >> > > > > > >> The solution in 2.x used to be fairly simple... > > > > > >> We got around this by overrinding Spring-JMS modules, providing > > our > > > > own > > > > > >> polling thread implementation that would initiate an > > InitialContext > > > > > >> (effectively logging in a Weblogic User), and delegate the > actual > > > work > > > > > to > > > > > >> the standard implementation. Nice, simple overloading. > > > > > >> Check out : > > > > > >> > > > > > >> > > > > > > > > > > > > > > > http://stackoverflow.com/questions/19849766/org-springframework-jms-jmssecurityexception-access-denied-to-resource-type-j > > > > > >> for a simple description. > > > > > >> > > > > > >> In 3.X, no more SpringJMS. And the poller runaable is > implemented > > > in a > > > > > >> private class, running inside a privately constructed Thread > Pool, > > > and > > > > > >> interaction with the secured ressources via private methods. So > > I'm > > > > > kinda > > > > > >> stuck... > > > > > >> > > > > > >> Does anyone have a solution / good idea for this ? Is this > somehow > > > in > > > > > the > > > > > >> docs (could not find it :() ? > > > > > >> > > > > > >> Thanks! > > > > > >> > > > > > >> > > > > > > > > > > > > -- > > > > > > Christian Schneider > > > > > > http://www.liquid-reality.de > > > > > > > > > > > > Open Source Architect > > > > > > http://www.talend.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > -- > > > > Christian Schneider > > > > http://www.liquid-reality.de > > > > < > > > > > > > > > > https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de > > > > > > > > > > > > > Open Source Architect > > > > http://www.talend.com > > > > < > > > > > > > > > > https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com > > > > > > > > > > > > > > > > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > < > https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de > > > > Open Source Architect > http://www.talend.com > < > https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com > > >
