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
> >
>
