I was thinking in providing a pool of CXF client objects (not STS client objects).
IMHO, in general, I'd prefer to have no dependency whether a programmer uses one proxy instance for all requests or a new one for each request. The creation if a proxy instance is "expensive" (download wsdl from remote location, parsing (incl. policies), ...). Therefore, I was thinking of a pool of CXF client objects (the parsed wsdl data could just be cloned (in case not thread safe)). Then, it would be fine to have a non thread safe STSClient also. It should also address the other exceptions described here: http://cxf.apache.org/faq#FAQ-AreJAXWSclientproxiesthreadsafe Thanks Oli ________________________________________ Von: Daniel Kulp [[email protected]] Gesendet: Freitag, 18. November 2011 23:15 Bis: [email protected] Cc: Oliver Wulff Betreff: Re: AW: Proxy object used in multi threaded case On Friday, November 18, 2011 8:00:46 AM Oliver Wulff wrote: > Can anybody give me a hint where to extend this functionality in CXF itself? Well, I can give you workaround that should work with CXF right now: Since the STSClient is retrieved as a contextual property: STSClient client = (STSClient)message .getContextualProperty(SecurityConstants.STS_CLIENT); You can actually create a pool of STSClients and set that on the RequestContext of the proxy or the message on a per-request basis. For example, an interceptor that runs before the IssuedTokenInterceptor could checkout a STSClient from a pool, stick it on the message, and then add an interceptor that runs later that sticks it back on the pool. (and also in the handleFault). Thus, you can still have a single proxy, but multiple STSClients. Longer term, one thing we could do is make the call to getClient first do something like: STSClientFactory factory = message .getContextualProperty(SecurityConstants.STS_CLIENT_FACTORY); if (factory != null) { client = factory.createClient(...); } else { client = (STSClient)message .getContextualProperty(SecurityConstants.STS_CLIENT); } or similar to introduce some sort of factory in there. We'd have to add a "releaseClient" and add finally blocks in various places so the factory could get re-called. (or, on the STSClient itself, have a release() method that a subclass could override to put it back in a pool) Patch would be welcome. :-) Dan > > Thanks > Oli > > ________________________________________ > Von: Oliver Wulff [[email protected]] > Gesendet: Mittwoch, 26. Oktober 2011 09:10 > Bis: [email protected] > Betreff: AW: Proxy object used in multi threaded case > > Hi there > > >> The SecureConv and IssuedToken interceptors current "sync" on the > >> client > >> object to make sure this case works. It definitely can be a > >> performance issue though. > > I guess you mean this: > > STSClient client = STSUtils.getClient(message, "sts", itok); > AddressingProperties maps = > (AddressingProperties)message > > .get("javax.xml.ws.addressing.context.outbound"); if (maps == null) { > maps = (AddressingProperties)message > .get("javax.xml.ws.addressing.context"); > } > synchronized (client) { > try { > > > I was thinking of using Apache Commons Pool for the proxy objects. But > before starting, I wanted to double check whether there are better ways > thus I could contribute the enhancements back to the community. Maybe we > could introduce a jaxws property for jaxws:client whether pooling should be > used or not. > > What is the best place to hook this functionality in (ClientFactoryBean, > ClientProxyFactoryBean or in the ClientProxy thus it works to inject the > proxy object in your impl class)? > > Thanks > Oli > ________________________________________ > Von: Aki Yoshida [[email protected]] > Gesendet: Mittwoch, 19. Oktober 2011 23:57 > Bis: [email protected] > Betreff: Re: Proxy object used in multi threaded case > > 2011/10/19 Aki Yoshida <[email protected]>: > > 2011/10/19 Daniel Kulp <[email protected]>: > >> On Wednesday, October 19, 2011 11:00:51 AM Oliver Wulff wrote: > >>> Hi guys > >>> > >>> I've got a question with respect to a deployment of CXF in an > >>> intermediary scenario. The service implementation of the > >>> intermediary injects the proxy instance for the target service it > >>> will call. Of course, this is a multi threaded environment where > >>> the service implementation gets the current user as part of the > >>> incoming message (not ws-security). > >>> > >>> The target service expects to get a security token issued by the > >>> STS. The username is expected to be set for the proxy and the > >>> WSSUsernameCallbackHandler is configured to get the user from there. > >>> > >>> Here a snippet of the configuration: > >>> <jaxws:client > >>> > >>> name="{http://www.example.org/contract/DoubleIt}DoubleItTransportION > >>> ABSTPor t" createdFromAPI="true"> <jaxws:properties> > >>> > >>> <entry key="ws-security.sts.client"> > >>> > >>> <bean > >>> class="org.apache.cxf.ws.security.tru > >>> st.STSClient">>>> > >>> <constructor-arg ref="cxf"/> > >>> <property name="onBehalfOf" > >>> > >>> ref="delegationCallbackHandler" /> > >>> > >>> > >>> The implementation of the intermediary service gets the > >>> BindingProvider and adds the username like this: > >>> > >>> BindingProvider.getRequestcontext().put(BindingProvider.USERNAME_PRO > >>> PERTY, "myuser) > >>> > >>> Has the request context the scope of the current thread or is it > >>> tight to the proxy instance. > >> > >> This is answered in the FAQ: > >> > >> http://cxf.apache.org/faq#FAQ-AreJAXWSclientproxiesthreadsafe%3F > >> > >>> If latter, an intermediary must create a new proxy per > >>> request. If the former, what is the scope of the STSClient instance? > >> > >> Per proxy. > > > > If your service implementation is using your proxy and the number of > > actively used configurations is small, you can pool (or cache) your > > proxy instances in your service so that you don't need to create a new > > proxy per call. > > > > For other cases where there is no choice and there is only one proxy > > instance, it would probably be nice if CXF can introduce an option to > > make the request/response context objects thread-local. But this may > > be more complicated and may have some adverse effect. > > I didn't see Dan's faq reference explaining that this thread-local > option is already provided. > so, please ignore my comment. > > regards, aki > > > regards, aki > > > >>> If > >>> there are several requests coming in, the proxy instance is global, > >>> the > >>> request context is correlated with the thread (assumption) it might > >>> not > >>> work because there is only one STSClient instance. > >> > >> The SecureConv and IssuedToken interceptors current "sync" on the > >> client > >> object to make sure this case works. It definitely can be a > >> performance issue though. > >> > >> > >> -- > >> Daniel Kulp > >> [email protected] > >> http://dankulp.com/blog > >> Talend - http://www.talend.com -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
