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}DoubleItTransportIONABSTPor >>> t" createdFromAPI="true"> <jaxws:properties> >>> <entry key="ws-security.sts.client"> >>> <bean class="org.apache.cxf.ws.security.trust.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_PROPERTY, >>> "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 >> >
