Well, one option may be to look into the http-client code and see if the SPNEGO stuff is easily pulled out into a org.apache.cxf.transport.http.HttpAuthSupplier thing. At one point, I did pull out the DIGEST stuff so digest auth is supported with CXF. I don't know anything about SPNEGO to know how easy/hard that would be to do. That said, you might want to just try enabling the DIGEST auth in CXF and see if that will work for you. There is a authSupplier thing on the conduit config that can be set to org.apache.cxf.transport.http.DigestAuthSupplier. Alternatively. just turn on the autoRedirect or maxRetransmits to > 1 and it may just work. :-)
Dan On Thu October 22 2009 3:22:53 am Spam wrote: > Hi all, > > I'm digging into including SPNEGO support for the web services (based on > CXF 2.2.4) I'm implementing. > > On server side, using 'Servlet Transport > <http://cxf.apache.org/docs/servlet-transport.html>', it shouldn't be an > issue since handling of (SPNEGO) authentication is performed by Tomcat. > On client side, I can successfully authenticate myself to Tomcat using > Commons HTTP Client 4.x (with some tweaking around 'Custom > authentication scheme'). > So I plan to use something like a 'Commons HTTP Client Transport' for > CXF, which sounds good from my newbies mind. > > Reading JIRA, and your mail, I'm a bit disappointed since 'Commons HTTP > Client Transport' is far to be a reality. > > Do you have some hints about a way to support SPNEGO for web services > based on CXF (at least for client side, i.e. 'Client HTTP Transport' > <http://cxf.apache.org/docs/client-http-transport-including-ssl-support.htm > l>)? > > Any help would be greatly appreciated. > Johann > > ---------- Forwarded message ---------- > From: *Daniel Kulp* <dk...@apache.org <mailto:dk...@apache.org>> > Date: Mon, Oct 5, 2009 at 11:13 PM > Subject: Re: Commons http client support? > To: users@cxf.apache.org <mailto:users@cxf.apache.org> > Cc: Kevin Priebe <ke...@realtyserver.com <mailto:ke...@realtyserver.com>> > > > > I'm definitely not sure what would be causing that sort of timeout. > Strange. > > I did look a little into doing an http-client based conduit, but it's not > exactly an easy task. The API's are pretty much backwords from > HTTPUrlConnection which makes mapping it hard. Basically, the > URLConnection > gives you an OutputStream that you write to as need to. With http-client, > you provide an object that it calls with the Outputstream when IT wants you > to. Thus, we would need to do some fancy PhaseInterceptorChain > pause/resume/reenter things to get it to still stream. Either that or > just don't stream which is another option. > > HTTPs is another whole HUGE HUGE issue. Mapping all the CXF https > options onto http-client is not easy, and in some cases, not possible due > to missing stuff in http-client (although that investigation was against > http-client 3, not 4 so things have possibly changed). > > Anyway, from my personal perspective, it just hasn't been enough of a > priority > to really start it. The customers I have dealt with haven't really hit > any issues with the current conduit to justify the amount of work to do > this. > > That said, if I was to start the work, I'd really suggest a layered > approach of subclassing the current conduit and just invoke the > http-client stuff in the "known cases" where it would work well. Example: > allow the existing code > to handle https for now, only use http-conduit if streaming is turned off > anyway (no chunking), etc... Then expand out from there. > > Dan > > On Mon October 5 2009 1:01:09 pm Kevin Priebe wrote: > > Hi, > > > > > > > > I have been transitioning our users from our old XFire client to a new > > CXF client over the past few months. I have been getting a lot more > > calls lately about read timeouts (SOAPFaultException: Could not send > > Message. - caused by - SocketTimeoutException: Read timed out). Here are > > my observations: > > > > > > > > - The users were successfully using the XFire client, and as > > soon as they start using the CXF client, they seem to randomly get these > > errors. > > > - Reverting to the old XFire client works fine for these users > > with no problems > > > > - Both web services are on the same server, running in the same > > tomcat instance - no other changes were made > > > > - It affects Satellite Internet users more, but also happens to > > fast Cable Internet users > > > > - A ping to our server for a Satellite user was always less > > than 2 > > > seconds, which is far less than the read timeout > > > > - Read timeout is set to 30 seconds - all requests are simple > > and should be fast - less than 5 seconds for sure > > > > - I have increased the timeout to 60 seconds, but got the same > > behaviour - either it successfully connects within seconds, or never > > does. The timeout just seems to delay the error... > > > > - I have experienced this problem when connecting to the live > > server myself, but only 2-3 times in the last few months. > > > > > > > > XFire just seems a little more resilient to connection problems than CXF. > > Perhaps this is because it uses the Apache commons httpclient? > > > > > > > > Are there any plans to use the commons httpclient in CXF? I found > > this old > > > open issue https://issues.apache.org/jira/browse/CXF-291 which appears to > > have been forgotten. The description says it shouldn't be hard to > > integrate. I even started looking into doing it myself, but am not sure > > I have time. If anyone has any pointers or partial code, that would be > > helpful. > > > > > > > > Thank you for any help or insight as to why this might be happening > > and how > > > to fix it. If you need additional information, let me know. We are > > using a pretty basic setup with the tomcat CXF servlet and JaxWS. We are > > using the GZip feature, and the following client policy config: > > > > > > > > httpClientPolicy.setConnectionTimeout(30000); > > > > httpClientPolicy.setReceiveTimeout(30000); > > > > httpClientPolicy.setAllowChunking(true); > > > > httpClientPolicy.setAutoRedirect(true); > > > > httpClientPolicy.setMaxRetransmits(3); > > > > > > > > I have tried disabling GZip and changing all the above settings, with no > > luck. > > > > > > > > Kevin > > -- > Daniel Kulp > dk...@apache.org <mailto:dk...@apache.org> > http://www.dankulp.com/blog > -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
