On Monday, November 21, 2011 9:02:31 AM Oliver Wulff wrote: > 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), ...).
Well, if you holdon to at least one proxy, its not "as expensive" as the WSDLManager should hold on to the parsed/processed WSDL. There is still quite a bit of annotation handling and such happening though. Dan > 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 = > > > > (AddressingPrope > > rties)message > > > > .get("javax.xml.ws.addressing.context.outbound"); if (maps == null) { > > > > maps = > > (AddressingProp > > erties)message > > > > .get("ja > > vax.xml. > > ws.addre > > ssing.co > > ntext"); > > > > } > > 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}DoubleItTranspor > > >>> tION > > >>> 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 -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
