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>
